Server-Side Ad Insertion (SSAI): Build vs Buy for OTT

Why Fora Soft wrote this SSAI playbook

We build video and streaming products for a living. Fora Soft has shipped 625+ projects since 2005, and a large share of them are OTT and VOD platforms that eventually have to answer the same question: how do we put ads in the stream without wrecking the experience or handing the revenue to ad blockers? We’ve answered it in production, not on a slide.

One of those builds added an ad-supported tier to Tradecaster, a live video community for stock traders. We wired a real SSAI pipeline that served brand-safe fintech ads on the free tier while the premium subscription stayed ad-free. We also built Vodeo, a Netflix-style VOD platform for Janson Media with 100,000+ users, so we own the whole delivery chain that ad insertion bolts onto: ingest, transcode, packaging, CDN, and player.

This guide is the honest, vendor-neutral version of what we learned. It explains what server-side ad insertion actually does, how it differs from client-side and server-guided insertion, what the managed vendors cost in 2026, when a custom build is worth it, and how much revenue SSAI recovers. No ad-tech vendor is paying us to say any of this. For the protocol-level mechanics, we’ll point you to our deep reference on how SSAI works rather than repeat it here.

What server-side ad insertion actually does

Server-side ad insertion (SSAI) is a server that splices ads into a video stream before it reaches the viewer. Instead of the player calling an ad server at each break, the origin rewrites the viewer’s manifest so ad segments and content segments sit in one playlist. The player just plays the stream it’s handed. Because there’s no separate ad request, a client-side ad blocker sees nothing to intercept, and the ad plays at the same resolution and volume as the show.

The mechanism is manifest manipulation. For an HLS stream the stitcher edits the .m3u8 playlist to insert the ad’s .ts or fMP4 segments at the marked break, adding an EXT-X-DISCONTINUITY so the player switches cleanly. The break points come from SCTE-35 markers embedded in the stream, and the actual creatives come from an ad server that answers with a VAST response. We keep the byte-level detail in our SSAI deep dive; here we care about the build decision.

Figure 1. The stitcher sits between your CDN and the player: SCTE-35 cues mark the break, the ad server returns creatives over VAST, and the manifest is rewritten so content and ads arrive as one continuous stream.

The plain-language version: SSAI is the difference between a waiter bringing you a plated meal with the side dish already on it, versus handing you a voucher to go fetch the side yourself. The voucher can be lost or refused at the door; the plated meal just arrives. That’s why ad-supported streaming services on TVs and phones lean on SSAI when the ad break has to feel like part of the show.

SSAI vs CSAI vs SGAI: which one fits

There are three ways to get an ad into a stream, and they trade the same three things against each other: ad-block resistance, tracking accuracy, and playback smoothness. Client-side insertion is easy and precise but blockable. Server-side is unblockable and smooth but harder to measure. Server-guided is the 2026 attempt to get both.

Figure 2. The trade-off, row by row. CSAI wins on client targeting, SSAI wins on unblockable delivery, and SGAI tries to keep both by letting the server signal the break and the client insert the ad.

CSAI (client-side) puts the ad logic in the player. The player calls an ad server over VAST at each break and plays the returned creative. You get rich targeting from client-side data and interactive ad formats, but an ad blocker on web or mobile can cut the ad request, and the switch to the ad player often stalls for a beat.

SSAI (server-side) stitches the ad into the stream so the player never makes a separate call. Ads survive blockers and play at the content’s bitrate, which is why it dominates connected TV and FAST channels. The catch is measurement: because tracking beacons fire from your server rather than the viewer’s device, you have to work to make impressions count as real.

SGAI (server-guided) is the newer middle path. The server marks the break using Apple’s HLS Interstitials (an EXT-X-DATERANGE tagged CLASS="com.apple.hls.interstitial") or the DASH equivalent, and the client fetches and inserts the ad itself. That keeps client-side tracking and targeting while the primary content stays untouched. The first deployments for major SVOD services landed in 2026, and AWS and Google both support the interstitial path now.

Why SSAI is worth the effort in 2026

Two numbers explain the urgency: ad blockers are everywhere, and streaming ad money has gone mainstream. Roughly 43% of internet users worldwide run an ad blocker, about 912 million people (Cropink, 2026). On the money side, US connected-TV ad spend crossed $37.95B in 2026, global FAST advertising reached about $12.23B (up from $10.60B in 2025), and CTV upfront commitments are projected to pass primetime linear TV for the first time. Ad-supported streaming is where the growth is, and blockers are trying to take a cut.

