CSAI (Client-Side Ad Insertion)

CSAI stands for Client-Side Ad Insertion. It is an ad-serving method in which the video player, not the server, fetches and plays each ad. The CDN delivers one identical content stream to every viewer. Ad selection, ad playback and ad tracking all happen on the client. CSAI is the counterpart of SSAI (server-side ad insertion). In SSAI, an intermediary server stitches the ad into the stream before it reaches the player.

CSAI is not a streaming protocol. It is not a container format. It is not something the CDN performs. The ad exchange runs over HTTP between the player and an ad server, using the IAB's VAST XML response framework. The player does not re-mux ads into the content stream either. Instead, it plays each ad in a separate ad element on top of the content player, then resumes the content. In short, CSAI buys per-session targeting, interactive creatives and accurate client-side metrics. In exchange, it costs you ad-blocker losses plus a fetch-and-wait pause at every break.

How it works

1. The player fetches the same manifest and the same segments from the CDN as every other viewer. This holds whether the stream is HLS or DASH. Nothing in the content path is per-viewer.
2. Break positions travel with the content, not with the viewer. In live and linear workflows, the stream is decorated upstream with SCTE-104 markers. The encoder translates these into SCTE-35 markers carried with the compressed bitstream. The packager then exposes them in the manifest. In HLS, that is an EXT-X-DATERANGE tag. Its SCTE35-OUT and SCTE35-IN attributes carry the splice information, per RFC 8216 section 4.3.2.7.1. Break timing can also come from a VMAP playlist. VAST 4.3 defines VMAP as the framework that says where to place ads within the content.
3. When the player reaches a cue, it pauses the content. It uses HTTP to send the ad request. Per VAST 4.3 section 1.1.1, the request goes to the primary ad server, "which may be the publisher's ad server or a supply-side platform (SSP)".
4. The ad server responds with VAST. If it can fill the request, it sends an InLine response. Otherwise, it commonly redirects the player to a secondary server with a Wrapper response. The player follows that chain until an InLine response arrives. VAST 4.3 recommends that wrappers "should be limited to five before resulting in an InLine response". This is a recommendation to the player, not a hard protocol limit.
5. The player executes the VAST response. It downloads the creative and plays it in a separate ad element positioned over the content player. It fires impression and quartile tracking at key points during ad playback. This happens for the InLine response and for every Wrapper it followed.
6. One response may carry a single ad. It may carry an ad pod: several ads ordered by the sequence attribute, played in numerical order. Or it may carry non-sequenced stand-alone ads. The player may choose from these and use them as substitutes when a pod ad fails.
7. When the break finishes, the player resumes the content. It resumes from the point where it paused.

Why it matters for a CDN

CSAI is the cache-friendly option. That is why it suits CDN delivery. Every viewer requests the same manifest and the same segments, so the edge caches one copy and serves it to everyone. There is no per-user manifest to generate, store or revalidate. That keeps the cache hit ratio high. It also keeps the content pipeline a pure content problem: advertising does not change the shape of the content traffic. SSAI is the opposite trade. Its per-viewer stitched manifests "cannot be cached and shared amongst all the users".

The cost moves elsewhere. Ads are separate objects. The player pulls them from a different origin than the video, so ad delivery is a second, independent delivery problem. Fill rate and ad-start time depend on the ad server and the creative store, not on your content cache. A perfect content hit ratio does not stop an ad from stalling.

What CDNs do

The CSAI machinery lives in the player and in the ad SDKs a streaming service embeds. It does not live at the edge. A CDN's contribution is delivery. Three concrete jobs:

• Serve one shared copy of the content. Identical manifest and segments for every viewer, cached normally. No manifest manipulation happens in the path.
• Deliver the ad creatives as ordinary cacheable objects. Ad media has a hard delivery budget on the client. In the Google IMA HTML5 SDK, that budget is loadVideoTimeout, 8 seconds by default. If a media file takes longer than that, the ad is cancelled. The next ad in the pod plays instead. Slow creative delivery is lost inventory.
• Do not break CORS on the ad path. Because the VAST response comes from another server, VAST 4.3 requires ad servers to return Access-Control-Allow-Origin set to the value of the request's Origin header. It also requires Access-Control-Allow-Credentials: true. This lets a JavaScript player read the response, and cookies work. Where the Origin header is null, ad servers should send only Access-Control-Allow-Origin: * and no credentials header. If a CDN fronts your ad server or creative store, edge rules that strip, cache or blanket-wildcard those headers break ad playback.

