What Is Server-Side Ad Insertion (SSAI)? How It Works and How to Implement It

U.S. connected TV ad spending is projected to top $40 billion by 2027, and most of that money flows through ad-supported streaming. If you run an OTT service, a live sports app, or any ad-funded video product, the way you deliver those ads decides how much revenue you keep — and how many viewers stick around.

Server-side ad insertion is the technique that stitches ads directly into a video stream on the server, so the viewer’s player receives one continuous playlist instead of juggling separate ad requests. It’s the backbone of ad delivery for platforms like Hulu, Peacock, and most connected TV apps, and it’s why ads on those services rarely buffer or get blocked.

This guide covers what server-side ad insertion is, how it differs from client-side and other methods, how the ad-stitching process works step by step, its advantages and trade-offs, and how to implement it in your own streaming stack. By the end, you’ll know whether SSAI fits your project and what infrastructure you need to run it.

What Is Server-Side Ad Insertion?

Server-side ad insertion (SSAI) is a video advertising technique that merges ad content and primary video into a single stream on the server before it reaches the viewer’s device. Instead of the player fetching ads separately, the SSAI service splices ad segments into the same manifest and delivers everything as one uninterrupted playlist.

Because the ads and the content share the same bitrate, resolution, frame rate, and codec, the player can’t tell where the show ends and the ad begins. There’s no second player to spin up, no separate network request that an ad blocker can catch, and no gap while an ad loads. SSAI is also called dynamic ad insertion (DAI) or ad stitching — the terms describe the same server-side process.

SSAI exists because client-side advertising broke down on modern streaming devices. Ad blockers grew good at killing separate ad calls, connected TV players had inconsistent ad support, and viewers hated the buffering that came with switching between content and ads. Moving the work to the server solved all three problems at once.

Here’s how SSAI compares to the client-side alternative at a glance:

SSAI vs CSAI vs DAI vs SGAI

The ad-insertion space is full of overlapping acronyms, so it’s worth pinning down each term before going deeper.

CSAI (client-side ad insertion) places the ad logic in the video player. When the player hits an ad marker in the manifest, it pauses content and calls an ad server directly, then plays the returned creative. It’s easier to build and supports clickable or skippable ad formats, but it’s exposed to ad blockers and often causes a visible pause.

SSAI (server-side ad insertion) moves that logic to the server. The stitcher builds a personalized manifest per session with ads already woven in, so the player just plays a continuous stream. This is what most large streaming platforms use.

DAI (dynamic ad insertion) is a broader term for any method that swaps in different ads dynamically rather than baking one fixed ad into a file. In practice, most people use DAI and SSAI interchangeably, since server-side stitching is the dominant way to do dynamic insertion today.

SGAI (server-guided ad insertion) is a newer approach where the server signals ad breaks and ad locations to the player through the manifest, but the player fetches and renders the creatives. It aims to combine SSAI’s reliability with CSAI’s interactivity, and it’s gaining traction for VOD and lower total cost.

For the rest of this guide, “SSAI” refers to the server-side stitching model, which is what most teams mean when they talk about ad insertion for streaming.

How Does Server-Side Ad Insertion Work?

SSAI works by intercepting the video manifest, deciding which ads to serve, conditioning those ads to match the stream, and stitching them in — all before the playlist reaches the viewer. The player only ever sees a single HLS or DASH manifest with content and ad segments listed together.

Here’s the process step by step:

1. The viewer requests the stream. When someone hits play, the player asks the SSAI service for the manifest instead of pulling the raw content playlist directly. The service creates a unique session for that viewer.
2. The stitcher detects an ad break. Upcoming ad opportunities are flagged by SCTE-35 markers embedded in the stream (for live) or by cue points defined in the VOD playlist. These markers say “an ad break starts here and lasts this long.”
3. The service calls an ad decision server. The stitcher sends a request — using the VAST specification or VMAP for multi-slot breaks — to an ad decision server (ADS). It passes context like device type, geography, and content metadata so the ADS can pick relevant ads.
4. Ads are conditioned to match the stream. The chosen creatives are transcoded to the same bitrate, resolution, frame rate, and codec as the primary content. This transcoding step is what makes the switch invisible to the player.
5. The ads are stitched into the manifest. The service rewrites the playlist, inserting the ad segments at the break point with an #EXT-X-DISCONTINUITY tag so the player knows encoding parameters may change, as documented for server-side stitchers. The manifest now reads as one continuous list of segments.
6. The stitched stream is delivered via CDN. The final playlist goes out through a content delivery network, so viewers everywhere get low-latency playback of the combined stream.
7. Ad views are tracked with beacons. As the viewer watches, the server (or in some setups the client) fires tracking beacons at each quartile — start, 25%, 50%, 75%, complete — to report impressions back to the ad system.

