SSAI vs CSAI: Server- vs Client-Side Ad Insertion (2026)

Updated October 2026: new short answer and FAST-channel section, eyeo 2026 ad-blocking data, the 2026 DASH 6th edition and MediaTailor low-latency HLS interstitials, SCTE 35-2, and an SSAI invalid-traffic warning.

SSAI vs CSAI: the short answer

SSAI (server-side ad insertion) stitches the ad into the video stream on the server, so the viewer's player receives one continuous stream; CSAI (client-side ad insertion) has the player pause the show, call an ad server itself and play the ad in a separate ad player. That one difference decides everything else: SSAI resists ad-blockers and plays breaks without a stall on every device, while CSAI keeps precise client-side measurement and clickable, interactive ads.

• Use SSAI for connected TV, live and linear streams, FAST channels and any web audience where ad-blockers cost you impressions.
• Use CSAI for short VOD pre-rolls, interactive or shoppable units and performance campaigns that need a click, mostly on web and mobile.
• Watch the hybrid. Server-guided ad insertion (SGAI, delivered on Apple devices as HLS interstitials) lets the server decide and the player render; it reached the DASH standard in ISO/IEC 23009-1:2026 (6th edition, July 2026) and runs in production on AWS Elemental MediaTailor.

Why this matters

If you run, or are about to build, an ad-supported streaming service — advertising video on demand (AVOD), a free ad-supported streaming TV (FAST) channel, or any hybrid that shows ads — the CSAI-versus-SSAI choice quietly decides three things you care about: how much ad revenue actually reaches your books, how good the viewing experience feels at every commercial break, and how much engineering you sign up for. Get it wrong on the web and ad-blockers erase a chunk of your revenue; get it wrong on a TV and clumsy ad transitions train viewers to look away. Connected-TV (CTV) advertising in the US is projected at $29.3 billion in 2026, up 11% (IAB 2026 Digital Video Ad Spend & Strategy Report, May 2026) — so the plumbing that puts an ad into a stream is now a first-order revenue system, not a detail. This article is the builder's guide to that plumbing, and the companion to the OTT monetization map, which shows where ad revenue sits among all the ways a platform earns. Once you have settled the method and are choosing a stitcher, our guide to server-side ad insertion vendors, costs and build vs buy compares MediaTailor, Google DAI and the broadcast specialists.

The one distinction: where the ad meets the video

Every other difference in this article follows from a single question. When a viewer reaches a commercial break, who joins the ad to the show, and where?

