View a markdown version of this page

Server-side verfolgt das Timing und das Caching-Verhalten - AWS Elemental MediaTailor
Grundsätze des ZeitplansArbeitsablauf verfolgenÜberlegungen zum CachingBehebung von Unstimmigkeiten

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Server-side verfolgt das Timing und das Caching-Verhalten

Bei serverseitigen Berichten werden Tracking-Ereignisse auf der Grundlage der tatsächlichen Segmentanfragen des Players MediaTailor ausgelöst, nicht aufgrund von Aktivitäten zum Analysieren oder Laden von Manifesten. Dieser Ansatz gewährleistet eine genaue Zählung der Impressionen, die den Industriestandards für die Messung von Videoanzeigen entspricht.

Wichtige Timing-Prinzipien

MediaTailor Das serverseitige Tracking folgt diesen grundlegenden Timing-Prinzipien:

  • Tracking-Ereignisse werden bei tatsächlichen Segmentanfragen ausgelöst. Beacons werden nur gesendet, wenn der Player HTTP-Anfragen an /v1/segment URLs stellt, nicht beim Parsen oder Caching von Manifesten.

  • Das Zwischenspeichern und Vorladen von Manifesten durch Spieler löst KEINE Ereignisse aus — Spieler können Manifestinformationen analysieren, zwischenspeichern oder vorab laden, ohne irgendwelche Tracking-Ereignisse zu generieren.

  • Das Vorabrufen von Segmenten löst Ereignisse aus — Wenn Spieler die tatsächlichen Anzeigensegmente vor der Wiedergabe vorab abrufen, folgt dies dem branchenüblichen Verhalten, bei dem Segmentanfragen gültige Impressionen darstellen.

  • Jede v1/segment /-Anfrage löst das entsprechende Beacon aus. Das spezifische Tracking-Ereignis (Impression, Quartil, Abschluss) wird durch die Position der Anzeige und das angeforderte Segment bestimmt.

  • Das Timing entspricht den IAB-Standards — Der Ansatz folgt den Richtlinien des Interactive Advertising Bureau zur Messung von Videoanzeigen und zur Zählung von Impressionen.

Server-side Ablauf zur Nachverfolgung

Die folgenden Diagramme veranschaulichen den vollständigen serverseitigen Tracking-Workflow und zeigen, wann Tracking-Ereignisse in Bezug auf Spieleranfragen ausgelöst werden:

Phase 1: Initialisierung der Sitzung

Der Player fordert ein Manifest von an MediaTailor, das ein personalisiertes Manifest zurückgibt, das die URLs der Anzeigensegmente enthält:

Phase der Sitzungsinitialisierung, in der der Spieler ein Manifest anfordert MediaTailor und ein personalisiertes Manifest mit Anzeigensegment-URLs erhält.
Phase 2: Verfolgung von Anzeigenanfragen und Impressionen

Wenn der Player das erste Anzeigensegment anfordert, MediaTailor werden Impressions- und Start-Beacons sowohl zum Ad Decision Server als auch zu den Ad Verification Services gesendet:

Phase zur Erfassung der Anzeigenimpressionen. Dabei werden sowohl die Impressions- als auch die Start-Beacons an den Ad Decision Server und die Ad Verification Services MediaTailor gesendet, wenn der Spieler das erste Anzeigensegment anfordert.
Phase 3: Verfolgung der Quartile

MediaTailor feuert Quartil-Beacons (erstes Quartil, Mittelpunkt, drittes Quartil, Abschluss) auf der Grundlage nachfolgender Segmentanfragen ab:

Quartil-Tracking-Phase, bei der Quartil-Beacons sowohl an den Ad MediaTailor Decision Server als auch an die Ad Verification Services gesendet werden, wenn der Spieler nachfolgende Anzeigensegmente anfordert.
Phase 4: Auslieferung der Segmente

Nach dem Auslösen der Tracking-Beacons MediaTailor erfolgt eine Weiterleitung zum eigentlichen Anzeigensegment von Amazon CloudFront oder Ihrem CDN:

Phase der Segmentbereitstellung, in der der Spieler nach dem Auslösen der MediaTailor Tracking-Beacons zum tatsächlichen Anzeigensegment von CloudFront oder CDN weitergeleitet wird.

