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.
# Serverseitiges Tracking-Timing und Caching-Verhalten
Bei serverseitigen Berichten werden Tracking-Ereignisse auf der Grundlage von tatsächlichen Segmentanfragen des Players MediaTailor ausgelöst, nicht auf manifesten Parsing- oder Pre-Loading-Aktivitäten. 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 sie stellt `/v1/segment` URLs, nicht beim Analysieren oder Zwischenspeichern von Manifesten.
+ **Durch das Zwischenspeichern von Spielern und das Vorabladen von Manifesten werden KEINE Ereignisse ausgelöst**. Spieler können Manifestinformationen analysieren, zwischenspeichern oder vorab laden, ohne Tracking-Ereignisse zu generieren.
+ **Das Vorabrufen von Segmenten *löst* Ereignisse aus** — Wenn Spieler vor der Wiedergabe tatsächliche Anzeigensegmente vorab abrufen, entspricht dies dem branchenüblichen Verhalten, bei dem Segmentanfragen gültige Impressionen darstellen.
+ **Jede /v1/segment-Anfrage löst den entsprechenden Beacon** aus. Das spezifische Tracking-Ereignis (Impression, Quartil, Abschluss) wird durch die Anzeigenposition und das angeforderte Segment bestimmt.
+ **Das Timing entspricht den IAB-Standards** — Der Ansatz entspricht den Richtlinien des Interactive Advertising Bureau für die Messung von Videoanzeigen und die Zählung von Impressionen.
## Workflow zur serverseitigen Nachverfolgung
Die folgenden Diagramme veranschaulichen den vollständigen serverseitigen Tracking-Workflow und zeigen, wann Tracking-Events im Zusammenhang mit Spieleranfragen ausgelöst werden:
**Phase 1: Initialisierung der Sitzung**
Der Player fordert ein Manifest von an MediaTailor, das ein personalisiertes Manifest mit einem Anzeigensegment URLs zurückgibt:
![\[In der Phase der Sitzungsinitialisierung fordert der Spieler ein Manifest an MediaTailor und erhält ein personalisiertes Manifest mit Anzeigensegment URLs.\]](http://docs.aws.amazon.com/de_de/mediatailor/latest/ug/images/ss-track-phase1.png)
**Phase 2: Anzeigenanfrage und Nachverfolgung von Impressionen**
Wenn der Player das erste Anzeigensegment anfordert, sendet er MediaTailor Impressions- und Start-Beacons sowohl an den Ad Decision Server als auch an die Anzeigenverifizierungsdienste:
![\[Phase zur Nachverfolgung von Anzeigenimpressionen, in der sowohl Impressionen als auch Start-Beacons an den Ad Decision Server und die Anzeigenverifizierungsdienste MediaTailor gesendet werden, wenn der Player das erste Anzeigensegment anfordert.\]](http://docs.aws.amazon.com/de_de/mediatailor/latest/ug/images/ss-track-phase2.png)
**Phase 3: Verfolgung von Quartilen**
MediaTailor löst Quartil-Beacons (erstes Quartil, Mittelpunkt, drittes Quartil, Abschluss) auf der Grundlage nachfolgender Segmentanfragen aus:
![\[In der Quartil-Tracking-Phase werden Quartil-Beacons sowohl an den MediaTailor Ad Decision Server als auch an die Anzeigenverifizierungsdienste gesendet, wenn der Spieler nachfolgende Anzeigensegmente anfordert.\]](http://docs.aws.amazon.com/de_de/mediatailor/latest/ug/images/ss-track-phase3.png)
**Phase 4: Bereitstellung in Segmenten**
Nachdem Sie die Tracking-Beacons ausgelöst haben, werden Sie von Amazon CloudFront oder Ihrem CDN zum eigentlichen Anzeigensegment MediaTailor weitergeleitet:
![\[Phase der Segmentbereitstellung, in der der Spieler nach dem Auslösen von MediaTailor Tracking-Beacons zum eigentlichen Anzeigensegment von CloudFront oder CDN weitergeleitet wird.\]](http://docs.aws.amazon.com/de_de/mediatailor/latest/ug/images/ss-track-phase4.png)
Der serverseitige Tracking-Workflow umfasst die folgenden wichtigen Timing-Verhaltensweisen:
1. **Sitzungsinitialisierung** — Der Player fordert ein Manifest von an. MediaTailor MediaTailor gibt ein personalisiertes Manifest zurück, das ein Anzeigensegment URLs mit dem `/v1/segment` Pfad enthält.
1. **Analysieren und Zwischenspeichern von Manifesten** — Der Spieler analysiert das Manifest und kann Segmentinformationen vorab laden oder zwischenspeichern. **In dieser Phase werden keine Tracking-Ereignisse ausgelöst, unabhängig vom Verhalten des Spielers beim** Zwischenspeichern.
1. **Anforderung von Anzeigensegmenten und Nachverfolgung von Impressionen** — Wenn der Player tatsächlich das erste Anzeigensegment anfordert (normalerweise für die Wiedergabe), wird das Impression-Beacon MediaTailor ausgelöst und das Ereignis wird sowohl auf dem Ad Decision Server als auch auf den Anzeigenverifizierungsdiensten verfolgt. Dies geschieht bei der eigentlichen HTTP-Anfrage an die `/v1/segment` URL, nicht bei der Analyse des Manifests.
1. **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 Anzeigenverifizierungsdienste auf der Grundlage von nachfolgenden Segmentanfragen, die den berechneten Quartilpositionen innerhalb der Anzeigendauer entsprechen.
1. **Segmentzustellung** — Führt nach dem MediaTailor Auslösen des entsprechenden Tracking-Beacons eine HTTP-Weiterleitung zum eigentlichen Anzeigensegment aus (entweder von Amazon CloudFront oder Ihrem CDN).
## Überlegungen zum Zwischenspeichern von Spielern und zum Vorladen
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:
+ **Vorladen von Manifesten** — Spieler, die Manifestinformationen vorab laden oder zwischenspeichern, lösen keine Tracking-Ereignisse aus. Tracking-Ereignisse werden nur ausgelöst, wenn tatsächlich Segmentanfragen gestellt werden.
+ **Vorabruf von Segmenten** — Wenn ein Player Anzeigensegmente vor der Wiedergabe vorab abruft, werden Tracking-Events ausgelöst, wenn diese Segmente angefordert werden, möglicherweise vor der tatsächlichen Wiedergabezeit. Dieses Verhalten entspricht den Branchenstandards, die Segmentanfragen als gültige Impressionen betrachten.
+ **Pufferung durch Spieler** — Das Standardverhalten von Playern (das Abrufen von Segmenten kurz vor der Wiedergabe) löst Tracking-Ereignisse zu den entsprechenden Zeiten aus, die auf dem Muster der Segmentanfragen basieren.
## Behebung von Tracking-Diskrepanzen
Wenn Sie Diskrepanzen zwischen MediaTailor serverseitigem Tracking und Messwerten von Drittanbietern feststellen, sollten Sie die folgenden Faktoren berücksichtigen:
+ **Unterschiede im Spielerverhalten** — Verschiedene Spieler haben möglicherweise unterschiedliche Prefetching- 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 dazu führen, dass Tracking-Ereignisse verpasst oder doppelt durchgeführt werden.
+ **Sitzungsverwaltung** — Stellen Sie sicher, dass für jede Wiedergabesitzung eine eindeutige Sitzungs-ID verwendet wird, um Konflikte bei Tracking-Ereignissen zu vermeiden.
Eine ausführliche Anleitung zur Problembehebung finden Sie unter[Behebung häufiger Probleme](monitoring-and-troubleshooting.md#troubleshooting-common-issues).