Server-Side Ad Insertion (SSAI): How It Works With Your Ad Server

It's the 80th minute of a cup final on your FAST channel. Two hundred thousand viewers hit the same ad break in the same second, and the server that inserts ads into the stream asks your ad server for two hundred thousand ads at once.

Requests that take too long get a filler screen instead of a paid ad. The rest all look like they come from one server, so your ad server can't tell where viewers are or how many times each one has seen the same ad. Advertisers see an audience they can't verify, and they pay less for it.

Viewers didn't notice a thing: the stream played smoothly, because server-side ad insertion (SSAI) did its part and put the ads in. Choosing those ads is a separate job that belongs to the ad server, and here the ad server couldn't see who was watching. The fix starts with making sure each viewer's IP address, device and device ID travel from the stitcher to the ad server.

This guide shows how the two halves fit together, where that viewer data gets lost and what to set up on each side so every break pays. It's written for CTV, FAST and streaming teams, and for anyone who needs to know where streaming ad revenue gets lost.

What Is Server-Side Ad Insertion?

Server-side ad insertion is a way of serving video ads in which a server stitches the ads into the stream before it reaches the viewer. It's an old television idea rebuilt for streaming: the ad travels inside the show, so the player gets one continuous stream and never makes a separate ad call. The method is often shortened to SSAI.

CTV apps, FAST channels, live sports and linear streams run on SSAI for four reasons:

• One continuous stream: no buffering or black frames between content and ads.
• Consistent playback: the same break plays on every TV, stick and console, because there's no ad player on the device.
• Broadcast-like quality: ads are transcoded to match the content's resolution and bitrate.
• Fewer lost ads: there's no separate ad request for a blocker to catch.

The trade-offs show up at the ad decision layer, covered in the section on what breaks behind a stitcher.

How Does Server-Side Ad Insertion Work? From SCTE-35 Marker to Stitched Stream

Server-side ad insertion works in six steps, from the break marker to the tracking beacon, and nothing in them is literally stitched. The SSAI stitcher, also called a manifest manipulator, rewrites each viewer's playlist so it points to ad segments as well as content.

1. The stream marks where the break goes: SCTE-35 signals in live streams, ad markers or cue points in on-demand (VOD) video.
2. The stitcher, which sits between the video source and the viewer, spots the marker.
3. It asks the ad decision server which ads to play, sending a VAST tag request on the viewer's behalf.
4. It converts the ad video to match the stream's format and quality (transcoding).
5. It updates each viewer's playlist (the HLS or DASH manifest) so the ad plays in the break.
6. It reports that the ad played (fires the tracking beacons), or leaves that to the player.

The process is also called ad stitching or dynamic ad insertion. VMAP can lay out the breaks across long content, but the stitcher still sends a VAST request for each break. The VAST vs VMAP comparison explains the difference.

Does Server-Side Ad Insertion Stop Ad Blockers?

A blocker can't remove what it can't tell apart from the show. Mostly, it's a side effect. Ad blockers work from filter lists: they block requests to domains known to belong to ad servers and let the publisher's content through.

With client-side insertion, the player requests each ad from such a domain, so a blocker can stop it. With server-side ad insertion, the ad segments arrive inside the same stream as the content, so there's no separate ad request to block. To cut the ad, a blocker would have to cut the show along with it.

Three caveats keep this from being the whole story:

• Tracking can still be blocked. Beacons the player fires itself, such as client-side reporting or verification scripts, go to tracking domains a filter list may cover. The ad plays, but some of the counting is lost.
• Server-guided insertion brings the request back. Under SGAI the player fetches the ad itself, so on the web that request is visible to blockers again.
• It's a by-product. SSAI was built for smooth playback and consistent quality across devices. On the web, fewer blocked ads is a bonus. For display and web video, our guide to protecting ad revenue from ad blockers covers what else works.

Does an SSAI Stitcher Need an Ad Server? The Ad Decision Server Explained

Yes. The stitcher delivers the ad, but an ad decision server chooses it, and that choice decides what the viewer sees and what the publisher earns. An ad decision server (ADS) receives the ad request and returns the ads to play, usually as a VAST response.

The ad decision server owns everything that makes a break pay:

• Which ad, which advertiser, at what price and priority, including direct deals against programmatic demand.
• Targeting, pacing and frequency.
• Reporting and log-level data for reconciling with advertisers.

That's also where demand competes. Direct campaigns and SSP bids meet in the ad decision server, so fill rate and CPM are decided there. The stitcher only inserts the result.

The choice of stitcher limits the choice of ad server. Google DAI is part of Google Ad Manager 360, and Ad Manager makes the decision. A publisher leaving Google Ad Manager usually needs a different stitcher as well.

