SSAI vs client-side ad insertion on CTV

Connected TV ads have to feel like television. A spinning buffer between the show and the commercial is how viewers learn to hate the app. Publishers solve that with server-side ad insertion (SSAI), also called stitching. The other method, client-side ad insertion (CSAI), leaves playback to the app, much like a video player on the web.

Both can be legitimate. They fail in different ways, and the bid request should say which one you are buying.

Client-side, in plain words

The app plays the program. At the break it pauses, calls an ad server, receives a VAST response, and plays the creative on the device. When the ad finishes, the program resumes. Beacons that count the impression can fire from the television or streaming stick, which is the same device the person is watching.

That is easy to measure and easier to debug. It is harder to make seamless on every television model. Low-end devices, live sports, and FAST channels often cannot afford a second player, a late creative, or a failed SDK.

Server-side, in plain words

A stitcher sits in the middle. It asks for ads, then builds one continuous stream: program, then commercial, then program. The television plays a single video. The viewer does not load a separate ad player, which is why SSAI is the default for live sports, broadcast-style FAST channels, and many premium streamers.

The cost shows up in measurement. The ad decision and the “impression” ping may happen on the server, not on the glass in the living room. If the stitcher fires beacons for streams nobody is watching, buyers pay for ads that never played. Good SSAI tells the buyer that stitching is in use, and whether tracking is server-side, client-side, or a hybrid.

What changes for the buyer

• Device signals. A server making the request can lose the television’s user agent, IP, or app identifiers unless the publisher forwards them on purpose.
• Invalid traffic. Server-side beacons are easier to separate from a real play. Ask whether a client event confirms the break.
• Privacy. Consent and US state strings still have to travel with the request. A stitcher that drops the GPP string is not “just a video feature.”
• Pods. SSAI is how most CTV ad pods are assembled. The pod rules live in OpenRTB; the stitcher is what plays them in order. See structured, dynamic, and hybrid pods.

What publishers should disclose

Say when SSAI is on. Say who counts the impression. Keep app-ads.txt, the supply chain, and the app bundle ID intact as the request moves from the app to the stitcher to the SSP. A clean stream with a blank identity is a stream buyers will stop buying.

IAB Europe’s 2026 programmatic CTV guidance makes the same point: stitching is welcome, silent measurement is not. Disclose the method, and preserve the device and app signals a buyer needs to validate the environment.

Which one to use

• CSAI when the device can run a player, you want client beacons, and a short handover will not ruin the show. Many on-demand apps can do this.
• SSAI when the content is live, the device is a dumb player, or the product promise is a broadcast-like break.
• Hybrid when the stream is stitched but a lightweight client event still confirms playback.

FAQ

Does SSAI stop ad blocking?

It stops blockers that look for a separate ad request. It does not, by itself, prove a human watched. Measurement still has to be honest.

Is SSAI the same as a CTV fraud problem?

No. SSAI is a delivery method. Fraud shows up when server-side events are counted without a matching play, or when the app identity is invented. The method just makes those checks more important.

Do I need a different OpenRTB integration?

You need video fields, pod support if you sell breaks, and an explicit SSAI signal so the DSP knows tracking may not come from the device. The auction is still OpenRTB.

← All posts · OpenRTB ad pods · What is CTV? · What is VAST?