What Is SGAI? Server-Guided Ad Insertion Explained

For years, streaming services picking an ad-insertion strategy faced a hard either/or. Client-side ad insertion (CSAI) gave you accurate measurement and interactivity but lost ads to ad blockers and struggled on TVs. Server-side ad insertion (SSAI) survived ad blockers and played everywhere but weakened measurement and locked out interactive formats. SGAI — server-guided ad insertion — is the hybrid that tries to end the trade-off, and it’s the fastest-moving topic in streaming monetization heading into 2026 after being formalized as a standard in late 2025. This guide explains what SGAI is at a technical level, then compares it head-to-head with SSAI and CSAI so you can see exactly where it fits.

What Is SGAI?

Server-guided ad insertion is an ad-delivery architecture where the server decides which ad plays and when, but the player fetches the ad and executes playback and tracking on the client. It deliberately splits the ad-insertion job across the two halves that CSAI and SSAI each tried to own entirely. The server keeps control of ad decisioning — the valuable, centralized part — while the player regains control of rendering and measurement — the part that needs to happen on the device to be accurate.

The name is precise: the server guides the player rather than doing the work for it (SSAI) or leaving the player to do everything (CSAI). Instead of stitching ad segments directly into the content byte stream the way SSAI does, the SGAI server sends the player a manifest containing ad-opportunity signals plus a description of what should fill each opportunity. The player reads those signals, requests the actual ad creative, splices it into playback locally, and fires its own tracking beacons through the standard measurement libraries it already runs.

A plain-language analogy

Think of the three ad insertion models as three different ways to cater a dinner. Each approach gets food to the table, but who prepares, delivers, and serves it changes the experience.

CSAI is like a guest who drives to the store, buys the food, cooks it, and serves it. They have complete control, but they can get stuck in traffic or be turned away at the door—the equivalent of an ad blocker preventing ads from loading.

SSAI is like hiring a caterer who prepares everything off-site and delivers finished plates that look identical to the host’s own cooking. The experience is seamless and difficult to block, but the host cannot see exactly what was served or make last-minute changes for individual guests.

SGAI is like the caterer providing a detailed menu and the ingredients while the venue’s kitchen performs the final plating. The decision about what to serve stays centralized, but the final assembly—and the ability to monitor it, personalize it, and adapt it to each guest—remains local.

How SGAI Works, Step by Step

An SGAI ad break moves through five stages. The division of labor between server and player is the thing to watch:

1. Signaling. The server marks an ad opportunity in the manifest the player is already receiving, using a standardized in-manifest signal (HLS Interstitials or MPEG-DASH events, described below). The signal says “an ad break belongs here, of this duration.”
2. Ad decision (server-side). The server — or a service it calls — runs the ad-decision logic: it queries the ad decision server over VAST, applies targeting rules, and selects which creative should fill the opportunity for this session. This is the part SGAI keeps centralized, exactly as SSAI does.
3. Guidance delivered to the player. Rather than stitching the chosen ad into the stream, the server hands the player a reference to it — typically a URL or a sidecar description the player resolves. The player now knows what to fetch and when to play it.
4. Ad fetch and execution (client-side). The player requests the ad creative directly, loads it, and splices it into playback at the marked opportunity. Because the player controls rendering, it can composite overlays, honor interactive formats, and manage the transition natively.
5. Tracking (client-side). The player fires impression and quartile beacons and runs the industry-standard measurement library (the IAB Open Measurement SDK) directly on the device — so the impression data carries the real device context instead of the server’s.

The pivotal difference from SSAI is in stages 4 and 5. SSAI does the fetch, the splice, and the tracking on the server, so the player only ever sees one continuous stream. SGAI moves those three back to the player while keeping the decision on the server. That single architectural choice is what recovers measurement accuracy and interactivity without giving up centralized ad control.

The Signaling Layer: HLS Interstitials and DASH Events

SGAI depends on a way to mark ad opportunities inside the manifest that the player understands natively. Two standards provide it. On the HLS side, HLS Interstitials — an extension to the HLS specification — let a playlist declare a timed interstitial (an ad) that the player resolves and plays without the content stream itself being modified. On the DASH side, MPEG-DASH events and the associated event-stream mechanisms carry the equivalent ad-opportunity markers. Both approaches share a key property: the content manifest advertises where an ad goes, but the ad itself is resolved separately by the player.

This is a meaningful departure from the SSAI signaling model. In SSAI, the underlying trigger is usually an SCTE-35 cue that the server consumes and then hides from the player by rewriting the manifest into one seamless timeline. In SGAI, the ad-opportunity marker is deliberately left visible to the player, because the player is the component that will act on it. The standardization of these in-manifest signals is precisely what made SGAI practical to deploy at scale, and why it moved from a vendor idea to an industry standard through 2025.

Because the signaling lives in the manifest rather than being baked into stitched segments, the same content segments can be cached and reused across every viewer, while personalization happens through the lightweight per-session guidance. That has favorable implications for CDN efficiency, which we return to below.

It’s worth being precise about what the player actually receives. The manifest carries the ad-opportunity marker—a timed range that indicates an interstitial belongs at a specific point and how long it should last. Separately, the player resolves what fills that range, either by following a reference the server supplies or by requesting guidance the server has prepared for that session.

This two-part design—a stable marker in a shared manifest, combined with a per-session resolution the player performs—is what allows Server-Guided Ad Insertion (SGAI) to preserve CDN caching while still delivering personalized ads. Shared content remains cacheable, while each viewer receives a tailored advertising experience.

It also means the player must be built to understand these markers. A legacy player that ignores HLS Interstitials or DASH events simply won’t act on the ad opportunity. As a result, player compatibility—not server capability—is the primary gating factor for SGAI adoption.

