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 & Media-Trailer-Einfügepipeline
Ein Streaming-Medienunternehmen benötigte eine robuste, automatisierte Pipeline zur Injektion von SCTE-35 Ad-Markern 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 implemented a manifest parser that extracts EXT-X-DATERANGE tags containing base64-encoded SCTE-35 splice_info_section data, decodes the splice commands, and triggers the ad decision request to the VAST/VMAP ad server with the appropriate break duration. The parser handles both time_signal and splice_insert command types across live and VOD manifests.
MicrocosmWorks built a shared ad playback SDK with platform-specific adapters for AVPlayer on iOS, ExoPlayer on Android, hls.js on web, and native players on Roku and Fire TV. The SDK normalizes ad lifecycle events like impression, quartile tracking, and completion across all platforms, ensuring unified reporting regardless of the playback device.
MicrocosmWorks implemented a timeout and fallback strategy where the player waits a maximum of 3 seconds for an ad server response before playing a default slate or skipping to the next content segment. The SDK also pre-fetches upcoming ad break VAST responses during content playback to minimize latency at the actual break point.
MicrocosmWorks integrated Open Measurement SDK (OM SDK) for viewability verification compatible with MOAT, IAS, and DoubleVerify, and the tracking implementation follows IAB VAST 4.2 specifications for impression counting and quartile events. The system also supports IAB's Video Ad Serving Template measurement guidelines for accurate ad completion rate reporting.
MicrocosmWorks delivers ad technology implementations at rates of $30-$50/hr, with a full CSAI system including SCTE-35 parsing, VAST/VMAP integration, and multi-platform player SDKs for iOS, Android, web, and CTV typically requiring 600-900 development hours. Each additional platform adapter adds approximately 80-120 hours to the base implementation.
Bereit, Ihr Unternehmen zu transformieren?
Lassen Sie uns besprechen, wie wir ähnliche Lösungen für Ihre Herausforderungen anwenden können.