The key difference from client-side insertion is that all of this happens server-side and per session, so each viewer can get a different, current ad without their player ever making a separate ad call.

Types of Server-Side Ad Insertion

SSAI isn’t one-size-fits-all. The right setup depends on whether you’re serving live or on-demand content and where in the video your ads run.

Live SSAI

Live SSAI stitches ads into a running broadcast in real time. Ad breaks are triggered by SCTE-35 markers inserted by the encoder or by an API call during the live event. It’s the hardest form to get right because timing, break duration, and viewer join-in-progress all have to be handled on the fly. Best for: live sports, news, and linear-style FAST channels.

VOD SSAI

VOD SSAI inserts ads into on-demand files using predefined cue points in the playlist. Because the content isn’t changing in real time, the stitcher has more room to condition and place ads accurately. Best for: OTT catalogs, replays, and live-to-VOD recordings.

Pre-Roll Ads

Pre-roll ads play before the main content starts. They have the highest completion rates because the viewer is waiting for the video, but too many can drive abandonment. Best for: short content and first-session monetization.

Mid-Roll Ads

Mid-roll ads run at natural breaks inside longer content. They command the highest CPMs since viewers are already committed, and SCTE-35 markers let you place them at scene changes rather than random points. Best for: long-form video, episodes, and sports.

Post-Roll Ads

Post-roll ads play after the content ends. Completion rates drop because viewers often leave, but they carry zero interruption cost. Best for: bonus inventory and sponsorship tags.

Advantages of Server-Side Ad Insertion

SSAI became the default for streaming monetization for good reasons. Here are the biggest ones.

Ad-Blocker Resistance

Because ads travel inside the same stream as the content, there’s no separate ad call for a blocker to intercept. Tests have shown client-side ads blocked on 74–95% of devices, while SSAI ads reach nearly all viewers. For an ad-funded business, that difference goes straight to revenue.

Smooth, Broadcast-Quality Playback

The viewer gets one continuous stream with no buffering or black screen when an ad starts. Since the creatives match the content’s bitrate and resolution, the transition looks like traditional TV. That polish keeps watch time and completion rates high.

Broad Device Compatibility

SSAI works on single-player devices — smart TVs, older set-top boxes, and web browsers — that can’t run the dual-player setup client-side ads require. One stitched stream plays anywhere your content already plays, so you don’t maintain device-specific ad code.

Accurate Ad Measurement

Because ad delivery is verified as part of stream consumption, impression counts reflect ads that actually reached the viewer. That reliability matters for reporting to advertisers and for revenue models tied to verified views.

Lower Client-Side Processing

The device doesn’t have to fetch, decode, and switch between separate ad and content players. That reduces CPU load, latency, and playback errors, which is especially valuable on low-powered TV hardware.

Personalized Ads Without Client Complexity

Each viewer session gets its own stitched manifest, so two people watching the same show can see different ads based on geography, device, or audience segment — all decided server-side without any extra work in the player.

Disadvantages of Server-Side Ad Insertion

No approach is free of trade-offs. Here are the challenges to plan for before you commit to SSAI.

Higher Infrastructure Cost and Complexity

SSAI needs servers that can transcode and stitch streams at scale, plus per-session manifest generation that grows with your audience. Building this in-house means real backend investment. Using a streaming platform or ad-stitching service that handles conditioning and delivery removes most of that burden.

Interactive Ad Formats Are Harder

Skippable, clickable, and overlay ads are native to client-side players but awkward in a stitched stream, since the creative is baked into the video. If interactivity is central to your ad product, you may need SGAI or a hybrid setup that keeps rendering on the client.

Ad Fraud Exposure

