Steuern der Ereignisreihenfolge
Erstellt für:
- Benutzende
- Admin
- Entwickler
Die Verfolgung von Streaming-Videos ist in hohem Maße zeitabhängig, und gelegentlich werden die Media Collection-API-Verfolgungsaufrufe im Back-End nicht ordnungsgemäß gesendet. Das Back-End versucht in solchen Fällen, die Ereignisse in eine Warteschlange einzureihen und je nach Zeitstempel im Objekt playerTime
neu zu ordnen. Dies geschieht mit einigen Einschränkungen. Aktuell kann die Neusortierung fehlschlagen, wenn die Verzögerung zwischen den nicht ordnungsgemäß eingehenden Aufrufen mehr als eine Sekunde beträgt. In zukünftigen Updates wird es eventuell möglich sein, die „akzeptable Zeitverzögerung“ zu optimieren und zu konfigurieren.
Beispiel für ein nicht in der Reihenfolge befindliches Ereignis
Ereignisse, die nicht in der richtigen Reihenfolge auftreten, werden ausgelöst, wenn Ereignisse das Netzwerk passieren, was manchmal zu einer Verzögerung führt.
Sie könnten beispielsweise ein adBreakStart
-Ereignis gefolgt von einem adStart
-Ereignis senden. Dies ist ein gängiger Anwendungsfall, da es für den Start einer Anzeige innerhalb einer Werbeunterbrechung erforderlich ist.
Wenn die Anzeige bereit und kein Puffer erforderlich ist, finden beide Ereignis praktisch sofort statt und die playerTime.ts
für beide Ereignis liegen sehr nahe beieinander – sie sollten jedoch nie gleich sein.
Der Ereigniswert „playerTime.ts“ sollte für kein Ereignis gleich sein, da der Sortieralgorithmus sonst nicht feststellen kann, welches Ereignis zuerst eintrat. Bei allen aufeinander folgenden Ereignissen sollten die Zeitstempel mindestens eine Millisekunde auseinander liegen.
Da sich beide Ereignisse beim Auslösen von Netzwerkaufrufen sehr nahe beieinander befinden, ist es möglich, dass sie nicht in der richtigen Reihenfolge ankommen. In diesem Beispiel kommt das Ereignis adStart
vor dem Ereignis adBreakStart
an.
Es gibt ein Zeitfenster für Ereignisse: 5 Sekunden oder maximal 10 Ereignisse. Die Ereignisse werden gepuffert, bevor sie an die Verarbeitungs-Pipeline gesendet werden. Wenn die Bedingungen erfüllt sind – wenn also 5 Sekunden vergangen oder mehr als 10 Ereignisse empfangen werden –, werden die Ereignisse basierend auf dem Wert playerTime.ts
neu angeordnet und dann in der neuen Reihenfolge an die Verarbeitungs-Pipeline gesendet.
sessionStart
stellt eine Ausnahme dar und wird sofort an die Verarbeitungs-Pipeline gesendet.Analytics
- Streaming Media Collection-Handbuch
- Versionshinweise
- Erste Schritte
- Implementierung
- Implementierungsübersicht
- Edge-Implementierungen (empfohlen)
- Nur Adobe Analytics-Implementierungen
- Voraussetzungen
- Media-SDKs/Erweiterung
- Mediensammlungs-APIs − Implementierung
- Mediensammlung
- API-Schnellstart
- Sitzungsanfrage
- Ereignisanfrage
- Anfrageparameter
- Ereignistypen und -beschreibungen
- Implementieren der API
- Einstellen des HTTP-Anfragetyps in Ihrem Player
- Beziehen einer Sitzungs-ID
- Implementieren einer Ereignisanfrage
- JSON-Validierungsschemas
- Validieren von Ereignisanfragen
- Senden von Ping-Ereignissen
- Senden von QoE-Daten
- Unterstützung benutzerspezifischer Metadaten
- Timeout-Bedingungen
- Steuern der Ereignisreihenfolge
- Einreihen von Ereignissen in die Warteschlange bei langsamer Sitzungsantwort
- Variablen
- Reporting
- Nutzungsszenarios
- Anwendungsfälle für Media SDK
- Player-Status-Tracking
- Tracking heruntergeladener Inhalte
- Federated Media
- Behandlung von Anwendungsunterbrechungen während der Wiedergabe
- Media Stream-Zuordnung
- Wiederaufnehmen von inaktiven Sitzungen
- Roku-Tracking in SceneGraph
- Umgang mit Lücken zwischen Anzeigen
- Timelines
- Verwenden von Analytics in OTT-Apps
- Tracking
- Datenschutz und Sicherheit
- Legacy-Implementierungen
- Legacy − Übersicht
- Legacy − SDKs herunterladen
- Legacy − Medien-SDKs
- Über Heartbeat-Messungen
- Adobe Primetime
- Aktivierung von Adobe Audience Management
- Implementierung benutzerdefinierter Links
- Veraltete Milestone-Verfolgung
- Validierung
- Legacy-Migration: VHL 1.x zu VHL 2.x
- Code-Vergleich von v1.x mit v2.x
- Tracking-APIs 1x bis 2x
- Legacy − Einführung in AVA
- Client-seitiger Pfad
- Legacy-Tracking
- Nachverfolgen der grundlegenden Wiedergabe auf Android
- Nachverfolgen der grundlegenden Wiedergabe auf iOS
- Tracking von Core-Wiedergaben in JavaScript
- Tracking von Core-Wiedergaben in JavaScript 2.x
- Nachverfolgen der Pufferung auf Android
- Nachverfolgen der Pufferung auf iOS
- Puffer-Tracking in JavaScript
- Nachverfolgen von Suchen auf Android
- Nachverfolgen von Suchen auf iOS
- Suchen-Tracking in JavaScript
- Standard-Metadaten in Android implementieren
- Standard-Metadaten in iOS implementieren
- iOS-Metadatenschlüssel
- Standard-Metadaten in JavaScript implementieren
- Anzeigen nachverfolgen
- Kapitel und Segmente nachverfolgen
- Fehler nachverfolgen
- Tracking-Szenarien
- VOD-Wiedergabe ohne Anzeigen
- VOD-Wiedergabe mit Pre-roll-Anzeigen
- VOD-Wiedergabe mit übersprungenen Anzeigen
- VOD-Wiedergabe mit einem Kapitel
- VOD-Wiedergabe mit einem übersprungenen Kapitel
- VOD-Wiedergabe mit Suche im Hauptinhalt
- VOD-Wiedergabe mit Pufferung
- Mehrere parallele VOD-Tracker
- Ein VOD-Tracker für mehrere Sitzungen
- Live-Hauptinhalt
- Live-Hauptinhalt mit sequentieller Verfolgung