The implementers of CSAI itself are player vendors. The Google IMA client-side SDK requests ads from any VAST-compliant ad server. It manages ad playback while the app keeps control of content playback. Bitmovin Player ships a CSAI advertising module with the IMA SDK pre-integrated on Web, iOS, tvOS and Android, but not Roku. Its VAST and VMAP support extends to Roku as well.

Watch out for

• Ad blocking cuts revenue. The player makes explicit calls to separate ad-server domains. Browser ad blockers find these easy to drop, so the viewer watches the content but the impression never counts. This is CSAI's biggest weakness against SSAI. With SSAI, ad blockers "are less effective at identifying and blocking stitched ads".
• A fetch-and-wait pause at every break. CSAI "starts with the player requesting an ad-server for an ad and then waiting for that ad to be delivered". This adds latency. Because the ad comes from a different origin, an ad server that is not well tuned makes the ad buffer.
• Client and device variance. Effectiveness depends on the capabilities of the client, so behaviour and performance differ across web, mobile and TV platforms. Features also vary by SDK. Bitmovin's table, for example, marks VPAID as supported on Web only. IMA media preloading is unavailable on mobile web on iOS, and it is unavailable with the HTML5 SDK on connected smart TVs.
• Quality mismatch at the edit. Ad inventory is not necessarily matched to the content's bitrates and resolutions, so viewers can see a visible jump in quality between content and ad.
• VPAID is deprecated. Older interactive ads executed a script inside the player. VAST 4.3 marks VPAID "Deprecated - VPAID is being phased out, to be replaced by OMID (for Verification) and SIMID for interactivity". Do not start new work on VPAID.
• Live and linear favour SSAI. A client-side pause-and-fetch at a live break is disruptive. Stitching ads directly into the stream is the usual way to avoid it.
• CSAI versus SSAI is no longer the only axis. Server-guided ad insertion keeps a shared, cacheable manifest while the client still fetches the ad. HLS Interstitials let servers schedule separate self-contained interstitial assets with EXT-X-DATERANGE tags. The client loads these by URI, with late binding as it buffers up to the scheduled time. Bitmovin lists SGAI as a third integration alongside CSAI and SSAI.

Best practice

• Choose CSAI when you need per-session ad control, interactive creatives and accurate client-side metrics. Choose SSAI when ad blocking is a real revenue risk, when device consistency matters more than control, or for live and linear mid-rolls.
• Know what your SDK actually preloads. The IMA HTML5 SDK always preloads the ad's VAST, regardless of settings. Preloading the ad media is opt-in via AdsRenderingSettings.enablePreloading. This loads only as much of the creative as the browser allows. With preloading on, the first ad of a mid-roll break loads 8 seconds before its start time. Do not assume the creative is fully buffered before playback.
• Serve ad creatives from a CDN so they are cacheable and arrive inside the player's media-load timeout. Cap the ad rendition the SDK picks too, so it matches the content's ABR ladder rather than jumping at the edit. IMA exposes AdsRenderingSettings.bitrate for this.
• Bound the wrapper chain and the error paths. Expect Wrapper redirects, and keep them near VAST's five-wrapper recommendation. Handle timeout and no-fill responses as normal cases, not failures.
• Measure latency, buffering, fill rate, error sources and ad completion rate per platform. Use an independent client-side tracker. Let that data drive the CSAI-versus-SSAI decision.
• If ad blocking is eroding fill rate but you want to keep client-side control, consider a documented hybrid. Brightcove, for example, delivers ads from the client, but automatically requests them from the server when the player detects an ad blocker. The trade-off is that those failover ads carry less session data.