SSAI (Server-Side Ad Insertion)

SSAI (server-side ad insertion) stitches ads into a video stream on the server, before the client ever sees it. It works by rewriting the manifest. At each marked ad break, the viewer's playlist points at ad segments chosen for that viewer. So the player downloads one continuous run of HLS or DASH segments. The player never learns which of the segments are ads.

SSAI is not CSAI (client-side ad insertion). The device makes no separate ad request and runs no ad player. So there is no ad call for a blocker to intercept.

SSAI is not a protocol and not a CDN feature. It is a service that sits between the CDN, the origin and an ad decision server (ADS). It uses the CDN to deliver both content and ad segments.

The industry also calls it DAI (dynamic ad insertion). Strictly, DAI is the umbrella term. It covers both insertion modes, server-side and client-side. But Google names its own server-side product Dynamic Ad Insertion. Google describes it as the first SSAI solution accredited by the Media Rating Council. So the two names are used interchangeably in practice.

For anyone running delivery, SSAI reduces to a single asymmetry. The media caches. The manifest does not.

How it works

The stitcher (AWS Elemental MediaTailor, Google Ad Manager DAI, Yospace, Brightcove SSAI and others) sits between the CDN, the origin and the ADS. For one viewer, the sequence is:

1. The origin manifest marks the breaks. MediaTailor inserts ads where SCTE-35 ad markers are present in the origin manifest. In HLS, these markers are signalled by EXT-X-CUE-OUT and EXT-X-CUE-IN. Markers are recommended but not required. With no markers, the stitcher makes a single ADS call and turns a VAST response into a pre-roll, or uses the time offsets in a VMAP response to build breaks through the manifest.
2. The player or the CDN requests the manifest from the stitcher. That request carries parameters from the player that describe the viewer. Personalization is based on those parameters.
3. The stitcher asks the ADS, passing the viewer information. The ADS picks ads from current campaigns and returns the URLs of the creatives in a VAST or VMAP response.
4. The stitcher rewrites the manifest. It replaces the ad markers from the origin manifest with URLs pointing at ad segments for that specific viewer. Those ad segments are transcoded to match the encoding characteristics of the origin content.
5. The fully personalized manifest goes back to the requesting CDN or player. The player then fetches content and ad segments through the CDN, in playback order.
6. Beacons record what was watched. The ADS tracks milestones such as start of ad, middle of ad and end of ad. At session initialization, the player declares whether it or the stitcher will send those beacons.

Two details decide how a stream behaves. First, live and on-demand differ. In live streams, MediaTailor always performs ad replacement, preserving the time between the markers as closely as possible. VOD is inserted or replaced, depending on marker configuration. If a break runs out of transcoded ads, the stitcher plays a configured slate or resumes the underlying content. Second, the stitcher works on manifests, not on media. It never needs to inspect the content segments. So, in Yospace's words, it is agnostic to plaintext or DRM-protected content. The ad creatives are the exception. They must be conditioned to the content's encoding before they can be stitched.

Why it matters for a CDN

SSAI splits one stream into two objects with opposite cache behaviour. AWS states the rule plainly for MediaTailor: personalized manifests cannot be cached, but content and ad segments should be cached aggressively. The manifest is unique to a viewer and an ad decision. So its TTL is 0 seconds, and every manifest request travels to the stitcher. The content segments are identical for everyone, and the ad creatives are shared by everyone who was served the same ad. So both are cached for 24 hours or more, and a popular creative is served from the edge to a very large audience.

The consequence for capacity planning is that the CDN absorbs the segment volume, while the stitcher absorbs the manifest volume: one uncollapsed request per viewer per playlist refresh. The levers are ordinary CDN ones: long segment TTLs, request collapsing at the CDN for concurrent requests, and an origin shield layer between the edge and the origin to cut origin requests. This asymmetry is also what server-guided ad insertion (SGAI) attacks. SGAI keeps a shared, non-personalized media manifest that stays cacheable, and moves per-viewer decisions into interstitial asset lists instead. That is why SGAI is a different insertion method, rather than another name for SSAI.

