Back to Insights
Monetization · Originally published August 30, 2026 · Substantially updated September 14, 2026 · By Darren Feher, Co-Founder & CTO · Published by Videostream Interactive Partners

Server-Side Ad Insertion for Live Sports: A Practitioner's Guide

Advertising in live sports streaming is technically more demanding than advertising in on-demand video. The stream cannot be paused and pre-processed. Ad decisions must be made in real time, under the timing pressure of a live broadcast. The transition between content and advertising must be invisible to the viewer. Server-side ad insertion — SSAI — is the technology that makes this possible. This guide covers how it works, where it fails, and what teams need to verify before a live event.

What SSAI is and why live sports is different from VOD

Server-side ad insertion means combining advertising content with video content on the streaming server before the combined stream is delivered to the viewer's device. The viewer receives a single, continuous video stream containing both the content and the ads, rather than having their player switch between two separate streams at ad break time.

The alternative — client-side ad insertion (CSAI) — has the video player on the viewer's device make a separate HTTP request to an ad server when it reaches an ad break, download the ad, play it, and then resume the content stream. CSAI is simpler to implement but creates visible seams at the transitions: buffering pauses, quality changes, or black frames. It is also vulnerable to ad blockers, which can intercept the ad request before it reaches the player.

For VOD content, SSAI can be done in advance — the ad breaks are known, the ad creatives can be pre-fetched and pre-transcoded, and the stitched stream can be prepared before any viewer requests it. For live sports, none of this is possible. The stream does not exist until it is produced. Ad breaks are signaled in real time. The SSAI system must detect the break signal, make an ad decision, fetch the creative, transcode it if necessary, and have it ready to stitch — all within the few seconds between the break signal and the break itself.

This timing pressure is the defining challenge of live sports SSAI. A football game has defined commercial break windows. The broadcast schedule does not wait for the ad system. If the SSAI system cannot fill the break in time, the viewer sees slate, silence, or a missed transition — all of which are visible failures.

How ad opportunities are signaled: SCTE-35

In a live sports broadcast, ad breaks are signaled using SCTE-35 markers — a standard defined by the Society of Cable Telecommunications Engineers that is embedded in the MPEG transport stream at the point where an ad break should begin. When a broadcast director triggers a commercial break, the production system inserts a SCTE-35 splice_insert or time_signal message into the stream. This message contains information about the break: when it starts, how long it should last, and sometimes a unique identifier for the break.

The SSAI system monitors the incoming live stream for these SCTE-35 markers. When it detects one, it knows that an ad opportunity is beginning and how long it will last. It then needs to fill that break with advertising content — which requires making a request to an ad decision server.

A problem we repeatedly encounter: SCTE-35 markers that arrive too late. The marker should arrive at least four to five seconds before the break begins — enough time for the SSAI system to make the ad decision request, receive a response, and have the first ad segment ready. Markers that arrive one or two seconds before the break leave no time for the ad decision pipeline to complete, and the break starts with slate or a missed transition.

SCTE-35 marker timing is a production configuration issue, not an SSAI issue. The broadcast encoder or production system controls when the marker is inserted. Verifying marker timing — using the actual production feed, not a test signal — is a required step in pre-event QA.

The ad decision server and the waterfall

When the SSAI system detects an ad break, it makes a request to an ad decision server (ADS) to determine which ads should fill the break. This request includes information about the viewer (if available and consented to), the content being watched, the break duration, and the technical parameters of the stream.

The ad decision server evaluates the available advertising inventory against the break parameters and the viewer context, runs any applicable targeting logic, and returns a response specifying which ads should be played, in what order, and for how long. This response is typically formatted as a VAST document.

Many streaming platforms use a waterfall or unified auction approach: direct-sold campaigns are served first at their contracted prices, and any unfilled inventory is then offered to programmatic buyers. The waterfall adds latency — each tier in the waterfall requires a separate ad decision request if the previous tier does not fill. For live sports, where the pre-break window is short, a deep waterfall can cause fill failures.

AWS MediaTailor is one example of a managed SSAI service that handles the ad decision request, creative fetching, and stream stitching as a managed infrastructure layer. Whether using a managed service or a custom SSAI implementation, the ad decision latency budget — the total time available from SCTE-35 detection to first ad segment ready — needs to be understood and tested before a live event.

VAST, VMAP, wrappers, and why wrapper depth matters

VAST (Video Ad Serving Template) is an XML-based standard defined by the IAB that specifies how an ad server communicates ad creative information to a player or SSAI system. A VAST response contains the URL of the ad video file, the duration of the ad, tracking event URLs (for impression, start, quartile, and completion events), and any companion ad specifications.

