SSAI Explained: How Server-Side Ad Insertion Works in CTV

Server-side ad insertion (SSAI) is the delivery infrastructure that makes CTV advertising work at television scale. Rather than loading ads as separate assets in the video player — the way web pre-roll works — SSAI stitches ad creative directly into the video stream on the server before the stream reaches the viewer's device. The player sees one continuous HLS or DASH manifest. It cannot distinguish content segments from ad segments. Ad blockers have nothing to intercept. Playback is seamless. This is why SSAI is the default ad delivery method for premium CTV apps, live sports streams, and FAST linear channels.

How SSAI works: the technical flow

When a viewer opens a CTV app and requests content, the app sends the manifest request to the SSAI endpoint rather than directly to the content origin. The SSAI stitcher forwards the request to the origin, receives the content manifest, and monitors it for ad break signals. For VOD content, break positions are defined in a VMAP document that specifies break timing and slot count. For live content, SCTE-35 cue tone markers embedded in the transport stream signal break start and duration.

When a break is detected, the stitcher calls the LtvAdx ad server with the available break duration, publisher parameters, and device signals. The ad server runs an auction, selects winning creatives for each slot, and returns VAST responses. The stitcher resolves any VAST wrapper redirects, validates the creative media files, and inserts the ad segments into the content manifest at the correct positions. Tracking event URLs from the VAST are embedded as timed metadata in the manifest so they fire at the correct playback offsets.

For a step-by-step walkthrough of the complete ad serving flow from break detection through beacon firing, see the end-to-end CTV ad serving guide.

SSAI vs CSAI: when to use each

Client-side ad insertion (CSAI) loads VAST ad assets in the video player at break time. The player pauses content playback, fires an ad call, loads the ad creative, plays it, and then resumes content. CSAI is simpler to implement and offers more flexibility for interactive overlays and companion ads, but it introduces latency at break boundaries, is vulnerable to ad blockers, and fails on restricted CTV SDKs that limit outbound network requests from the player layer.

SSAI eliminates all of these problems by moving the ad decision and stitching to the server. The trade-off is infrastructure complexity: the stitcher must handle manifest rewriting, beacon injection, and slate management at scale. For live sports and FAST linear channels where viewer experience and ad-block resistance are critical, SSAI is the correct choice. For VOD environments with permissive player SDKs and interactive ad requirements, CSAI remains viable. Most production CTV deployments run SSAI for live and linear content and evaluate CSAI only for specific VOD use cases.

SCTE-35 and live break detection

SCTE-35 is the broadcast standard for signaling commercial break opportunities in live video streams. A SCTE-35 spliceInsert or timeSignal command is embedded in the transport stream by the encoder operator when a break begins. The SSAI stitcher monitors the incoming live manifest for these markers and initiates the ad decision process immediately upon detection.

SCTE-35 markers carry the break duration, which determines how many ad slots the stitcher can fill. A 120-second break with 30-second slot maximum supports four slots. The stitcher requests creatives for all slots from the ad server, stitches the filled slots, and inserts slate for any unfilled positions. The return-from-break transition must be seamless — if the break ends before the last ad creative finishes, the stitcher either truncates the creative or compacts the pod to fit the available duration.

Tracking and measurement in SSAI

VAST defines tracking events that should fire at specific playback milestones: impression (first frame rendered), firstQuartile (25% complete), midpoint (50%), thirdQuartile (75%), and complete (100%). In SSAI, these beacons are fired by the stitcher at manifest-defined time offsets rather than by client-side JavaScript. This means a beacon fires when the manifest clock reaches the relevant position — not necessarily when the viewer's screen renders that frame.

This distinction matters for measurement accuracy. Stitcher-fired beacons confirm manifest delivery; player-fired beacons confirm actual rendering. For campaigns requiring verified viewability, client SDK integration that fires player-level events provides a more accurate signal. The VCR vs completion rate analysis covers the implications for benchmarking and reporting.

VAST 4.2 introduced verification node support, enabling third-party vendors like IAS and DoubleVerify to measure SSAI impressions without JavaScript. The stitcher preserves the verification node in the stitched manifest so the player can execute the vendor's measurement instructions independently of the SSAI infrastructure.

Slate and fallback management

When a pod slot does not fill — because no bid clears the floor price, the ad call times out, or creative validation fails — the SSAI stitcher must insert something to prevent dead air. Slate is the fallback: a house promo, a branded interstitial, or a blank screen with a timer. Configure slate at the pod level, not just the placement level, so every unfilled slot has a guaranteed fallback regardless of which position failed to fill.

Monitor unfilled slot rate by pod position and demand source in the LtvAdx reporting dashboard. A spike in late-pod unfill usually signals floor prices above market clearing rate at that daypart — not absent demand. Segment the analysis before cutting floors globally.

LtvAdx SSAI configuration

The LtvAdx SSAI engine supports HLS and DASH manifests for both live and VOD delivery. SCTE-35 break detection is active by default for live streams. VMAP break configuration is handled at asset ingest or session initialization for VOD. Pod templates — slot count, duration, slate assignment, competitive separation rules — are configured in the publisher portal without engineering involvement for routine changes. For implementation documentation covering manifest configuration, beacon setup, and device QA, start with the integration guide or request a walkthrough.

Frequently asked questions about SSAI