The same layer that hides ads from blockers also sits between your stack and the viewer’s device, which makes SSAI a target for impression fraud. Working with vetted ad partners and adopting server-side verification standards helps close that gap.

Live Timing and Join-In-Progress

For live streams, coordinating break timing, break duration, and viewers who join mid-break is genuinely hard. Systems typically round ad breaks to the nearest quartile for late joiners, but getting this smooth takes tuning and reliable SCTE-35 signaling.

Manifest Scaling

Because each viewer gets a personalized playlist, manifest generation scales with concurrency. A large live event can mean millions of unique manifests at once, so your delivery layer and CDN strategy have to handle that load.

Now that you understand what SSAI is, how it works, and where it shines or struggles, let’s get into the practical side — how to implement it and what infrastructure you need to run it.

How to Implement Server-Side Ad Insertion

Adding SSAI to your product means connecting four pieces: a stream source, ad markers, an ad decision server, and a stitcher that delivers the final playlist. Here’s how to approach it.

1. Prepare Your Stream Source

Start with a clean streaming pipeline. Your content needs to be ingested — over RTMP or SRT for live, or uploaded for VOD — and packaged as adaptive HLS or DASH with consistent encoding. Consistent bitrate ladders and codecs across content and ads are what make stitching invisible later.

2. Insert Ad Break Markers

Define where ads can run. For live, that means embedding SCTE-35 markers at your ad break points (via the encoder or an API call). For VOD, you set cue points in the manifest. Placing markers at natural scene breaks rather than fixed intervals improves the viewer experience and mid-roll completion rates.

3. Connect an Ad Decision Server

Set up or integrate an ad decision server that responds to VAST/VMAP requests. This is where your ad inventory, targeting rules, and demand partners live. The stitcher will call it at each break, passing session context so it can return relevant creatives.

4. Choose Your Streaming and Stitching Infrastructure

Building the full stitching pipeline — real-time transcoding, per-session manifest rewriting, CDN delivery, and beaconing — takes an experienced team months. Most teams instead build on a video streaming API that handles ingest, adaptive bitrate encoding, HLS output, and global delivery, then layer ad stitching on top. LiveAPI gives you live and VOD streaming with RTMP and SRT ingest, instant encoding, HLS delivery across Akamai, Cloudflare, and Fastly, and live-to-VOD recording — the streaming foundation an ad-supported product needs, ready in days instead of months. From there you connect your ad decision server and stitching logic to monetize the stream.

5. Handle Ad Tracking and Reporting

Wire up beaconing so impressions, quartiles, and completions report back to your ad system. Server-side beaconing is the default and most reliable; use webhooks and event notifications to trigger analytics and reconcile ad delivery with playback data.

6. Test Across Devices and Network Conditions

Validate playback on the devices your audience actually uses — smart TVs, mobile, and web — and test join-in-progress on live streams. Check that the discontinuity between content and ad segments plays cleanly and that quality doesn’t drop at the switch.

Infrastructure You Need for SSAI

SSAI sits on top of a working streaming stack. These are the pieces that have to be in place for ad stitching to run reliably.

Ingest and Encoding

You need dependable ingest and adaptive bitrate encoding so both content and ads share the same rendition ladder. Mismatched encoding is the most common cause of glitches at the ad boundary, so instant, consistent transcoding matters.

Ad Decision Server

The ADS holds your inventory and targeting logic and speaks VAST/VMAP. You can run your own or connect a demand partner or ad network. This component decides which ad plays for each viewer at each break.

Ad Stitcher

The stitcher is the engine that reads SCTE-35 markers, calls the ADS, conditions creatives, and rewrites the manifest per session. Providers like AWS Elemental MediaTailor, Yospace, and Mux specialize here — see our Mux alternatives roundup for how these fit into a broader stack.

Video Streaming API

Rather than assembling ingest, encoding, storage, and delivery separately, a video streaming API gives you the whole pipeline through one integration. LiveAPI streams up to 4K, records live to VOD automatically, and delivers HLS through multiple content delivery networks — so building an ad-supported OTT service takes days of work instead of a multi-month infrastructure project. That lets your team focus on the ad logic and monetization instead of the streaming plumbing.

Content Delivery Network

