CTV ad serving is one of those technical topics where a surface-level understanding produces misconfigured campaigns, incorrect reporting, and misplaced blame when something goes wrong. A publisher who does not understand the decision chain cannot diagnose why a slot is unfilled. An advertiser who does not understand VAST wrapper mechanics cannot explain why their tracking pixels are not firing. An ad operations manager who does not understand how SSAI interacts with the ad server cannot configure latency budgets correctly. This guide walks the full technical path of a CTV ad impression — from the viewer pressing play through the creative appearing on screen and the beacons firing — using the LtvAdx ad server and SSAI engine as the operational reference.
Step one: content request and break detection
The process begins when a viewer opens a CTV app and requests video content. For Video on Demand (VOD), the player requests a master manifest file — an HLS .m3u8 or DASH .mpd — that describes the content stream. For live or FAST linear content, the player requests the live manifest, which updates at a regular cadence (typically every 2–6 seconds for HLS) to describe the current and upcoming stream segments.
In an SSAI delivery path, the player does not request the manifest directly from the content origin. Instead, the app sends the manifest request to the LtvAdx SSAI endpoint, which forwards it to the origin, receives the content manifest, and begins the process of monitoring for ad break signals. For VOD content, the SSAI stitcher reads the VMAP document associated with the content to determine where breaks fall and how many slots each break contains. For live content, the stitcher monitors HLS EXT-X-DATERANGE tags or SCTE-35 signals embedded in the transport stream.
When a break signal is detected, the SSAI stitcher initiates the ad decision process. This happens ahead of the break — not at the moment the player reaches the break point — to allow time for ad auction, creative selection, and any necessary transcoding or packaging before the player needs to play the ad. For live content, SCTE-35 markers typically provide 3–8 seconds of advance notice before the break begins. For VOD, the stitcher can initiate ad calls earlier because the break timing is known at session start.
Step two: the ad decision request
With a break detected and the available duration known, the SSAI stitcher constructs an ad decision request to the LtvAdx ad server. This request carries the publisher's ad tag parameters: publisher ID, ad unit ID, break position (pre-roll, mid-roll, post-roll), pod slot count, minimum and maximum slot duration, and content metadata (genre, content rating, series, episode). The stitcher also passes device-level signals it received from the player when the session was initialized: device type, platform advertising ID, IP address, and any first-party identity data the app collected.
These signals form the context for the ad decision. The LtvAdx ad server processes them in sequence. First, it identifies the publisher and applies publisher-level settings: floor prices, competitive separation rules, content category restrictions, and demand source configuration. Second, it applies audience targeting: if the device resolves to a HouseholdID in the identity graph, the household is matched against active campaign audience requirements. Third, it evaluates deal priority: programmatic guaranteed deals are checked first, then private marketplace deals, then open auction demand, then house ads.
Step three: the programmatic auction
For programmatic inventory, the ad server constructs an OpenRTB bid request and broadcasts it to eligible demand sources — DSPs, ad networks, and direct API buyers configured for the publisher. The bid request carries all the context assembled in step two: device signals, content metadata, audience segments if HouseholdID is resolved, deal IDs for eligible PMP deals, and technical parameters (slot duration, aspect ratio, creative format requirements).
Demand sources have the configured timeout window — typically 100–200ms for CTV — to respond with a bid. The bid response contains: a CPM bid price, a deal ID if the bid is responding to a PMP or PG deal, the creative to be served (either inline VAST XML or a VAST redirect URL), and win notification and impression tracking URLs. Responses received after the timeout window are discarded.
The ad server runs a second-price auction among responding bids: the highest bid wins and pays the second-highest bid price plus one cent. The winning bid is selected for each pod slot sequentially, with competitive separation rules applied between slots: if slot one's winner is from an auto advertiser, slot two will not award to another auto advertiser if competitive separation is configured. The auction results in a ranked list of winning creatives for the pod, one per slot.
Step four: VAST resolution and creative validation
If the winning bid contains a VAST redirect URL rather than inline VAST XML — which is common when the winning creative is hosted by a third-party ad server — the LtvAdx system must resolve the redirect chain before stitching can proceed. VAST redirect resolution involves making HTTP GET requests to each wrapper URL in sequence until the inline VAST with the media file URL is reached. Each hop adds latency; the maximum wrapper depth is enforced to prevent runaway resolution chains from consuming the entire break timing budget.
Once the media file URL is obtained from the inline VAST, the SSAI stitcher validates the creative: confirms the media file is reachable via HTTPS, checks the declared duration against the slot duration parameter, verifies the codec and bitrate are compatible with the content manifest's technical parameters, and parses the tracking event URLs from the VAST for inclusion in the stitched manifest. Any creative that fails validation falls back to the next-ranked bid or, if all bids fail, to slate.
The creative validation step is where VAST 4.2 features add value. VAST 4.2's verification node — the <Verification> element — carries third-party brand safety and viewability measurement instructions that the player executes independently. The stitcher does not need to execute the verification script; it simply preserves the verification node in the stitched manifest so the player can execute it. This is how IAS, DoubleVerify, and similar vendors measure CTV impressions in SSAI environments.
Step five: manifest stitching
With validated creative media files for each pod slot, the SSAI stitcher assembles the stitched manifest. For HLS, this means inserting EXT-X-DISCONTINUITY markers at the boundaries between content segments and ad segments, appending the ad media segments to the playlist at the appropriate temporal position, and maintaining the correct sequence number and timing metadata so the player transitions seamlessly between content and ad content.
The tracking event URLs parsed from the VAST are converted into beacon insertion markers in the stitched manifest. For each tracking event — impression, start, firstQuartile, midpoint, thirdQuartile, complete — the stitcher embeds a timed metadata event in the manifest segment at the correct playback position. When the player reaches that position in the stream, it fires the tracking beacon URL. In this model, beacon firing is time-triggered by manifest position rather than player-event-triggered, which is why SSAI beacons are sometimes described as "stitcher-fired" rather than "player-fired."
The distinction between stitcher-fired and player-fired beacons matters for measurement accuracy. A stitcher-fired beacon confirms that the manifest reached the relevant playback position; a player-fired beacon confirms that the player actually rendered the content at that position. In environments where player states (background playback, screen-off detection) can't be guaranteed, player-fired beacons via client SDK integration are more reliable. The LtvAdx SSAI documentation describes both beacon modes and when each is appropriate.
Step six: delivery and win notification
The stitched manifest is delivered to the player. As the player progresses through the ad segments, the timed metadata events trigger beacon fires to the tracking URLs. The LtvAdx system records each beacon event in the impression log: publisher ID, advertiser ID, campaign ID, creative ID, event type, timestamp, device type, and HouseholdID if resolved. This log is the source of truth for delivery reporting in the reporting dashboard.
The winning DSP receives a win notification URL fire at impression time, informing it that its bid was selected and at what clearing price. Win notification timing is critical for budget management on the buyer side: if the win notification fires before the ad actually plays (which can happen if the stitcher fires it at stitch time rather than at playback time), the buyer's impression counter will exceed its budget before the ads have actually been viewed. Configure win notification to fire at VAST impression beacon time — first frame rendered — not at stitch time, to align buyer-side counting with publisher-side counting.
Step seven: post-impression signals
After the impression is delivered, several post-impression processes begin. The frequency counter for the winning campaign is incremented against the HouseholdID in the identity graph, so subsequent ad calls from any device in the same household will reflect the updated frequency count. The auction metadata — bid prices, timeout events, fill rate, winning CPM — is written to the publisher's analytics store for yield optimization analysis. Any attribution lookback window configured for the campaign begins: downstream conversion events that match the household IP or authenticated identifier will be attributed to this impression within the configured lookback period.
For the publisher, the end state of this process is a filled break with accurate delivery records and incremented revenue accounting. For the advertiser, it is a delivered impression with a VAST complete beacon (confirming playback completion), a win notification (confirming the auction outcome), and the start of the attribution lookback window. For the viewer, it is a seamless commercial break — indistinguishable from content at the manifest level — that played without interruption, buffering, or error.
Understanding this end-to-end process helps publishers diagnose fill rate issues (which step is the bottleneck?), helps advertisers debug tracking discrepancies (which beacon is not firing and why?), and helps ad operations teams configure timeout budgets and slate behavior that reflect the actual latency distribution of their demand stack. For detailed technical documentation of each step in the LtvAdx implementation, start with the integration guide and reference the SSAI integration documentation and VAST integration reference. For a live walkthrough of the ad serving flow with your specific inventory, request a platform demonstration.
