SSAI vs CSAI: Server-Side and Client-Side Ad Insertion Compared

Every ad-supported streaming service has to answer one architectural question: does the player insert the ads, or does the server? Client-Side Ad Insertion (CSAI) and Server-Side Ad Insertion (SSAI) lead to very different systems, with sharp tradeoffs in ad-blocker resistance, tracking accuracy, and viewer experience. This post compares them end to end. For the signaling and ad-tag mechanics underneath both, see SCTE-35 and VAST; to inspect breaks and ad responses, use the SSAI tool and the VAST viewer.

CSAI: the player does it

In CSAI, the content plays normally until the player hits an ad cue. The player then:

1. Detects the ad opportunity (a cue point / marker, or a scheduled position).
2. Calls an ad decision server / ad tag — usually VAST or VMAP — to get creatives.
3. Pauses content, switches to an ad player (often a separate decode pipeline), and plays the ad creative.
4. Fires VAST tracking beacons (impression, quartiles, complete) directly.
5. Resumes content.

This is the model behind Google IMA SDK and most web pre-roll. It's straightforward to build and gives accurate, first-party tracking because the player knows exactly what played and when.

CSAI tradeoffs

• Ad-block vulnerable. Ad requests go to recognizable ad domains and can be blocked by extensions and DNS filters, killing revenue on web.
• Boundary buffering. Switching from the content pipeline to a separate ad pipeline (different codec/DRM context, a fresh buffer) often causes a visible stall or black frame at the ad transition.
• Client complexity / fragmentation. Every platform's player needs the ad logic, and behavior diverges across devices.

SSAI: the server does it

In SSAI (also called ad stitching), a service between origin and viewer splices ad segments directly into the media stream so the player sees one continuous timeline of content and ads in the same format.

Per session, the SSAI service:

1. Reads the content manifest and finds ad break markers (SCTE-35 → DATERANGE / CUE-OUT, or DASH ad periods).
2. Calls the ad decision server (VAST/VMAP) to fill each break.
3. Conditions the ad creatives — transcodes/packages them to match the content's rendition ladder, codecs, and segment duration.
4. Rewrites the manifest so ad segments appear inline and serves a per-session, personalized manifest.

Manifest stitching in practice

In HLS, the stitched playlist simply lists ad segments between markers, in the same EXTINF format as content:

#EXT-X-CUE-OUT:30.000
#EXT-X-DISCONTINUITY
#EXTINF:6.000,
https://cdn.example.com/ads/ad_0_0.ts
#EXTINF:6.000,
https://cdn.example.com/ads/ad_0_1.ts
...
#EXT-X-DISCONTINUITY
#EXT-X-CUE-IN
#EXTINF:6.000,
content_103.ts

The EXT-X-DISCONTINUITY tags tell the player the timestamp/encoding context changes across the splice. In DASH, each ad is typically a separate <Period>. Because the ad bytes are the same format and on the same CDN as content, the player can't distinguish them — the basis of SSAI's ad-block resistance.

SSAI tradeoffs

• Ad-block resistant. No recognizable ad domain, no separate ad request from the client to filter.
• Seamless playback. Same pipeline, same buffer — no codec/DRM context switch, so far fewer ad-boundary stalls (if conditioning is correct).
• Per-session manifest cost. Each viewer needs a personalized manifest; media segments can still be shared on the CDN, but manifest generation is real infrastructure.
• Tracking is hard (next section).
• Conditioning failures. If an ad isn't packaged to match the ladder exactly, you get glitches or a stall precisely where SSAI was supposed to be smooth.

The tracking problem

With CSAI the player fires VAST beacons because it knows when an ad starts and ends. With SSAI the player sees an undifferentiated timeline, so something else must beacon — and accuracy is the whole game for ad buyers:

• Server-side beaconing. The SSAI server fires events based on segment delivery. Simple, but delivery is not playback — it can't know the viewer paused, seeked, or dropped mid-ad, so quartiles overcount.
• Client-side beaconing via a tracking endpoint. The SSAI service exposes a tracking metadata API mapping timeline positions to VAST events; a client SDK fires them as playback actually crosses each position. More accurate, and what premium deployments converge on — but it requires SDK cooperation on every platform.
• In-band timed metadata. SSAI often injects ID3 (HLS) or emsg (DASH/CMAF) at ad boundaries so the client can detect "an ad started" at the right PTS and align beacons.

Inspect VAST tracking URLs and quartile events in the VAST viewer, and see how breaks surface on the timeline in the SSAI tool.

Choosing between them

• Web with heavy ad-blocking, or live linear/FAST channels → SSAI for revenue protection and seamless playback.
• Apps where you control the SDK and want precise tracking / interactive ads → CSAI (or HLS Interstitials as a hybrid).
• Hybrid: HLS Interstitials. Apple's interstitials point the player at a secondary ad asset at a timeline offset — SSAI-like UX with client-side, accurate tracking. Increasingly the pragmatic middle ground.

Rough QoE comparison

Illustrative, not measured:

• Ad-boundary stalls: SSAI lower (shared pipeline) vs CSAI higher (pipeline switch).
• Tracking accuracy: CSAI high (first-party) vs SSAI variable (depends on beaconing approach).
• Revenue resilience to ad-block: SSAI high vs CSAI low on web.
• Build/operate cost: SSAI higher (per-session manifests, conditioning) vs CSAI lower.

Takeaways

SSAI wins on ad-block resistance and playback smoothness but pays for it with per-session manifest infrastructure and a genuinely hard tracking pipeline; CSAI is simpler and tracks perfectly but is fragile to ad-blockers and stalls at the boundary. Most mature services end up with SSAI for live/FAST and a hybrid (interstitials or CSAI) where tracking precision and interactivity matter.