CTV SSAI and ad serving: how VAST, VMAP and OpenRTB pod bidding fit together

In client-side ad insertion, the player fetches VAST, plays the ad file and fires the tracking pixels itself. In SSAI, a server does all three. That shift fixes playback and creates a measurement problem, because every request now comes from one server.

The imp.ssai values come from OpenRTB 2.6, where 0 means unknown (OpenRTB 2.6, Object: Imp). Buyers use them to decide how far to trust the impression signal, so send the true value.

The sequence below combines the stitching flow in VAST 4.4 with the long-form workflow Prebid Server documents (VAST 4.4, section 1.1.2; Prebid Server long-form video).

1. The app starts a session. It asks the SSAI service for a stream and passes device and consent data.
2. The stitcher finds the break. For live streams it reads a cue marker, often SCTE-35; for video on demand it reads a schedule such as VMAP.
3. It requests ads for the whole break. The request goes to the publisher ad server, which may call an exchange with an OpenRTB pod request.
4. Buyers bid per slot. The seller builds the pod from the bids and may mix buyers or take fewer bids than were sent.
5. VAST comes back. The response lists the ads in sequence, each with a creative ID and media files.
6. The stitcher conditions the creative. If it has a transcoded rendition for that creative ID, it uses it. If not, it starts a transcode from the mezzanine file and skips the ad for now.
7. It writes the ads into the manifest. HLS or DASH segments for the ads replace the break in the content.
8. Tracking fires. The server, or the app's SDK, sends impression and quartile beacons with the device's IP and user agent attached.

VAST 4.0 was released in January 2016, 4.1 in November 2018 and 4.2 in June 2019 (IAB Tech Lab VAST repository). From 4.3 the text moved to a separate repository, where 4.4 is the current version (VAST4.x repository). In OpenRTB requests, you declare which versions you accept with AdCOM protocol codes, such as 7 for VAST 4.0, 11 for VAST 4.1, 13 for 4.2 and 15 for 4.3 (AdCOM 1.0, Creative Subtypes).

Older tags still circulate. The VAST CTV Addendum 2024 adds non-breaking extensions so VAST 2 and 3 tags can carry a registered UniversalAdId, Open Measurement resources and a mezzanine file (VAST CTV Addendum 2024). A two-ad pod in VAST 4 looks like this, trimmed to the parts a stitcher reads:

VMAP 1.0 is an XML playlist that tells a player, or a stitcher, where ad breaks sit in a piece of content. Its schema notes that the current version is 1.0.1 (IAB VMAP repository, vmap.xsd). Each <AdBreak> has a required timeOffset, written as a time code, a percentage, "start" or "end", or a position such as #2. A breakType hint says whether the break takes linear, nonlinear or display ads, and an <AdSource> carries either inline VAST or an ad tag URI.

For video on demand, a VMAP document is a clean way to say "pre-roll, two mid-rolls, post-roll" once per title. Live streams rarely use it. There, the stitcher waits for cue markers in the stream, and AWS Elemental MediaTailor, for example, reads the duration of each break from those markers (MediaTailor ad insertion behaviour).

Pod bidding lets an exchange sell an ad break as a unit. OpenRTB 2.6 describes three shapes (OpenRTB implementation guide, section 7.6). A structured pod has fixed slots, each its own impression. A dynamic pod fixes only the total time and the maximum number of ads. A hybrid pod mixes both.

Field definitions are from OpenRTB 2.6 and AdCOM 1.0 (OpenRTB 2.6, Object: Video; AdCOM 1.0 lists). Here is a dynamic two-minute mid-roll in a live sports stream on a TV, with every request field the stitcher should fill. Identifiers and the user agent are placeholders.

startdelay -1 marks a generic mid-roll, plcmt 1 is instream and devicetype 3 is connected TV (AdCOM 1.0). A buyer answers with one bid per ad it wants in the break, each with its duration:

Check the floors yourself. With mincpmpersec of $0.50, a 30-second ad must bid at least $15.00 CPM and a 15-second ad at least $7.50. Both bids clear. The seller may still use one, both or neither, and may fill the other 75 seconds with other buyers (OpenRTB implementation guide, section 7.6). Floor tactics for pods, including duration floors, are covered in floor price strategy, and the full bid request in OpenRTB 2.6 explained.

Ad servers apply pod floors differently. Google Ad Manager applies floors on podded app traffic to the combined CPM of the pod, so single ads can report CPMs below the floor (Google Ad Manager Help, pricing rules).

When a stitcher fires every request from its own servers, the ad server sees thousands of impressions from one address. VAST notes that such traffic "look[s] similar to invalid traffic" (VAST 4.4, section 1.1.3). The fix is to forward the viewer's device details in headers, and to keep them identical to the ones in the original request.

VAST makes the first two headers mandatory for ad stitching providers and recommends X-Device-Referer, X-Device-Accept-Language and X-Device-Requested-With when available. Other client headers may travel with an X-Device- prefix. X-Forwarded-For is accepted for backward compatibility but deprecated (VAST 4.4, section 1.1.3). In OpenRTB, the same values go in device.ip, device.ua and, where available, the structured user agent device.sua.

Headers can be faked, so the OpenRTB guide adds a second layer. It recommends that a server sending impression notifications sign them with ads.cert Authenticated Connections, so recipients can check who sent them (OpenRTB implementation guide, section 7.8). For supply-chain checks on CTV apps, see SupplyChain object, ads.txt and sellers.json. Invalid traffic detection vendors are compared in ad fraud detection tools.

