SSAI — server-side ad insertion — is the method by which ads are stitched into a video stream on a server before the stream reaches the viewer's device. The device receives a single, continuous video file that alternates between content and ads seamlessly; it cannot distinguish the ad from the content at the stream level. This is the dominant ad delivery method for premium CTV publishers globally, and for good reason: it eliminates ad blockers, improves beacon reliability, removes client-side latency, and produces a TV-like viewing experience with no buffering between content and ads.
SSAI vs CSAI: the core difference
The alternative to SSAI is CSAI — client-side ad insertion. In CSAI, the video player on the viewer's device handles ad requests and playback itself:
- The content stream pauses or leaves an ad break slot
- The device's video player sends a VAST request directly to the ad server
- The ad is fetched and played by the device's player
- The content resumes after the ad completes
The difference in where the work happens — server vs device — produces dramatically different outcomes for quality and reliability:
- Ad blockers: CSAI ad requests are made from the device and can be intercepted by network-level or app-level ad blockers. SSAI ad requests happen on the server; the device only sees a continuous video stream and has nothing to block.
- Buffering: In CSAI, the device must fetch the ad creative from a CDN mid-playback, often producing a buffering pause between content and ad. In SSAI, the ad is pre-fetched server-side before the break point, so the transition is instantaneous.
- Beacon reliability: CSAI beacons (quartile events, complete) are fired by the device. Unreliable device networks, app crashes, or background app suspension can cause beacon loss, inflating VAST error rates and understating VCR. SSAI fires beacons server-side — they are not affected by device-side connectivity fluctuations.
- Latency: CSAI adds 500ms–2s of ad-request latency at the point of the break. SSAI eliminates this because the ad decision happens before the break.
How SSAI works technically
The SSAI delivery sequence:
- Content manifest requested: The CTV app requests the video manifest (HLS or DASH) from the publisher's CDN or origin server.
- SSAI server intercepts: The manifest request is routed through the SSAI server (e.g., AWS Elemental MediaTailor, Google DAI, SpringServe, Yospace). The SSAI server knows the ad break schedule from the content's SCTE-35 markers embedded in the stream.
- Ad decision made server-side: Before the viewer reaches the break point, the SSAI server makes an ad request to the publisher's ad server (which runs the auction via SSPs and DSPs). The winning creative is fetched from the CDN.
- Stream stitched: The SSAI server inserts the ad video segment into the content stream at the break point. The resulting manifest delivered to the device shows a continuous sequence of video segments — content, then ad, then content — with no indication that a different source was used.
- Beacons fired server-side: As the stitched stream plays, the SSAI server tracks playback progress server-side and fires VAST event beacons (impression, quartile, complete) on behalf of the device.
Benefits for buyers and publishers
For publishers:
- Near-100% ad fill on premium breaks — the ad decision is made before the break, so there is no unfilled inventory gap visible to viewers
- Higher CPMs — SSAI inventory is verifiably premium, supporting higher floor prices and better programmatic yields
- Competitive separation enforcement — the SSAI server can enforce category exclusions and competitive separation (no two competing brands in the same pod) more reliably than CSAI
For buyers:
- Higher VCR — SSAI inventory consistently delivers 90–97% VCR; CSAI inventory averages 75–88% in India
- Accurate beacon data — quartile reporting on SSAI is reliable; CSAI beacon loss can understate completion by 5–10 percentage points
- Brand-safe environment — SSAI publishers have higher control over ad adjacency and content context
SSAI in India CTV
In India, SSAI adoption tracks publisher sophistication:
- JioHotstar: Full SSAI on CTV (smart TV, Fire TV, Apple TV). Uses Google DAI (Dynamic Ad Insertion) for its premium inventory. This is why JioHotstar CTV VCR benchmarks consistently come in at 93–97% — the ad delivery infrastructure is strong.
- SonyLIV: SSAI on CTV via a combination of internal ad stack and Magnite's SpringServe. Premium live sports (IPL equivalent content) uses SSAI; some long-tail on-demand content uses CSAI.
- Zee5: Mixed — SSAI on premium content tiers, CSAI on lower-tier VOD. VCR on Zee5 CTV varies more than JioHotstar as a result.
- FAST channels in India: Most India FAST channels (on Samsung TV Plus, LG Channels) use CSAI or hybrid SSAI. Full SSAI requires significant server infrastructure investment that smaller FAST operators have not yet made.
For buyers, the practical implication: ask the publisher directly whether the inventory is SSAI or CSAI. If they cannot answer, treat the VCR benchmark conservatively. When a publisher claims 95%+ VCR on CSAI inventory, verify with third-party measurement before accepting the number.