In client-side ad insertion — CSAI, the method built into most web and mobile video players — the joining happens on the viewer's device. The app's video player has a small advertising component (an "ad SDK"). When the show reaches an ad cue, the player pauses the content, sends a request out to an ad server (the system that decides which ad to show and hands back the ad's video file), downloads that ad, plays it in a separate ad player, then switches back to the show. The ad is a distinct event the device fetches and plays on its own.

In server-side ad insertion — SSAI, the method that dominates connected-TV — the joining happens on the platform's servers, before the video reaches the device. A stitching service splices the ad's video segments into the content stream so that, by the time the player receives the stream, the ad is already part of it. The player just keeps playing; it never makes a separate ad call and often cannot tell where the show ends and the ad begins.

Here is the analogy to hold onto. CSAI is a TV that, at each break, stops the show and dials out to a sponsor to ask "what should I play now?" — quick when the line is clear, awkward when it isn't, and easy for someone to cut the phone line. SSAI is the old broadcast model: the ads are spliced into the reel at the station, so the same continuous tape plays the show and the ads with no dialing out at all. Everything below — ad-blocker resistance, playback smoothness, measurement difficulty, build cost — is a consequence of that one choice of where the splice happens.

Figure 1. The one distinction. In CSAI the device calls the ad server itself and plays the ad separately; in SSAI a server-side stitcher bakes the ad into the same stream the player already trusts.

How CSAI works, step by step

Walk a single ad break in client-side insertion, because the mechanics explain both its strengths and its failure modes.

The player reaches an ad cue — a marker that says "a break goes here." The ad SDK builds a request and sends it to the ad server using a standard called VAST, short for Video Ad Serving Template — the XML format, maintained by the IAB Tech Lab, that an ad server uses to describe an ad to a player: where the video file is, what tracking to fire, what to do on a click (IAB Tech Lab VAST; current line VAST 4.3, December 2022, with the VAST CTV Addendum 2024). The ad server replies with a VAST document. The player reads it, downloads the ad creative, plays it in its ad player, and as the ad runs it fires tracking beacons — little web requests that report "the ad started," "25% watched," "50%," "complete" — back to the ad server and any measurement vendors. When the ad finishes, the player tears the ad player down and resumes the show.

That round trip is the source of CSAI's two real problems. First, it is a call the device makes to a known ad domain, so it is blockable. An ad-blocker is mostly a list of ad-server domains plus a rule: drop any request to them. Because CSAI's ad request goes from the viewer's browser to an ad server the blocker recognizes, the blocker simply cancels it, the player gets no ad, and the impression — and its revenue — never happens. Second, the round trip takes time at the worst possible moment. Between tearing down the content and having an ad buffered, the player must resolve the ad domain, complete the request, parse the VAST, fetch the creative, and fill its buffer. On a clean connection that is a beat; on a congested phone it is one to three seconds of spinner, or a timeout that shows a blank slate. Every break is a small chance to stall.

CSAI's strengths come from the same architecture. Because the ad runs in a real player on the device, it can be interactive and clickable — a "tap to learn more" overlay, an expandable unit — through the interactive-ad standard that replaced the old VPAID, now SIMID (Secure Interactive Media Interface Definition). And because the device itself plays the ad, the client knows exactly what happened: precise viewability, exact completion, device and session signals, easy per-device frequency capping (limiting how many times one viewer sees the same ad). CSAI keeps the richest data and the most interactivity. It just pays for that with ad-blocker exposure and a stutter at every break.

How SSAI works, step by step

Server-side insertion moves the whole join to the platform. To do that it needs a new component the client side never had: a stitcher, also called a manifest manipulator.

Start with the manifest — the small text playlist that tells a video player which short video chunks to download and in what order. Modern streaming (covered in packaging: CMAF, HLS, and DASH) cuts video into segments of a few seconds and lists them in this manifest; the two manifest formats are HLS (Apple's, RFC 8216) and MPEG-DASH (ISO/IEC 23009-1). The player just fetches whatever segments the manifest names. The stitcher's trick is to rewrite that manifest so it lists ad segments alongside content segments. For the cross-section mechanics of those manifest formats, see HLS vs DASH in the Video Streaming section; here we care only about what the stitcher does to them.

The sequence is the same at every break. The live or VOD stream carries an in-stream ad marker — an SCTE-35 cue, the broadcast standard that signals "an ad break starts here, this long" (ANSI/SCTE 35, covered in depth in SCTE-35 and ad signaling). In 2026 SCTE split the standard in two: SCTE 35-1 keeps the classic splice- and time-based cues, and the new SCTE 35-2 (2026) adds a streamlined event-based descriptor for MPEG-TS, DASH and HLS, so new stitchers should plan to read both. The stitcher sees the cue and, for this viewer's session, calls the ad decision server with a VAST request — the same VAST standard CSAI uses, but now the server makes the call, not the device. The ad server returns the ad. The stitcher conditions the ad — transcodes it to match the exact resolutions and bitrates of the content's quality ladder, so it slots in without a jarring quality jump — and rewrites the manifest so the ad's segments appear in line with the content's, marked with a discontinuity tag (#EXT-X-DISCONTINUITY in HLS) that tells the player "the stream properties change here, keep playing." The player downloads ad segments exactly as it downloads content segments: same server, same format, same buffer.

Two consequences fall straight out of this design. Because the ad arrives from the same servers and in the same stream as the content, there is no separate call to a recognizable ad domain — so a network ad-blocker has nothing to cancel without blocking the whole video. And because the ad segments sit in the same buffer the player already fills for content, the transition is broadcast-smooth: no dial-out, no spinner, no slate. SSAI trades CSAI's stutter and ad-blocker exposure for a gap-free, blocker-resistant break. What it gives up — measurement and interactivity — we come to after the picture. For the stitcher internals on their own — ad conditioning, pod serving and session handling — see how an SSAI stitcher works inside in the Video Streaming section.

Figure 2. The SSAI stitching pipeline. An SCTE-35 cue triggers a VAST call to the ad decision server; the stitcher conditions the ad to match the content ladder and rewrites the manifest, so the player sees one continuous stream.

Why SSAI beats ad-blockers — the part nobody explains clearly

This is the question that sends most people to this topic, so it deserves a precise answer rather than the usual hand-wave that SSAI is "more resistant."

An ad-blocker is, at heart, a bouncer with a guest list of ad-server domains. It inspects the requests a device makes and drops any addressed to a name on the list. CSAI hands that bouncer an easy target: the player's ad request travels from the viewer's device to an ad server whose domain is almost certainly on the list, so the bouncer cancels it and no ad loads. The ad request is a separate, identifiable, client-originated call — exactly what blockers are built to catch.

SSAI removes the call entirely. There is no client-to-ad-server request to inspect, because the server made that request, out of the viewer's sight, when it built the stream. What the device downloads is a sequence of video segments from the platform's own content servers, in the same format and from the same domain as the show. To the blocker, an ad segment and a content segment are indistinguishable bytes from a trusted source; it cannot drop one without dropping the video the viewer came to watch. That is the whole mechanism: SSAI wins not by hiding the ad better, but by deleting the separate request that ad-blockers depend on.

The revenue at stake is not small, especially on the web, where blocking is heaviest. About 1.1 billion people — 30% of the internet population — used an ad-blocker in Q4 2025, and the growth is on phones: 629 million mobile blocking users (up 27% since 2023) against 448 million on desktop (down 4%) (eyeo 2026 Ad-Blocking Report, May 2026). So the "CSAI is fine on mobile" assumption no longer holds. On connected-TV the threat is different — most TVs do not run browser ad-blockers — but SSAI still wins there for the other reason: app-store TV players are a fragmented zoo of devices, and a server-side stitch gives every one of them the same smooth, SDK-free ad experience instead of asking each device's flaky ad SDK to behave. On the web SSAI defends revenue; on the TV it defends experience and consistency.

Figure 3. Why SSAI resists blockers. CSAI's separate call to a known ad domain is exactly what a blocker cancels; SSAI's ad segments are indistinguishable from content served by the same CDN, so there is no separate request to block.

The honest trade-off: what SSAI gives up

SSAI is not free wins. Moving the join to the server breaks the two things the client did effortlessly — measurement and interactivity — and adds a cost the client never had.

Measurement gets harder because the device is no longer the one calling the ad server. In CSAI the player fires every tracking beacon itself, so the ad server sees exactly what the viewer saw. In SSAI the stitcher is the natural place to fire beacons, but the stitcher is a server — it knows it sent ad bytes, not whether the screen was on, the app was foregrounded, or the viewer was even in the room. The industry fixed this deliberately: VAST 4.1 (2017) added explicit support for server-side ad insertion and aligned with the Open Measurement standard (OMID), the IAB Tech Lab framework that lets an approved measurement script run in the player and report real viewability even when the ad was stitched server-side (IAB Tech Lab VAST 4.1; Open Measurement SDK). Done right, SSAI plus OMID measures viewability properly; done lazily — beacons fired blindly from the stitcher — it over-counts impressions and an auditor will catch it. Measurement is solvable, but it is now your problem to solve.

Interactivity gets harder for the same reason: a stitched ad is just video in the stream, so the rich clickable units CSAI supports need extra wiring (a metadata side-channel the player listens to) to work at all. Many SSAI deployments simply accept non-interactive spots, which is fine for TV-style brand ads and weak for performance advertising that needs a click.

Frequency capping and personalization need session plumbing. The infamous SSAI symptom is the same ad five times in one break — the result of a stitcher that calls the ad server without passing enough about who this viewer is and what they have already seen. To target ads and cap repetition, the stitcher must thread a per-viewer session identity and history through to the ad decision server on every call. That is exactly what dynamic ad insertion (DAI) means: SSAI plus per-session targeting, where every viewer gets a personalized manifest. It works, but the per-session manifest is less cacheable than a single shared stream, which raises delivery cost — a real line item the OTT cost model has to carry.

And conditioning ads costs compute. Transcoding each ad to match every rung of the content ladder, for every campaign, is real transcode load — the price of the gap-free transition. None of these is a deal-breaker; together they are why SSAI is a build, not a checkbox.

Server-side beacons are also easier to fake. Because a stitcher, not the TV, reports the impression, fraudsters can spoof SSAI traffic from a data center. Pixalate measured invalid-traffic (IVT) rates 110% higher on SSAI than on non-SSAI CTV traffic, while 70% of CTV apps on Roku, Fire TV, Samsung and Apple TV used SSAI for open programmatic ads (Pixalate Q2 2024 SSAI benchmark). The defense is the one the VAST 4.x guidance already describes: forward the real device IP and user agent from the stitcher to the ad server (headers such as X-Forwarded-For and X-Device-User-Agent; VAST 4.1 grades the SSAI headers as must, should and may), authenticate server-to-server calls, and let OMID verification run on the client. AWS Elemental MediaTailor, for example, has authenticated its server-side requests to Google Ad Manager, Campaign Manager and DV360 automatically since May 2026.

Putting it side by side

The two approaches, and the hybrid we meet next, line up cleanly once the mechanism is clear. The table includes a "works without an ad-blocker problem?" column because that is the question most teams arrive with — but read every row, because the right answer depends on your surface (web, mobile, TV) and your goal (revenue defense, experience, interactivity).

Table 1. CSAI, SSAI, and the converging hybrid. No row makes one approach win outright; the choice follows your surface and your goal. The "beats ad-blockers?" column is the question most teams start with, but the measurement and interactivity rows are where SSAI projects pay their dues.

A worked example: what the choice is worth in revenue

Abstract trade-offs become decisions when you put money on them. Ad revenue follows one formula everywhere, so start there:

ad revenue = ad impressions × CPM ÷ 1000

CPM is cost per mille — what an advertiser pays per thousand times an ad is shown. Take a mid-size AVOD service and use round numbers:

viewers (monthly)          = 500,000
ad-supported hours each    = 15 / month
ad slots per hour          = 8            (e.g. 4 breaks × 2 ads)
ad opportunities (avails)  = 500,000 × 15 × 8 = 60,000,000 / month
fill rate                  = 70%          (share of avails an ad actually fills)
impressions                = 60,000,000 × 0.70 = 42,000,000 / month
CPM                        = $20
ad revenue                 = 42,000,000 ÷ 1000 × $20 = $840,000 / month

Now the part the insertion method decides. In client-side insertion, a share of those 42 million impressions never renders or never counts — ad-blockers cancel the call on the web, ad SDKs time out on weak phones, slow ad loads get abandoned. Assume a conservative 15% loss for an audience with meaningful web and mobile reach:

impressions lost to CSAI failure  = 42,000,000 × 0.15 = 6,300,000 / month
revenue lost                      = 6,300,000 ÷ 1000 × $20 = $126,000 / month
recovered by moving to SSAI       ≈ $126,000 / month  ≈ $1.5M / year

About $1.5 million a year, on the same audience and the same ad sales, recovered purely by deleting the blockable ad call and the lossy client-side fetch. That is the SSAI business case in one number — and the reason every AVOD and FAST operator at scale runs server-side. The inputs here are illustrative; plug your own audience mix, fill rate, and CPM in, but the shape holds: the more of your audience sits on ad-blocked web and flaky mobile, the more SSAI is worth.

There is a smaller, sharper version of the same argument in playback quality. A CSAI break spends one to three seconds dialing out and buffering the ad; an SSAI break spends roughly zero, because the ad is already in the buffer at the content's bitrate. Multiply a few seconds of risk across every break, every viewer, every day, and you are trading measurable startup and rebuffering pain — the quality metrics that predict whether viewers stay — for a smooth one. Revenue and retention point the same way.

Where it is heading: the hybrid that ends the either/or

The cleanest news in this topic is that the industry is converging on a third option that keeps SSAI's smoothness while handing back some of CSAI's measurement and control. Instead of physically splicing ad bytes into the content manifest, the server inserts a pointer — a marker that tells the player "at this point, go play the ad from this separate list" — and the player fetches and presents the ad itself, natively.

Two names matter. HLS interstitials are Apple's version: the manifest carries an EXT-X-DATERANGE marker of the interstitial class with an X-ASSET-LIST that points to the ad, and a supporting player plays it as a player-native break (Apple HLS specification). Server-guided ad insertion (SGAI) is the broader pattern, formalized for DASH in the 6th edition of MPEG-DASH, published as ISO/IEC 23009-1:2026 in July 2026. It is no longer an experiment: AWS Elemental MediaTailor added HLS interstitials for VOD in April 2024, for live streams in November 2025 and for Low-Latency HLS live streams on 10 September 2026, where every viewer gets the same cacheable playlist and the ad call moves off the manifest request path (AWS What's New, 2024–2026). Google Ad Manager's Dynamic Ad Insertion offers SGAI for livestreams through its pod-serving API (Google Ad Manager developer documentation, 2025).

The payoff is structural. Because the ad payload is decoupled from the content stream, the content manifest stays shared and cacheable — cheaper to deliver than a per-session stitched manifest — while the ad fetch, being client-side, restores accurate viewability and easier interactivity. It is not a free lunch: it is the newest approach, support is still spreading across the device fleet, and there are fewer turnkey options than for classic SSAI. But the direction is clear — server decides, client renders — and a platform built today should treat SGAI/interstitials as the architecture it grows into, not a science project. This is why the comparison table has three columns, not two.

Figure 4. The convergence. CSAI keeps measurement and interactivity but loses to blockers and stutters; classic SSAI flips that; server-guided insertion (HLS interstitials, DASH SGAI) aims to keep the best of both — server decides, client renders.

A common mistake: choosing the insertion method before the surface and the goal

The recurring error is to treat this as a single platform-wide switch — "we'll do SSAI" — decided by an engineer's preference rather than by where the audience watches and what the ads must do. It backfires in predictable ways. A performance-advertising business that needs clickable, interactive units ships pure SSAI and discovers its ads cannot click. A web-heavy AVOD service ships CSAI to keep interactivity and watches ad-blockers erase a fifth of its revenue. A team rolls out SSAI without threading session identity to the ad server and ships the "same ad five times" experience that makes viewers mute the TV. Each is the same root mistake: the method was chosen before the surface (web, mobile, CTV) and the goal (revenue defense, smooth experience, interactivity, measurement) were named.

The fix is to decide per surface against a goal, not once for the whole platform. CTV, where blocking is rare but device fragmentation is brutal and the experience must feel like television, is the textbook home for SSAI or server-guided insertion. Ad-blocked web, where a separate ad call is a liability, is where SSAI defends revenue — unless interactivity is the whole business model, in which case CSAI with anti-blocker mitigations earns its keep. Most serious platforms end up mixed: server-side on TV, server-side or hybrid on web for blocker resistance, with measurement wired through VAST 4.1 and OMID regardless. Name the surface and the goal first; the method follows.

Figure 5. Choosing per surface and goal. Start from where the audience watches and what the ad must do — not from an engineering preference — and the insertion method falls out.

SSAI vs CSAI for FAST channels

For a FAST (free ad-supported streaming TV) channel, default to SSAI: FAST is linear TV watched mostly on connected TVs, where every break must play like broadcast and no device ad SDK can be trusted to behave the same way. The audience is growing fast — FAST viewing hours rose 55% and ad impressions 53% year over year in spring 2026, with the US and Canada taking 74% of impressions (Amagi AIRTIME Report, June 2026) — so the cost of a stalled or blank break grows with it. If you are new to the format, our explainer on VOD, live, linear and FAST sets out how a FAST channel differs from on-demand video.

• Difference for FAST. With SSAI the channel's SCTE-35 cues become stitched ad pods inside the linear stream, identical on every TV. With standard client-side insertion each app has to detect the cue, pause the live stream, fetch the ad and rejoin the live edge, and a slow ad call means a skipped break or a jump in the program.
• Ad-blocking resistance. On TVs blocking is rare, so the real comparison is on web and mobile players of the same channel: CSAI's ad call to a known ad domain is blocked outright, SSAI's ad segments come from the content CDN and survive. Rank the three methods SSAI > SGAI > CSAI for blocker resistance.
• When CSAI still fits a FAST channel. Your own web or mobile player with a small audience, ads sold through a single tag, interactive or shoppable units, or a pilot channel where you want to prove demand before paying for a stitcher. On a channel watched mainly on connected TVs, CSAI is rarely worth it.
• Distribution platforms. FAST aggregators usually take a linear HLS feed with SCTE-35 markers and run their own server-side insertion for their share of the inventory, so clean, frame-accurate SCTE-35 matters more than which insertion method your own player uses.
• Quick CSAI setup for a small channel. Use a player ad SDK such as the Google IMA SDK on web and mobile with a VAST or VMAP tag from your ad server, map each SCTE-35 cue to an ad break, and test the rejoin to the live edge on your slowest target device before launch.

If a vendor recommends CSAI for your FAST channel, check four things: how its player rejoins the live edge after a break, what share of your viewing is on connected TVs, how it measures impressions on devices without a reliable SDK, and what moving to SSAI or SGAI later would cost. If the answers are vague, an independent architecture review of your ad-insertion stack is cheaper than a year of lost breaks. The business side — channel packaging, distribution deals and launch steps — is covered in our guide to launching a FAST channel.

Frequently asked questions

What is the difference between SSAI and CSAI?

SSAI stitches ads into the video stream on the server, so the player receives one continuous stream; CSAI has the player request and play each ad itself in a separate ad player. SSAI wins on smooth playback and ad-blocker resistance, CSAI on measurement and interactivity.

Is SSAI better than CSAI?

For connected TV, live, linear and FAST, yes: breaks play without stalls and ad-blockers cannot remove them. For interactive ads and click-driven performance campaigns on web and mobile, CSAI is still the better tool, and most large platforms run both.

Can ad-blockers block SSAI ads?

Network-level ad-blockers cannot, because SSAI ad segments come from the same CDN and stream as the content. CSAI ads are easy to block, which matters because 30% of internet users ran an ad-blocker in Q4 2025 (eyeo, 2026).

Is SSAI the same as dynamic ad insertion (DAI)?

Not exactly. SSAI is the stitching technique; dynamic ad insertion is SSAI plus per-viewer ad decisions, so each viewer gets a personalized manifest with targeted ads and frequency caps.

What is SGAI, server-guided ad insertion?

SGAI is a hybrid in which the server marks the ad break and the player fetches and plays the ad natively. It is standardized for DASH in ISO/IEC 23009-1:2026, delivered on Apple devices as HLS interstitials and supported by AWS Elemental MediaTailor and Google Ad Manager.

Does SSAI work on Roku, Fire TV and smart TVs?

Yes, and that is where it is most used: about 70% of CTV apps on Roku, Fire TV, Samsung and Apple TV used SSAI for open programmatic ads (Pixalate, Q2 2024). The player only needs to play a normal HLS or DASH stream.

Why does SSAI sometimes show the same ad repeatedly?

Because the stitcher calls the ad server without passing who the viewer is and what they have already seen. Passing a per-session viewer ID and history to the ad decision server on every call fixes it.

Is SSAI more prone to ad fraud?

It can be: Pixalate measured 110% higher invalid-traffic rates on SSAI than on non-SSAI CTV traffic (Q2 2024). Forwarding the real device IP and user agent, authenticating server-to-server calls and running OMID verification closes most of the gap.

Where Fora Soft fits in

Ad insertion is where streaming scale meets advertising revenue, and the expensive failures are quiet ones: a fifth of web impressions blocked before they count, a TV fleet where every device's ad SDK breaks differently, a stitcher that over-counts impressions and fails an audit, or the "same ad on repeat" that drives viewers away. Fora Soft has built video-streaming and OTT/Internet-TV platforms since 2005, across 250+ shipped projects, which means we have wired SCTE-35 ad signaling into live and VOD pipelines, integrated server-side stitching with ad decision servers, conditioned ad creative to match the encoding ladder so breaks stay gap-free, and kept measurement honest through VAST and Open Measurement. Our stance is scalability-first and vendor-neutral: we start from where your audience watches and the ad revenue you must protect at scale, then build the insertion architecture — CSAI, SSAI, or the server-guided hybrid — that your surfaces and your advertisers actually require. If you are adding ad-supported tiers to your own service, our OTT and Internet TV development team builds the SCTE-35 signaling, stitching and ad-decision integration, and our video streaming software development practice covers the live and VOD pipelines underneath.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume handbook that takes the video stack from a single pixel to production — encoding, delivery, audio and AI — and someone who works through it can design and build an ad-supported platform end to end. Volume 3 is the one to open next to this article: players, ABR buffers, CDN caching and the economics of delivery, which is where a stitched break stays smooth and a per-session manifest shows up on the bill. Volume 2 covers the HLS and DASH manifests the stitcher rewrites, and volume 1 the encoding ladder every ad has to be conditioned to match. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. ANSI/SCTE 35 2023r1 — Digital Program Insertion Cueing Message. Society of Cable Telecommunications Engineers (SCTE). Tier 1. The controlling standard for in-stream ad-break signaling; defines splice_insert, time_signal, and the segmentation_descriptor cues that mark ad avails, now carried in HLS and DASH delivery. Published 2023-11-30. https://account.scte.org/standards/library/catalog/scte-35-digital-program-insertion-cueing-message/ — accessed 2026-06-17. Since 2026 the standard is published as SCTE 35-1 (legacy splice- and time-based signaling) plus SCTE 35-2 2026 (event-based signaling): SCTE 35-2 catalog entry — accessed 2026-10-14.
2. VAST — Digital Video Ad Serving Template (version history; VAST 4.3, Dec 2022; VAST 4.1, Aug 2017; VAST CTV Addendum 2024). IAB Tech Lab. Tier 1. The XML ad-response standard used by both CSAI and SSAI; VAST 4.1 added explicit server-side-ad-insertion support and Open Measurement alignment. VAST 4.3 is still the current version as of October 2026. Page body last updated 2024-07-18. https://iabtechlab.com/standards/vast/ — accessed 2026-06-17.
3. Open Measurement SDK (OMID). IAB Tech Lab. Tier 1. The viewability/verification framework that restores honest ad measurement under server-side insertion, declared via VAST <AdVerifications>. https://iabtechlab.com/standards/open-measurement-sdk/ — accessed 2026-06-17.
4. HTTP Live Streaming — RFC 8216. IETF. Tier 1. The HLS manifest standard the stitcher rewrites; #EXT-X-DISCONTINUITY marks the content-to-ad boundary, and EXT-X-DATERANGE carries interstitial (ad) markers. https://www.rfc-editor.org/rfc/rfc8216 — accessed 2026-06-17.
5. Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1, ISO/IEC 23009-1. ISO/IEC. Tier 1. The DASH manifest standard; its 6th edition, ISO/IEC 23009-1:2026 (published July 2026), formalizes server-guided ad insertion (SGAI) for high-concurrency live and VOD. https://www.iso.org/standard/89027.html — accessed 2026-10-14.
6. HLS Interstitials (Apple HLS specification / authoring update). Apple. Tier 3 (first-party, spec author). Player-native ad-break markers (EXT-X-DATERANGE interstitial class with X-ASSET-LIST) that underpin the server-guided hybrid. https://developer.apple.com/streaming/ — accessed 2026-06-17. Spec evolving — re-verify.
7. AWS Elemental MediaTailor — server-side ad insertion, manifest stitching, and HLS interstitials (VOD 2024, live 2025). Amazon Web Services. Tier 3 (first-party vendor). Documents how a production stitcher calls the ADS, conditions ad creative to the content ladder, rewrites manifests, and supports server-guided insertion. https://docs.aws.amazon.com/mediatailor/latest/ug/ — accessed 2026-06-17. Vendor docs — re-check.
8. Google Ad Manager — Dynamic Ad Insertion (DAI) and DAI Pod Serving. Google. Tier 3 (first-party vendor). Server-side stitch for live, linear, and VOD; pod serving lets a platform own its workflow and receive ready-to-stitch ad pods, removing the ad request from the client SDK. https://support.google.com/admanager/answer/6147120 — accessed 2026-06-17. Vendor docs — re-check.
9. Connected-TV advertising market, 2026. IAB, 2026 Digital Video Ad Spend & Strategy Report (May 2026): US CTV ad spend $29.3B in 2026, +11%. Tier 5. eMarketer's forecast is higher (~$38B); analyst estimates vary by scope and method. https://www.iab.com/insights/ — accessed 2026-10-14.
10. eyeo 2026 Ad-Blocking Report (May 2026). eyeo. Tier 4. 1.1B ad-blocking users in Q4 2025 (30% of the internet population); 448M desktop (−4% since 2023), 629M mobile (+27%). https://eyeo.com/wp-content/uploads/2026/05/eyeo_2026-ad-blocking-report.pdf — accessed 2026-10-14.
11. Global Q2 2024 SSAI Benchmark Report for Connected TV. Pixalate. Tier 4. 70% of CTV apps use SSAI for open programmatic; SSAI IVT rates 110% higher than non-SSAI. https://www.pixalate.com/blog/global-q2-2024-server-side-ad-insertion-ssai-benchmark-report-for-connected-tv — accessed 2026-10-14.
12. AIRTIME Report, June 2026. Amagi. Tier 4 (one platform's data, ~6,500 channel deliveries). FAST viewing hours +55% and ad impressions +53% year over year (1 Apr–15 Jun 2026); US and Canada 74% of impressions. https://www.advanced-television.com/2026/07/01/report-fast-viewing-up-55-as-metadata-challenges-hit-revenue/ — accessed 2026-10-14.
13. AWS Elemental MediaTailor — What's New (Low-Latency HLS ad insertion with HLS interstitials, 10 Sep 2026; automatic Google ad-platform integration, 5 May 2026). Amazon Web Services. Tier 3. https://aws.amazon.com/about-aws/whats-new/2026/09/aws-elemental-mediatailor-low-latency-hls-ad-insertion/ — accessed 2026-10-14.
14. CSAI vs SSAI — technical explainers. Bitmovin, Wowza, OTTVerse, AdExchanger. Tier 6 (orientation). Consulted for cross-checking the stitching mechanics and the ad-blocker framing; not used as the source for any spec claim. https://bitmovin.com/blog/csai-vs-ssai-client-side-server-side-ad-insertion/ — accessed 2026-06-17.
15. Fora Soft — Video Streaming App Monetisation (overview blog). Fora Soft. Tier 7. Product-level companion on AVOD/SVOD/TVOD and ad-supported monetization; the commercial-intent counterpart this educational article links to. https://www.forasoft.com/blog/article/video-streaming-app-monetization-strategies — accessed 2026-06-17.

Where sources disagreed, the controlling standard or first-party document was followed. SCTE-35, VAST/OMID, RFC 8216 (HLS), and ISO/IEC 23009-1 (DASH) are cited from the issuing bodies; the stitching behavior is cross-checked against first-party vendor documentation (AWS Elemental MediaTailor, Google DAI) and dated, because vendor capabilities and the HLS-interstitials/SGAI specs are actively evolving in 2026. The popular framing that SSAI "hides" ads from blockers was overridden in favor of the precise mechanism — SSAI removes the separate client-to-ad-server request — per the spec-over-listicle hierarchy. CTV-spend and ad-blocker figures are 2025–2026 analyst ranges, never quoted as universal numbers.