SSAI (server-side ad insertion) and CSAI (client-side ad insertion) are two fundamentally different approaches to delivering video ads on CTV. SSAI stitches the ad into the content stream at the server before it reaches the device — the TV app receives a single, seamless video manifest. CSAI pauses the content stream, requests an ad from the client device, plays it, then resumes content. The difference is not just technical: it determines beacon reliability, ad blocking resistance, viewer experience quality, and how much measurement data buyers can trust.
What is CSAI and why it was the original approach
Client-side ad insertion was the original way video ads were delivered — borrowed from web display advertising. The video player running on the device calls a VAST tag URL, receives an XML response pointing to an ad creative, fetches the MP4 file from a CDN, plays it, and fires impression and quartile beacons back to the ad server. All of this happens on the device itself.
CSAI works reasonably well on desktop browsers where the JavaScript runtime and HTTP stack are predictable. On CTV, it introduces three problems:
- Beacon failure rate: Native TV apps fire HTTP beacons from code running on constrained hardware. Network interruptions, app crashes mid-ad, and slow event firing all cause beacon loss. Industry estimates for CTV CSAI beacon failure range from 5–15% depending on device and network quality.
- Ad blocking exposure: A CSAI ad request comes from the device's IP and resolves to a known ad server domain. DNS-level ad blockers (Pi-hole, router-level blocking) and some smart TV firmware features can suppress these requests. Less prevalent in India than in Western markets, but growing.
- Buffering at ad transitions: When content pauses and the device fetches an ad creative from a different CDN origin, the buffer empties. The viewer experiences a loading spinner or black frame at every ad break. This is a significant viewer experience problem on slower connections.
What is SSAI and how manifest manipulation works
Server-side ad insertion removes the device from the ad delivery equation. When a viewer requests a video stream, the SSAI server (MediaTailor, Yospace, SpringServe, or a publisher's custom SSAI) intercepts the HLS or DASH manifest that describes the content segments. It makes an ad call to the programmatic stack, receives a winning creative URL, and rewrites the manifest to include the ad video segments in the correct position. The device receives a single, continuous manifest with no visible distinction between content and ads.
From the device's perspective, it is downloading one video stream. There is no separate ad fetch, no ad server domain in the network request, no buffering transition. The ad is already encoded and stitched before the segments arrive.
Beacon firing in SSAI is handled server-side. The SSAI system fires impression, quartile, complete, and error beacons from the server's reliable network connection — not from the device. This is why SSAI beacon reliability is substantially higher than CSAI.
SSAI vs CSAI: side-by-side comparison
| Dimension | CSAI | SSAI |
|---|---|---|
| Where ad stitching happens | On the device (player) | On the server (manifest rewrite) |
| Beacon firing | Device fires HTTP beacons | Server fires beacons |
| Typical beacon reliability | 85–95% | 95–99% |
| Ad blocking resistance | Low (device-level blocking possible) | High (no visible ad domain in manifest) |
| Buffering at ad break | Yes — fetch latency visible | No — seamless stream transition |
| Publisher infrastructure cost | Low | High (SSAI server, CDN re-encoding) |
| Third-party measurement access | Easier — device-level pixels possible | Harder — requires SSAI tracking URL passthrough |
| Creative format flexibility | Supports VPAID (though deprecated on CTV) | MP4/H.264 only — no JavaScript execution |
Why SSAI beacon reliability matters for measurement
Impression and completion beacons are how ad servers — and third-party measurement vendors — confirm that an ad played. A missed beacon means an impression that happened but was not counted. In CSAI environments, beacon loss of 5–15% is common on CTV. In an SSAI environment, the server fires beacons from a stable data centre connection, and loss rates drop to 1–5%.
For buyers, the difference is meaningful. A campaign with 5 million impressions planned has a reporting gap of 250,000–750,000 impressions in CSAI environments — impressions that played but were not billed or measured. Publishers operating CSAI tend to under-report delivery relative to actual viewership. SSAI environments report closer to true delivery.
The measurement implication cuts both ways. SSAI's server-side beacon firing makes it harder for third-party measurement vendors (IAS, DoubleVerify, Moat) to independently verify ad delivery because their JavaScript tags cannot run in a native SSAI stream. Publishers operating SSAI need to pass third-party verification URLs through the SSAI system explicitly. Not all SSAI implementations do this correctly.
Which approach India publishers use
India's major streaming platforms have moved toward SSAI for their premium long-form inventory, while CSAI remains common on smaller publishers and FAST channels:
- JioHotstar: Uses SSAI for IPL and premium long-form streams, particularly on CTV and Jio set-top boxes. CSAI still used on some mobile delivery paths. Their scale and infrastructure investment make SSAI viable.
- SonyLIV: Uses SpringServe as SSAI/ad server. SpringServe's manifest manipulation handles ad insertion for CTV inventory. Beacon reliability is high on SonyLIV premium inventory.
- Zee5: Uses a combination. PubMatic OpenWrap handles programmatic decisioning server-side; creative delivery involves SSAI stitching on CTV apps.
- FAST channels (regional and niche): Most use CSAI due to the infrastructure cost of SSAI. Buyers should expect higher beacon loss rates on FAST inventory.
- YouTube CTV: Technically SSAI — Google handles all ad insertion within the YouTube player at the server level. Buyers do not interact with insertion mechanics directly.
What buyers need to know
Understanding whether a publisher uses SSAI or CSAI affects how you interpret campaign data and configure third-party measurement:
- Ask publishers about their insertion method before running third-party measurement tags. SSAI requires publishers to pass your verification pixel URL through the SSAI manifest — this cannot be done by dropping a JavaScript tag.
- Do not compare completion rates across SSAI and CSAI publishers directly. SSAI publishers will show higher reported completion rates partly because beacon loss is lower — not necessarily because their audiences are more engaged.
- Expect higher VAST error rates on CSAI environments. Slow device networks, older firmware, and CDN latency cause creative fetch timeouts. Error code 301 (redirect timeout) and 303 (no ads available within timeout) are more common in CSAI.
- Creative pre-delivery matters more for SSAI. SSAI systems transcode and cache creatives ahead of the live ad break — especially critical for IPL. Creatives submitted late or in non-compliant formats cause null fills at break time, not just error logs.