CTV SSP vs ad server: what a mid-size publisher actually needs

The short answer

A supply-side platform connects your inventory to buyers. It takes an ad opportunity, packages it as a bid request, sends it to demand-side platforms and agency desks, collects the bids, runs the auction and returns the winning creative and its price. Its value is the demand it brings and the buyer relationships behind that demand. It is paid, in nearly every case, as a percentage of the media that clears through it.

An ad server decides what plays. It receives the break from the player or the stitching layer, works out how many slots it has and how long they run, applies your rules, asks one or more demand sources for candidates, assembles the pod, hands it to insertion and records what happened. Direct-sold campaigns live here. Frequency caps, competitive separation, category exclusions and floors are enforced here. It is the system of record for your delivery and the place your first-party data accumulates.

They are different jobs because they answer to different parties. The SSP works for the transaction: it exists to match a buyer to an impression. The ad server works for you: it decides whether that transaction should happen at all, at what priority, and next to what. Most SSPs contain some ad-serving logic and several ad servers contain an exchange, which is where the confusion comes from. What matters is which system holds the final decision and the data behind it.

Who needs what, by publisher size

The right stack tracks whether you sell directly and how many demand sources you run. Audience size matters less than people expect.

The layer to own

A mid-size publisher needs both. The question is which layer to invest in and which to treat as a utility, and the market has effectively answered it. Ad servers are where decisioning lives and where your first-party data ends up: every slot served, at what price, next to what, to which household, and how the viewer behaved. Changing ad server means moving that history and rebuilding those rules, which is why publishers do it rarely and carefully.

SSPs connect publishers to programmatic buyers, and their demand can overlap. Adding or removing one may involve certification, commercial approval, reporting changes and engineering work. Evaluate each source on incremental revenue after fees, latency and operational cost, rather than assuming every SSP is interchangeable.

The two layers have different switching costs. Choose the one with the high switching cost on its merits, and the ones with low switching costs on their results.

Podding, insertion, integration speed and fill

Podded ads and server-side insertion

A connected TV break is a pod of several ads in sequence, not a single slot. Pod bidding, where the request describes the whole break and the demand source returns candidates for it, is defined in OpenRTB 2.6. What to require from each vendor:

• From the SSP: OpenRTB 2.6 pod objects, including slot position and pod duration, and VAST 4.x creatives with the mezzanine file and creative identifiers that stitching needs. Ask how it handles a bid for a slot that has already been filled from another source.
• From the ad server: pod construction across all demand at once, fitted to the signalled break length; competitive separation within the pod; and manifest-level insertion that stitches exactly the pod the decision produced. Ask how it distinguishes a pre-fetched segment from a watched one, because that is where impression discrepancies come from.

Server-side insertion is not an SSP function. A vendor describing itself as an SSP with SSAI is bundling an ad server or a stitching layer, and it is worth knowing which one you are being sold and where the decision is made.

What makes an integration go live fast

Integration speed depends on the approved products, engineering scope and validation, not shared standards alone. Four technical checks help scope the work:

1. VAST 4.x on the creative side

   A shared VAST version is a starting point, not proof of compatibility. Validate required metadata, media files, wrappers, creative identifiers and tracking against the insertion layer; translation or creative conditioning may still be needed.

2. OpenRTB 2.6 on the request side

   Confirm support on both sides, including the exact pod fields and integration mode; support for an OpenRTB version alone does not establish interoperability. Field mapping or a custom adapter may still be required.

3. Manifest-level SSAI already in place

   With a compatible, validated integration, adding demand may stay behind the existing manifest endpoint. Player, insertion or tracking changes may still be required; confirm the scope before estimating the timeline.

4. A current ads.txt or app-ads.txt file

   Buyers will not bid on inventory they cannot authorise. Publishing the SSP's seller entries in your app-ads.txt is a small task that regularly delays first revenue by weeks when forgotten.

For an approved integration with a certified connection, validated creative handling and no player or insertion changes, days to a few weeks is an illustrative planning estimate for testing and traffic ramp, not a measured benchmark or delivery commitment. Obtain a scoped timeline covering commercial approval, engineering and certification from both providers.

What affects paid fill rate

Fill rate is the share of ad opportunities filled under a stated definition. Paid fill depends on eligible demand, inventory quality, geography, targeting, consent, floors, timeouts and pod construction. No SSP or ad server can guarantee paid fill on every break.

An ad server can compare eligible demand across sources and fit creatives to the available break. That can recover opportunities lost to poor pod construction, but adding SSPs does not guarantee incremental spend. A ninety-second break with one thirty-second paid ad may reflect a lack of eligible demand, not a software defect. House ads can cover unsold time, but they are not paid fill.

