Clientseitige Anzeigeninsertion (CSAI) mit SCTE-35 Marker-Parsing & Multi-Plattform-Player-Integration
Eine Video-Streaming-Plattform musste die Clientseitige Anzeigeninsertion (CSAI) über Web-, Mobil- und Connected TV-Apps hinweg implementieren – was personalisierte, gerätespezifische Anzeigenerlebnisse mit vollständiger Unterstützung der Anzeigeninteraktion (anklickbare Overlays, Companion-Banner, Skip-Buttons) ermöglicht, die serverseitige Insertion nicht bieten kann.
Ihr Projekt besprechen
Die Herausforderung
Die Plattform nutzte zuvor ausschließlich SSAI (serverseitige Anzeigeninsertion), was die Monetarisierung gut abwickelte, aber erhebliche Einschränkungen für interaktive Anzeigenerlebnisse hatte:
- Mit SSAI zusammengefĂĽgte Anzeigen konnten keine anklickbaren Overlays, Companion-Banner oder interaktiven Anzeigen-Einheiten unterstĂĽtzen
- Keine Möglichkeit, clientseitige Anzeigenereignisse (Quartilsfortschritt, Viewability, Click-Through) zu verfolgen, die von Premium-Anzeigenkäufern gefordert werden
- Connected TV-Plattformen (Roku, Fire TV, Apple TV) erwarteten CSAI fĂĽr ihre nativen Ad Frameworks und Zertifizierungsanforderungen
- SCTE-35 Marker in HLS/DASH Manifesten mussten clientseitig geparst werden, aber jedes Player SDK handhabte Cue-Events unterschiedlich
- Ad Pod Management (BefĂĽllen von Multi-Slot-Werbeunterbrechungen mit mehreren Anzeigen) erforderte clientseitige Orchestrierung
- Ad Blocker-Erkennung und Fallback-Logik waren erforderlich, um Einnahmen auf Web-Plattformen zu schĂĽtzen
- Das Vorladen von Anzeigen ohne Unterbrechung des Content-Buffers erforderte ein sorgfältiges Player-Lifecycle-Management
Unsere Lösung
Wir haben ein Cross-Plattform CSAI-Framework mit einer einheitlichen Anzeigen-Orchestrierungsschicht entwickelt, die SCTE-35 Marker aus HLS/DASH Manifesten parst, mit VAST/VMAP Ad Servern kommuniziert und den Anzeigen-Wiedergabe-Lebenszyklus ĂĽber Web (Video.js/Shaka), iOS (AVPlayer), Android (ExoPlayer) und Connected TV-Playern hinweg verwaltet.
Architektur
- Content Delivery: HLS/DASH Streams mit SCTE-35 Markern ĂĽber AWS MediaPackage + CloudFront
- Ad Decision Server: Google Ad Manager (GAM) / SpotX mit VAST 4.2 und VMAP UnterstĂĽtzung
- Web Player: Video.js mit benutzerdefiniertem SCTE-35 Cue Parser und Google IMA SDK Integration
- iOS Player: AVPlayer mit
AVDateRangeMetadataGroupListener und IMA iOS SDK - Android Player: ExoPlayer mit
MetadataOutputListener und IMA Android SDK - Connected TV: Plattform-native Player (Roku RAF, Fire TV IMA, Apple TV AVKit) mit Ad Framework Adaptern
- Ad Analytics: Benutzerdefinierte Event Pipeline fĂĽr Impression, Quartil, Completion, Click und Viewability Tracking
- Fallback: Slate-/House-Ad-Bereitstellung, wenn keine Anzeigen verfĂĽgbar sind oder ein Ad Blocker erkannt wird
SCTE-35 Clientseitiges Parsing
HLS Manifest Marker
SCTE-35 Signale erscheinen in HLS Manifesten in zwei Formaten, die beide vom Client geparst werden:
EXT-X-DATERANGE (HLS v7+)- Player hört auf
#EXT-X-DATERANGETags mitSCTE35-OUTundSCTE35-INAttributen - Attribute beinhalten
PLANNED-DURATIONfür die Länge der Werbeunterbrechung undIDfür die Ereigniskorrelation - Bevorzugtes Format für moderne Player (AVPlayer, ExoPlayer, Shaka)
#EXT-X-CUE-OUT:DURATION=markiert den Start der Werbeunterbrechung#EXT-X-CUE-INmarkiert die Rückkehr zum Inhalt- Unterstützt für Abwärtskompatibilität mit älteren Playern und Encodern
DASH Manifest Marker
- SCTE-35 Signale erscheinen als
schemeIdUri="urn:scte:scte35:2013:xml" presentationTime,durationund Base64-kodiertes SCTE-35 Binär-Payload- Shaka Player und ExoPlayer parsen diese nativ über ihre Event Listener APIs
Marker-Verarbeitungsfluss
- Erkennung — Player-Metadaten-Listener erkennt SCTE-35 Cue-Event während des Manifest-Parsings
- Extraktion — Break-Dauer, Event ID und Segmentierungstyp werden aus dem Marker extrahiert
- Anzeigenanfrage — VAST/VMAP-Anfrage wird an den Ad Decision Server mit Targeting-Parametern (Content ID, Genre, Gerätetyp, Benutzersegment, Geo) gesendet
- Pod-Planung — Anzeigenantwort wird geparst, um einen Ad Pod zu erstellen (geordnete Liste von Ad Creatives, die die Break-Dauer füllen)
- Vorladen — Ad Creatives werden während der Content-Wiedergabe vorgeladen, um Latenz beim Start der Werbeunterbrechung zu eliminieren
- Pause & Wechsel — Content-Wiedergabe am Cue Point pausiert, Player wechselt zur Anzeigenwiedergabe
- Anzeigenwiedergabe — Anzeigen werden sequentiell mit Quartil-Tracking, Companion-Banner-Anzeige und Click-Through-Handhabung abgespielt
- Fortsetzen — Nach Abschluss des Pods wird die Content-Wiedergabe ab dem exakten Frame nach dem Cue Point fortgesetzt
Plattformspezifische Implementierungen
Web (Video.js + IMA SDK)
- Benutzerdefiniertes Video.js-Plugin fängt
#EXT-X-DATERANGEMetadaten ĂĽbertextTrackCue-Change-Events ab - Google IMA HTML5 SDK verwaltet VAST-Anzeigenanfragen, Anzeigenwiedergabe und Companion-Rendering
- Anzeigen-Container-Overlay ĂĽber dem Videoelement positioniert fĂĽr Click-Through- und Skip-Button-UnterstĂĽtzung
- Ad Blocker-Erkennung über Canary-Anfrage — bei Erkennung Fallback auf House Ads oder Content-Wiederaufnahme
- Preroll-, Midroll- und Postroll-UnterstĂĽtzung ĂĽber VMAP oder manuelle Cue-Point-Planung
iOS (AVPlayer + IMA SDK)
AVPlayerItem.navigationMarkerGroupsundAVDateRangeMetadataGroupwerden zur Erkennung von SCTE-35 Cues verwendetAVPlayerItemMetadataOutputDelegate feuert bei jedem Cue-Event mit geparsten Timings und Payload- Google IMA iOS SDK verarbeitet VAST-Anfragen und Anzeigenwiedergabe in einer separaten
AVPlayerInstanz - Picture-in-Picture (PiP) wird während Werbeunterbrechungen gemäß der Plattform-Anzeigenrichtlinie pausiert
- Hintergrund-Audio wird behandelt — Anzeigen werden nicht im Hintergrundmodus abgespielt
Android (ExoPlayer + IMA SDK)
Player.Listener.onMetadata()mitMetadataOutputerfasst SCTE-35 Events von HLS/DASH- Google IMA Android SDK integriert ĂĽber ExoPlayer's
ImaAdsLoaderErweiterung - Anzeigenwiedergabe verwendet eine separate
MediaSource, um den Content-Buffer nicht zu verschmutzen - Verwaltet den Activity Lifecycle — Anzeigenstatus bleibt über Konfigurationsänderungen und Backgrounding hinweg erhalten
- Android TV und Mobilgeräte teilen die gleiche Anzeigenlogik mit UI-Layer-Anpassungen
Connected TV-Plattformen
Roku (RAF — Roku Ad Framework)- Roku's native RAF-Bibliothek parst SCTE-35 Marker direkt aus HLS Manifesten
RAF.setAdUrl()mit VAST Endpoint konfiguriert; RAF ĂĽbernimmt Anzeigenanfrage, Pod-Erstellung und Wiedergabe- Companion Ad-UnterstĂĽtzung ĂĽber RAF's
renderStitchedAdundrenderTrackingEventCallbacks - Roku-Zertifizierung erfordert RAF-Nutzung — benutzerdefinierte Anzeigenplayer werden bei der Überprüfung abgelehnt
- Verwendet Android ExoPlayer + IMA SDK Implementierung, angepasst fĂĽr Fire TV's Leanback UI
- D-pad-Navigation fĂĽr Skip-Button und "Mehr erfahren" Click-Through auf Anzeigen-Overlays
- Fire TV Ad ID wird fĂĽr Ad Targeting in VAST-Anfragen verwendet
AVPlayerViewControllermitinterstitialTimeRangesfĂĽr native Anzeigenunterbrechungs-UI-Indikatoren- SCTE-35 Cues geparst ĂĽber
AVPlayerItemMetadataCollector - Anzeigenwiedergabe in einem separaten
AVQueuePlayerfĂĽr saubere Content-/Anzeigen-Trennung verwaltet - tvOS Remote Click Handler fĂĽr interaktive Anzeigenelemente
Ad Pod Management
- Pod-Befüllung — Mehrere VAST-Anzeigen werden zusammengestellt, um die signalisierte Break-Dauer zu füllen
- Waterfall — Wenn der primäre Ad Server keine Füllung zurückgibt, werden sekundäre/tertiäre Nachfragequellen sequentiell abgefragt
- Daueranpassung — Pod Builder wählt Anzeigenkombinationen aus, die innerhalb der Break-Dauer passen (±0,5s Toleranz)
- Deduplizierung — Das gleiche Ad Creative wird nicht zweimal in einem einzelnen Pod angezeigt
- Frequency Capping — Pro-Benutzer-, Pro-Sitzungs-Caps werden clientseitig erzwungen, um Anzeigenermüdung zu vermeiden
- Bumpering — Kurze Bumper-Creatives ("Wir sind gleich zurück" / "Willkommen zurück") umhüllen Ad Pods
Ad Event Tracking & Analytics
- Standard VAST Events —
impression,start,firstQuartile,midpoint,thirdQuartile,complete,skip,clickThrough - Viewability — MOAT/IAS Viewability-Pixel werden basierend auf Anzeigen-Viewport-Sichtbarkeit und Dauer-Schwellenwerten ausgelöst
- Benutzerdefinierte Events — App-level Events (Start/Ende der Werbeunterbrechung, Pod-Füllrate, Preload-Timing, Fallback ausgelöst)
- Server Pipeline — Client sendet Events an einen leichtgewichtigen Event Collector, der an GAM, MOAT und das interne Analytics Warehouse verteilt
- Abgleich — Serverseitiger Log-Abgleich mit clientseitigen Events zur Diskrepanzerkennung
Ad Blocker Handhabung (Web)
- Erkennung — Canary VAST-Anfrage an eine bekannte Ad-Domain; Timeout oder Blockierung deutet auf Ad Blocker hin
- Fallback-Strategie — Auslieferung von House Ads oder Werbe-Trailern von der First-Party CDN-Domain
- Content Gating — Optionales Soft Gate: Benutzer auffordern, die Website vor der Wiedergabe des Inhalts auf die Whitelist zu setzen
- Analytics — Ad Blocker-Erkennungsrate pro Browser, Geografie und Seite verfolgt
Hauptmerkmale
- Cross-Plattform CSAI — Einheitliche Anzeigeninsertion über Web, iOS, Android, Roku, Fire TV und Apple TV hinweg
- SCTE-35 Client Parsing — HLS
EXT-X-DATERANGE,CUE-OUT/INund DASHEventStreamParsing - Interaktive Anzeigen — Anklickbare Overlays, Companion-Banner und Skip-Buttons auf allen Plattformen
- Ad Pod Orchestrierung — Befüllen von Multi-Ad-Breaks mit Waterfall, Daueranpassung und Deduplizierung
- Vorladen — Ad Creatives werden während der Content-Wiedergabe vorgeladen für Anzeigenübergänge ohne Latenz
- Viewability Tracking — MOAT/IAS-Integration für die Viewability-Anforderungen von Premium-Anzeigenkäufern
- Connected TV-Konformität — Roku RAF-, Fire TV IMA- und Apple TV AVKit-Integrationen erfüllen die Zertifizierungsanforderungen
- Ad Blocker Resilienz — Erkennung und Fallback auf First-Party House Ads im Web
Ergebnisse
Technologie-Stack
caseStudyDetail.more Fallstudien
Entdecken Sie mehr unserer technischen Implementierungen
SCTE-35 Ad Marker Signalisierung & Medien-Trailer-EinfĂĽge-Pipeline
Ein Streaming-Media-Unternehmen benötigte eine robuste, automatisierte Pipeline zur Einspeisung von SCTE-35-Werbemarkern in Live- und VOD-Streams sowie die Möglichkeit, Werbetrailer (Pre-Roll, Mid-Roll und Post-Roll) an präzise getimten Positionen einzufügen — um die Monetarisierung über FAST-Kanäle, Live-Events und On-Demand-Inhaltsbibliotheken zu ermöglichen.
AWS Mediendienste fĂĽr FAST-Kanal-Streaming ĂĽber SRT
Ein Medienunternehmen benötigte die Einrichtung zuverlässiger, latenzarmer Zuspiel-Feeds für seine FAST-Kanäle unter Verwendung des Secure Reliable Transport (SRT)-Protokolls – um die hochwertige Aufnahme von Inhalten aus entfernten Studios, Cloud-Playout-Systemen und Syndikationspartnern über unvorhersehbare Internetverbindungen zu ermöglichen.
Häufig gestellte Fragen
MicrocosmWorks hat einen Manifest-Parser implementiert, der EXT-X-DATERANGE-Tags extrahiert, die base64-kodierte SCTE-35 splice_info_section-Daten enthalten, die Splice-Befehle dekodiert und die Ad-Decision-Anfrage mit der entsprechenden Unterbrechungsdauer an den VAST/VMAP-Ad-Server auslöst. Der Parser verarbeitet sowohl time_signal- als auch splice_insert-Befehlstypen über Live- und VOD-Manifeste hinweg.
MicrocosmWorks entwickelte ein gemeinsames Anzeigen-Playback-SDK mit plattformspezifischen Adaptern für AVPlayer unter iOS, ExoPlayer unter Android, hls.js im Web und native Player auf Roku und Fire TV. Das SDK normalisiert Anzeigen-Lebenszyklus-Ereignisse wie Impression, Quartil-Tracking und Abschluss auf allen Plattformen und gewährleistet ein einheitliches Reporting, unabhängig vom Wiedergabegerät.
MicrocosmWorks hat eine Timeout- und Fallback-Strategie implementiert, bei der der Player maximal 3 Sekunden auf eine Ad-Server-Antwort wartet, bevor er einen Standard-Slate abspielt oder zum nächsten Inhaltssegment springt. Das SDK pre-fetches auch bevorstehende Ad-Break-VAST-Antworten während der Inhaltswiedergabe, um die Latenz am eigentlichen Breakpoint zu minimieren.
MicrocosmWorks hat das Open Measurement SDK (OM SDK) zur Überprüfung der Sichtbarkeit integriert, kompatibel mit MOAT, IAS und DoubleVerify. Die Tracking-Implementierung folgt den IAB VAST 4.2 Spezifikationen für die Zählung von Impressionen und Quartil-Ereignissen. Das System unterstützt außerdem die Messrichtlinien der IAB Video Ad Serving Template für eine genaue Berichterstattung der Anzeigenabschlussrate.
MicrocosmWorks liefert Ad-Technologie-Implementierungen zu Preisen von $30-$50/Stunde, wobei ein komplettes CSAI-System, einschließlich SCTE-35 Parsing, VAST/VMAP-Integration und Multi-Plattform-Player-SDKs für iOS, Android, Web und CTV, typischerweise 600-900 Entwicklungsstunden erfordert. Jeder zusätzliche Plattformadapter fügt der Basisimplementierung etwa 80-120 Stunden hinzu.
Bereit, Ihr Unternehmen zu transformieren?
Lassen Sie uns besprechen, wie wir ähnliche Lösungen für Ihre Herausforderungen anwenden können.