Put those together and the case is simple. If you monetize with client-side ads on a web or mobile audience, you hand roughly the ad-blocked slice of your inventory to browser extensions for free. SSAI closes that leak because the ad is baked into the same stream as the content. On CTV the block rate is near zero, but SSAI still wins there for a different reason: it makes the ad break behave like television across a brutal spread of TV apps and devices.

This is why ad insertion has become a standard line item in an OTT platform build, not an afterthought. If you’re still choosing a revenue model, our guide to streaming monetisation models covers where AVOD, FAST, and hybrid fit before you pick an insertion method.

Build vs buy: the decision that sets your bill

For almost every team, the honest first answer is buy. A managed stitcher like AWS Elemental MediaTailor or Google Ad Manager DAI turns SSAI into a per-insertion line item and hides the fleet, the transcoding, and the tracking hygiene. Building your own stitcher only makes sense at high volume, or when you need custom ad logic, on-prem data residency, or control that a vendor won’t give you.

Buying means you send the vendor your stream and an ad-server URL, and they return personalized manifests. They handle creative conditioning (transcoding each ad to match your bitrate ladder), manifest rewriting, and server-side beacons. You pay per ad inserted. Time to first ad break is days to weeks, not quarters.

Building means you run a stitching service that rewrites manifests per session, a transcoding pipeline to condition creatives, a VAST proxy to your ad server, and the beacon logic that keeps impressions from being flagged as fraud. It’s real infrastructure that scales with concurrency, plus the ongoing maintenance as ad-tech standards move. The reward is full control and, past a certain volume, a lower marginal cost.

SSAI options compared: MediaTailor, Google DAI, specialists, custom

The market splits into cloud stitchers you rent by the insertion, broadcast-grade specialists you contract with, and a build-it-yourself path. The right pick depends on whether you already sell your own ads, which platforms you serve, and your monthly volume. Here is how the main options line up, with pricing captured from vendor pages in July 2026.

Two honest notes. First, Google Ad Manager DAI is “free” only in the sense that the stitching tool has no per-insertion sticker price; you pay through Google’s ad-serving revenue share, and it’s gated to Ad Manager 360 partners on an advanced contract. Second, the specialists like Yospace (which reported crossing 10 billion monthly ad insertions in April 2026) and broadpeak.io don’t publish prices because deals are negotiated for broadcast scale; treat them as the option when you outgrow a self-serve cloud tool.

What managed SSAI costs: the MediaTailor math

Managed SSAI is cheap per insertion, so at normal volumes the stitching fee is a rounding error next to the ad revenue it protects. AWS Elemental MediaTailor prices ad insertion at $0.50 per 1,000 for live and $0.25 per 1,000 for VOD, with no tiers and no minimum, as listed on the AWS pricing page we captured on July 13, 2026. Let’s run the numbers out loud.

The insertion fee. Say your ad tier serves 10 million live ad insertions a month. That’s 10,000 units of 1,000, times $0.50, so $5,000 a month in stitching. AWS’s own worked example is smaller and identical in shape: 1,000 viewers, 3 breaks of 5 ads each, is 15,000 insertions and costs $7.50. VOD would be half the rate.

The extras you can’t skip. MediaTailor includes 10 free ad transcodes per 1,000 insertions, then bills additional conditioning at MediaConvert rates ($0.0075/min SD, $0.015/min HD in US East, July 2026). You also pay ad-delivery egress, roughly $0.09 per GB on the first tier, which is why AWS tells you to front it with a CDN. New in 2026, Monetization Functions let you run custom ad-decisioning logic at lifecycle hooks for $0.0001 per invocation.

Why this beats building at first. That same 10 million insertions on a custom stitcher costs little in raw compute, but you carry the engineers who build and run the pipeline. One small SSAI team’s fully-loaded cost dwarfs a $5,000 monthly fee. The stitching fee only rivals a team’s payroll in the high tens to hundreds of millions of insertions a month, which is the real build-vs-buy crossover. We keep our own build estimates conservative and will tell you if your volume doesn’t justify one.

The revenue side: what SSAI actually recovers

The cost of SSAI is small; the revenue it protects is the point. On a web or mobile ad tier where a chunk of viewers run blockers, SSAI recovers the inventory that client-side ads would lose. The recovered revenue usually dwarfs the stitching fee. Here is the arithmetic, kept deliberately conservative.

Figure 3. The stitching fee versus the ad-blocked inventory it recovers, at 10 million monthly insertions and a $12 CPM. The net is illustrative; your CPM and block rate set the real figure.