Measurement rules favour the device. VAST quotes the MRC video guidelines: ad counting must use a client-initiated approach, and server-initiated counting is not acceptable, though pass-through of client-side events to a server is (VAST 4.4, section 1.1.3). That is why imp.ssai 2, stitched ads with tracking fired by the device, is the stronger signal for buyers.

Many stitchers still beacon from the server. AWS Elemental MediaTailor defaults to server-side reporting. When the player requests an ad segment, the service sends start and quartile beacons to the ad server and redirects the player to the segment (MediaTailor server-side reporting). Because the beacon follows a real segment request, the event starts at the device, but the report itself comes from the server.

For billing, the OpenRTB guide names the VAST <Impression> event as the official billable signal for video. It discourages the billing notice URL, burl, for video and audio, and says win notices must never count impressions (OpenRTB implementation guide, section 7.8). Verification vendors load through <AdVerifications>, which most CTV players run only through an OM SDK integration. The vendors themselves are reviewed in CTV measurement companies.

A TV stream has its own bitrate ladder, codec and loudness. An ad that does not match looks and sounds wrong next to the show. So stitchers transcode each creative into the same renditions as the content, starting from the best source they can get.

That source is the mezzanine file. The IAB Tech Lab's guidelines recommend a .mov container with Apple ProRes and 10-bit colour where possible. Keep native resolution and frame rate, use PCM audio at 48 kHz and add no slate (IAB Tech Lab, Ad Format Guidelines for Digital Video and CTV). Standard linear lengths are 6, 15, 20 and 30 seconds, and transcoding may shift duration by no more than 1 second.

Transcoding takes time, so the first request for a new creative usually loses. VAST describes the flow: if the creative ID has never been seen, the stitcher extracts the mezzanine, starts the transcode, skips the ad and returns error code 407 (VAST 4.4, section 1.1.2). If the creative changes, it needs a new UniversalAdId, or the stitcher will keep playing the old rendition.

Duration fit is the other trap. MediaTailor's documentation gives two cases. A 70-second break offered two 40-second ads plays one ad and then the slate or content. A 30-second break offered only 40-second ads plays no ads at all (MediaTailor ad insertion behaviour). This is why live sellers use rqddurs and buyers should send the exact dur of the creative.

Prebid.js removed its adpod module in version 11.0, released on 12 March 2026, and its documentation now says long-form pods are no longer supported in Prebid.js (Prebid.org, Adpod module; Prebid.js 11.0.0). Prebid Server documents the server route. The SSAI server sends pod requirements to Prebid Server, which collects bids, translates categories for competitive separation and caches the creatives. It then returns key-values for the ad server, and the stitcher fetches the winning creatives from the cache (Prebid Server long-form video).

If you run Prebid Server yourself, the Prebid Server self-hosting guide covers deployment. The choice of CTV ad server, which decides most of this flow, is compared in CTV ad server options, and the FAST channel business in FAST channels advertising.

1. Sending ssai 0 when you know the answer. Buyers treat unknown as the weakest case. Send 2 or 3.
2. Forwarding the stitcher's own IP. Put the device IP in X-Device-IP and device.ip, never the server's.
3. Mismatched headers and payload. The headers must match the original request; mismatches look like fraud.
4. Reusing a creative ID after an edit. The stitcher serves the cached old version. Issue a new UniversalAdId.
5. No mezzanine file. Publishers that require one may drop the ad with error 406.
6. Bidding without dur. The seller cannot place the ad, or places it badly.
7. Ignoring rqddurs in live breaks. A 20-second ad in a break built from 15- and 30-second slots is rejected.
8. Counting win notices as impressions. In video, the VAST impression event is the billable signal.
9. Assuming every SSAI vendor beacons the same way. Ask whether events start at the device or the server, and test with your verification vendor.

The RTB architecture hub links the related pages on bid requests, latency and supply-chain checks.

1. IAB Tech Lab, VAST 4.4 specification, sections 1.1.2, 1.1.3, 1.2, 1.3, 1.9, 2.2, 3.3.1, 3.7.1, 3.9.2 (repository version, accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/VAST4.x/blob/main/4.4.md
2. IAB Tech Lab, VAST4.x repository and commit history (4.4 "considered released since July 22, 2026", commit of 8 September 2026). https://github.com/InteractiveAdvertisingBureau/VAST4.x
3. IAB Tech Lab, VAST repository README and release notes (VAST 4.0 to 4.2 dates). https://github.com/InteractiveAdvertisingBureau/vast
4. IAB Tech Lab, "VAST CTV Addendum 2024". https://github.com/InteractiveAdvertisingBureau/vast/blob/master/VAST%20CTV%20Addendum%202024.md
5. IAB, VMAP 1.0 repository and schema (vmap.xsd). https://github.com/InteractiveAdvertisingBureau/vmap
6. IAB Tech Lab, OpenRTB 2.6 specification, Objects Imp, Video, Content, Device, Bid (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
7. IAB Tech Lab, OpenRTB 2.x implementation guide, sections 7.6, 7.8 and 7.11 (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md
8. IAB Tech Lab, openrtb2.x releases, 2.6-202606 (11 June 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/releases
9. IAB Tech Lab, AdCOM 1.0, lists for creative subtypes, device types, slot position in pod and pod deduplication (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/main/AdCOM%20v1.0%20FINAL.md
10. IAB Tech Lab, "Ad Format Guidelines for Digital Video and CTV", v2.0 (repository updated 20 July 2026). https://github.com/InteractiveAdvertisingBureau/Ad-Format-Guidelines-for-Digital-Video-CTV/blob/main/v2.0.md