Attribution Reporting API

Konzepte und Verwendung

Werbetreibende möchten häufig messen, wie viele Nutzer eine Anzeige sehen und anschließend ein Produkt ansehen und kaufen (Konversionen). Dies ermöglicht ihnen festzustellen, welche Werbeplatzierungen den größten Return on Investment (ROI) liefern, sodass sie ihre Werbestrategie entsprechend anpassen können. Der Prozess der Konversionsmessung umfasst in der Regel die Erfassung von Daten wie:

• Welche Nutzer konvertiert haben (zum Beispiel einen Artikel gekauft oder sich für einen Dienst angemeldet), und wie viele.
• Die geografischen Regionen, in denen sie sich befinden.
• Auf welchen Seiten die Anzeigen platziert wurden.
• Wie viele Produkte verkauft oder Dienste abonniert wurden, etc.
• Wie viel Umsatz generiert wurde.

Traditionell wurde im Web die Konversion mithilfe von Drittanbieter-Tracking-Cookies gemessen. Eine Anzeige wird typischerweise auf einer Webseite in einem <iframe> eingebettet, das ein Cookie mit Informationen über den Nutzer und seine Interaktion mit der Anzeige setzen kann.

Später, wenn der Nutzer die Website des Werbetreibenden besucht, vorausgesetzt, sie ist von derselben Domain wie die Anzeige, kann diese Seite auf das von der Anzeige vorher gesetzte Drittanbieter-Cookie zugreifen. Der Werbetreibende kann dann die Daten der Anzeige mit seinen eigenen Erstanbieterdaten verbinden, um Fragen wie "Hat der Nutzer ein Produkt gekauft, nachdem er mit einer Anzeige für das Produkt von einer anderen Seite interagiert hat?" zu beantworten.

Dies ist schlecht für die Privatsphäre der Nutzer. Zu diesem Zeitpunkt kann jede Seite derselben Domain auf dieses Cookie sowie auf Informationen von Seiten, die diese Seiten einbetten, zugreifen. Eine überraschend große Anzahl von Parteien kann auf diese Daten zugreifen und basierend auf den Surfgewohnheiten der Nutzer zusätzliche Daten ableiten.

Die Attribution Reporting API bietet eine Möglichkeit, Werbekonversionen auf eine Art zu messen, die die Privatsphäre der Nutzer schützt.

Wie funktioniert es?

Lassen Sie uns veranschaulichen, wie die Attribution Reporting API funktioniert, anhand eines Beispiels.

Angenommen, wir haben einen Online-Shop, shop.example (also den Werbetreibenden), der eine Anzeige für eines seiner Produkte auf einer Content-Website, news.example (also den Publisher), einbettet. Der Anzeigeninhalt befindet sich unter ad.shop.example.

Die Online-Shop-Besitzer möchten messen, wie viele Konversionen sie von Nutzern erhalten, die mit der Anzeige interagieren, die Produktseite auf ihrer Website ansehen und das Produkt in ihren Einkaufswagen legen.

Die beteiligten Schritte sind wie folgt:

1. Wenn ein Nutzer die Seite news.example besucht, kann eine Attributionsquelle für spezifische Nutzerinteraktionen mit der eingebetteten Anzeige registriert werden. Es gibt mehrere Möglichkeiten, wie ein Nutzer mit Anzeigen auf der Seite interagieren kann. Damit eine Interaktion mit einer Anzeige eine Attributionsquelle registriert, muss die Anzeige eine Anfrage mit einem Attribution-Reporting-Eligible Header senden, um anzuzeigen, dass die Antwort berechtigt ist, eine Attributionsquelle zu registrieren. Die Registrierung wird abgeschlossen, wenn die Antwort einen entsprechenden Attribution-Reporting-Register-Source Header enthält. Die Attributionsquelle kann zum Beispiel sein:
   • Ein Link. In diesem Fall ist die Interaktion das Klicken des Nutzers auf den Link (direkt über ein <a> Element oder durch einen Window.open() Aufruf). Die Quelle wird über die Antwort auf die Navigationsanfrage registriert.
   • Ein Bild wie ein Werbebanner oder ein 1x1 transparenter Tracking-Pixel. In diesem Fall ist die Interaktion das Besuchen der Seite durch den Nutzer. Die Quelle wird registriert, wenn das Bild geladen wird, d.h. wenn der Server auf die Bildanfrage antwortet.
   • Eine Fetch-Anfrage (d.h. ein fetch() oder XMLHttpRequest). In diesem Fall kann die Interaktion so spezifiziert werden, wie es für Ihre App sinnvoll ist — zum Beispiel könnte die Fetch-Anfrage durch ein click oder submit Ereignis ausgelöst werden. Die Quelle wird registriert, sobald die Antwort zurückkommt.
