Connected TV in Your DSP or SSP: What Changes and What to Build Yourself

Connected TV (CTV) ads are video ads that play on internet-connected TVs, usually in a break of several ads inside a streaming app. A DSP or SSP built for web and app banners has to change in four places to handle them. The bid request describes a whole ad break instead of one ad slot. The ad arrives as a VAST response, an XML document that points to the video files. Many TV apps cannot request and track ads the way a browser does, so a stitching service puts the ad into the stream. That service then sends the ad requests, and often the tracking calls too, on the TV's behalf, so you have to identify devices and count impressions differently. Bidding on ad breaks and VAST support are worth building into your own platform. The stitching belongs to the publisher or to a service built for that job.

What is different about connected TV ads?

On a website, an ad request usually asks for one ad for one slot, and the browser loads that ad and reports the impression. On a TV, the viewer watches a show in a streaming app, and the ads come in breaks, as on broadcast TV. IAB Tech Lab, the body that maintains the OpenRTB bidding protocol, calls such a break an ad pod: one or more ads that “play out contiguously within a stream of video or audio content”.

IAB Tech Lab's OpenRTB 2.6 specification describes version 2.6 as the one that “Introduces Ad Pods for CTV transactions”. This article draws on that specification and on IAB Tech Lab's implementation notes for it, read on 2 November 2026 like the other sources here.

How does an ad break arrive in a bid request?

In OpenRTB 2.6, a break arrives as one or more impression objects in the bid request, and impression objects that share the same podid belong to the same break. The implementation notes describe three kinds of break:

• Structured: the seller fixes the number of slots, their order and the length of each in advance, and each slot is its own impression object
• Dynamic: the seller fixes the total length and the maximum number of ads but not the number or length of each ad, and the whole break can arrive as a single impression object
• Hybrid: part of the break is fixed and part is dynamic

Most banner platforms have never had to read the following fields:

• poddur, the total number of seconds advertisers may fill in a dynamic break, and maxseq, the largest number of ads it may hold
• rqddurs, a list of exact ad lengths. The specification says it is meant for live TV, “where non-exact ad durations would result in undesirable ‘dead air’”
• slotinpod, which says whether the seller can guarantee the first or last slot, and podseq, the position of the break in the show
• mincpmpersec, a price floor per second of ad time for the dynamic part of a break

Each bid states the length of its ad in the dur field. The implementation notes also say that buyers “should expect that final pod construction is done by the seller”. If you send several bids for one break, the seller may use any number of them, from none to all, and mix them with other buyers' ads.

Send the advertiser's domain (adomain) and the creative's ID (crid) with every bid. The specification lists both among the attributes used “for ad quality checks or enforcing publisher restrictions”.

For a DSP, ad breaks change the bidding logic. A banner bidder prices one impression at a time. A CTV bidder has to choose which of its ads fit the time left in the break and price them per second, and it cannot control which of them the seller keeps.

What does the VAST response have to include?

Video ads are delivered with VAST, which IAB Tech Lab describes as “a universal XML schema for serving ads to digital video players”. Its VAST page, last updated in July 2024, lists VAST 4.3 from December 2022 as the newest version. IAB Tech Lab's VAST 4.x repository on GitHub also holds VAST 4.4, which a maintainer's note there describes as released on 22 July 2026. VAST 4.4 adds CTV formats such as pause and screensaver ads. The quotations below come from VAST 4.3.

In July 2024, IAB Tech Lab also published a CTV addendum that brings the creative ID and the mezzanine file of VAST 4 to the older VAST 2 and 3. The addendum says that these earlier versions “still dominate the market today”.

Two parts of VAST matter most on TV:

• A mezzanine file, “the raw high-quality video file” from which the publisher's systems make a version for each screen. VAST 4.3 says a mezzanine file “is required in ad-stitched executions”, and that a stitching service may reject a response without one
• A UniversalAdId, an identifier that stays with the creative from system to system. VAST 4.3 requires it for linear ads, the kind that play inside the show, and the addendum adds it to VAST 2 and 3 as an extension. Stitching services use it to tell whether they have already converted a creative

In the stitching process that VAST 4.3 describes, a creative the service has never seen has to be converted before it can play, so the break plays another ad in its place. VAST 4.3 notes that the first download of a mezzanine file “may take several hours”. AWS describes the same rule for MediaTailor, its cloud service that stitches ads into streams: “If an ad hasn't yet been transcoded to match the content, MediaTailor will skip inserting it”, and the ad is prepared for the next request.

A new creative can therefore miss its first chances to play on each stitching service. VAST 4.3 says a creative that is changed in any way should get a new identifier. Do not change the identifier while the creative itself is unchanged, so that each stitching service converts it only once.

For verification code, VAST 4.3 recommends Open Measurement (OMID) and “strongly against using VPAID”, the older way of running code inside a video ad. It names SIMID as VPAID's replacement for interactive ads. VAST 4.3 keeps interactive code apart from the video file so that players working with a stitching service can still play the video when they cannot run the code. Make sure every TV creative works as a plain video.

What changes when a server stitches the ad into the stream?

Many TV apps cannot request and track ads the way a browser does. VAST 4.3 describes the alternative, called server-side ad insertion (SSAI) or ad stitching. The app asks a stitching service for the stream, the service asks the ad server for ads, and the ads are stitched into the content so that the viewer gets “one continuous stream”.

