SSAI vs CSAI: Stitchers, Beacons, and Ad Insertion for OTT

Every ad-supported stream answers the same question twice: where do commercials enter the timeline, and who is responsible when measurement disagrees with the buyer? Server-side ad insertion (SSAI) and client-side ad insertion (CSAI) are the two dominant answers. They share ad decisioning, trafficking, and creative QC upstream, but they diverge at the moment of playback. SSAI pushes stitching and often beacon proxying into the cloud so the player sees one continuous HLS or DASH manifest. CSAI keeps the content manifest clean and lets the player or an in-app ad SDK fetch VAST, resolve media files, and swap the pipeline at runtime. Neither is universally better; the choice is a product, platform, and compliance trade-off that affects fill rate on living-room devices, resistance to ad blockers on web, and how verification vendors count impressions.

Shared vocabulary before you pick a side

Ad decisioning still happens in an ad server or supply-side platform regardless of insertion style. Trafficking binds line items to content IDs, channels, geo, and dayparts. Avails are the slots where ads may run: pre-roll before VOD, mid-roll after SCTE-35 cues in live, or pod breaks in FAST schedules. A pod is a group of sequential spots with a total duration cap. Creatives arrive as mezzanine files or as VAST tags pointing at transcoded outputs. Measurement relies on beacons: HTTP requests fired at start, quartiles, complete, click, and skip events. The insertion architecture only changes where those beacons originate and whether the player ever downloaded the ad creative URL directly.

• CSAI: player-visible ad requests; strong on web SDKs; fragile on some CTV stacks and against blockers.
• SSAI: single manifest timeline; better living-room UX; stitcher becomes a critical production system.
• Hybrid: SSAI on TV apps, CSAI on web, unified reporting layer so finance sees one truth with documented deltas.

How client-side ad insertion works in production

In CSAI, the content player loads a primary manifest, then consults a sidecar: VMAP for pod structure on VOD, or live ad break metadata from the player integration. When a break starts, the client requests VAST from the ad server, parses MediaFiles, selects a compatible creative for device capability, and instantiates a second playback path or swaps source buffers. The content engine pauses or hides while the ad engine plays. When the ad completes or errors, control returns to content at the correct timeline position. Because the client performs each HTTP call to the advertiser domain, verification pixels in VAST often fire naturally from the device, which buyers like. Because those same calls are visible to browser extensions, ad blockers can suppress them on web.

1. Load content and register listeners for time updates or cue events.
2. Request ad decision at the avail; respect timeout and fallback to house or slate.
3. Parse VAST; reject unsupported codecs before attempting playback.
4. Play ad; fire tracking URLs per event; on failure, fail open or closed per policy.
5. Resume content; reconcile content position with expected pod duration.

CSAI shines when you ship one web codebase with a mature IMA or similar SDK, when you need rapid A/B tests on ad logic without redeploying stitchers, and when your analytics team wants client-side signals such as viewability hooks tied to DOM or player callbacks. It struggles when OEM TV players lack reliable ad SDK ports, when you must guarantee identical pod behavior across ten embedded platforms, or when autoplay policies interfere with preroll on mobile web.

How server-side ad insertion reshapes the manifest

SSAI intercepts the path between origin packager and player. A stitcher service receives the content manifest, ad decision results, and transcoded ad segments. It emits a new manifest where ad periods appear as ordinary media segments in sequence with program content. Players that trust the manifest play through breaks without knowing an ad server existed. Stitchers may operate per session (personalized manifests) or per channel edge (shared FAST output with regional variants). Personalization increases revenue but multiplies origin load and complicates CDN caching rules for playlists versus segments.

The stitcher must preserve timing invariants: EXT-X-DISCONTINUITY or DASH Period boundaries at pod edges, aligned audio tracks, consistent frame rates, and PROGRAM-DATE-TIME continuity for live so electronic program guides and replay markers stay sane. A one-frame gap at a stitch point sounds like a click to viewers and like a fraud signal to verification partners. SSAI vendors differ in whether they transcode on the fly, pull from a pre-normalized ad cache, or require operators to pre-ingest creatives into a library keyed by asset ID.

