If you’re running an AVOD platform and your ad breaks feel clunky this is almost certainly why.
Server-side ad insertion stitches ads directly into the video stream before it ever reaches the viewer. From their end, it’s one continuous feed. No visible seam between the show and the commercial. Client-side does the opposite. The player on the device fetches and plays the ad separately whenever it hits a break point, which means two different systems are juggling playback in real time instead of one clean stream.
Think of it the way live TV broadcast worked for decades. The ad was already baked into the signal before it hit your television. Nobody’s device was deciding mid-stream whether to fetch a commercial. SSAI is the streaming version of that same idea.
For AVOD at any real scale, SSAI usually wins and it’s not close. Ad blockers mostly can’t touch it because there’s nothing for them to detect, the stream just looks like content. Buffering at ad breaks practically disappears. And on TVs and connected devices, where client-side ad SDKs are often half-baked or missing entirely, SSAI just works without you having to fight the hardware.
CSAI isn’t useless. It’s simpler to set up and gives you richer interactivity along with cleaner viewability data, since the ad request happens right there on the device. But you pay for that simplicity. Impressions leak straight through to ad blockers and the handoff between content and ad tends to feel like exactly what it is: two systems stitched together a little awkwardly. Most serious OTT operators run SSAI for the bulk of inventory and keep CSAI for interactive or web placements.
By the Flicknexs team. We build white-label OTT/VOD/IPTV streaming platforms, so this is written from hands-on streaming-platform experience.
If you monetize with advertising, the way you insert ads is not a back-office detail. It directly shapes how many impressions you can actually fill and bill. This guide compares server-side ad insertion against client-side insertion the way an operator weighs them by fill rate, blocker resistance, playback quality, device reach and the engineering cost of running each at scale.
What server-side ad insertion (SSAI) actually does
SSAI doesn’t add ads after the fact, it builds them into the actual file before anything plays, which is why there’s no seam by the time it reaches you.
Here’s the mechanic. Your encoder drops SCTE-35 markers into the stream at every spot an ad should go, little flags saying insert here, and when someone requests the stream an SSAI service reads those markers and assembles a manifest on the spot, HLS or DASH, weaving ad segments into the timeline right at those points so the player isn’t dealing with two separate things, just one stream, frame-aligned, same encoding profile the whole way through.
Kind of like a tailor finishing the alterations before you ever try the suit on, instead of pinning fabric while you stand there awkwardly in the fitting room mirror. One arrives done. With the other you can spot exactly where the needle went in if you look close enough.
Which is also why ad blockers basically can’t do anything here. There’s no separate request firing off, nothing hitting a different server that a blocker can intercept and kill. The ad is just sitting inside the manifest, same as every other piece of content around it, nothing flagging it as different.
And that’s really the whole story. The device never sees an “ad” as its own request and that one detail explains basically everything, the smoothness, why ad blockers are useless against it, why it holds up fine even on cheap TV hardware that can barely run a modern app. Same thing causes the downside though. Once it’s baked into the manifest you give up some of the flexibility you’d have on the client side and you don’t really get that back once the stream’s already assembled.
The mechanics in plain terms
- Ad decisioning: at break time the SSAI service calls your ad server, a VAST or VMAP endpoint, the exact same way a client-side request would. Nothing different here, it’s just happening one layer back from the viewer.
- Transcoding/conditioning:whatever creative comes back almost never matches your stream out of the box. The SSAI service has to transcode it to match your resolution, your bitrate ladder, your codec, otherwise you’d get a jarring resolution drop or a stutter the second the ad starts.
- Stitching: now the ad segments actually go into the manifest, dropped in right at the SCTE-35 cue points, either replacing slate or filling it. This is the step that turns two separate pieces of video into one stream the player can’t tell apart.
- Beaconing: the server fires the impression and quartile tracking beacons (often with help from the player for client-side viewability signals).
What client-side ad insertion (CSAI) does differently
With CSAI, the player ships with an ad SDK (an IMA-style SDK, for example). At a break, the player pauses content, calls the ad server itself, downloads the creative, plays it in a separate ad slot, fires the beacons, then resumes content. The content and the ads are two distinct playback sessions glued together by the SDK.
This is the older, simpler model and it’s still the default on the open web for a reason. You get the richest interactivity here. Clickthroughs, overlays, skippable countdowns, companion banners, all the stuff that’s genuinely hard to pull off once ads are baked into a stitched stream. Viewability and verification data comes out cleaner too, because the ad is actually running inside the player’s own context, where measurement vendors can watch it happen in real time instead of guessing.
Why CSAI struggles at OTT scale
The same separation that enables interactivity is also CSAI’s weakness. A separate ad request is trivially easy to spot, so ad blockers and privacy tooling drop a meaningful share of those calls. Those are lost impressions you can never bill.
On connected TVs and set-top boxes, ad SDK support is a mess. Inconsistent at best, missing entirely on a lot of cheaper devices. Every time the player has to switch from a content decoder to an ad decoder and back, that’s a real risk point, and it’s exactly where you get the buffering, the black frames, the audio glitches that make viewers want to throw the remote.
What actually happens on a real device is uglier than any spec sheet admits. A budget living-room box hits the ad break, the decoder hands off and the viewer’s just sitting there staring at a spinner for two or three seconds before anything even plays. Some of them don’t wait it out. They close the app and go watch something else.
SSAI vs CSAI: the head-to-head comparison
| Dimension | Server-side (SSAI) | Client-side (CSAI) |
|---|---|---|
| Ad-blocker resistance | Strong, ads are part of the stream | Weak, separate ad calls are easily blocked |
| Playback quality at breaks | Seamless, broadcast-grade | Prone to buffering/black frames |
| Device reach (CTV, STB, mobile) | Broad, no ad SDK needed on device | Limited by SDK availability |
| Interactivity (clickthrough, overlays, skippable) | Harder; needs player cooperation | Native and rich |
| Viewability & verification accuracy | Improving but historically weaker | Strong, runs in player context |
| Targeting granularity | Good with per-session manifests | Good; device has full first-party context |
| Engineering & ops cost | Higher, stitching, transcode, scaling | Lower, SDK does the work |
| Live/linear support | Excellent (built for it) | Workable but fragile at scale |
Which one actually boosts AVOD revenue?
Revenue from ad-supported video, at the most basic level, is filled impressions × eCPM. SSAI tends to lift the first number; CSAI can sometimes lift the second. Here’s how the trade-off plays out.
SSAI usually grows billable volume
Every impression a blocker eats is revenue that never existed. By delivering ads inside the content stream, SSAI recovers a large share of impressions that CSAI loses and it makes those impressions playable on the big-screen CTV inventory where ad budgets are concentrated. Seamless breaks also protect completion rates. Viewers who don’t get jarred by a buffering ad break are more likely to watch the whole pod and high video-completion rates are exactly what advertisers pay premiums for. For most AVOD and FAST operators, that combination (more impressions, on more devices, completed more often) is the bigger lever.
CSAI can earn richer dollars on the inventory it keeps
Where CSAI works (web and mobile-app environments with healthy SDK support and lower blocker rates), it delivers better measurement and interactivity. Buyers pay more when they trust viewability numbers and can run interactive or shoppable units. So on a per-impression basis, CSAI inventory can command a higher eCPM. It just has fewer impressions to sell.
The honest answer: most operators run a hybrid
There is no single universally-correct choice and anyone quoting a precise “SSAI lifts revenue by X%” figure is usually overstating their certainty. The real number depends entirely on your device mix, blocker exposure and demand sources. In practice, mature platforms use SSAI for live, linear/FAST, and the bulk of CTV VOD inventory, while using CSAI (or a client-stitched hybrid) for web and interactive placements. If you’re building an ad-supported business across SVOD, AVOD and TVOD tiers, plan your insertion strategy alongside your broader monetization mix. See our hybrid monetization guide for how ads, subscriptions and pay-per-view fit together.
Implementation realities operators underestimate
SCTE-35 and clean cue points
SSAI is only as good as its markers, full stop. Your encoder or transcoder has to emit clean, reliable SCTE-35 signalling, because that’s the only thing telling the stitcher exactly where a break starts and where it ends. Get sloppy with cue points and you end up with ads overlapping each other, content getting clipped mid-scene or breaks that just never trigger at all. None of those are subtle bugs either. They’re far more visible to a viewer than a slightly weaker eCPM will ever be to you. And the first time a break chops off the last two seconds of a scene right before the punchline, you’re not finding out from a dashboard. You’re finding out from someone furious in your reviews.
Creative transcoding and the bitrate ladder
For a break to look seamless, ad creatives have to be conditioned to match every rung of your adaptive bitrate ladder and the content codec. That’s real compute and storage and it’s why SSAI carries higher infrastructure cost. Caching conditioned creatives is essential once you’re at any kind of scale.
Tracking and viewability under SSAI
Because the device isn’t making the ad call, you have to deliberately wire up impression and quartile beacons and pass client signals (player state, viewability) back so measurement vendors can verify. The IAB Tech Lab’s VAST and the open ad-insertion specs document the patterns here; following them closely is what keeps demand partners comfortable. See the IAB Tech Lab VAST standard for the canonical tracking event model.
Personalized manifests and CDN scale
Per-session manifests mean your CDN and origin have to handle a unique stream per viewer at break time. This is solvable (it’s how every large SSAI deployment works), but it changes your caching strategy and load profile versus a generic stream. The HLS and DASH delivery specs underpin all of this; the Apple HLS documentation is a good primary reference for the manifest behavior SSAI manipulates.
How to decide for your platform
- Look at your device mix. Heavy CTV/STB/IPTV audience, and SSAI is close to mandatory. Mostly web/mobile-web, and CSAI is viable.
- Estimate your blocker exposure. The higher your blocked-impression rate on CSAI, the stronger the SSAI revenue case.
- Check your content type. Live and linear/FAST channels strongly favor SSAI. On-demand catalog is flexible.
- Weigh interactivity needs. If shoppable or interactive ads are core to your pitch, keep a CSAI path for those units.
- Budget the engineering. SSAI needs stitching, transcoding, beacon wiring, and CDN tuning. A managed OTT platform absorbs most of this for you.
If you’d rather not build the stitching, SCTE-35 handling and ad-server integration yourself, that’s exactly the kind of plumbing a white-label platform handles out of the box. Explore the Flicknexs OTT platform to see how SSAI-ready AVOD monetization can be configured rather than coded.
Frequently asked questions
Related guides
- Video Monetization Models Explained: SVOD, AVOD, TVOD, PPV & Hybrid (hub)
- How to Launch a FAST Channel in 2026: Step-by-Step Setup & Distribution
- Hybrid Monetization: Combining Subscriptions, Ads & Pay-Per-View Profitably
Planning your own platform? Learn how to create your own OTT platform with Flicknexs — VOD, live, DRM, multi-device apps and hybrid monetization.
Leave a Reply