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.
# MediaTailor Serverseitiges Ad-Tracking und Reporting
AWS Elemental MediaTailor verwendet standardmäßig serverseitige Berichte für eine umfassende Nachverfolgung und Messung von Anzeigen. Wenn der Player bei der serverseitigen Berichterstellung eine Werbe-URL vom Manifest anfordert, meldet der Service die Werbekonsumierung direkt der Werbeverfolgungs-URL. Nachdem der Player eine Wiedergabesitzung mit initialisiert hat MediaTailor, sind keine weiteren Eingaben von Ihnen oder dem Player erforderlich, um serverseitige Berichte zu erstellen. MediaTailor Sendet bei der Wiedergabe jeder Anzeige Beacons an den Anzeigenserver, um zu melden, wie viel von der Anzeige angesehen wurde. MediaTailor sendet Beacons für den Beginn der Anzeige und für den Verlauf der Anzeige in Quartilen: erstes Quartil, Mittelpunkt, drittes Quartil und Abschluss der Anzeige.
**So führen Sie die serverseitige Werbe-Berichterstellung durch**
+ Initialisieren Sie vom Player aus eine neue MediaTailor Wiedergabe-Sitzung mit einer Anfrage in einem der folgenden Formate gemäß Ihrem Protokoll:
+ Beispiel: HLS-Format
```
GET /v1/master///?ads.&
```
+ Beispiel: DASH-Format
```
GET /v1/dash///?ads.&
```
Die Schlüssel-Wert-Paare sind die dynamischen Targeting-Parameter für die Werbenachverfolgung. Weitere Informationen zum Hinzufügen von Parametern zur Anforderung finden Sie unter [MediaTailor dynamische Anzeigenvariablen für ADS-Anfragen](variables.md).
AWS Elemental MediaTailor beantwortet die Anfrage mit der Manifest-URL. Das Manifest enthält URLs für die Medienmanifeste. Die Medien-Manifeste enthalten eingebettete Links für Werbesegment-Anforderungen.
**Anmerkung**
Wenn in MediaTailor einer Tracking-URL ein doppelter Schrägstrich (//) vorkommt, werden die Schrägstriche zu einem (/) zusammengefasst.
Wenn der Player die Wiedergabe über eine Anzeigensegment-URL (`/v1/segment`Pfad) anfordert, AWS Elemental MediaTailor sendet er das entsprechende Beacon über das Anzeigen-Tracking an den Anzeigenserver. URLs Gleichzeitig gibt der Service eine Umleitung zum tatsächlichen `*.ts`-Werbesegment aus. Das Anzeigensegment befindet sich entweder in der CloudFront Amazon-Distribution, in der transkodierte Anzeigen MediaTailor gespeichert werden, oder im Content Delivery Network (CDN), in dem Sie die Anzeige zwischengespeichert haben.
In den folgenden Abschnitten finden Sie weitere Informationen zur Arbeit mit serverseitigem Ad-Tracking von. MediaTailor
**Topics**
+ [Serverseitiges SGAI-Tracking](ad-reporting-server-side-sgai.md)
+ [Beacon-Glossar](ad-reporting-server-side-beacon-glossary.md)
+ [Timing und Caching-Verhalten](ad-reporting-server-side-timing-behavior.md)
+ [Funktionen zur Nachverfolgung](ad-reporting-server-side-features.md)
# Serverseitiges Tracking mit serverseitiger Anzeigeneinfügung (SGAI)
Wenn Sie die serverseitige Anzeigeneinfügung (SGAI) verwenden, verwendet das serverseitige Tracking einen Beaconing-Mechanismus ohne *Sitzung*, der sich von dem oben beschriebenen Ansatz im gestickten Modus unterscheidet. Anstatt Anzeigensegmente in das Inhaltsmanifest MediaTailor einzufügen (wo `/v1/segment` Anfragen nachverfolgt werden), gibt SGAI Anzeigenverweise als separate Playlisten in einer Asset-Listen-Antwort mit in die Anzeige eingebetteten Beacon-Metadaten zurück. URIs
## So funktioniert serverseitiges Beaconing ohne Sitzung
In den folgenden Schritten wird beschrieben, wie serverseitiges Beaconing für SGAI-Sitzungen funktioniert:
1. **Sitzungsinitialisierung**: Der Player fordert die multivariante HLS-Wiedergabeliste mit an. `aws.insertionMode=GUIDED` Serverseitige Berichterstattung ist die Standardeinstellung (kein `aws.reportingMode` Parameter erforderlich). Im Gegensatz zum Modus „Zusammenfügen“ enthält die Antwort auf die Sitzungsinitialisierung *kein*. `trackingUrl`
1. **Zwischenspeicherbares Manifest**: MediaTailor Gibt ein zwischenspeicherbares Manifest zurück, das `EXT-X-DATERANGE` Tags `CLASS="com.apple.hls.interstitial"` und `X-ASSET-LIST` Attribute enthält, die auf den Endpunkt der MediaTailor interstitiellen Asset-Liste verweisen.
1. **Asset-Liste mit Beacon-Metadaten: Wenn der Player auf** eine Werbeunterbrechung stößt, ruft er die Asset-Liste ab. MediaTailorgibt eine JSON-Antwort zurück, in der jede Anzeigen-URI verschlüsselte Beacon-Metadaten enthält:
```
{
"ASSETS": [
{
"DURATION": 30.0,
"URI": "https://cdn.example.com/ad/master.m3u8?awsBeaconData=&awsBeaconDomain=&awsConfigurationName="
}
]
}
```
Wenn die serverseitige Berichterstattung aktiv ist, enthält die Antwort *keinen* `TRACKING` Abschnitt. Die Anzeige enthält URIs alle Beacon-Daten.
1. **HLS-Variablenersetzung**: Der Player ruft die multivariante Anzeigen-Playlist ab. Das Anzeigenmanifest verwendet `#EXT-X-DEFINE:QUERYPARAM` Direktiven, um die Beacon-Parameter aus der URI-Abfragezeichenfolge per HLS-Variablenersetzung an das Segment zu übergeben: URLs
```
#EXTM3U
#EXT-X-DEFINE:QUERYPARAM="awsBeaconData"
#EXT-X-DEFINE:QUERYPARAM="awsBeaconDomain"
#EXT-X-DEFINE:QUERYPARAM="awsConfigurationName"
#EXTINF:5.0,
{$awsBeaconDomain}/segment/hash/{$awsConfigurationName}/{$awsBeaconData}/0/0?aws.segmentRelativePath=asset_00001.ts
```
Der Player löst die `{$awsConfigurationName}` Variablen `{$awsBeaconData}``{$awsBeaconDomain}`, und anhand der Werte aus der URI-Abfragezeichenfolge für das Anzeigenmanifest auf und fordert dann jedes Anzeigensegment an. MediaTailor
1. **Auslösung eines Beacons bei Segmentanforderung**: Wenn der Player jedes Anzeigensegment anfordert, wird die Anfrage weitergeleitet. MediaTailor Der Dienst entschlüsselt die Beacon-Daten, bestimmt die Position des Segments innerhalb der Anzeige (Impression, erstes Quartil, Mittelpunkt, drittes Quartil oder vollständig) und sendet das entsprechende VAST-Tracking-Beacon an den Anzeigenserver. MediaTailor leitet den Player dann zum eigentlichen Anzeigeninhaltssegment weiter.
## Spieleranforderungen für serverseitiges SGAI-Beaconing
Um serverseitiges Beaconing mit SGAI verwenden zu können, muss Ihr Player die folgenden Anforderungen erfüllen:
+ HLS Version 11 oder höher
+ Support für `EXT-X-DATERANGE` mit `CLASS` Attribut für HLS Interstitials
+ Support für `#EXT-X-DEFINE:QUERYPARAM` Variablensubstitution (RFC 8216bis). Der Spieler muss die Werte der Abfrageparameter prozentual dekodieren, bevor er sie in ein Segment einfügt. URLs
**Anmerkung**
Serverseitiges SGAI-Beaconing wird derzeit nur für HLS unterstützt. DASH wird für serverseitiges SGAI-Beaconing noch nicht unterstützt.
## Vergleich mit serverseitigem Tracking im Stitched-Modus
In der folgenden Tabelle wird zusammengefasst, wie sich serverseitiges Tracking zwischen gestickter und serverseitiger Anzeigeneinfügung unterscheidet:
| Aspekt | Gestickt (SSAI) | Servergeführt (SGAI) |
| --- | --- | --- |
| Offensichtliche Cache-Fähigkeit | Pro Sitzung, nicht zwischenspeicherbar | Cachefähig, von allen Zuschauern gemeinsam genutzt |
| Routing von Anzeigensegmenten | Durch die /v1/segment/ Verwendung der Sitzungs-ID | Durch die /v1/segment/ Verwendung eines verschlüsselten Beacon-Datenblobs |
| Sitzungsstatus für Beacons | Pro Sitzung gespeichert in MediaTailor | Sitzungslos — der gesamte Status wird im verschlüsselten Parameter übernommen awsBeaconData |
| Tracking-URL beim Start der Sitzung | Wurde in der Antwort auf die Initialisierung der Sitzung zurückgegeben | Nicht angegeben — Beacon-Daten sind in die Anzeige URIs in jeder Antwort auf die Asset-Liste eingebettet |
| DASH-Unterstützung | Unterstützt | Noch nicht unterstützt |
**Anmerkung**
Für Live-SGAI-Sitzungen können Sie das manifestbasierte Vorabrufen von Anzeigen mithilfe von aktivieren. `aws.guidedPrefetchMode=MANIFEST` Dies ist unabhängig von der zeitplanbasierten Prefetch-API, die bei zusammengestellten Sitzungen (SSAI) verwendet wird. Details hierzu finden Sie unter [Geführter Prefetch mit offensichtlichem Herzschlag](sgai-guided-prefetch.md).
# Glossar für serverseitige Tracking-Beacons
MediaTailor Beim serverseitigen Tracking wird ein standardisierter Satz von Beacons verwendet, um den Fortschritt der Anzeige an Anzeigenserver und Bestätigungsdienste zu melden. Diese Beacons entsprechen den Standards des Interactive Advertising Bureau (IAB) für die Messung von Videoanzeigen und bieten genaue Berichte über Anzeigenimpressionen und Abschlussquoten.
**Typen serverseitiger Tracking-Beacons**
| Typ des Beacons | Wann gefeuert | Zweck | Einzelheiten zum Zeitplan |
| --- | --- | --- | --- |
| Eindruck | Wenn der Spieler das erste Anzeigensegment anfordert | Weist darauf hin, dass der Anzeigeninhalt geladen wurde und demnächst dem Zuschauer angezeigt wird | Wird bei der ersten /v1/segment Anforderung einer Anzeige ausgelöst. Entspricht den IAB-Richtlinien, nach denen Anzeigeninhalte geladen werden müssen, bevor eine Impression gezählt wird. Die vollständige [Workflow zur serverseitigen Nachverfolgung](ad-reporting-server-side-timing-behavior.md#ad-reporting-server-side-timing-behavior-workflow) Reihenfolge finden Sie unter. |
| Starten | Wenn der Player mit dem Rendern des Anzeigeninhalts beginnt | Bestätigt, dass die Anzeigenwiedergabe tatsächlich gestartet wurde | Wird normalerweise gleichzeitig mit dem Impression-Beacon bei der ersten Segmentanforderung ausgelöst, stellt jedoch den tatsächlichen Beginn des Anzeigenrenderings dar. Diese Unterscheidung ist wichtig für Verifizierungsdienste, die sowohl Impressions- als auch Startereignisse getrennt verfolgen. |
| Erstes Quartil | Wenn der Spieler 25% der Anzeigendauer erreicht | Measures setzte die Anzahl der Werbeanzeigen während des ersten Quartals der Anzeige fort | Wird ausgelöst, wenn der Player das Segment anfordert, das den 25% -Punkt der Anzeigendauer enthält. Bei einer 20-Sekunden-Anzeige mit 2-Sekunden-Segmenten würde dies in der Regel bei der Anfrage für das dritte Segment ausgelöst (etwa 4-6 Sekunden nach Beginn der Anzeige). |
| Mittelpunkt | Wenn der Spieler 50% der Anzeigendauer erreicht | Measures hat die Anzeige während der Hälfte der Werbeanzeige fortgesetzt | Wird ausgelöst, wenn der Player das Segment anfordert, das den 50% -Punkt der Anzeigendauer enthält. Bei einer 20-Sekunden-Anzeige mit 2-Sekunden-Segmenten würde dies in der Regel bei der Anfrage für das 5. Segment ausgelöst (etwa 8 bis 10 Sekunden nach Beginn der Anzeige). |
| Drittes Quartil | Wenn der Spieler 75% der Anzeigendauer erreicht | Measures hat die Anzeige während drei Vierteln der Werbeanzeige fortgesetzt | Wird ausgelöst, wenn der Player das Segment anfordert, das den 75% -Punkt der Anzeigendauer enthält. Bei einer 20-Sekunden-Anzeige mit 2-Sekunden-Segmenten würde dies in der Regel bei der Anfrage für das 8. Segment ausgelöst (etwa 14-16 Sekunden nach Beginn der Anzeige). |
| Vollständig | Wenn der Spieler das Ende der Anzeige erreicht | Bestätigt, dass dem Zuschauer die gesamte Anzeige zugestellt wurde | Wird ausgelöst, wenn der Player das letzte Segment der Anzeige anfordert. Dies deutet darauf hin, dass der Zuschauer möglicherweise den gesamten Anzeigeninhalt gesehen hat. Bei einer 20-Sekunden-Anzeige mit 2-Sekunden-Segmenten würde dies in der Regel bei der Anfrage für das 10. Segment ausgelöst (etwa 18 bis 20 Sekunden nach Beginn der Anzeige). |
**Anmerkung**
Der genaue Zeitpunkt der Auslösung des Beacons hängt von der Dauer des Segments und der Länge der Anzeige ab. MediaTailor berechnet auf der Grundlage der spezifischen Anzeigendauer und Segmentstruktur die entsprechende Segmentanforderung, die jeder Quartilposition entspricht.
# 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).
# MediaTailor Funktionen und Funktionen zur serverseitigen Nachverfolgung
AWS Elemental MediaTailor wendet diese integrierten serverseitigen Tracking-Funktionen automatisch an, um die Genauigkeit und Zuverlässigkeit der Anzeigenmessung zu optimieren. Das System verhindert doppelte Beacons, verwaltet den Datenverkehr in Zeiten mit hohem Datenvolumen, sorgt für eine korrekte Reihenfolge der Ereignisse und bietet eine umfassende Leistungsüberwachung, ohne dass Sie eine Konfiguration vornehmen müssen. Sie müssen lediglich sicherstellen, dass Ihr Ad Decision Server (ADS) die Tracking-Beacons in der VAST-Antwort bereitstellt.
**Anmerkung**
Diese Funktionen sind für Neukunden ab dem 30. September 2025 verfügbar. Bestandskunden werden im Rahmen der laufenden Serviceverbesserungen bis 2025 Zugriff darauf haben. Wenn Sie sofort auf diese Funktionen zugreifen möchten, wenden Sie sich an den [AWS-Support](https://aws.amazon.com/premiumsupport/).
**Anmerkung**
Diese Funktionen gelten sowohl für zusammengefügte (SSAI) als auch für servergeführte (SGAI) Methoden zum Einfügen von Anzeigen. Die Beacon-Typen und das Timing sind in beiden Modi identisch. Sie unterscheiden sich darin, wie Beacons MediaTailor ausgelöst werden. Weitere Informationen [Serverseitiges Tracking mit serverseitiger Anzeigeneinfügung (SGAI)](ad-reporting-server-side-sgai.md) zum serverseitigen SGAI-Beaconing finden Sie unter.
## Beacon-Deduplizierung
MediaTailor verhindert das doppelte Auslösen von Beacons bei identischen Werbeereignissen. Das serverseitige Tracking-System sendet jede Impression, jedes Quartil und jedes Abschluss-Beacon nur einmal pro Sitzung, in der sich die Anzeige angesehen hat. Wenn Videoplayer aufgrund von Netzwerkbedingungen, Bitratenänderungen oder Pufferstrategien mehrmals dasselbe Anzeigensegment anfordern, MediaTailor verfolgt es ausgelöste Beacons und blockiert redundante Übertragungen.
Durch die Deduplizierung werden häufig auftretende Szenarien, die zu einer erhöhten Anzahl von Beacons führen, automatisch behoben:
+ **Adaptives Bitraten-Streaming** — Wenn Spieler unterschiedliche Qualitätsvarianten desselben Anzeigensegments herunterladen
+ **Wiederholungsszenarien im Netzwerk** — Wenn Spieler Segmente aufgrund von Netzwerkproblemen oder Timeouts erneut anfordern
+ **Pufferstrategien für Spieler** — Wenn Spieler Segmente zu Pufferzwecken vorab abrufen oder erneut abrufen
Das System ist so konzipiert, dass Impression Beacons nur einmal ausgelöst werden, selbst wenn Spieler zwischen verschiedenen Qualitätsstufen wechseln.
## Adaptive Drosselung und wiederholte Beacon-Versuche
MediaTailor verwaltet automatisch die Beacon-Datenverkehrsraten auf der Grundlage von Serverantwortindikatoren. Das System überwacht HTTP-Antwortmuster, Verbindungs-Timeouts und Fehlercodes, um Überlastungen zu erkennen, und passt dann die Datenverkehrsraten entsprechend an. Wenn das System Indikatoren für die Serverauslastung identifiziert, reduziert es die Datenverkehrsraten für die betroffene Domäne und erhöht die Rate automatisch, wenn Server eine verbesserte Kapazität nachweisen.
Das System überwacht den Serverstatus anhand dieser Indikatoren:
+ **Timeouts bei HTTP-Verbindungen** — Wenn Messplattformen nicht innerhalb des erwarteten Zeitrahmens reagieren
+ **Fehlerantwortcodes** — 503-, 504- und 507-Antworten, die auf eine Serverüberlastung hinweisen. Ihr Anzeigenserver muss diese Fehlercodes ebenfalls unterstützen, um eine vollständige Kompatibilität zu gewährleisten.
+ **Reaktionsmuster** — Leistungsänderungen der Messplattform, die auf Kapazitätsprobleme hindeuten
Beim Wiederholungsversuch wird automatisch eine Zustellung für bis zu 1 Stunde versucht, wobei zwischen den Versuchen eine Verzögerung von mindestens 30 Sekunden besteht. Dieses Wiederholungsverhalten kann nicht konfiguriert werden.
## Verwaltung des Beacon-Datenverkehrs pro Sekunde
Sie können TPS-Grenzwerte festlegen, um die Übertragungsraten von Beacons zu steuern. Dies ist die einzige konfigurierbare Einstellung für serverseitige Tracking-Funktionen. Limits auf Kontoebene begrenzen die Gesamtzahl der Ad-Tracking-Anfragen, die an alle Messpartner gesendet werden. MediaTailor erzwingt ein TPS-Limit von mindestens 10.000, um ausreichend Kapazität für den Betrieb auf Unternehmensebene bereitzustellen.
Reichen Sie ein AWS Supportticket ein, um TPS-Limits mit den folgenden Informationen festzulegen:
+ **AWS-Konto-ID** — Ihre spezifische Konto-ID
+ **Zielregion** — Die AWS-Region, in der das TPS-Limit angewendet werden soll
+ **Gewünschter TPS-Schwellenwert** — Ihr erforderliches Limit für Transaktionen pro Sekunde (mindestens 10.000)
Standardmäßig gibt es kein TPS-Limit. Sie können ein TPS-Limit anfordern, wenn Ihr Ad Decision Server (ADS) dies erfordert, aber das Limit muss höher als 10.000 TPS sein. MediaTailor wird das angegebene Limit nicht überschreiten, garantiert aber keinen gleichbleibenden Durchsatz bis zu diesem Limit. Ihr Anzeigenentscheidungsserver teilt Ihnen mit, welche TPS-Grenzwerte er unterstützen kann.
## Beaconing in der richtigen Reihenfolge
MediaTailor sorgt automatisch für die sequentielle Bereitstellung von Ad-Tracking-Ereignissen. Das System behält die Reihenfolge der Beacons bei, auch wenn Netzwerkprobleme, Wiederholungsversuche oder Datenverkehrsmanagement auftreten. Dadurch wird sichergestellt, dass die Messpartner die Ereignisse in der richtigen Reihenfolge erhalten, sodass genaue Analysen möglich sind.
Das System folgt der branchenüblichen Beacon-Reihenfolge:
1. **Ereignisse starten** — Wird ausgelöst, wenn die Anzeigenwiedergabe beginnt
1. **Ereignisse im ersten Quartil** — werden ausgelöst, wenn die Anzeige zu 25% abgeschlossen ist
1. **Ereignisse in der Mitte —** Die Anzeige wird bei 50% abgeschlossener Anzeige ausgelöst
1. **Ereignisse im dritten Quartil** — Die Anzeige wurde zu 75% ausgelöst
1. **Fertigstellungsereignisse** — werden ausgelöst, wenn die Werbung beendet ist
Diese Funktionen arbeiten automatisch zusammen:
+ Die Beacons werden während der Drosselung aktiviert, um die richtige Reihenfolge aufrechtzuerhalten
+ Jede Domäne des Messpartners verfügt über separate Ereigniswarteschlangen, um Störungen bei Ratenanpassungen zu vermeiden
+ Bei der Deduplizierung werden der Ereignistyp und die zeitliche Position unter Beibehaltung der chronologischen Reihenfolge verfolgt