The Three Models Compared: CSAI, SSAI, SGAI

To place SGAI properly, it helps to define the two models it descends from, then compare all three across the dimensions that actually drive the decision.

CSAI — Client-Side Ad Insertion

The original approach. The player holds two sources — content and ads — and when it reaches a break, it calls the ad decision server, downloads the ad, and plays it, then resumes content. Everything happens on the device. Strengths: excellent measurement (the beacons fire from the real device), rich interactivity, and easy personalization. Weaknesses: ad blockers can pattern-match and block the ad requests; every transition is a visible pipeline change; and it works poorly on connected-TV devices that can’t run a heavy JavaScript ad SDK. CSAI still dominates browser and short-form video, where every device runs an SDK already.

SSAI — Server-Side Ad Insertion

The connected-TV workhorse. A server rewrites each viewer’s manifest to stitch personalized ad segments into the same byte stream as the content, so the player sees one continuous program. Strengths: it survives ad blockers, plays on every device class without a custom SDK, and produces a seamless TV-like experience — which is why it’s the default for CTV and FAST channels. Weaknesses: measurement fidelity drops because beacons fire from the server rather than the device; interactive formats are hard because the ad is just stitched pixels; and the per-session manifest manipulation and ad conditioning make it the most expensive model to operate.

SGAI — Server-Guided Ad Insertion

The hybrid. The server decides the ad (like SSAI) but the player fetches, plays, and tracks it (like CSAI). Strengths: it aims for SSAI-level ad-blocker resistance and reach while restoring CSAI-level measurement accuracy and interactivity, and it can be more CDN-efficient because content segments stay shared across sessions. Weaknesses: it’s the most complex to implement, it needs players that support the interstitial/event signaling and the client-side tracking layer, and — as the newest model — it has fewer mature implementations and some device compatibility still catching up.

Side-by-side comparison

The dimensions that decide most real deployments:

Why SGAI Matters: Measurement and Interactivity

Two structural problems with SSAI explain why the industry invested in SGAI at all.

The first is measurement. Under SSAI, impression and quartile beacons fire from the ad-insertion service, not the viewer’s device, so the ad ecosystem loses the real device context — the true IP, the true user agent, and on-device viewability. That gap makes attribution harder and contributes to elevated fraud rates on connected TV, because a beacon that fires from a server IP is far harder to validate than one that fires from a real device. Because SGAI returns the fetch and tracking to the player, the device fires its own beacons and runs the standard on-device measurement library, restoring the fidelity advertisers expect from client-side delivery — and, in turn, the CPMs that come with verifiable impressions.

The second is interactivity. When ads are stitched into the content stream as plain segments, they are just pixels — the player can’t composite anything on top or respond to input. SGAI’s client-side execution unlocks the interactive formats that stitched SSAI structurally cannot express.

Interactive ad formats SGAI unlocks

Alongside the SGAI signaling standards, the industry defined a set of richer formats that depend on client-side compositing:

• Pause ads — an ad (often a static or lightweight unit) that appears when the viewer pauses playback, filling otherwise unmonetized screen time.
• Overlays — graphics or banners composited on top of playing content without interrupting it.
• L-shaped frames — the content shrinks into an L while an ad occupies the freed border, common in live sports and news.
• Squeezebacks — the content is squeezed to make room for a promotional element during a transition.

None of these are possible when the ad is a stitched segment indistinguishable from content. They require the player to be an active participant in ad rendering — which is exactly what SGAI restores.

SGAI and Delivery Cost

There’s a delivery-economics angle that’s easy to miss. Under SSAI, the ad-insertion service produces a personalized manifest per session and often transcodes ad creative to match the content’s encoding ladder — both real costs that scale with audience. Under SGAI, the content segments stay identical across all viewers because ads aren’t stitched into them, so they cache cleanly at the edge and personalization rides on lightweight per-session guidance instead of per-session stream manipulation. In principle this rebalances cost: less server-side manifest manipulation and conditioning, at the price of more player-side complexity.

For any of these models, delivery still rests on a video-capable CDN that can serve both content and ad segments quickly and keep cache hit ratios high. As ad-supported streaming keeps growing across FAST and CTV, the interaction between ad-insertion architecture and delivery efficiency is becoming a first-order design decision, not an afterthought.

Which Model Should You Use?

There is no single winner — the honest answer for most services in 2026 is that they run more than one, chosen per device class and priority. A practical way to decide:

6. Browser and short-form video → CSAI is still the natural fit, since every device runs a JavaScript ad SDK and measurement is already strong.
7. Connected TV and FAST today → SSAI remains the default, because it plays on every TV device without a custom SDK and beats ad blockers.
8. Mobile apps and modern players where measurement and interactivity matter → SGAI is the strategic choice, and the one to pilot now if your players can support the signaling and tracking layer.
9. Mixed audiences → run a split deployment (for example SSAI on CTV, CSAI on web, SGAI on mobile) behind an abstraction layer that picks the model per session.

The trajectory is clear even if the timing isn’t: SSAI is the present default for the living room, CSAI holds the browser, and SGAI is the model most likely to absorb share as player support matures and advertisers push for the measurement and interactivity it restores.

Bringing Ad Insertion and Delivery Together

Whichever model you choose, the ad-insertion layer and the delivery layer have to be designed together — the cue signaling, the ad-decision path, the player behavior, and the CDN that carries both content and ad segments all affect the viewer’s experience and your fill and completion rates. If you’re building or scaling an OTT or FAST platform and want your ad-insertion strategy and global delivery planned as one system, the 5centsCDN team can help you match the right insertion model to your device mix and delivery footprint.

Frequently Asked Questions