Ad insertion is how most free and ad-supported streaming services generate revenue. The technical implementation — whether ads are stitched into the stream on the server or loaded separately by the player — has significant implications for viewer experience, ad blocker resistance, measurement accuracy, and engineering complexity.
SSAI (server-side ad insertion) and CSAI (client-side ad insertion) are not interchangeable. Each has engineering tradeoffs that affect every part of the video delivery pipeline from the ad decisioning call through CDN delivery to playback on the device.
How CSAI works
In client-side ad insertion, the player handles ad loading and playback directly.
- The player requests an ad decision from an ad server (via VAST/VMAP tags)
- The ad server returns ad creative URLs and tracking beacons
- The player pauses content playback, loads the ad creative, and plays it
- The player fires tracking beacons (impression, quartile, completion) to the ad server
- After the ad break, the player resumes content playback
The content stream and ad creatives are separate. The player manages the transition between them.
CSAI advantages
- Simpler server infrastructure. No ad stitching service required. The player handles everything.
- Dynamic ad loading. The player can make ad decisions in real time, adapting to viewer context, frequency caps, and targeting signals.
- Standard ad SDKs. Google IMA SDK, FreeWheel SDK, and other ad SDKs provide turnkey CSAI implementation with built-in VAST parsing, tracking, and error handling.
CSAI disadvantages
- Ad blockers. CSAI makes separate requests to ad server domains, which ad blockers can identify and block. On browser-based players (including smart TV web apps on Samsung Tizen and LG webOS), ad blocking is a real threat to revenue.
- Playback disruption. The transition from content to ad and back involves pausing the content player, initializing a separate ad player (or reusing the same player element), and then resuming content. This transition can cause buffering, black frames, or audio glitches on constrained devices.
- Device-specific ad SDK issues. Ad SDKs are primarily designed for mobile and web. On Roku (BrightScript) and native smart TV platforms, CSAI implementation is custom work without a standard SDK.
- Quality mismatch. Ad creatives may be encoded at different bitrates, resolutions, or codecs than the main content, causing visible quality shifts during ad breaks.
How SSAI works
In server-side ad insertion, ads are stitched into the content manifest on the server before the player receives it.
- The player requests the content manifest from the SSAI service
- The SSAI service makes ad decisions (via VAST/VMAP)
- The SSAI service creates a personalised manifest that includes ad segment URLs interleaved with content segment URLs
- The player receives a single continuous manifest and plays it without knowing which segments are ads
- The SSAI service handles tracking beacon firing (server-side) or returns tracking URLs for the player to fire (client-side tracking with server-side stitching)
From the player’s perspective, it is playing a single continuous stream. There is no separate ad player, no content pause/resume, and no visible transition.
SSAI advantages
- No ad blockers. Ad segments come from the same origin/CDN as content segments. There is no separate ad server request for the player to make, so ad blockers cannot distinguish ad segments from content segments.
- Seamless playback. No buffering gaps between content and ads. The player’s buffer spans the transition, so it feels like continuous content.
- Device-agnostic. The player does not need ad SDK support. If the device can play HLS or DASH, it can play SSAI content. This is a major advantage on connected TV platforms where ad SDK support varies.
- Consistent quality. The SSAI service can transcode ad creatives to match the content’s ABR ladder, codec, and segment format, eliminating quality mismatches.
SSAI disadvantages
- Infrastructure cost. SSAI requires a manifest manipulation service that runs per-session, per-viewer. At scale, this is a significant infrastructure cost.
- Ad creative conditioning. Ad creatives arrive in various formats and need to be transcoded and repackaged to match the content stream. This requires an ad conditioning pipeline.
- Measurement complexity. Because the player does not interact with the ad server directly, ad impression tracking needs a different approach. SSAI services typically fire server-side beacons, but some advertisers require client-side verification.
- Less dynamic. The manifest is built before playback starts (or at manifest request time). Changing ad decisions mid-stream (e.g., based on viewer engagement) requires more complex manifest manipulation.
Technical comparison
| Characteristic | CSAI | SSAI |
|---|---|---|
| Ad blocker resistance | Low | High |
| Playback continuity | Disrupted (pause/resume) | Seamless |
| Smart TV compatibility | Requires ad SDK per platform | Works with standard players |
| Infrastructure cost | Low (client-side) | High (per-session manifest) |
| Ad creative format flexibility | Limited (player must support) | High (server transcodes) |
| Tracking accuracy | Client fires beacons directly | Server fires or proxies beacons |
| Dynamic ad decisions | Real-time per break | Per-manifest or per-break |
| DRM interaction | Complex (separate ad/content DRM) | Simpler (unified stream) |
DRM and ad insertion interaction
DRM adds complexity to both approaches.
CSAI with DRM: the content stream is DRM-encrypted, but ad creatives typically are not. The player must handle the transition from encrypted content to clear ad and back to encrypted content. This means managing DRM session state across the gap. On some devices, closing and reopening the DRM session causes delay.
SSAI with DRM: the stitched manifest can include ad segments that are either clear (not encrypted) or encrypted with the same key as the content. Clear ad segments in an otherwise encrypted stream work on most players, but some DRM implementations require all segments in the manifest to be encrypted. Test this on your target device matrix.
For more on DRM implementation details, see our guide on content security and DRM practices.
Implementation on connected TV platforms
Roku
Roku has built-in support for Roku Advertising Framework (RAF), which provides CSAI with ad tracking and measurement. RAF is the most common ad insertion approach on Roku and integrates with major ad servers.
For SSAI, Roku’s video node plays the stitched manifest natively. No special ad framework is needed — the player sees a continuous stream. RAF also supports SSAI tracking event passthrough.
Samsung Tizen and LG webOS
On web-based TV platforms like Samsung Tizen and LG webOS, CSAI requires loading the Google IMA SDK (or equivalent) in the web app. IMA SDK support on smart TV browsers is functional but has quirks: the video element handling during ad-to-content transitions can cause blank frames on some model years.
SSAI is simpler on these platforms: the web player (Shaka Player, hls.js, dash.js) plays the stitched manifest like any other stream.
Google TV / Android TV
On Google TV and Android TV, both ExoPlayer (Media3) and IMA SDK have native Android implementations. CSAI integration is well-documented. SSAI works with ExoPlayer’s standard HLS and DASH support.
Hybrid approach
Many services in 2026 use a hybrid: SSAI for the main stream (especially on connected TVs where ad blocker resistance and seamless playback matter most) and CSAI for mobile and web where the IMA SDK is well-supported and infrastructure costs are lower.
The hybrid approach lets you optimise for each platform’s strengths while maintaining a unified ad decisioning and measurement pipeline on the backend.
Choosing for your service
Use SSAI when:
- Ad revenue is critical and ad blocker resistance is important
- Your device matrix includes smart TVs with limited ad SDK support
- Playback quality and seamlessness are top priorities
- You have the infrastructure budget for per-session manifest manipulation
Use CSAI when:
- Your primary platforms are mobile and web with strong ad SDK support
- You need maximum ad decisioning flexibility (real-time targeting, interactive ads)
- You want to minimise server-side infrastructure
- Your device matrix is limited and well-supported by ad SDKs
Use hybrid when:
- You have a broad device matrix that includes both smart TVs and mobile/web
- You want ad blocker resistance on TV but ad SDK flexibility on mobile
- You can invest in both SSAI infrastructure and CSAI integration
The ad insertion architecture affects revenue, viewer experience, and engineering effort in roughly equal measure. Align the choice with your business model and streaming app architecture from the start.