Which SSAI Stitchers Work With Your Own Ad Server? MediaTailor, Google DAI, Yospace, Broadpeak and Others

Most SSAI stitchers can call any ad server that answers in VAST, and they're bought like bandwidth: per thousand insertions or by contract. The column that decides fit is whether a stitcher accepts your ad server.

As of November 2026; vendor pricing and features change.

Server-Side vs Client-Side vs Server-Guided Ad Insertion: Where the Ad Decision Happens

Server-side, client-side and server-guided ad insertion all ask the same ad decision server for the ad. They differ only in who plays it and who tracks it.

Server-guided ad insertion uses HLS Interstitials and MPEG-DASH events to tell the player when to fetch an ad. It brings back device-side measurement and interactivity, but the decision still happens on the server.

For the ad server, SGAI raises the bar. The VAST response now has to work in a real player that measures viewability and runs verification, so VAST 4.1 or later with Open Measurement becomes a requirement. Epom Ad Server already serves both.

What Breaks Behind an SSAI Stitcher, and How to Fix It

Behind an SSAI stitcher, the ad request comes from the stitcher's data centre. Unless the stitcher forwards the viewer's data and the ad server reads it, three things break without an error.

Further down the chain, other problems have nothing to do with viewer data: cached creatives, fake stitchers and buyers who can't verify what they buy. Each part below names the problem, then the fix.

Why Does Geo Targeting Break Behind a Stitcher?

With a data-centre IP address, every viewer appears to be wherever the stitcher runs. Regional campaigns either miss their audience or bill for impressions outside it.

The fix: the stitcher passes the viewer's IP address in the X-Device-IP header or an IP macro in the VAST tag. The ad server then geolocates that address, not the stitcher's.

Why Does SSAI Traffic Look Like Bot Traffic?

Thousands of requests and beacons from one server address look like bot traffic. IAB VAST 4.1 (2018) defines device headers such as X-Device-IP and X-Device-User-Agent so a stitching service can pass the viewer's details along.

Why Do Frequency Caps Fail With SSAI?

On the web, an ad server counts how many times a person has seen an ad with a browser cookie. Behind a stitcher there's no browser and no cookie, and every request carries the stitcher's IP, so an ad server that caps by cookie or IP counts the whole audience as one viewer. The cap then blocks everyone or nobody.

See frequency capping best practices for how caps should work.

One more trap: if the ad server falls back to an old VAST version, the response loses features such as Open Measurement, which arrived with VAST 4.1.

Why Does an Old Ad Keep Playing After You Replace the Creative?

Stitchers have long memories: each creative is transcoded once and the result is stored under its creative ID. AWS MediaTailor keeps transcoded ads indefinitely, so a new video file that arrives under an old ID plays as the old spot.

The reverse hurts too. A new ID for a file that was already transcoded makes the stitcher skip the ad while it transcodes again, which MediaTailor logs as NEW_CREATIVE (AWS troubleshooting guide).

Is SSAI Traffic Easier to Fake?

It can be, because every legitimate SSAI request comes from a data centre: a fraudster can pose as a stitcher and send requests for TVs and viewers that don't exist. That's SSAI spoofing.

The largest known case, ICEBUCKET, was uncovered by White Ops (now HUMAN) in April 2020. Near its peak it made up almost 28% of the programmatic CTV traffic the company could see, about 1.9 billion ad requests a day.

Will a Lesser-Known Stitcher Get Traffic Flagged as Invalid?

It can, and correct headers alone may not prevent it. Verification vendors recognise established stitchers by their server IP ranges, so traffic from a stitcher they don't know looks like ordinary data-centre traffic. Impressions get filtered as invalid, and fill and CPMs drop until the stitcher is recognised.

Your own ad server shouldn't add to the problem. In Epom Ad Server, whitelist the stitcher's egress IP ranges; the suspected-IP check for video impressions is off by default for this reason.

Why Do Buyers Bid Less on CTV Inventory Sold Through a Stitcher?

Buyers price what they can see. When a request passes through a stitcher, three things often go missing: the full supply chain (schain), content signals such as genre, rating and whether the stream is live, and privacy strings such as GPP and COPPA.

Without them, a DSP can't verify the path or target the content, so it bids lower or skips the request.

Since release 154, the Epom VAST tag takes a schain parameter filled from SpringServe, MediaTailor and Brightcove macros, used on sites with the seller type Intermediary or Both. The stitcher's content signals reach DSPs, and its privacy strings do too once an admin turns on Pass privacy signals to DSPs.

The section on how Epom Ad Server works behind a stitcher shows each of these fixes as product settings.

How Epom Ad Server Works Behind an SSAI Stitcher