OpenRTB 2.6 adds an ssai field to the impression object to say how much of the stitching and tracking happens on a server. Its values run from “all client-side” to “all server-side”. In the middle case, the video is stitched on the server and the tracking pixels are fired by the device. The default value, 0, means the status is unknown, so a request without the field tells you nothing either way.

When the ad requests and the tracking calls come from a server, many viewers seem to share one IP address. VAST 4.3 warns: “To an ad server that is receiving tracking information, the reports look similar to invalid traffic.” It says stitching providers must send the device's IP address and user agent in two headers, X-Device-IP and X-Device-User-Agent, with their tracking requests, and that these values must match the ones in the original ad request.

For your platform, this means:

• When traffic comes through a stitching service, take the device's details from these headers and from the bid request. The IP address that connects to you then belongs to the stitching service, so do not use it for the device
• Ask the seller about any server-side traffic that arrives without the X-Device headers
• Check that the seller is listed in the publisher's app-ads.txt file. IAB Tech Lab's specification extends ads.txt to apps from “connected television app stores”
• Base frequency caps and audiences on device IDs. VAST 4.3 notes that a stitching service “cannot access cookies”. In OpenRTB 2.6, the ifa field carries an advertising ID that is expected to come from the device's operating system, and the lmt field says when tracking must be limited

How are impressions counted and billed?

OpenRTB's implementation notes compare the ways of counting billable events. For audio and video they recommend the VAST impression event. The billing notice URL (burl), which works well for banners, is “Not recommended for audio/video”.

The notes also advise bidders to track the delay between the auction and the billing notice, because spend goals, frequency caps and pacing depend on it. In their table of reasonable delays, the row for audio or video with server-side stitching reads “Very Long or Unknown”.

With the exp field, the seller says in the request how many seconds may pass between the auction and the impression, and the buyer says in the bid how many seconds it is willing to wait. Both values are advisory. The notes warn bidders not to assume that a billing notice arriving after their bid's exp will go unbilled, because that is a matter for the contract with the exchange.

Server-side stitching has not changed the counting rules. VAST 4.3 quotes the IAB measurement guidelines developed with the Media Rating Council (MRC): “The Measurement Guidelines require ad counting to use a client-initiated approach”. The same passage allows counting on a server “as long as it is initiated based on client-side events and measurement assets”. It rejects counting that a server starts on its own, because that is “the furthest away from the user actually seeing the ad”. Ask each seller which event starts its impression count when a server stitches the ad.

What should you build yourself, and what do partners already handle?

Some parts of a CTV setup belong to the publisher or to services built for publishers. The stitching itself is one of them. MediaTailor, for example, sends the viewer's details to the ad decision server, receives the chosen ads in the ad server's response and stitches them into the stream. Converting video files into each publisher's format is part of the same job.

Other parts decide what your platform earns, and those are worth building yourself:

• For a DSP: choosing which ads fit a break and pricing them per second
• For a DSP: pacing budgets when billing notices arrive late
• For a DSP: serving creatives with a mezzanine file and a creative ID that changes only when the creative does, in the UniversalAdId element of VAST 4 or in the addendum's extension for VAST 2 and 3
• For an SSP: building each break from the bids of several buyers and applying the publisher's rules about which advertisers may appear
• For an SSP: passing the pod fields and the ssai value to every buyer
• For both: reading device details from the X-Device headers and filtering invalid server-side traffic
• For both: counting impressions in a way buyers and auditors accept

A DSP that only wants to test whether its advertisers want CTV can start with one or two SSPs that already sell CTV, and bid on structured breaks first. Ask those SSPs how much of their CTV supply comes as dynamic breaks, because the implementation notes encourage sellers to offer dynamic pods when possible. Live TV, with its exact ad lengths, can wait until the first campaigns show that advertisers want it.

Build everything in the list above when CTV becomes a lasting share of your revenue. The same applies if you make your own deals with TV publishers, or if a partner's way of handling breaks keeps deciding which of your bids run.

What should we ask a firm that adds CTV to our platform?

• Which OpenRTB 2.6 pod fields will the system read, and how does it choose ads for a dynamic break?
• How does the system price bids per second, and does it respect mincpmpersec?
• Which VAST versions will our creatives use, and where do the mezzanine files come from?
• Will our creatives carry registered UniversalAdIds, or the default value “unknown”?
• How does the system handle server-side traffic, and where does it take the device's IP address and user agent from?
• How are impressions counted for each seller?
• How is pacing kept accurate when billing notices arrive very late?
• Which partners will we test with first, and which features can wait?

Where does amBrain fit?

In AdTech, amBrain works on DSP development, real-time bidding platforms, and ad exchange engineering. Two of its service lines read: “amBrain builds supply-side platforms (SSP) for publishers.” and “amBrain builds ad servers: targeting, frequency capping and reporting.” RTBBidder is a demand-side platform amBrain built for a client.

amBrain has been building software since 2019. It works in three formats: full delivery, a dedicated team, or engineers embedded in your team. Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.”

This article is not a case study. Apart from naming RTBBidder, it describes no client work: it does not say that amBrain has added connected TV to any platform, and it gives no figures about RTBBidder and no amBrain prices or timelines. IAB Tech Lab and AWS are quoted from their own documents, and the article claims no relationship between amBrain and either of them. If amBrain is on your shortlist, ask it the same questions as any other firm.