Stitched, per-session manifests scale with your audience, so a CDN with global reach and high concurrency is non-negotiable for live events. Multi-CDN delivery adds redundancy so a single provider outage doesn’t take your ad-funded stream — and its revenue — offline.

Is Server-Side Ad Insertion Right for Your Project?

SSAI is the strongest choice for most ad-supported streaming, but it isn’t the only option. Use this checklist to decide.

SSAI is a good fit if you:

• Run an ad-supported (AVOD or FAST) streaming service
• Serve connected TV, smart TV, or single-player web audiences
• Want ads that resist blockers and match broadcast quality
• Need accurate, verifiable ad impression counts
• Deliver live sports, news, or long-form content with mid-rolls
• Care about watch time and completion rates

SSAI may not be the right fit if you:

• Depend heavily on interactive, skippable, or clickable ad formats
• Run a small catalog where client-side ads are simpler to ship
• Have no ad infrastructure and want the lowest possible complexity to start
• Are building a subscription-only product with no ads at all

If you’re weighing ad-supported against subscription revenue, our guide to AVOD vs SVOD breaks down the trade-offs. For most teams building ad-funded video today, SSAI plus a reliable streaming backend is the combination that scales.

Server-Side Ad Insertion FAQ

What is the difference between SSAI and CSAI?

SSAI stitches ads into the video stream on the server, so the player receives one continuous playlist. CSAI inserts ads on the viewer’s device, with the player making separate ad requests. SSAI resists ad blockers and plays smoother; CSAI is simpler and supports interactive ad formats.

Is server-side ad insertion the same as dynamic ad insertion?

Mostly, yes. Dynamic ad insertion (DAI) is the broader idea of swapping in different ads dynamically, and server-side stitching is the dominant way to do it. In everyday use, SSAI and DAI refer to the same server-side process.

Does SSAI stop ad blockers?

Largely, yes. Since ads are delivered as part of the same stream rather than through a separate request, ad blockers have nothing distinct to block. Client-side ads, by contrast, have been blocked on 74–95% of devices in testing.

What is SCTE-35 in ad insertion?

SCTE-35 is a standard for embedding cue messages in a video stream to mark where ad breaks start and end. SSAI stitchers read these markers to know when to insert ads, especially in live streams. The markers carry the break timing and duration.

What are VAST and VMAP?

VAST (Video Ad Serving Template) is an IAB standard for how an ad decision server describes a single ad to a player or stitcher. VMAP (Video Multiple Ad Playlist) describes a full schedule of breaks — pre-roll, mid-roll, and post-roll — across a piece of content. SSAI uses both to request and place ads.

Can I use SSAI for live streaming?

Yes. Live SSAI triggers ad breaks with SCTE-35 markers during the broadcast and stitches ads in real time. The main challenges are break timing and viewers who join mid-break, which systems usually handle by rounding the break to the nearest quartile for late joiners.

How much does server-side ad insertion cost?

Costs vary by provider and model. Ad-stitching services often charge per ad impression or per streamed minute, and ad servers can start around $250–$500 per month for basic tiers, scaling with volume. Building the streaming and stitching pipeline in-house adds significant engineering and infrastructure cost, which is why many teams use a video streaming API to cover the delivery side.

What is SGAI and how is it different from SSAI?

Server-guided ad insertion (SGAI) has the server signal ad breaks and ad locations in the manifest, but the player fetches and renders the creatives. It aims to keep SSAI’s reliability while restoring the interactivity and lower cost of client-side rendering. It’s an emerging option, especially for VOD.

Final Thoughts

Server-side ad insertion is how modern streaming platforms monetize without wrecking the viewing experience. By stitching ads into the stream on the server, you get ad-block resistance, broadcast-smooth playback, broad device support, and reliable measurement — the qualities that make ad-supported video actually profitable.

The one thing that matters most: SSAI only works as well as the streaming pipeline underneath it. Consistent encoding, dependable ingest, and multi-CDN delivery are what make ad stitching invisible to the viewer.

Ready to build ad-supported streaming? LiveAPI gives you live and VOD streaming, instant encoding, HLS delivery across Akamai, Cloudflare, and Fastly, and automatic live-to-VOD — the foundation for SSAI, launched in days, not months. Get started with LiveAPI.