What CDNs do

The recommended architecture positions the CDN between viewers and ad insertion, with ad insertion reading content directly from the origin. AWS credits that layout with effective caching of content and ad segments, reduced request load on MediaTailor, faster delivery, simpler URL management and consistent personalized advertising across devices. Concretely, a CDN in an SSAI workflow does three things:

• Splits cache behaviours by object type. MediaTailor's caching guide sets multivariant playlists, media playlists and DASH MPDs to a 0-second TTL, with a cache key of URL path plus all query parameters. It sets content and ad segments to 24 hours or more, with a cache key of URL path only.
• Routes segments to two different origins. Content segment requests go to the content origin. Ad segment requests go to the ad-insertion service, which serves the transcoded ads from its own S3 bucket. The CDN prefix set on the MediaTailor playback configuration is what makes the service write your CDN's domain names into the content and ad segment URL prefixes it puts in the manifest.
• Forwards the personalization. All manifest requests are forwarded to the stitcher with every query parameter and header intact, so the ADS can use those parameters to decide which ads to insert.

Provider integrations differ in how much of the workflow they own. Google Ad Manager offers two modes. In full DAI, Ad Manager builds the ad pod, conditions the creatives and does the manifest manipulation. In DAI Pod Serving, Ad Manager only builds and conditions the pod, then sends ready-to-stitch ad pods to a partner's existing streaming solution, which does the manifest manipulation. Yospace pulls only the stream manifest from the origin or CDN entry point. Brightcove adds auto failover with ad block detection: it plays client-side ads when no blocker is present, and server-side ads when one is detected.

Watch out for

• A personalized manifest in a shared cache serves the wrong viewer's ads. AWS's stated reason for the 0-second manifest TTL is that viewers must receive up-to-date ad content. AWS separately recommends including personalization parameters in the cache key if you support targeted advertising. Both point the same way: nothing that identifies one viewer's ad decision may be reused for another.
• Do not put the CDN between the stitcher and the origin. AWS explicitly does not recommend it. Query parameters mishandled in the cache key make the stitcher receive the wrong manifest. Some CDNs deliver corrupt gzip payloads that cause manifest parsing failures, and stale live manifests desynchronise content and ads. It also adds hops and complicates troubleshooting.
• An unconditioned creative does not play on first sight. If an ad has not yet been transcoded to match the content, MediaTailor skips inserting it and uses MediaConvert to prepare the ad for the next request instead. A break with too few transcoded ads falls back to the configured slate, or to the underlying content when there is no slate.
• Ad-block resistance comes from the missing ad call, not from indistinguishable URLs. Brightcove markets SSAI as something that cannot be blocked like client-side ads can. But ad segments still travel under their own path: MediaTailor's default ad segment path pattern is /v1/segment/*, and the CDN ad segment prefix is a configuration choice. What a blocker cannot see is a separate VAST or VPAID call from an ad player, because there is none.
• Beacon placement is a delivery decision, not a detail. Ad tracking can be emitted by the player or by the stitcher. Brightcove advises server-side beacons for devices that cannot run its player, and for web cases where ad blocking is enabled, since client-side beacons are as blockable as client-side ads.

Best practice

• Cache content and ad segments for 24 hours or more. Set every personalized manifest to a 0-second TTL. Turn on request collapsing at the CDN, so concurrent requests for the same object become one.
• Key manifests on URL path plus all query parameters, and segments on URL path only. Include personalization parameters in the cache key whenever campaigns are targeted.
• Place the CDN between viewers and the ad-insertion service. Forward manifest requests to it with all query parameters and headers. Set the CDN prefix on the playback configuration, so segment URLs carry your CDN's hostnames.
• Give ad segments their own cache behaviour and origin, separate from content segments.
• Precondition and transcode creatives to the content's encoding, and configure a slate. Set a personalization threshold to bound unfilled ad time in a break.
• Test HLS and DASH, live and VOD, with and without a browser ad blocker. Confirm beacons arrive from whichever side you chose to send them.