A plain-language guide to server-side ad insertion (SSAI): how it stitches ads into the video stream, why it beats ad blockers, and why it works on every device.
What Is SSAI? Server-Side Ad Insertion Explained
By Sampath Mallidi, CEO of Revidd · Last updated June 2026
SSAI, or server-side ad insertion, is a method of stitching ads directly into a video stream on the server before it reaches the viewer's device. The ads become part of the same video file as the content, so they play back as one continuous stream. This makes ads harder to block, easier to play on legacy TVs, and more likely to fill. SSAI is the standard way broadcasters monetize FAST and AVOD.
If you run a FAST channel or an ad-supported library and your ads are not playing on some devices, are getting skipped by blockers, or leave black gaps when no ad fills, the cause is usually how the ads are inserted. This post explains what SSAI is, how it uses SCTE-35 markers, how it differs from client-side insertion, and why it matters for the money you make per stream.
TL;DR
SSAI stitches ads into the video stream on the server, so the ad and the content arrive as one file.
It relies on SCTE-35 markers in the stream to signal where each ad break starts and how long it runs.
Because the ad looks like content, ad blockers can't easily strip it, which protects fill rates and revenue.
It plays on every device, including older connected TVs and Roku boxes that handle client-side ads poorly.
The alternative, CSAI (client-side ad insertion), is more flexible for interactivity but weaker on blockers, playback, and legacy device support.
What does SSAI actually do?
SSAI takes the ad and the content and merges them into a single continuous video stream on the server, before delivery. Instead of the viewer's app pausing the content and fetching an ad separately, the ad is already part of the stream the device plays. The device never knows where the content ends and the ad begins.
Think of it as the difference between splicing two reels of film into one reel, versus stopping the projector to load a second reel mid-show. With SSAI, there is one reel. The ad frames sit between content frames in the same video manifest, encoded to match the content's resolution and bitrate ladder. To the player, it is all just video.
This is why SSAI is the default for linear-style streaming. A FAST channel runs 24/7 like a broadcast TV channel, and viewers expect ad breaks to play without buffering, freezing, or popping the resolution down. Server-side stitching delivers that because the ad is encoded and packaged like the show around it.
How does SSAI use SCTE-35 markers?
SSAI depends on SCTE-35 markers to know exactly when an ad break starts, how long it lasts, and when content resumes. These markers are signals embedded in the stream by the playout or encoding system. When the stitching server sees a marker, it requests an ad, transcodes or selects a matching creative, and splices it into the manifest at that precise frame.
SCTE-35 is the broadcast standard for signaling ad opportunities, carried over from cable TV into streaming. The Society of Cable Telecommunications Engineers defined it, and per Bitmovin's SCTE-35 guide, it remains the core industry standard for ad insertion and program control across both broadcast and streaming workflows. A marker tells the system "an ad slot opens here for 30 seconds," and the SSAI layer fills that slot.
In practice, the flow looks like this:
The playout system inserts a SCTE-35 marker at each ad break point.
The SSAI server reads the marker and calls an ad decision server using an IAB VAST tag.
The ad server returns a creative, which is transcoded to match the content's encoding ladder.
The SSAI layer stitches the ad into each viewer's manifest at the marked frame.
The viewer's device plays one continuous stream: content, ad, content.
If you want the underlying signaling explained on its own, our guide to SCTE-35 markers covers how the cue messages are structured and read.
Why does SSAI beat client-side ad blockers?
SSAI beats ad blockers because the ad is part of the same stream as the content, so there is no separate ad request for a blocker to intercept. Most ad blockers work by spotting and killing calls to known ad servers. With SSAI, the device only ever requests the video stream, and the ad is already inside it.
Client-side insertion (CSAI) works the opposite way: the player pauses the content and makes a separate call to an ad server. That separate call is exactly what blockers are built to catch. According to AdExchanger's explainer on server-side ad insertion, SSAI stitches ads into the stream before it loads on the device, which is why it is far harder to block than the client-side approach.
The revenue effect is direct. Industry estimates put ad-blocker losses on CSAI at roughly 15 to 30 percent of effective fill on audiences that use blockers heavily. Every blocked ad is an impression you served but cannot bill. SSAI closes most of that gap, which is why broadcasters running AVOD monetization lean on it. Higher fill on the same audience means higher revenue per stream, and a cleaner story to tell buyers about delivered impressions.
Monetizing a FAST channel or ad-supported library? Revidd's broadcast-grade playout includes SCTE-35 ad signaling, SSAI, and an ad filler playlist so breaks never leave a black gap. Book a demo to see ad insertion configured on a live channel.
Why does SSAI work on every device, including legacy CTV?
SSAI works on every device because the ad is delivered as plain video inside the stream, and every device that can play video can play it. There is no requirement for the player to support an ad SDK, parse VAST on the device, or handle a mid-stream ad call. That matters most on older connected TVs and streaming sticks where client-side ad logic is fragile or missing.
CSAI needs a capable player on the device. On a modern phone or a current Roku, that is fine. On a five-year-old smart TV, an older Roku model, or a low-end Android TV box, client-side ad handling can stutter, fail to load the ad, or crash the session. Since FAST and AVOD audiences skew toward the living-room TV, much of that audience sits on exactly these devices.
SSAI sidesteps the problem. The device plays a single HLS or DASH stream and never has to do anything special at the ad break. This is why SSAI is the practical choice for reaching the full connected-TV install base, not just the newest hardware. With Revidd, one integration covers native apps across Roku, Fire TV, Apple TV, Android TV, Samsung, LG, Vizio, iOS, Android, and web, and SSAI lets ad breaks behave the same way across all of them.
SSAI vs CSAI: how do they compare?
SSAI and CSAI both insert ads into streaming video, but they do it in different places and trade off differently. SSAI stitches ads on the server for resilience and playback quality. CSAI inserts ads in the player for flexibility and richer interactivity. For most broadcasters monetizing FAST and AVOD, SSAI wins on the factors that protect revenue.
Factor | SSAI (server-side) | CSAI (client-side) |
|---|---|---|
Where ads are inserted | On the server, into the stream | In the player, on the device |
Ad blocker resistance | High, no separate ad call to block | Low, blockers target the ad call |
Playback quality | Smooth, no buffering at the break | Can stutter or rebuffer at the break |
Legacy / older CTV support | Strong, plays as plain video | Weak, needs a capable player or SDK |
Fill rate impact | Higher, blockers can't strip ads | Lower on blocker-heavy audiences |
Interactivity (clickable, overlays) | Limited | Stronger |
Best fit | FAST, AVOD, linear, broad CTV reach | Web/app environments needing interactivity |
The short version: if ad-blocker resistance, clean playback on TVs, and broad device reach matter most, SSAI is the right default. CSAI earns its place where interactive ad formats are the priority and the audience sits on capable, modern devices.
What does SSAI mean for broadcasters monetizing FAST and AVOD?
For a broadcaster, SSAI is the difference between impressions you can bill and impressions that quietly leak away. It protects fill, keeps playback clean on the living-room devices where your audience actually watches, and gives ad buyers confidence that the impressions you report were really delivered. That is the foundation of an AVOD or FAST business that holds up to scrutiny.
It also keeps the operational picture simple. With SSAI tied to SCTE-35 markers in playout, ad breaks are scheduled as part of the channel, not bolted on per device. On Revidd, the playout configuration includes ad break duration, SCTE-35 signaling, and an ad filler playlist that plays when no paid ad is available, so a break never shows a black screen. That last detail matters: an empty break is a worse viewer experience than a filled one, and it signals an unsold inventory problem to anyone watching your channel.
If you are weighing ad-supported against subscription, or running a mix, the mechanics of SSAI feed directly into the bigger monetization decision. Our breakdown of the OTT business model walks through how AVOD, SVOD, and TVOD stack up for different broadcaster types.
The bottom line on SSAI
To recap what SSAI is: server-side ad insertion stitches ads into your video stream on the server, using SCTE-35 markers to mark each break, so ads play as part of the content on every device and survive ad blockers. For broadcasters monetizing FAST channels and ad-supported libraries, it is the method that protects fill rate, keeps playback clean across the connected-TV install base, and gives buyers a trustworthy impression count.
Revidd runs broadcast-grade playout with SCTE-35 ad signaling, server-side ad insertion, and ad filler built in, across native apps on every major device from one integration. We power on-demand, live, and FAST streaming reaching more than 38 million viewers across 15 countries, for faith networks, sports rights holders, regional stations, and diaspora channels. If you want ad-supported streaming that fills and plays cleanly without building the ad stack yourself, book a Revidd demo and we will show SSAI running on a live channel.
FAQ
What is SSAI in simple terms?
SSAI, or server-side ad insertion, means ads are merged into your video stream on the server before it reaches the viewer. The ad and the content arrive as one continuous file, so the ad plays like part of the show on any device.
What is the difference between SSAI and CSAI?
SSAI inserts ads on the server, stitched into the stream, which makes them resistant to ad blockers and smooth to play on any device. CSAI (client-side ad insertion) inserts ads in the player on the device, which allows more interactivity but is easier for blockers to strip and can stutter on older TVs.
Does SSAI stop ad blockers?
SSAI largely defeats common ad blockers because there is no separate ad request for the blocker to intercept. The ad is delivered inside the same video stream as the content, so the device only ever requests the video, not an ad URL a blocker would recognize.
How does SSAI use SCTE-35?
SSAI relies on SCTE-35 markers embedded in the stream to know exactly where each ad break begins, how long it lasts, and when content resumes. When the SSAI server sees a marker, it requests an ad, transcodes it to match the content, and splices it into the stream at that frame.
Why is SSAI better for FAST channels?
FAST channels run continuously like broadcast TV and reach a wide range of connected-TV devices, including older ones. SSAI plays the ad as plain video in a single stream, so breaks stay smooth and play everywhere, which protects both the viewer experience and ad fill rate.
Does SSAI work on Roku, Samsung, and LG TVs?
Yes. Because SSAI delivers the ad as part of the regular video stream, it plays on Roku, Samsung, LG, Vizio, Apple TV, Android TV, and mobile without needing a special ad SDK on the device. This is a key reason broadcasters choose it for broad device reach.