2. Wenn die Interaktion mit der Attributionsquelle erfolgt, werden die in dem Attribution-Reporting-Register-Source Header zurückgegebenen Quelldaten in einem privaten lokalen Cache gespeichert, der nur vom Browser zugänglich ist. Diese Daten beinhalten die auf der Seite und für den Werbetreibenden verfügbare kontextuelle und Erstanbieterdaten, den Ursprung des Ad-Tech-Unternehmens, das die Konversionsdaten sammelt, und ein oder mehrere Ziele (eTLD+1s), bei denen Sie erwarten, dass die Konversion von dieser Anzeige stattfindet (d.h. die Website(s) des Werbetreibenden, z.B. shop.example).
3. Wenn der Nutzer später shop.example besucht, kann diese Seite einen Attributionstrigger registrieren, wenn eine Interaktion anzeigt, dass eine Konversion stattgefunden hat (zum Beispiel, der Nutzer klickt auf den "In den Einkaufswagen"-Button auf shop.example). Der Browser wird dann eine Anfrage zusammen mit einem Attribution-Reporting-Eligible Header senden, um anzuzeigen, dass die Antwort berechtigt ist, einen Attributionstrigger zu registrieren, und die Registrierung wird abgeschlossen, wenn die Antwort einen entsprechenden Attribution-Reporting-Register-Trigger Header enthält. Der Attributionstrigger kann zum Beispiel sein:
   • Ein Bild wie ein Einkaufswagensymbol oder ein 1x1 transparenter Tracking-Pixel. In diesem Fall ist die Interaktion das Besuchen der Seite durch den Nutzer. Der Trigger wird registriert, wenn das Bild geladen wird, d.h. wenn der Server auf die Bildanfrage antwortet.
   • Eine Fetch-Anfrage (d.h. ein fetch() oder XMLHttpRequest). In diesem Fall kann die Interaktion so spezifiziert werden, wie es für Ihre App sinnvoll ist — zum Beispiel könnte die Fetch-Anfrage durch ein click oder submit Ereignis ausgelöst werden. Der Trigger wird registriert, sobald die Antwort zurückkommt.
4. Wenn die Trigger-Attribution abgeschlossen ist, versucht der Browser, die Daten aus dem Attribution-Reporting-Register-Trigger Header mit einem in dem privaten lokalen Cache gespeicherten Quelldateneintrag abzugleichen (siehe 2.). Siehe Registrierung von Attributionstriggern für Abgleichsmethodik und Anforderungen.
5. Wenn ein Abgleich erfolgt, sendet der Browser Berichtsdaten an einen Endpunkt auf einem Berichtserver, der typischerweise dem Ad-Tech-Anbieter gehört, wo sie sicher analysiert werden können. Anders als bei Cookies sind die Daten nur für die spezifische Website verfügbar, an die Sie sie senden — es werden keine Daten anderswo geteilt. Diese Berichte können entweder sein:
   • Ereignisbasierte Berichte: Berichte basierend auf einem Attributionsquellenereignis, bei dem detaillierte Quelldaten mit groben Triggerdaten verknüpft werden. Zum Beispiel kann ein Bericht wie "Click-ID 200498 auf ad.shop.example führte zu einem Kauf auf shop.example" aussehen, wobei "Click-ID 200498" die detaillierten Quelldaten sind und "Kauf" die groben Triggerdaten sind. Die detaillierten Quelldaten können Erstanbieter- oder kontextuelle Daten von der Quellseite kodieren, und die Triggerdaten können das Ereignis von der Triggerseite kodieren.
   • Zusammenfassende Berichte: Detailliertere Berichte, die Daten aus mehreren Konversionen auf sowohl der Quellen- als auch der Triggerseite kombinieren. Zum Beispiel "Kampagnen-ID 774653 auf news.example führte zu 654 Verkäufen von Widgets auf shop.example von Nutzern in Italien mit einem Gesamterlös von $9540." Das Erstellen eines zusammenfassenden Berichts erfordert die Verwendung eines Aggregationsdienstes (siehe zum Beispiel den Google Aggregationsdienst).