Inside the stitcher: manifest surgery and segment assembly

Think of the stitcher as a specialized packager that runs after ad decisioning. For VOD, it splices ad segments into the media playlist at byte-aligned boundaries or fMP4 fragment boundaries so players can decode without reset artifacts. For live, it listens for SCTE-35 splice_insert or time_signal descriptors, reserves a window in the outgoing playlist, and fills it with pod segments before the playhead reaches the hole. Some architectures use just-in-time stitching: the stitcher only writes ad segments into the playlist once decisioning returns, which risks late pods if the ad server is slow. Others pre-pad with slates and replace them when demand arrives, trading slight latency for safer live sports.

• Manifest cache keys must include session or geo dimensions when ads differ; otherwise viewers see wrong sponsorship.
• Segment URLs should be immutable once published so CDNs cache aggressively; playlist URLs stay hot and short TTL.
• Audio loudness and channel layout must match program segments; EBU R128 normalization belongs in the ad ingest path.
• DRM boundaries: stitched ads may need clear segments while program stays encrypted, or a common encryption schema end to end.

SCTE-35 cues and live ad breaks

Broadcast-originated live feeds often carry SCTE-35 in MPEG-TS or embedded in fMP4 emsg boxes. The cue signals out-of-band ad opportunities: splice time, break duration, and whether the break is auto-return. OTT packagers must not strip these markers during transcoding. If your encoder chain re-times video, cue PTS must be re-stamped consistently or the stitcher will insert pods early or late relative to on-screen action. For studio-origin live without broadcast cues, operators inject markers from automation or manual GPI. FAST linear adds another layer: avails may be schedule-driven rather than cue-driven, but the stitcher still needs frame-accurate pod templates per show block.

When failover switches encoders, duplicate cues or missing cues are common failure modes. Runbooks should define whether the stitcher holds the last good break schedule, inserts a house pod, or passes content unmonetized until operators confirm markers. Sponsors notice missed breaks in sports more than in catalog comedy; tier your response by revenue impact.

Beacons: who fires them and why dashboards disagree

Beacons are the currency of video advertising. A quartile beacon does not guarantee human attention, but it is how contracts define delivery. In CSAI, the player or SDK typically fires tracking URLs from the VAST TrackingEvents list as playback progresses. Network failures, double-fires on seek-back, and background tab throttling all create noise. In SSAI, the player may never see VAST at all. Stitchers or companion SDKs fire beacons server-side, at the edge, or through a client shim that maps continuous timeline positions back to logical ad IDs. Server-side firing reduces blocker impact on web but shifts trust questions: buyers want proof the beacon correlates with a device that could render video.

Beacon placement patterns operators should document

• Client-only: traditional CSAI; easiest for third-party verification tags; weakest against blockers.
• Server-side proxy: stitcher fires on segment start as seen in manifest; must align with actual device start or discrepancies spike.
• Hybrid shim: lightweight SDK on TV maps SSAI timeline to VAST events; common on Roku and Fire TV integrations.
• Measurement id in manifest: custom tags carry ad IDs for downstream analytics even when creatives are opaque to the player.

Reconcile discrepancies with a written counting charter: does an impression start at first frame, at downloaded bytes, or at visible pixels? SSAI and CSAI rarely match byte-for-byte. Finance should see expected variance bands, not nightly surprises. Log stitch decisions with content ID, pod index, creative ID, and beacon batch ID so post-mortems do not devolve into guessing.

Viewer experience: continuity, latency, and failure modes

SSAI usually wins perceived quality on TVs: no full-screen loader between content and ad, fewer player handoffs, and breaks that scrub like the rest of the timeline. CSAI can feel faster to start on web when preroll decisioning overlaps content buffer, but mid-roll swaps still cause visible stalls if creatives are oversized or CDN cold. Failure behavior differs. CSAI can skip a broken ad and jump to the next VAST candidate. SSAI may show a black hole in the playlist if transcoding failed unless the stitcher inserts slate segments atomically. Define fail-open versus fail-closed per surface: news FAST might pass content to preserve trust; AVOD VOD might hold the frame on a house promo rather than skip monetization silently.