Take 10 million monthly insertions on a web/mobile audience where about 43% would be blocked under client-side ads. SSAI keeps that 43%, roughly 4.3 million impressions, that CSAI would have dropped. At a $12 CPM, 4.3 million impressions is 4,300 times $12, or about $51,600 a month in recovered ad revenue. Subtract the $5,000 stitching fee and you net around $46,600. That’s a return of roughly ten times the cost, before you count the smoother playback.

Be honest about where this holds. The 43% recovery is a web-and-mobile number, because that’s where blockers live. On connected TV the block rate is near zero, so SSAI doesn’t recover much there; its value on CTV is a broadcast-quality break and reach across TV apps, not blocker defense. Plug in your own CPM and audience mix before you promise a board a specific number.

Reference architecture: wiring SSAI into your OTT stack

SSAI sits between your packager and your CDN, and it touches four things you already run: the origin that serves manifests, the SCTE-35 markers in the stream, the ad server that answers with creatives, and the player. Get those four wired and the stitcher does the rest. Here is the shape of a working setup.

Signal the breaks. Your live encoder or VOD packager writes SCTE-35 cues that mark where ads may go. For live, those cues come from the broadcast signal or your automation; for VOD, you place them at chosen points. The stitcher reads them to know when to splice.

Point the player at the stitcher. Instead of requesting the manifest from your CDN directly, the player asks the SSAI service for a session, and the stitcher returns a personalized manifest that mixes content and ad segments. Everything downstream, including your live-streaming delivery, still runs on your CDN for caching.

Condition and track. When a break hits, the stitcher calls your ad server over VAST, transcodes the returned creative to match your bitrate ladder, splices it, and fires the tracking beacons. If you want the protocol detail on SCTE-35 in HLS and DASH and the VAST exchange, our SSAI reference walks the five-stage pipeline byte by byte. Our streaming development team wires this into existing stacks without re-platforming.

Which ad server and signaling you plug into

SSAI is only the stitching layer; it still needs an ad server to decide what to play and a signaling standard to know when. The three pieces you’ll name in any build are SCTE-35 for the cue, VAST for the ad response, and VMAP for the break schedule. A stitcher speaks all three so it can talk to whatever demand you already sell.

SCTE-35 is the in-band cue that marks ad-break start and end inside the transport stream, HLS playlist, or DASH manifest. It’s the same standard broadcast has used for years, which is why live sports and linear channels map onto SSAI cleanly.

VAST (Video Ad Serving Template) is the XML an ad server returns describing the creative and its tracking URLs. VMAP schedules the pre-, mid-, and post-roll breaks around your content, and VAST fills each one. The 2026 detail worth knowing: VAST 4.x improved impression and quartile tracking for server-to-server setups, which cuts the count discrepancies that plague SSAI.

The ad server is your demand source: Google Ad Manager, a specialist like SpringServe, or a custom decisioning service. A good stitcher stays agnostic here, which keeps your inventory portable. If you sell direct and programmatic both, make sure the stitcher can call your SSP path too, or you’ll leave fill rate on the table.

Tracking, viewability, and the invalid-traffic trap

The hardest part of SSAI isn’t stitching; it’s proving the impression was real. Because the stitcher fires tracking beacons from your server instead of the viewer’s device, every impression can look like it came from one IP address, which is exactly the signature of invalid traffic. Get this wrong and advertisers refuse to pay for perfectly real views.

The fix is written into the IAB’s guidance. When your stitcher calls the ad server, it has to forward the viewer’s real context, chiefly the X-Forwarded-For IP and X-Device-User-Agent headers, so the ad server and measurement vendors see a real device, not your data center. Skip it and your impressions get filtered as fraud and go unpaid.

Viewability follows the same logic. Server-side beacons can confirm an ad was delivered, but confirming it was actually on screen needs signal from the client, which is one more reason the industry is moving toward server-guided insertion where the client fires the trackers. If your revenue depends on verified viewability, design the client-side reporting path from day one rather than bolting it on when a buyer audits you.

Live vs VOD SSAI: two different problems

SSAI on demand and SSAI on a live stream share a stitcher but not much else. VOD is the forgiving case: you know the content ahead of time, can pre-condition creatives, and latency doesn’t matter. Live is where SSAI earns its keep and its headaches, because everything happens in the seconds before the break.

VOD SSAI lets you decide ad placement in advance, transcode creatives before anyone watches, and cache aggressively. The main design choice is how personal the ads should be, which trades cache efficiency against targeting. It’s also priced lower: MediaTailor charges half the live rate for VOD.