A single VAST response describes a single ad. For an ad break containing multiple ads — a 90-second break with three 30-second spots — the collection of ads is called an ad pod. VMAP (Video Multiple Ad Playlist) is a higher-level IAB standard that describes an entire ad schedule for a piece of content, specifying where breaks occur, how long each break is, and providing the VAST responses for each break.

VAST wrappers are a practical problem for live sports SSAI. A wrapper is a VAST response that points to another VAST response rather than directly to an ad creative. Wrappers are used in programmatic advertising chains where multiple intermediaries are involved in serving a single ad. Each wrapper adds a layer of tracking and a redirect to another VAST document. The SSAI system must unwrap the entire chain to reach the actual ad creative.

In our platform work, deep wrapper chains — four or more levels — are a consistent source of ad decision latency problems in live sports. Each wrapper requires an additional HTTP request, and the cumulative latency can exceed the available pre-break window. Limiting wrapper depth in programmatic demand sources, or pre-caching creatives from known demand sources, are operational approaches to managing this problem.

Ad stitching into HLS: encoding requirements and the live-to-ad transition

Once the SSAI system has the ad creative, it stitches it into the live content stream. For HLS (HTTP Live Streaming) — the most common format for live sports streaming — the stream is divided into short segments, typically two to six seconds each. The SSAI system replaces the content segments that fall within the ad break window with ad segments, and updates the HLS manifest (the .m3u8 playlist file) to point to the ad segments instead of the content segments.

For this to work without visible seams, the ad video must be encoded to match the content stream's encoding parameters: the same video codec, the same resolution and bitrate ladder, the same audio codec and loudness normalization, and the same segment duration. If the ad is encoded differently, the player may experience a quality change or a brief stall at the transition. SSAI systems typically transcode ad creatives to match the content stream's parameters before stitching — a process that requires compute resources and adds to the pre-break preparation time.

Audio normalization deserves specific attention. Ad creatives are often produced at different loudness levels than sports content. A viewer who experiences a sudden volume increase when an ad starts — or a sudden drop when the content resumes — notices it immediately. Normalizing ad audio to match content audio (typically -24 LKFS for streaming) is a technical requirement, not an optional enhancement.

The live-to-ad and ad-to-live transitions are the most technically demanding aspects of live sports SSAI. The live stream has continued while the ad was playing — the game does not pause for commercials — so the SSAI system must rejoin the live stream at the correct point after the break ends. A missed transition produces a visible jump or a brief period of wrong content. Testing these transitions on physical devices — not just in a monitoring dashboard — is required pre-event QA.

Fill rate, slate, and what happens when a break cannot be filled

Fill rate — the percentage of available ad break time filled with paid advertising — is a key operational metric. A 90-second break filled with 60 seconds of paid ads and 30 seconds of slate has a 67% fill rate. Low fill rates mean revenue is being left on the table.

What happens to unfilled break time depends on how the SSAI system is configured. Options include: returning to the live content early (which means the viewer rejoins the game before the broadcast break has ended, potentially missing content shown after the break in the broadcast feed); playing a slate (a static image or branded placeholder video); playing house ads (promotional content for the team or platform); or attempting to fill the remaining time with additional programmatic ads.

Slate behavior needs to be configured and tested before a live event. A blank black screen as slate is a visible failure. A branded slate — a team logo or a "We'll be right back" message — is a much better fan experience. The slate video needs to be encoded to match the content stream's parameters, just like an ad creative.

Device differences: mobile versus CTV

SSAI behavior can differ between mobile and CTV platforms, and the differences are not always obvious until a live event reveals them.

On mobile (iOS and Android), the player typically supports HLS natively and handles the stitched stream without special configuration. Ad tracking pixels fire from the SSAI system, not from the player, so ad blockers on the device cannot intercept them. Device identifiers (IDFA on iOS, GAID on Android) are available for targeting if the user has consented, though iOS 14.5+ requires explicit opt-in for IDFA access.

On CTV, the primary device identifiers are platform-specific advertising IDs: Roku's RIDA, Amazon's AFAI, Apple's tvOS identifier. These identifiers allow advertisers to frequency-cap their campaigns and measure reach across CTV devices. Passing these identifiers correctly in the ad decision request requires platform-specific implementation in the CTV app.

CTV devices also have different performance characteristics. An older Roku or Fire TV device may have less processing power than a current-generation device, which can affect how quickly the player can switch between content and ad segments. Testing SSAI transitions on minimum-spec CTV hardware — not just the latest devices — is necessary to confirm the experience is acceptable across the full device population.