Platform matrix: where each model tends to win

Living-room apps on Samsung Tizen, LG webOS, and embedded Linux players often lack consistent CSAI SDK parity with mobile. SSAI reduces the integration surface to your core player plus optional measurement shim. Mobile web remains CSAI-heavy because you control JavaScript and can iterate tags quickly. Native iOS and Android may use either model depending on app store policies and partner SDKs. Gaming consoles and set-top boxes vary by OEM; proof-of-concept on real hardware beats spec sheets. FAST linear almost always uses SSAI at the head end because thousands of concurrent viewers must not each trigger independent ad calls against the same break.

• Web AVOD: CSAI or hybrid with SSAI fallback for browsers with strict autoplay.
• CTV apps: SSAI primary; CSAI only where OEM mandates partner SDK.
• Live sports OTT: SSAI with low-latency HLS only if stitcher keeps pace with part-hold playlists.
• Podcast-style long VOD: either model works; prioritize scrub bar accuracy and bookmark resume across breaks.

CDN, cache, and origin load implications

CSAI pushes bursty traffic to ad CDNs at break time while content CDNs stay predictable. SSAI merges both into your origin and edge footprint. Personalized manifests cannot sit on long TTL caches; segment files still can. Misconfigured cache keys cause viewers in one city to inherit another city’s political ad. Rate-limit ad decisioning separately from manifest fetches so a traffic spike during a finale does not starve stitcher workers. Monitor playlist request rates per active viewer; SSAI live can multiply polls if stitchers rewrite windows aggressively.

Creative pipeline requirements for stitchers

Stitchers reject creatives that do not match channel specifications: wrong resolution, interleaved audio the packager cannot mux, variable frame rate spots against constant frame rate program, or ads longer than the avail. Build an ad ingest QC gate similar to content QC: loudness, black frames, slate detection, and maximum bitrate. Normalize to the ladder rung used for your FAST output, not only to the highest mezzanine you accept. Store transcoded ad segments keyed by creative ID so repeated flights do not re-transcode nightly. For dynamic personalization, keep a library of modular bumpers and end cards the stitcher can assemble within pod duration caps.

1. Ingest mezzanine; validate duration within trafficked tolerance (often plus or minus one second).
2. Transcode to house codec profile; attach metadata for language and click-through if CTV supports it.
3. Register in ad server with segment URLs or internal IDs the stitcher resolves.
4. Preflight stitch in staging with real program segments before flight start.

Verification, fraud, and brand safety under SSAI

Third-party verification vendors historically assumed client visibility into creative requests. SSAI obscures that path, so integrations move to OM SDK on supported devices, server-side validation, or data partnerships with the stitcher. Invalid traffic detection watches for beacon floods without corresponding session starts. Geo spoofing shows up when SSAI manifests keyed incorrectly. Brand safety still needs genre and rating from your catalog CMS at decision time, not only keyword lists on the ad server. Document which insertion path runs verification tags so compliance audits do not miss CTV.

Privacy, consent, and limited ad tracking

Personalized SSAI manifests imply you passed identifiers or household graphs to ad decisioning. GDPR, CPRA, and platform ATT prompts constrain what you may send on web versus logged-in TV apps. Kids profiles should disable behavioral ads entirely; stitchers must not rewrite kids manifests with adult-targeted pods because the adult profile logged in on another device. Consent strings and GPP signals belong in the ad request whether insertion is server or client side. SSAI does not bypass privacy law; it only moves where requests execute.

Debugging stitch failures without blaming Wi-Fi

Support tickets that say ads are broken often mix causes. Build an internal trace ID propagated from ad decision through stitcher logs to player session analytics. Compare manifest snapshots at break time: were ad segments present in the playlist? Did PROGRAM-DATE-TIME jump? Did the player seek across a discontinuity and skip beacons? For CSAI, capture VAST XML and selected MediaFile URL. For SSAI, capture stitched playlist URLs before CDN edge and after. Maintain a replay tool that feeds recorded live cues into a staging stitcher so engineers reproduce sports breaks without rerunning the game.