Floors belong in the ad server too, because a floor set inside one SSP only shapes that SSP's bids. Set them once, above all demand, and adjust from data.

A worked example stack

Here is what a mid-size streamer's stack commonly looks like once the layers are separated. The names are candidates to evaluate, not a list of certified GoGo CTV integrations. Some services combine roles; confirm inventory eligibility, commercial access and supported connection methods with each vendor.

An illustrative rollout sequence for an approved, compatible integration. The weeks below are planning examples, not measured benchmarks or delivery commitments:

1. Week one

   Point the player at the insertion layer for a test channel. Load direct campaigns and rules. Publish app-ads.txt entries for every SSP.

2. Week two

   Connect the first SSP over OpenRTB 2.6. Run in shadow, with the ad server deciding but nothing reaching a viewer, and compare fill, latency and pod fit against the current setup on the same requests.

3. Week three onwards

   Move live traffic across in slices. Add the remaining SSPs one at a time so the change in fill and yield can be attributed to each. Tune floors from the data.

An additional SSP can be a configuration task when a certified integration already exists. Otherwise, allow time for engineering, commercial approval and validation. Keeping decisioning in one place can reduce the scope of the change, but does not remove those dependencies.

When you do not need an independent ad server

If you are a very small publisher with one SSP, no direct sales, no sponsorships and no advertiser demanding pod rules, the SSP's built-in ad-serving features will do the job and an independent ad server is a cost you cannot yet justify. The signals that it is time to change are specific: a second demand source, your first direct deal, a buyer asking for competitive separation, or a reporting request the SSP's dashboard cannot answer.

Frequently asked

CTV SSP vs ad server: what do I actually need as a mid-size broadcaster?

Both. A mid-size broadcaster with a sales team and programmatic demand needs an ad server to hold direct-sold campaigns, build pods and enforce rules, and one or more SSPs to bring open-market and deal demand into that ad server. Retain control over decisioning and evaluate demand sources on their documented capabilities and results.

I need an SSP that supports podded CTV ads and server-side ad insertion. Any recommendations?

Evaluate demand partners on their documented compatibility with your ad server and insertion layer. Ask each partner which integration methods, OpenRTB versions and pod signals it supports, which VAST versions it returns, and how server-side tracking is validated. SSAI may be a separate service or part of a bundle; confirm which system performs insertion.

What are the best CTV ad servers and SSP stack for a publisher trying to boost fill rate?

Evaluate the stack on eligible demand, inventory quality, floors, latency and pod construction. An ad server that compares multiple sources can help use available demand more effectively, but additional SSPs do not guarantee higher paid fill. Test incremental revenue after fees, and report house ads separately from paid impressions.

I manage a streaming app. Which SSP integrates fastest with my CTV ad server?

Timing depends on commercial approval, a validated connection, creative handling and testing, not shared protocol versions alone. For an approved, certified integration needing no player or insertion changes, days to a few weeks is an illustrative planning estimate for testing and traffic ramp, not a benchmark or commitment. Obtain a scoped timeline from both providers.

CTV monetisation stack for a small streaming app: what tools do I need?

At minimum: a player that can signal ad breaks, an insertion method tested for smooth playback on your supported devices, one SSP for demand and an app-ads.txt file. A very small app with no direct sales can let the SSP's own ad-serving features handle decisioning. Add an independent ad server when you start selling directly, run more than one SSP or need pod rules enforced.

A checklist to take to vendors

Put these to every vendor in the evaluation, us included.

• Where is the final decision made? Which system chooses the ad for each slot when direct and programmatic both want it?
• Do you support OpenRTB 2.6 pod bidding and VAST 4.x? Which fields of the pod object are honoured?
• Who performs the insertion? Is it manifest-level, and does the system that decided the pod also stitch it?
• How do you count an impression in SSAI? Specifically, how is a pre-fetched segment distinguished from a watched one?
• Can I run more than one SSP behind you, and can I remove one without a migration?
• Can I export every decision and delivery event, and in what format?
• Are you paid a percentage of my media, a licence, or both?
• Will you run against a slice of my live traffic, side by side with my current stack, before I commit?

That last question is the one we most want to be asked. We shadow-test a slice of live inventory and show fill, latency and pod fit against whatever is running today, on the same requests, with nothing reaching a viewer. Ask us to set one up.

Related reading

• The GoGo CTV ad server, what it does and how it is measured
• A FreeWheel alternative, and when you actually need one
• A SpringServe alternative, for publishers whose ad server is owned by an SSP
• Server-side ad insertion, explained, including the beaconing problem
• The CTV monetisation glossary