A break request carries timing and audience context.
SSAI is a timing and accountability system
Coordinate ad cues, decisioning, media conditioning, manifest personalization, playback and measurement so monetization failures do not become programme failures.
Define fallback and measurement responsibility before stitching the first live break.
Ad media must match the programme boundary.
Track delivery, quartiles, errors and fallback.
On this page
Server-side ad insertion, or SSAI, personalizes a streaming presentation so content and advertising reach the player through one coordinated media path. The server-side layer detects an ad opportunity, asks an ad decision server what should fill it, prepares compatible ad media, and returns a manifest or segment sequence that includes the selected ads.
How server-side ad insertion works
AWS describes this pattern in its official MediaTailor ad insertion flow: the service sits between the content origin, CDN, and ad decision server; receives viewer context; retrieves an ad response; adjusts the manifest; and coordinates tracking. Google documents related DAI pod-serving options for live and VOD workflows.
Where Callaba fits—and where it does not
Callaba can carry a compatible live output or publish a managed Video on Demand asset around an SSAI architecture, then expose the result through a Callaba Web Player. The ad decision server, campaign manager, marketplace, consent platform and universal insertion role are not part of that product claim.
| Layer | Callaba role | Required external evidence |
|---|---|---|
| Media path | Compatible ingest, processing, recording, and Web Player playback | Conditioned output remains continuous through the break |
| Ad decision | No native claim | Campaign, targeting, consent, VAST, and decision logs |
| Insertion | No universal stitching claim | Named SSAI service, manifest result, CDN, and player outcome |
SSAI vs CSAI
| Area | SSAI | Client-side ad insertion |
|---|---|---|
| Assembly | Server or guided service prepares the ad path around the presentation | Player or client SDK requests and inserts ads |
| Player complexity | Can reduce some player-side stitching work, but still needs session and tracking integration | Player owns more ad lifecycle and transitions |
| Media continuity | Ad media must be conditioned to match the content path | Client may switch between content and separate ad playback contexts |
| Caching | Personalized manifests and shared segments require deliberate cache design | Content delivery and ad requests are more visibly separate |
| Blocking resistance | Media can resemble the content path, but no architecture guarantees immunity | Separate client ad calls may be easier to identify or block |
| Measurement | Server-side beacons, client-side beacons, or a defined hybrid | Commonly driven by the client SDK and player events |
Ad cues start the workflow
A live channel needs reliable signals for when an opportunity begins, its expected duration, and how the programme resumes. SCTE-35 is commonly used in broadcast and streaming chains, but the cue still has to survive ingest, transcoding, packaging, and manifest generation. A missing, duplicated, late, or inconsistent cue can create dead air, clipped content, or an ad break that never fills.
SCTE-35 cue messages deserve their own implementation runbook. In the complete SSAI architecture they are one input: a valid cue still has to reach the right service, at the right time, with usable identifiers and a tested fallback policy.
Ad media must match the programme
An ad response can be commercially valid and technically unusable. The creative may have the wrong codec, resolution, bitrate, frame rate, audio layout, loudness, duration, segment structure or encryption. Conditioning it into the admitted ladder before the break reduces the risk of an opportunity passing during last-second transcoding.
Both sides of the transition matter: timestamp discontinuities, decoder resets, black frames, audio pops, loudness jumps, captions, bitrate shifts and the return to programme. An ad URL in the manifest is not acceptance.
Personalization and caching must agree
Viewer or session parameters may affect the personalized manifest. The CDN must forward the required query strings, headers, or cookies and avoid serving one viewer's personalized response to another. Content and ad segments may remain broadly cacheable even when manifests differ, but that depends on the architecture.
AWS's current SSAI/CDN architecture guidance places the CDN in front of manifest personalization and describes distinct routing for manifests and segments. Treat vendor diagrams as implementation evidence for that service, not a universal configuration for every SSAI system.
Measurement needs one owner
Measurement needs an owner for impression and quartile beacons, retry behavior, duplicate requests and the event that means an ad was actually viewed. A returned manifest is not a completed impression, and a segment request is not always visible playback. The test must reconcile ad decision, SSAI, CDN and player timelines.
Failure behavior is part of monetization
- No ad returned: decide whether the viewer sees programme, slate, a house ad, or a cleanly shortened break.
- Creative incompatible: reject or replace it without breaking the presentation.
- Ad decision timeout: use a bounded fallback rather than holding the player indefinitely.
- Manifest personalization failure: preserve a safe content path and expose the incident.
- Tracking failure: distinguish lost measurement from failed playback.
- Viewer seeks or reconnects: define whether and how the ad break is resumed or replayed.
Decisioning and insertion remain outside the product claim
An SSAI design needs named external decisioning and insertion components with a validated handoff. A healthy Callaba media process does not imply cue preservation, manifest manipulation or campaign reporting.
The existing AWS Elemental MediaTailor page owns that vendor's architectural evaluation. The AVOD/SVOD/TVOD comparison owns the business-model decision. This page owns the protocol-neutral SSAI workflow.
A break-level record connects revenue to playback
Every live break needs a correlation identifier across the cue, ad request, decision response, selected creative, conditioned media, manifest change, player session and measurement events. Viewer identity need not be exposed to every system, but operations and revenue teams must be able to explain why an opportunity filled, fell back or failed. Aggregate fill rate cannot distinguish “no eligible ad” from “eligible ad could not play.”
| Failure | Viewer-safe fallback | Evidence to preserve |
|---|---|---|
| Decision timeout | Return to programme, slate or a policy-approved house creative without extending the break. | Timeout budget, request context, decision endpoint and fallback chosen. |
| Creative mismatch | Reject media that cannot join the programme cleanly. | Codec, resolution, frame rate, audio layout, duration and conditioning result. |
| Manifest stitch error | Preserve programme continuity even if the opportunity is unfilled. | Personalized manifest diff, discontinuity handling and player outcome. |
| Tracking gap | Do not fabricate completion; reconcile from available delivery and player evidence. | Server beacons, player events, deduplication key and consent state. |
Example: the ad decision succeeds, but a viewer gets the wrong break
An operator sees a valid ad response for two test sessions. The first viewer receives the intended creative; the second receives a manifest carrying the first session's selection. Programme video is healthy, so restarting the encoder would discard the useful evidence. The first comparison belongs at the personalization-to-CDN boundary: session parameters, returned manifests, cache keys and cache-status headers.
If both requests resolve to the same cached personalized manifest, the failure is in request forwarding or cache variation rather than ad eligibility or media encoding. Preserve the two session IDs and manifest responses, repair the cache rule, then repeat the break and reconcile player events with decision and tracking records.
SSAI FAQ
Does SSAI prevent ad blocking?
SSAI can make advertising part of the coordinated media path and reduce dependence on a separate client ad request. It does not guarantee that every blocker, network, player, or privacy tool will treat the stream identically.
Does SSAI work with live and VOD?
Yes, but cueing, preparation, personalization, seeking, break duration, and failure behavior differ. Test each admitted service type separately.
What is an ad decision server?
It applies campaign, targeting, inventory, and policy logic and returns the selected advertising response. The insertion layer then has to turn that response into a technically compatible viewing path.
Is SSAI the same as AVOD?
No. AVOD is a business model funded by advertising. SSAI is one technical way to insert ads into the video experience.