• Black pod: transcoding failure or empty decision; check ad server timeout logs.
• Audio pop: loudness or sample rate mismatch at stitch boundary.
• Wrong ad: stale manifest cache key or geo misrouting.
• Double pod: duplicate SCTE-35 on encoder failover.
• Missing beacons: shim not loaded on TV build; server-side firing disabled by misconfig.

Hybrid architectures that teams actually ship

Pure single-model stacks are rare at scale. A typical pattern: SSAI for FAST and CTV VOD, CSAI for mobile web, unified ad server trafficking both, and a reporting warehouse that normalizes impressions to a canonical schema. Accept that quartile counts will diverge; publish internal conversion factors only after statistical study, not wishful thinking. Another pattern uses SSAI for mid-roll and CSAI for interactive overlays where SSAI cannot carry HTML. Gate features behind capability detection in the player SDK rather than forking business rules per platform in the ad server.

Decision checklist for architects

1. List target devices for the next 18 months; mark which lack ad SDK support.
2. Measure current ad-related rebuffer and exit rate before changing insertion model.
3. Run parallel shadow traffic in staging with real creatives and verification tags.
4. Define beacon charter with finance and top advertisers before launch.
5. Plan stitcher capacity for peak concurrent live viewers plus manifest personalization factor.
6. Choose fail-open versus fail-closed per content brand before the first live incident.

How LinqTV fits SSAI and CSAI workflows

LinqTV treats ad insertion as part of the playback fabric, not a bolt-on iframe. The Player SDK exposes timeline events, cue metadata, and partner hooks so you can run CSAI on web while SSAI manifests feed living-room builds from the same entitlement and analytics backbone. When evaluating LinqTV against point stitchers, ask how live SCTE-35 survives your playout path, how offline or time-shifted FAST behaves if manifests are personalized, and whether beacon strategies are documented per platform rather than left to integrators to guess. A proof of concept should include a misbehaving creative, a slow ad server, and a failover cue storm so you see fail-open behavior before sponsors do.

Operators using LinqTV One for AVOD launches should connect trafficking, stitcher outputs, and player telemetry into one incident channel. Revenue teams get fill metrics; engineering gets stitch latency and beacon drop rate; support gets session traces keyed to content IDs. That unity matters because SSAI incidents look like playback bugs to viewers even when encoders are healthy.

FAQ

Is SSAI the same as dynamic ad insertion (DAI)?

In vendor language, DAI often means SSAI for live and VOD, especially personalized streams. CSAI is still dynamic when avails are filled at playback time, but the insertion point differs. Clarify terms in contracts so engineering scope matches sales promises.

Can we switch from CSAI to SSAI without retagging our entire library?

VOD mid-roll markers must exist as time offsets or cue metadata the stitcher understands. If you only had player-side VMAP, you will need to migrate break points into CMS or SCTE markers during mezzanine ingest. Budget content ops time, not only ad tech integration.

Why do beacon counts differ between SSAI and CSAI on the same campaign?

Different firing locations, blocker effects, seek behavior, and counting definitions stack into gaps of several percent, sometimes more on web. Align on a charter, measure variance for two weeks in parallel, then set expectations with buyers instead of debating single sessions.

Do stitchers work with low-latency HLS?

They can, but the stitcher must keep pace with partial segments and shorter playlist windows. Late decisioning shows up as visible holes near live edges. Test with your actual LL-HLS packager; vanilla VOD stitcher configs often fail on part-hold live.

What is the first metric to alert on for SSAI health?

Pod fill rate combined with stitch latency at cue time. Falling fill with rising latency usually predicts black breaks minutes before support queues spike. Pair it with beacon success rate so you distinguish decisioning problems from player shim problems.

Should FAST channels ever use CSAI?

Rarely at scale. Linear simulcast expects one stitched output synchronized for all viewers. CSAI per viewer fights the broadcast model and overloads ad servers. Use SSAI at the head end; reserve CSAI for companion apps or clips, not the primary linear feed.