Live SSAI has to react in real time: the SCTE-35 cue arrives, the stitcher calls the ad server, conditions the creative, and splices it before the break window closes, across thousands of concurrent viewers at once. Cue reliability, ad-decision latency, and graceful fallback when no ad fills are the make-or-break details. This is the same real-time discipline behind our video monetization platform work, where a missed break is lost revenue you never get back.

Mini-case: an SSAI ad tier for Tradecaster

Situation. Tradecaster ran live video rooms for stock traders on a single paid subscription. Growth was capped at the paywall: first-time visitors bounced before they ever saw the product, and the team wanted a free, ad-supported tier without cheapening the premium experience or letting ad blockers strip the ads they’d sell.

Plan. We built an SSAI pipeline into Tradecaster that stitched brand-safe fintech ads into the free “viewer” tier’s live streams, with ad breaks at session start so the trading content itself stayed uninterrupted. Because the ads were server-stitched, blockers couldn’t remove them, and the break played at the stream’s own bitrate. An entitlement engine kept the premium tier ad-free, and payments stayed on Stripe. The monetization-model side of this build, including how we chose the tiers, lives in our streaming monetisation guide.

Outcome. The ad tier landed $4–6 in monthly ARPU thanks to high-CPM fintech inventory, and double-digit monthly conversion from ad-tier viewers into paid subscriptions more than paid back the extra engineering inside a quarter. Premium revenue held up because the ad tier was deliberately the lesser product. Want a similar assessment of your ad stack? Grab a 30-minute call.

A decision framework in five questions

Five questions route you to a path: who sells your ads, which platforms you serve, your volume, your control needs, and your data rules. Answer them in order and the architecture picks itself, from a free Google tool to a custom stitcher.

Figure 4. Four questions route you to a managed vendor, Google’s stack, a broadcast specialist, or your own stitcher — with a rule of thumb on when building starts to pay off.

1. Do you already sell ads through Google? If your demand runs on Ad Manager 360, Google DAI is the low-friction path and the stitcher is effectively free. If not, you want an ad-server-agnostic stitcher like MediaTailor.

2. CTV and FAST, or web and mobile? On TV, SSAI or SGAI is the answer for a broadcast-grade break. On web and mobile, SSAI mainly earns its place by beating ad blockers; if blocking isn’t hurting you, CSAI may be enough.

3. What’s your monthly insertion volume? Under the high tens of millions, a per-insertion cloud fee is noise next to salaries, so buy. Into the hundreds of millions, the fee starts to rival a team and building earns its keep.

4. How much control do you need? If you need custom ad decisioning, unusual formats, or ad insertion as your actual product, own the stitcher. If it’s a feature under your real product, rent it.

5. Where must the data live? If contracts or regulation forbid sending streams and viewer signals to a third party, a custom or on-prem stitcher is the only path. Otherwise a managed vendor with the right certifications is fine.

Five pitfalls that break SSAI projects

SSAI projects rarely fail at the demo. They fail a few weeks in, on the same five problems. Knowing them upfront is the difference between a launch and a rebuild.

1. Treating SSAI as a checkbox, not a pipeline. Stitching is the easy 20%. Creative conditioning, ad-decision latency, fallback slates, and beacon hygiene are the other 80%, and they’re where a naive build falls over in production.

2. Ignoring the invalid-traffic trap. If you don’t forward the viewer’s real IP and user agent, measurement vendors flag your impressions as fraud and buyers don’t pay. Design the header pass-through before you serve a single ad.

3. Underbudgeting ad transcoding. Every creative has to be re-encoded to match your bitrate ladder, or the ad break will jump quality and give the SSAI away. That’s compute and, on managed tools, a line item past the free allowance.

4. Trusting live SCTE-35 you don’t control. On live, a missed or malformed cue means a missed break and lost revenue. Test cue handling against real signal, and always have a fallback for when no ad fills in time.

5. Locking in too early. Pick a stitcher that keeps your ad server and manifests portable. If switching vendors means re-plumbing your whole ad path, you’ve traded a monthly fee for a strategic hostage situation.

KPIs: what to measure once ads are live

Three buckets tell you whether your SSAI is healthy: ad quality, business yield, and reliability. Pick one hard number in each and watch it weekly.

Quality KPIs. Ad fill rate (share of breaks that get a paid ad), ad-break error rate (cues that fired but didn’t serve), and rebuffering at the ad boundary. A break that stalls or shows a slate is a viewer you’re training to leave.

Business KPIs. Ad-tier ARPU, effective CPM, and yield (fill rate times CPM). The one that matters most is recovered-versus-blocked inventory: the whole reason you chose SSAI is that this number stops leaking. Tie it to a dollar figure or nobody funds the next improvement.

