Einführung in die Attributionsberichterstattung (Conversion-Messung)
Einführung und Schlüsselkonzepte zum Verständnis des Attribution Reporting APIs.
Published on • Updated on
Translated to: Español, Português, 한국어, 中文, Pусский, 日本語, Français
Developer Relations Engineer for security/privacy, Chrome and web
Dieses API hat den Status eines Vorschlags und wird im Laufe der Zeit erweitert werden. Dieser Blogbeitrag beschreibt den aktuellen Stand und wird im Zuge der Entwicklung des API aktualisiert.
Aktualisierungen:
- Anfang 2021: aggregierte Berichte und View-through-Messungen wurden dem Vorschlag hinzugefügt.
- Anfang 2021: Das API wurde in „Attribution Reporting API“ umbenannt.
- Dieser Beitrag konzentriert sich auf Werbeanwendungsfälle, aber das Attribution Reporting API kann auch Anwendungsmöglichkeiten außerhalb des Werbebereichs haben.
- Die Werbeanwendungsmöglichkeiten für dieses API konzentrieren sich auf die Verknüpfung von Anzeigenklicks oder -aufrufen mit Conversions (Conversion-Messung).
Einführung
Mit dem Attribution Reporting API lässt sich messen, wann ein Klick oder die Ansicht einer Werbeanzeige zu einer Conversion auf der Website eines Werbetreibenden führt, z. B. zu einem Verkauf oder einer Registrierung. Das API setzt dabei nicht auf Drittanbieter-Cookies oder Mechanismen, die verwendet werden können, um einzelne Benutzer über verschiedene Websites hin zu identifizieren.
Dieser Vorschlag wird in einem offenen Verfahren entwickelt. Der Vorschlag und die zugehörigen Diskussionen sind im WICG GitHub-Repository zu finden.
Dieses API ist Teil der Privacy Sandbox, einer Reihe von Vorschlägen mit dem Ziel Anwendungsmöglichkeiten für Drittanbieter zu schaffen, ohne Drittanbieter-Cookies oder andere websiteübergreifende Tracking-Mechanismen zu nutzen. Siehe Privacy-Sandbox-Vorschläge.
Warum wird dieses API benötigt?
Heutzutage basiert die Messung von auf Anzeigen zurückzuführender Conversions häufig auf Drittanbieter-Cookies. Browser schränken den Zugriff auf Drittanbieter-Cookies ein, da diese verwendet werden können, um Benutzer über Websites hinweg zu verfolgen und die Privatsphäre der Benutzer beeinträchtigen. Dieses API ermöglicht diese Messungen auf datenschutzwahrende Weise ohne Drittanbieter-Cookies.
Wer sollte über dieses API Bescheid wissen?
- Adtech-Plattformen wie nachfrageseitige Plattformen (DSP) oder Datenverwaltungsplattformen (DMP) können dieses API verwenden, um Funktionen zu unterstützen, die derzeit auf Drittanbieter-Cookies angewiesen sind.
- Werbetreibende und Betreiber, die auf benutzerdefinierten Code für Werbung oder Conversion-Messung angewiesen sind, können dieses API verwenden, um bestehende Techniken zu ersetzen.
- Werbetreibende und Betreiber, die sich für die Conversion-Messung auf Adtech-Plattformen verlassen, müssen das API zwar nicht direkt nutzen, haben aber möglicherweise Interesse daran es zu verstehen, wenn sie mit Adtech-Plattformen zusammenarbeiten, die diese API-Integration nutzen.
Debuggen Sie die API-Fehler mit den Chrome-Entwicklertools
Erhältlich ab Chrome 93. Fehler des Attribution Reporting APIs werden jetzt in den DevTools unter der Registerkarte „Issues“ gemeldet.
Beteiligen Sie sich
Ihre Teilnahme ist gefragt! Dieses API muss höchstwahrscheinlich Unterstützung für eine Vielzahl von Anwendungsmöglichkeiten zur Conversion-Messung und -optimierung bieten. Es ist entscheidend, dieses Ökosystem mit Ideen zu bereichern, um sicherzustellen, dass Lösungen zur Unterstützung aller dieser Anwendungsfälle offen diskutiert werden.
Beteiligen Sie sich an der Diskussion und testen Sie das API. Beides zu tun wäre optimal, aber Sie können sich gerne auch ohne eigener Erfahrung mit dem API an der Diskussion beteiligen.
Beteiligen Sie sich an der Diskussion
- Nehmen Sie an den zweiwöchentlichen Sitzungen (jede zweite Woche) teil. In diesen Telefonkonferenzen diskutieren die Teilnehmer Vorschläge zum API-Design und wie das API verschiedene Anwendungsfälle für Messungen unterstützen könnte. Sie können jederzeit Themen zur Tagesordnung der nächsten Sitzung hinzufügen. Jeder ist herzlich eingeladen, an diesen Diskussionen teilzunehmen. Treten Sie einfach der WICG bei.
- Eröffnen Sie eine Issue, um Fragen zu stellen, Funktionen vorzuschlagen oder Anwendungsmöglichkeiten zu diskutieren. Wenn Sie sich nicht sicher sind, wie Sie Ihr Problem formulieren sollen, sehen Sie sich Beispiele wie diese Issue und diese Issue an. Sie können sich auch an der Diskussion zu bestehenden Problemen beteiligen.
Probieren Sie das API aus
Wenn Sie mit dem API in Chrome experimentieren, haben Sie Zugriff auf alle derzeit implementierten Funktionen. Nicht alle im Repository und in der Sitzung besprochenen Funktionen sind in der Chrome-Origin-Trial implementiert. Informationen über den aktuellen Status einer Funktion finden Sie unter Status. Die für Experimente verfügbaren Funktionen sind eine Teilmenge dessen, was letztendlich von dem API unterstützt werden wird. Sie sind ständigen Änderungen unterworfen, während das API in diesem öffentlichen Verfahren entwickelt wird und Feedback aus dem Software-Ökosystem gesammelt wird.
Experimentieren Sie lokal oder mit einer Demo
- Um das API lokal in Ihrem Browser zu aktivieren, aktivieren Sie das Flag
#enable-experimental-web-platform-features. Ein Chrome-Flag ist ein Schalter, der Ihrem Browser mitteilt, bestimmte experimentelle Funktionen zu aktivieren. Fügen Sie zur Aktivierung dieses Flagschrome://flags/#enable-experimental-web-platform-featuresin die Suchleiste von Chrome ein und klicken Sie auf Aktivieren. - Führen Sie die Demo lokal aus (oder probieren Sie die Live-Demo aus).
- Erstellen Sie einen Fork des Democodes und passen Sie diesen an oder erstellen Sie von Grund auf Ihre eigene Demo.
Experimentieren Sie auf einer aufgesetzten Website mit Endbenutzern
Aktivieren Sie das API für Endbenutzer, indem Sie sich für eine Origin-Trial registrieren, falls verfügbar. Eine Origin-Trial gibt Ihnen Zugriff auf eine experimentelle Funktion, um diese für eine begrenzte Zeit ausprobieren zu können. Beachten Sie, dass Drittanbieter-Origin-Trials es Dritten wie Werbeanbietern und Werbeanalysediensten ermöglichen, ein API über mehrere Websites zu testen. Um die derzeit verfügbaren Origin-Trials für dieses API anzuzeigen, navigieren Sie zu Status. Um über zukünftige Origin-Trials informiert zu werden, tragen Sie sich in die Attributionsberichterstellung-Mailingliste für Entwickler ein.
Integrieren Sie das API in Ihre Websites und Systeme.
Wenn Sie Fragen zur Implementierung haben, tragen Sie sich in die Attributionsberichterstattung-Mailingliste für Entwickler ein und fragen Sie nach.
Wenn Sie allgemeine technische Fragen bezüglich Ihres Anwendungsfalls haben, sollten Sie eine Issue im Privacy-Sandbox-Entwicklersupport-Repository öffnen.
Demo
Es stehen Ihnen einige Demos zum Ausprobieren zur Verfügung.
Berichte auf Ereignisebene (nur Klicks betreffend):
- Live-Demo.
- Quellcode für diese Demo, den Sie nach Bedarf forken und anpassen können.
Anwendungsfälle und Funktionen
Dieses API befindet sich in stetiger Weiterentwicklung und wird sich im Laufe der Zeit je nach Feedback und Einflüssen des Software-Ökosystems weiterentwickeln.
Alle von diesem API unterstützten Funktionen sind Vorschläge. Alle Vorschläge werden offen diskutiert und es kann Feedback für sie abgegeben werden, auch für diejenigen, für die schon eine erste Browserimplementierung vollzogen wurde.
Dieses API wird in einem offenen Verfahren entwickelt. Ziehe in Erwägung, dich an der Diskussion zu beteiligen.
Dieses API ermöglicht es Websites, Conversions in den folgenden Fällen zu messen:
- Bei Anzeigenklicks und Anzeigenansichten.
- Für Werbeanzeigen in einem **Drittanbieter-**iframe, z. B. bei Anzeigen eines Adtech-Drittanbieters auf einer Betreiberwebsite.
- Für Anzeigen in einem Erstanbieter-Kontext, wie zum Beispiel Anzeigen in einem sozialen Netzwerk, auf der Ergebnisseite einer Suchmaschine oder aber von einem Betreiber selbst geschalteten Anzeigen.
Ein flexibles Attributionsmodell wird unterstützt. Siehe Details unter Status.
Dieses API ermöglicht den Zugang zu unterschiedlichen Erkenntnissen über zwei Typen von Berichten, die an einen Werbetreibenden oder einen Adtech-Drittanbieter gesendet werden können. Diese beiden Berichtstypen können gleichzeitig genutzt werden, da sie sich ergänzen.
Berichte auf Ereignisebene verknüpfen einen Anzeigenklick oder eine Anzeigenansicht mit groben Conversion-Daten.
news.example (angehängt an die Benutzer-ID „Bob_Doe“ auf news.example) hat zu einem Kauf auf shop.example geführt.Berichte auf Ereignisebene eignen sich für:
- Anwendungsfälle von Optimierung. Berichte auf Ereignisebene helfen bei der Beantwortung von Fragen wie „Wie kann ich meine Return on Investment verbessern?“. Sie können insbesondere zur Optimierung der Anzeigenplatzierung genutzt werden, da eindeutige IDs auf Anzeigenseite in den Berichten zur Verfügung gestellt werden können. Berichte auf Ereignisebene können Trainingsdaten für Machine-Learning-Modelle bereitstellen.
- Anwendungsfälle grober Berichterstattung, bei denen nur sehr wenige Informationen über die Conversion benötigt werden. Die aktuelle Begrenzung für Klicks liegt bei Conversion-Daten mit 3 Bits – das heißt, einer Conversion kann eine von acht Kategorien zugeordnet werden. Für Anzeigenansichten liegt die Begrenzung bei 1 Bit. Die Kodierung detaillierter Conversion-Daten, wie z. B. eines bestimmten Kaufpreises oder einer Conversion-Zeit, wird daher in Berichten auf Ereignisebene nicht unterstützt.
- Anwendungsfälle von Betrugserkennung. Die Daten in einigen Berichten können für die Erkennung und Analyse von Werbeanzeigenbetrug hilfreich sein, da Sie Muster erkennen, mit denen Spam oder ungültige Aktivitäten identifiziert werden können.
Aggregierte Berichte hingegen bieten detailliertere Conversion-Daten und mehr Flexibilität beim Zusammenführen von Klick-/Ansichtsdaten und Conversion-Daten.
news.example hat zu 518 Conversions auf shoes.example und zu Gesamtausgaben von 38174 $ geführt. Die Hälfte der Conversions stammte von Nutzern in NYC, USA.Aggregierte Berichte eignen sich am besten für die Berichterstattung. Sie helfen bei der Beantwortung von Fragen wie „Wie hoch ist mein Return on Investment?“.
Die Nutzung aggregierter Berichte für Anwendungsfälle von Optimierung – beispielsweise zum Optimieren eines Einkaufswerts, die von Berichten auf Ereignisebene nicht unterstützt wird, weil die Conversion-Daten zu grob sind – ist ein Bereich aktiver Forschung. Siehe Offene Fragen.
Warum werden zwei Berichttypen benötigt?
Berichte auf Ereignisebene bieten nur grobe Conversion-Daten, um die Privatsphäre der Benutzer zu wahren.
Diese groben Daten reichen jedoch möglicherweise nicht aus, um die Effektivität von Kampagnen zu messen. Marketingspezialisten müssen möglicherweise weitere Details zu Conversions in Erfahrung bringen, z. B. den Einkaufswert, die vom Werbetreibenden aggregierten demografischen Daten konvertierter Benutzer, Kategorien gekaufter Produkte, Informationen zum Kundenstatus (Erstkunde oder wiederkehrender Kunde), Einkaufswageninhalte etc.
Aus diesem Grund wurden aggregierte Berichte entwickelt.
Andere in diesem API vorgeschlagene Funktionen sind App-to-Web-Attribution (Ansehen oder Klicken einer Anzeige in einer App und konvertieren im Web) und geräteübergreifende Attribution (Ansehen oder Klicken einer Anzeige auf einem Mobilgerät und konvertieren auf dem Desktop-Computer).
In einer Zukunft ohne Drittanbieter-Cookies würde dieses API mit anderen datenschutzwahrenden Werbe-APIs kombiniert werden, um Ende-zu-Ende-Anwendungsfälle abdecken zu können:
Status
🕙 Letzte Aktualisierung: August 2021
Status:
🤿 Wird ergründet: Diese Idee befindet sich in einer frühen Diskussionsphase.🥚 Vorschlag: Ein erster Entwurf ist fertig und wird in einem öffentlichen Verfahren weiterentwickelt.🏗️ In der Entwicklung (BROWSER_NAME): Die Funktion wird in BROWSER_NAME implementiert.🧪 Experiment (BROWSER_NAME): Ein Experiment ist in BROWSER_NAME verfügbar. In Chrome wird ein Experiment als Origin-Trial bezeichnet.🚀 Stable (BROWSER_NAME): Die Funktion wird standardmäßig in BROWSER_NAME ausgeliefert.
Aktuelle Origin-Trial (Chrome-Experiment 🧪)
Es werden mehrere Origin-Trials (Experimente) durchgeführt. Jede Entwicklungsrunde wird verwendet, um das API basierend auf dem Feedback aus dem Software-Ökosystem zu verbessern und anzupassen.
| Vorschlag | Status |
|---|---|
| Berichte auf Ereignisebene für Klicks Erläuterung | 🧪 Experiment (Chrome) |
| Berichte auf Ereignisebene für Klicks Erläuterung | 🏗️ In Entwicklung (Chrome) |
| Aggregierte Berichte für Klicks und Ansichten Erläuterungen | 🥚 Vorschlag |
| Conversion Journey: geräteübergreifend Erläuterung | 🥚 Vorschlag |
| Conversion Journey: App-to-Web Erläuterung | 🥚 Vorschlag |
| Attributionsmodell: letzter Klick Erläuterung | 🧪 Experiment (Chrome) |
| Attributionsmodell: prioritätsbasiert Erläuterung | 🏗️ In Entwicklung (Chrome) |
| Attributionsmodell: flexibel | 🤿 Wird ergründet |
Über Attributionsmodelle
Über Attributionsmodelle
Beim prioritätsbasierten Modell kann der Browser jeder Attributionsquelle eine Priorität zuordnen. Dies kann genutzt werden, um:
- Zu entscheiden, ob ein Klick oder eine Ansicht die wahrscheinlichste Ursache für die Conversion war (ein Klick wird normalerweise als klareres Signal des Nutzerinteresses angesehen).
- Ein First-Touch-Attributionsmodell festzulegen, indem Sie
attributionsourcepriorityrelativ zur Zeit einstellen. - Legen Sie ein (probabilistisches) lineares Attributionsmodell fest, indem Sie die Priorität einheitlich als zufällig einstellen.
In Zukunft könnten auch andere Attributionsmodelle unterstützt werden. In aggregierten Berichten würde das Worklet-basierte Schema möglicherweise flexiblere Attributionsoptionen ermöglichen (einschließlich der Angabe zur teilweisen Anerkennung mehrerer vorheriger Attributionsquellen).
Browser-Unterstützung
- Firefox und Edge haben keine Signale geteilt.
- Von Safari/Webkit ist es negativ und ein anderes API zur Messung von Anzeigenconversions mit der Bezeichnung Private Click Measurement wurde vorgeschlagen.
Obwohl sich die beiden APIs unterscheiden, arbeiten Chrome und WebKit in einem offen Verfahren zusammen, um die Entwicklungserfahrung zu vereinfachen, indem sie beispielsweise die Attributnamen und die JSON-Struktur von Berichten aneinander anpassen.
Unterschiede zwischen dem von Chrome vorgeschlagenen API und dem von WebKit vorgeschlagenen API