Der serverseitige Tracking-Workflow umfasst die folgenden wichtigen Timing-Verhaltensweisen:

  1. Sitzungsinitialisierung — Der Spieler fordert ein Manifest von an. MediaTailor MediaTailor gibt ein personalisiertes Manifest zurück, das Anzeigensegment-URLs mit dem /v1/segment Pfad enthält.

  2. Analysieren und Zwischenspeichern von Manifesten — Der Player analysiert das Manifest und kann Segmentinformationen vorab laden oder zwischenspeichern. In dieser Phase werden keine Tracking-Events ausgelöst, unabhängig davon, wie sich der Spieler beim Zwischenspeichern verhält.

  3. Anzeigensegment-Anfrage und Impressions-Tracking — Wenn der Player tatsächlich das erste Anzeigensegment anfordert (in der Regel für die Wiedergabe), MediaTailor löst er das Impression-Beacon aus und startet das Tracking-Ereignis sowohl an den Ad Decision Server als auch an die Ad Verification Services. Dies geschieht bei der eigentlichen HTTP-Anfrage an die /v1/segment URL, nicht beim Analysieren des Manifests.

  4. Quartil-Tracking auf der Grundlage von Segmentanfragen — MediaTailor sendet Quartil-Beacons (erstes Quartil, Mittelpunkt, drittes Quartil, Abschluss) sowohl an den Ad Decision Server als auch an die Ad Verification Services, basierend auf nachfolgenden Segmentanfragen, die den berechneten Quartilpositionen innerhalb der Anzeigendauer entsprechen.

  5. Segmentauslieferung — Nach dem Auslösen des entsprechenden Tracking-Beacons erfolgt eine HTTP-Weiterleitung zum eigentlichen Anzeigensegment ( MediaTailor entweder von Amazon oder Ihrem CDN). CloudFront

Überlegungen zum Zwischenspeichern und Vorladen von Spielern

MediaTailor Das serverseitige Tracking ist so konzipiert, dass es mit verschiedenen Strategien zum Zwischenspeichern und Vorladen von Spielern kompatibel ist und gleichzeitig eine genaue Messung der Impressionen gewährleistet ist:

  • Vorabladen von Manifesten — Spieler, die Manifestinformationen vorab laden oder zwischenspeichern, lösen keine Tracking-Ereignisse aus. Tracking-Ereignisse werden nur ausgelöst, wenn tatsächliche Segmentanforderungen gestellt werden.

  • Segmentvorabruf — Wenn ein Player Anzeigensegmente vor der Wiedergabe vorab abruft, werden Tracking-Events ausgelöst, wenn diese Segmente angefordert werden, möglicherweise früher als die tatsächliche Wiedergabezeit. Dieses Verhalten entspricht den Industriestandards, nach denen Segmentanfragen als gültige Impressionen betrachtet werden.

  • Player-Pufferung — Das Standardverhalten beim Puffern von Playern (das Abrufen von Segmenten kurz vor der Wiedergabe) löst Tracking-Ereignisse zu den richtigen Zeiten aus, die auf dem Muster der Segmentanforderungen basieren.

Behebung von Tracking-Diskrepanzen

Wenn Sie Diskrepanzen zwischen MediaTailor serverseitigem Tracking und Metriken von Drittanbietern feststellen, sollten Sie die folgenden Faktoren berücksichtigen:

  • Unterschiede im Spielerverhalten — Verschiedene Spieler haben möglicherweise unterschiedliche Prefetch- und Pufferstrategien, die sich darauf auswirken, wann Segmentanfragen gestellt werden.

  • Netzwerkbedingungen — Schlechte Netzwerkbedingungen können dazu führen, dass Spieler Segmente mehrmals oder in anderen Intervallen als erwartet anfordern.

  • CDN-Konfiguration — Falsches CDN-Caching von /v1/segment Anfragen kann zu verpassten oder doppelten Tracking-Ereignissen führen.

  • Sitzungsverwaltung — Stellen Sie sicher, dass jede Wiedergabesitzung eine eindeutige Sitzungs-ID verwendet, um Konflikte bei der Nachverfolgung von Ereignissen zu vermeiden.

Eine ausführliche Anleitung zur Problembehandlung finden Sie unterBehebung häufiger Probleme.