Epom Ad Server is the ad decision server behind the stitcher: the stitcher calls the Epom VAST tag, Epom picks the ads, and the stitcher splices them in.

What an ad server needs to work behind a stitcher

Five things decide whether an ad server is ready for SSAI: it identifies the viewer instead of the stitcher, caps frequency without cookies, reads CTV signals, returns stitcher-ready VAST, and answers a live break in time.

It reads the viewer behind the stitcher

In Epom Ad Server, the viewer comes from an explicit clientIp, then the X-Device-IP header, then X-Forwarded-For, as IAB VAST 4.1 describes. The device user agent replaces the stitcher's. Device targeting, bot detection and the user agent sent to DSPs then all describe the TV.

The same applies to impression, click and event pixels the stitcher fires. If a stitcher forwards no viewer IP, add its egress ranges as whitelist rows on the IP blacklist tab.

It fills the stitcher's macros for you

A video placement's VAST configuration has a server-side ad insertion picker: IAB standard macros, Google Ad Manager DAI, AWS Elemental MediaTailor, SpringServe (Magnite) or Brightcove SSAI. The tag then carries that vendor's macros for viewer IP, user agent, device ID, ID type, limit-ad-tracking flag and app bundle. The placement also flags the macros the player must pass to the stitcher.

With Google DAI, Epom takes part as VAST demand inside Ad Manager, and the DAI preset fills the macros for that setup. The picker is a list of admin presets: the five above plus FreeWheel and Publica, and an admin can add your own. Fill from document reads a vendor's macro list from its PDF or a screenshot, so a new stitcher no longer needs a product release.

Two guards keep viewers apart. An all-zero device ID and any macro that arrives unreplaced, such as a literal [DEVICEUA], count as not sent. Bid requests from an SSAI placement tell DSPs so, with imp.ssai = 3.

It caps frequency by device ID

With the cap subject set to server-side or mixed, frequency caps count a TV or app viewer by the hashed device advertising ID (Roku RIDA, Samsung TIFA, AAID, IDFA); cookie-based caps work as before. Without a usable ID, the cap falls back to a fingerprint of the viewer's IP and user agent, which counts a whole household as one viewer.

It returns VAST that stitchers can cache

Epom gives every video creative it hosts a stable ID tied to its file and offers a mezzanine file. It also sends only standard tracking event names, because AWS MediaTailor rejects a whole response over a single non-standard one.

Pods can keep competitors apart: one spot per advertiser domain, or per domain and category (off by default), and the same spot never plays twice in one break. For uploaded videos, an operator can apply presets built from 15 streaming publishers' published specs, such as Hulu, Disney+, Peacock and Roku, so a video that misses a site's spec isn't served there. The check is off by default behind a role permission, and Advanced Local Video(s) send each site only the renditions its spec accepts.

It answers a live break in time

In a local burst test that replayed a live break, Epom Ad Server answered 10,000 single-ad calls a second at a p99 of 15 ms. It answered 6,000 three-ad pods at a p99 of 18–24 ms, well inside a stitcher's three-second window.

Set it up in five steps

1. Put the Epom VAST tag in the stitcher's ad decision server URL, with the VAST version set (4.2 by default in the new interface).
2. Pick your stitcher in the placement's SSAI setting, and pass the macros it flags from the player to the stitcher.
3. Set the pod size and competitive separation for the break.
4. Set the frequency cap subject to server-side or mixed so caps use the device ID, and whitelist the stitcher's IP ranges if it doesn't forward viewer IPs.
5. Test the tag in the Epom VAST Inspector before go-live.

Want the ad decisions behind your stitcher to see each viewer behind it? Set up video ad serving with Epom Ad Server.

What Does an SSAI Stack Cost?

Count three bills: the stitcher, the ad server and the player. The stitcher charges per inserted ad, the ad server charges by monthly video impressions, and the player or SDK is usually part of your app.

Take a service with 1 million views a month and four ads per view: 4 million video ads.

Transcoding beyond MediaTailor's free allowance, CDN delivery and player work come on top. A smaller service, 250,000 views with four ads each, fits Epom's Growth plan ($1,000 a month, up to 2M video and HTML5 impressions) plus $250 of VOD stitching.

List prices as of November 2026, monthly billing; annual billing on Epom saves 15%. Sources: AWS Elemental MediaTailor pricing and Epom Ad Server pricing.

Choosing an SSAI Setup for CTV, FAST and Live Streaming

Choose the setup by where your demand lives and who should own the decisions. A stitcher inserts the ads, and the ad decision server picks them and runs reporting. SSPs or direct deals supply the demand for each break.

The stitcher is replaceable infrastructure. Your decision logic, pricing and log-level data shouldn't be.

FAQ