SSAI and SGAI monitoring: verify the ad break viewers actually see

SSAI and SGAI monitoring: verify the ad break viewers actually see

Kyle Suess

A two-minute break can finish without a black frame and still be commercially wrong.

Imagine a planned pod of four 30-second ads. The ad server returns four creatives. The manifest carries four. One television plays two ads, 30 seconds of slate and a final ad. A phone plays all four, then returns to the programme six seconds late. The server logs can look healthy while neither viewer receives the intended break.

That hypothetical is the core problem for SSAI and SGAI monitoring. The planned break, insertion events, media requests, observed playback and measurement records are related, but they are not interchangeable. If a team cannot reconcile them, it cannot explain what failed or which number finance should trust.

![Conceptual live ad-insertion workflow comparing intended events with the media sequences observed on several viewer devices](https://media.amiralabs.com/blog/ssai-sgai-live-ad-break-verification/766a936a041f-ssai-sgai-live-ad-break-verification-hero-1600x838.jpg)

Why can every ad system report success at the same time?

Each ad system can report success because each one observes a different boundary.

The automation system knows that a break was scheduled. The encoder or playout chain knows that it emitted a cue. The ad decision server knows that it returned a response. The manifest service knows that it referenced or stitched media. The content delivery network knows which objects were requested. The player knows what it attempted to render. A measurement provider applies a separate definition to events and signals.

All of those records are useful. None alone proves the entire chain.

The distinction matters more as AI enters planning, pricing, optimization and measurement. IAB's August 24, 2026 guide says AI is being embedded across the programmatic video supply chain and identifies transparency and trust as central questions. Faster decisions can increase the number of breaks, variants and explanations an operations team must reconcile.

Start by assigning each record a narrow claim:

Record

What it can establish

What it cannot establish alone

Schedule or traffic log

A break and duration were planned

The cue left, an ad was selected or media played

SCTE-35 or manifest marker

An opportunity was signalled

The signal was acted on correctly by every downstream path

Ad-server response

A decision service returned ads or slate instructions

The creative was compatible, fetched or rendered

Stitched or guided manifest

Media references were prepared for a session or player

The device requested every segment or displayed it

CDN request log

A device or intermediary requested objects

The screen was on, the player rendered the frames or the event qualifies as an impression

Device observation

Particular media and transitions appeared on a tested endpoint

Accredited reach, viewability, attention or campaign outcome

Measurement report

Events met that provider's documented method

The root cause of a media-delivery fault without supporting evidence

The operations record should connect these claims rather than flatten them into one “ads delivered” flag.

What is the operational difference between SSAI and SGAI?

SSAI usually stitches advertising into the stream on the server side, while SGAI uses server-provided guidance and leaves more of the final resolution or insertion work to the player.

IAB Australia's August 6 explainer describes server-guided ad insertion as an emerging hybrid pattern whose terminology still varies by vendor. The Streaming Video Technology Alliance defines SGAI as the server providing opportunity marking and priming while the player performs final resolution and insertion. That distribution of responsibility changes what must be observed.

Question

Typical SSAI answer

Typical SGAI answer

Where are ads joined to programme media?

In a server-side stitching or manifest-personalization path

In or under the control of the client player, following server guidance

What reaches the player?

Commonly a continuous personalized stream or manifest

Content plus interstitial or ad references the player resolves

Where can playback truth be observed?

Server events plus device behavior

Server guidance, asset-list or ad references, and richer player behavior

What is a common reach advantage?

Works with many constrained or older devices

Supports modern players and cacheable content manifests in some implementations

What is a common verification risk?

Server delivery can be mistaken for client playback

Player diversity can create endpoint-specific failures

These are typical patterns, not universal product definitions. AWS MediaTailor, for example, lets a session select guided or stitched insertion when configured for player choice. Its current SGAI documentation says ads are referenced as separate playlists rather than stitched directly into the media playlist. For HLS server-side beaconing, AWS requires player support for specific HLS interstitial and variable-substitution behavior.

Apple's HLS authoring specification says interstitial and programme boundaries should use EXT-X-DATERANGE, and recommends aligned segment boundaries across variants and renditions for interoperability. Those protocol requirements help components communicate. They still do not certify that a viewer saw the intended ad.

What should an ad-break reconciliation record contain?

An ad-break reconciliation record should connect one planned avail to one observed outcome using durable identifiers and a shared time reference.

Do not begin with dashboards. Begin with a row that an engineer, ad-operations lead and revenue owner can read together.

Field

Example purpose

Programme and distribution output

Distinguishes the national stream, regional variant, app or device path

Avail or opportunity ID

Joins the scheduled break to downstream events

Planned start and duration

Establishes the intended programme boundary

Cue receipt and normalized duration

Shows what the insertion path actually received

Decision request and response ID

Links the opportunity to the returned pod

Expected sequence

Lists creative IDs, durations and approved slate or fallback

Manifest or asset-list evidence

Records what the delivery system prepared

Observed media sequence

Shows what a test device actually rendered

Programme-return timestamp

Measures underfill, overrun or late recovery

Tracking and measurement references

Links beacons and reports without treating them as media truth

Exception owner and disposition

Records who investigated, accepted or corrected the result

Keep personal data out of the operational evidence unless it is necessary and authorized. A consented synthetic test session can exercise targeting branches without copying production viewer identifiers into a troubleshooting system.

Use a common clock where possible. If the automation log uses local time, the ad server uses UTC and the player reports media time, normalize them before comparing. Preserve the original timestamps too. Normalization should not erase the evidence needed to find clock drift.

![Hypothetical reconciliation timeline comparing a planned ad break, system events, observed playback and measurement](https://media.amiralabs.com/blog/ssai-sgai-live-ad-break-verification/924e13ace498-live-ad-break-reconciliation-timeline-1600x1050.png)

How do live ad breaks fail in practice?

Live ad breaks fail at the cue, decision, creative, timing, media-compatibility, playback or return boundary.

Broadpeak's troubleshooting documentation gives concrete product-specific examples. Its live replacement requires detectable SCTE-35 markers. It lists non-200 ad-server responses, empty or invalid VAST, inaccessible media, incomplete transcoding and creative manifests that do not match the source. The documentation also describes a five-second overall processing limit and a two-second ad-server response timeout for that service. Those are Broadpeak parameters, not industry-wide deadlines.

Turn each failure class into a controlled test:

  • Remove or alter the cue in a staging feed.
  • Return an empty, invalid or deliberately delayed ad response.
  • Offer one creative with an unsupported media type or mismatched rendition.
  • Make an ad segment unavailable after the manifest is prepared.
  • Underfill and overfill a fixed-duration break.
  • Interrupt a device during an ad, then resume playback.
  • Seek into a live DVR window that contains a replaced break.
  • Remove the insertion worker or player integration and verify the approved fallback.

Record what the viewer receives. A safe result may be programme, slate, a house ad or no monetized break, depending on the rights and product decision. The test passes only when the observed result matches the declared fallback and returns to programme at the expected boundary.

False success is especially dangerous. Broadpeak documents an optional server-side tracking check that confirms ad media segments are available before firing a beacon. That is a useful safeguard within its product, but segment availability still is not the same claim as rendered playback or viewability. Every evidence field needs a precise name.

How should you test SSAI and SGAI across devices?

Test SSAI and SGAI on the device families, player versions, consent states and network conditions that carry meaningful audience or revenue.

A single desktop browser proves very little about a connected-TV service. The Media Rating Council's August 2021 OTT, CTV and SSAI guidance describes fragmented SSAI implementations and notes that some smart TVs may not support client-initiated measurement integrations. IAB Tech Lab's current Open Measurement compliance programme lists tvOS, Android TV, Fire TV, LG and Samsung among its CTV environments. Support still depends on the implementation and certified integration.

Create a device matrix that reflects your real service:

Dimension

Minimum useful coverage

Device family

Major CTV platforms, mobile operating systems and browser players in scope

Player state

Fresh start, long-running session, background and foreground, seek, pause and resume

Consent state

Each permitted targeting and measurement path

Network

Normal delivery, constrained throughput, packet loss and transient segment failure

Break type

Pre-roll, scheduled mid-roll, manual live trigger, replay or DVR replacement

Creative mix

Multiple durations, codecs, aspect ratios, audio layouts, captions and slate

Insertion mode

SSAI, SGAI and any configured per-session fallback

Sample the outputs continuously during a rehearsal or shadow run. Do not wait for a revenue discrepancy to become the first device-level test.

Define an alert deduplication rule. One unavailable creative may affect thousands of sessions, and an operator does not need thousands of identical incidents. The alert should retain scope, representative evidence and the affected opportunity while grouping repeated symptoms.

What proves that an ad was viewed or billable?

Operational media evidence can prove what appeared on an observed output, but it does not by itself prove a billable impression, viewability, attention or business outcome.

The Media Rating Council maintains separate guidance for OTT, CTV and SSAI measurement. IAB Tech Lab's Open Measurement SDK supplies standardized signals for participating environments and verification providers. VAST tracking and standardized macros can carry relevant events and context. The commercial definition still depends on the measurement method, device support, consent state and agreements among publisher, buyer and verification partner.

Keep four questions separate:

  1. Was media prepared? The insertion service produced a manifest, playlist or segment reference.
  2. Was media requested? A client or intermediary fetched relevant objects.
  3. Was media rendered in an observable session? Player or external evidence indicates playback.
  4. Did the event meet the agreed measurement definition? The accredited or contractually chosen method counted it.

These questions may yield different totals without any party committing fraud. Retries, caching, buffering, background playback, television power state and partial quartiles can change the relationship between requests and measured impressions.

IAB Australia's practical advice is sound: agree the impression event and source-of-truth hierarchy before launch. When records disagree, the team needs a written reconciliation rule, not a meeting in which each dashboard owner defends a different denominator.

For Amira Labs, the relevant boundary is media evidence. Observing what played and when can shorten an incident investigation and challenge a false delivery assumption. It should not be presented as a substitute for an ad server, consent system, verification partner or accredited audience measurement.

Why is the return to programme part of ad verification?

The return to programme is part of ad verification because an ad pod can be correct while the viewer misses live content.

Underfill can expose slate, a frozen frame or an unintended return. Overfill can cut into programme. A delayed player transition can show the final ad after the event has resumed. Live sport makes the cost visible immediately, but the same fault can affect news, awards and scheduled entertainment.

Test both sides of the boundary. Place synchronized visual and audio markers before the avail, at the expected return and shortly after. Compare the source programme with the device output. Measure:

  • cue-to-break transition time;
  • total observed ad and slate duration;
  • gap, overlap or discontinuity at each creative boundary;
  • expected-return to observed-return difference;
  • first intact programme frame and audio after the break.

Check every rendition and audio group that matters. Broadpeak's content-replacement documentation lists codec, audio, subtitle and language mismatches among reasons replacement can fail. A video-only spot check can miss a wrong-language or absent-audio result.

The monitoring plan should raise two different incidents when appropriate: commercial underdelivery and programme impairment. They have different owners and urgency.

When should SSAI remain the default?

SSAI should remain the default where device reach, predictable continuous playback and support for constrained endpoints matter more than player-side flexibility.

SGAI is an additional operating model, not a mandatory migration. IAB Australia notes that SSAI remains important for broad device reach and that modern-player support for SGAI is not universal. AWS's implementation also documents current boundaries: its server-side SGAI beaconing is HLS-only and requires particular player capabilities.

Hybrid operation can be sensible. It also doubles the acceptance surface if teams treat SSAI and SGAI as interchangeable. A per-session choice needs an observable mode, a tested fallback and mode-specific reconciliation. If a legacy device silently falls back to SSAI, the measurement and troubleshooting expectations must follow it.

There is also a volume floor. A small service with direct-sold campaigns and a narrow device set may be able to reconcile breaks manually. Building a large evidence pipeline can cost more than it saves. Start with the outlets and events where concurrent audience, campaign value or incident frequency makes ambiguity expensive.

What should you ask an ad-insertion vendor at IBC?

Ask vendors to reconcile one deliberately broken live break from schedule to screen.

  • Which identifier follows an avail through cue, decision, manifest or asset list, playback and measurement?
  • What evidence shows the exact media sequence prepared for one session and the sequence observed on a device?
  • How are empty VAST, timeouts, incompatible creatives, missing segments and underfilled pods handled?
  • How does the workflow return to programme after an early, late or interrupted pod?
  • Which devices and player versions support each insertion and measurement mode?
  • How are SSAI, SGAI and fallback sessions distinguished in operations and reporting?
  • Which events are delivery telemetry, and which are eligible for the agreed impression or viewability count?
  • Can one root-cause incident group affected sessions without hiding device-specific failures?

Use the same discipline described in our AI broadcast monitoring buyer's checklist: inject known faults, measure detection and retain timecoded evidence. If automation may change a live service or fallback, map its authority with the human-approval framework for broadcast AI.

What can your team do this week?

First, draw the break chain on one page. Include traffic, cueing, decisioning, insertion, CDN, player, observation and measurement. Put an owner beside each boundary.

Second, define one reconciliation record for one live channel. Use a stable avail ID, common clock and explicit expected sequence.

Third, build five failure tests: missing cue, empty response, incompatible creative, unavailable segment and late programme return. Run them only in staging or an authorized shadow path.

Fourth, compare the logs with a real device capture. Any field called “delivered” should say exactly which boundary it represents.

Take that evidence to IBC. The most useful demo will be the one where something goes wrong and the team can prove what happened.

Sources