Measurement, attribution, and third-party verification

SSAI systems generate impression-level data for every ad served: which ad was played, on which device, at what time, for how long, and whether the viewer watched it to completion. This data is captured through the tracking event URLs in the VAST response — the SSAI system fires HTTP requests to these URLs at the impression, start, quartile, and completion events.

This impression-level data is more granular and more reliable than the panel-based audience measurement used in traditional broadcast. Advertisers receive reports showing how many impressions their campaign delivered, what the completion rate was, and — if the platform supports it — what the reach and frequency were across unique viewers.

Third-party measurement verification — using an independent company to verify that impressions were delivered as reported — is increasingly expected by sophisticated advertisers. For streaming platforms that want to attract national or regional brand advertisers, supporting third-party verification is a practical requirement.

Beyond impression measurement, platforms with a direct fan identity layer can offer attribution reporting: connecting an ad impression to a downstream action taken by the same viewer. This kind of closed-loop attribution is only possible when the platform has an authenticated relationship with the audience — which is why first-party fan data and SSAI are complementary capabilities, not independent ones.

Common failure scenarios and how to prepare for them

SCTE-35 marker not detected

Cause: Marker not present in the feed, or SSAI system not configured to detect the marker format used by the production system.

Result: Ad break is missed entirely. Content plays through the break window.

Mitigation: Verify SCTE-35 detection with the actual production feed before the event. Confirm the marker format (splice_insert vs. time_signal) matches the SSAI system's configuration.

Ad decision latency exceeds pre-break window

Cause: Deep VAST wrapper chains, slow ad decision server response, or high concurrent load on the ad decision infrastructure.

Result: Break starts with slate or a missed transition. First ad segment is not ready when the break begins.

Mitigation: Limit wrapper depth in programmatic demand sources. Test ad decision latency under expected peak load. Configure a fallback to house ads or slate if the decision cannot be completed in time.

Ad encoding mismatch

Cause: Ad creative is encoded at different parameters than the content stream (different bitrate, codec, segment duration, or audio level).

Result: Visible quality change or audio level jump at the content-to-ad transition.

Mitigation: Transcode all ad creatives to match the content stream's encoding parameters before stitching. Test transitions on physical devices.

Live stream rejoin failure

Cause: SSAI system fails to correctly identify the rejoin point in the live stream after the ad break ends.

Result: Viewer sees wrong content, a jump, or a brief period of black after the break.

Mitigation: Test live-to-ad and ad-to-live transitions with the actual production feed. Verify rejoin behavior on all target platforms.

Fill rate collapse

Cause: Programmatic demand drops (common during low-demand periods or for niche content), or ad decision server is unavailable.

Result: Breaks are filled with slate or house ads. Revenue is lost.

Mitigation: Configure house ads as a fallback. Monitor fill rate in real time during the event. Have a direct-sold campaign available as a guaranteed fill source.

Pre-event SSAI readiness checklist

  • Confirm SCTE-35 markers are present in the production feed — test with the actual broadcast encoder, not a test signal
  • Verify SCTE-35 timing: markers should arrive at least 4–5 seconds before the break begins
  • Test the full ad decision chain: SSAI system → ADS → VAST response → creative fetch → transcode → stitch
  • Confirm ad audio is normalized to match content audio levels (typically -24 LKFS for streaming)
  • Verify slate behavior: confirm what plays when a break cannot be filled
  • Test ad-to-content and content-to-ad transitions on physical devices for each target platform
  • Confirm ad tracking pixels fire correctly: impression, start, first quartile, midpoint, third quartile, complete
  • Verify consent signals are passed correctly to the ad decision server
  • Test fill rate with expected demand — confirm programmatic fallback is configured
  • Verify VAST wrapper depth: confirm the ad decision pipeline can resolve wrappers within the available pre-break window
  • Confirm CDN is configured to serve ad segments from the correct origin
  • Test concurrent ad serving at expected peak load — ad decision latency increases under load
  • Verify monitoring is in place for fill rate, ad error rate, and SCTE-35 detection
  • Confirm escalation path to the ad serving vendor is documented and contacts are reachable
  • Run a full end-to-end test with a live feed at least 30 minutes before the event
About the author

Darren Feher is Co-Founder and CTO of Videostream Interactive Partners. He was the youngest-ever C-Suite executive at GE and NBC-Universal, served as CTO for 11 years earning 3 Emmy Awards, was a founding member of Hulu, former CEO of Conviva, and co-founder of Vizbee, which powers cross-device streaming for 350M devices and 110M households.

Originally published August 30, 2026. Substantially updated September 14, 2026 by Videostream Interactive Partners.