Für weitere Informationen zur Implementierung der für die oben genannten Schritte erforderlichen Funktionalität, siehe:

1. Registrierung von Attributionsquellen
2. Registrierung von Attributionstriggern
3. Erzeugung von Berichten

Schnittstellen

Die Attribution Reporting API definiert keine eigenen, spezifischen Schnittstellen.

Erweiterungen auf andere Schnittstellen

HTMLAnchorElement.attributionSrc, HTMLImageElement.attributionSrc, HTMLScriptElement.attributionSrc

Die attributionSrc Eigenschaft ermöglicht es Ihnen, das attributionsrc Attribut auf <a>, <img> und <script> Elementen programmatisch zu speichern und abzurufen. Es spiegelt den Wert dieses Attributs wider.

fetch() und der Request() Konstruktor, die attributionReporting Option

Wenn Sie eine Anfrage über fetch() generieren, zeigt dies an, dass Sie möchten, dass die Antwort eine Attributionsquelle oder einen Attributionstrigger registrieren kann.

XMLHttpRequest.setAttributionReporting()

Wenn Sie eine Anfrage über XMLHttpRequest generieren, zeigt dies an, dass Sie möchten, dass die Antwort eine Attributionsquelle oder einen Attributionstrigger registrieren kann.

Window.open(), das attributionsrc Schlüsselwort

Verursacht den Abschluss der Registrierung einer Attributionsquelle und löst aus, dass der Browser die zugehörigen Quelldaten speichert (wie im Attribution-Reporting-Register-Source Antwort-Header angegeben), wenn die open() Methode abgeschlossen wird. Beachten Sie, dass Window.open() Aufrufe nicht zur Registrierung von Attributionstriggern verwendet werden können.

HTML-Elemente

<a>, <img>, und <script> — das attributionsrc Attribut

Gibt an, dass Sie möchten, dass der Browser einen Attribution-Reporting-Eligible Header zusammen mit der zugehörigen Ressourcenanforderung sendet. Auf der Serverseite wird dieser Header verwendet, um das Senden eines Attribution-Reporting-Register-Source oder Attribution-Reporting-Register-Trigger Headers in der Antwort auszulösen. Bei der Registrierung einer Attributionsquelle ist dies erforderlich; bei der Registrierung eines Attributionstriggers ist es nur erforderlich, wenn Sie einen separaten Registrierungsserver angeben möchten, auf den das src Attribut zeigt. Beachten Sie, dass <a> Elemente nicht zur Registrierung von Attributionstriggern verwendet werden können.

HTTP-Header

Attribution-Reporting-Eligible

HTTP-Anfrage, die angibt, dass die entsprechende Antwort berechtigt ist, eine Attributionsquelle oder einen Attributionstrigger zu registrieren.

Attribution-Reporting-Register-Source

HTTP-Antwort, die ein Seitenmerkmal als Attributionsquelle registriert. Dies ist Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible Header enthielt.

Attribution-Reporting-Register-Trigger

HTTP-Antwort, die ein Seitenmerkmal als Attributionstrigger registriert. Dies ist Teil einer Antwort auf eine Anfrage, die einen Attribution-Reporting-Eligible Header enthielt.

Permissions-Policy attribution-reporting Direktive

Steuert, ob das aktuelle Dokument das Berichtswesen für Attributionen verwenden darf.

Registrierung und lokales Testen

Um die Attribution Reporting API auf Ihren Websites zu nutzen, müssen Sie sie im Registrierungsprozess für die Datenschutzoase angeben. Wenn Sie dies nicht tun, wird der API-Ablauf zum Zeitpunkt der Antwort blockiert, d.h. die Antwort-Header werden ignoriert und Quellen und Trigger werden nicht registriert.

Sie können Ihren Attribution Reporting API-Code jedoch weiterhin lokal ohne Registrierung testen. Um lokales Testen zu ermöglichen, aktivieren Sie das folgende Chrome-Entwickler-Flag:

chrome://flags/#privacy-sandbox-enrollment-overrides

Beispiele

Siehe Demo: Attribution Reporting API für eine Beispielimplementierung (siehe auch den Quellcode).

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Attribution Reporting Header Validation tool
• Attribution reporting auf privacysandbox.google.com (2023)
• Enable conversion measurement auf privacysandbox.google.com (2023)
• The Privacy Sandbox auf privacysandbox.google.com (2023)