Reliability KPIs. Measured-impression rate (the share of served ads that count as valid, not IVT), stitcher latency at the break, and manifest error rate. These are the numbers that decide whether advertisers keep buying, and they’re the ones a managed vendor quietly handles for you.

When NOT to use SSAI

Don’t reach for SSAI if you don’t run ads, if your ad formats need to be interactive, or if you have no way to measure server-side impressions properly. In those cases SSAI adds cost and complexity for no gain, and client-side or server-guided insertion is the smarter call.

If your ads are shoppable, clickable, or otherwise depend on client-side interaction, CSAI keeps that behavior that stitched ads make awkward. If your audience is entirely on connected TV where blocking is rare, you still get SSAI’s smooth break, but the ad-block argument doesn’t apply, so weigh it against SGAI’s better tracking. And if you can’t yet forward real viewer signals to your ad server, fix measurement before you turn on server-side stitching, or you’ll serve ads that don’t get paid.

The trend line still points at server-side. As HLS Interstitials and SGAI mature through 2026, the middle ground gets you unblockable delivery with client-grade tracking, which is why we design new ad tiers to support the interstitial path even when they launch on plain SSAI. Honesty about the exceptions is what keeps the recommendation credible.

FAQ

What is server-side ad insertion (SSAI)?

SSAI is a technique where a server stitches ads directly into a video stream by rewriting each viewer’s HLS or DASH manifest, so content and ads arrive as one continuous stream. Because the player never makes a separate ad call, client-side ad blockers can’t easily strip the ads, and the break plays at the same quality as the content.

What’s the difference between SSAI and CSAI?

CSAI (client-side ad insertion) has the player call an ad server at each break, which allows rich targeting and interactive formats but is blockable and can stall at the ad. SSAI (server-side) stitches the ad into the stream on the server, so it survives ad blockers and plays smoothly, at the cost of harder server-side tracking.

What is SGAI (server-guided ad insertion)?

SGAI is a hybrid where the server signals the ad break using Apple HLS Interstitials or DASH events, and the client player fetches and inserts the ad itself. It keeps SSAI’s unblockable delivery while restoring client-side targeting and tracking accuracy, and it’s the direction most 2026 CTV builds are heading.

How much does SSAI cost?

Managed SSAI is cheap per insertion. AWS Elemental MediaTailor charges $0.50 per 1,000 live ad insertions and $0.25 per 1,000 for VOD (AWS pricing page, July 2026), plus ad transcoding past a free allowance and delivery egress. Google Ad Manager DAI has no per-insertion sticker price but takes a share through GAM. A custom build trades those fees for compute plus an engineering team.

Does SSAI stop ad blockers?

Largely, yes. Because the ad is part of the same stream as the content and there’s no separate ad request, client-side blockers have nothing distinct to intercept. It’s the most effective way to beat browser and mobile blockers, which matters most on web and mobile, where roughly 43% of users run one (Cropink, 2026). On connected TV, blocking is already rare.

Do I need SCTE-35 for SSAI?

For live and linear, effectively yes: SCTE-35 is the in-band cue that tells the stitcher where ad breaks start and end, and it’s the standard broadcast already uses. For VOD you can place break points yourself, but most pipelines still express them as SCTE-35 so the same stitcher works for both live and on-demand content.

Should I build SSAI or use a vendor?

Use a vendor unless volume or control forces a build. Managed stitchers hide the fleet, transcoding, and tracking for a per-insertion fee, and they win until that fee rivals an engineering team, which happens in the high tens to hundreds of millions of insertions a month. Build when you need custom ad logic, data residency, or ad insertion as your core product.

Does SSAI hurt ad tracking and viewability?

It makes tracking harder, not impossible. Because beacons fire from your server, impressions can look like invalid traffic unless you forward the viewer’s real IP and user agent (the X-Forwarded-For and X-Device-User-Agent headers per IAB guidance). Verified viewability still needs a client-side signal, which is one reason SGAI, where the client fires trackers, is gaining ground.

What to read next

Ready to add SSAI to your platform?

Server-side ad insertion stitches ads into the stream so they survive ad blockers and play like broadcast. In 2026 that matters because ad-supported streaming is where the money moved and blockers are trying to skim it. For most teams a managed stitcher like MediaTailor at $0.50 per 1,000 insertions or Google DAI beats building, until volume or control pushes you to own the stack, and SGAI is the path worth designing toward.

Whichever way you lean, get the measurement right so your impressions get paid, budget for creative transcoding, and don’t trust a live cue you can’t control. Our streaming engineering team has wired SSAI into real ad tiers end to end. If you want a second opinion on build versus buy, that’s a conversation we enjoy.