Der Vorschlag für die Attribution Reporting API wurde aufgrund des Feedbacks der Community in mehreren Punkten geändert, von Änderungen am API-Mechanismus bis hin zu neuen Funktionen.
Änderungsprotokoll
- 7. Februar 2022: Abschnitt zur Weiterleitung über einen Header-Trigger hinzugefügt.
- 27. Januar 2022: Erstveröffentlichung des Artikels
An wen richtet sich dieser Beitrag?
Dieser Beitrag richtet sich an folgende Nutzer:
- Wenn Sie die API bereits kennen, z. B. wenn Sie die Diskussionen im WICG-Repository beobachtet oder daran teilgenommen haben und die Änderungen verstehen möchten, die im Januar 2022 am Vorschlag vorgenommen wurden.
- Wenn Sie die Attribution Reporting API in einer Demo oder in einem Test in der Produktion verwenden.
Wenn Sie noch keine Erfahrung mit dieser API haben und/oder sie noch nicht ausprobiert haben, gehen Sie direkt zur Einführung in die API.
Migration bevorsteht
Sobald diese Änderungen in Chrome implementiert sind: Wenn Sie Berichte auf Ereignisebene aus der Attribution Reporting API in einer Demo oder in einem Test in der Produktion (Ursprungstest) verwenden, müssen Sie Ihren Code bearbeiten, damit die API weiterhin funktioniert. Sie können auch die neuen Funktionen nutzen.
In diesem Artikel werden auch Änderungen an aggregierten Berichten aufgeführt. Wenn diese Änderungen implementiert werden, sind jedoch keine Maßnahmen oder Migrationen erforderlich, da es zum Zeitpunkt der Erstellung dieses Artikels noch keine Browserimplementierung für aggregierbare Berichte gibt.
Namensänderungen
Zusammenfassende und aggregierbare Berichte
Berichte, die bisher als zusammengefasste Berichte bezeichnet wurden, werden jetzt als Zusammenfassungsberichte bezeichnet.
Zusammenfassungsberichte sind die Endausgabe der Aggregation mehrerer aggregierbarer Berichte, die früher als Beiträge oder Histogrammbeiträge bezeichnet wurden.
Änderungen am API-Mechanismus
Header-basierte Quellenregistrierung (Berichte auf Ereignisebene)
Was ändert sich und warum?
Wenn sich der Nutzer eine Anzeige ansieht oder auf sie klickt, erfasst der Browser – lokal auf dem Gerät des Nutzers – dieses Ereignis zusammen mit Parametern, die speziell für Attributionsberichte bestimmt sind (z. B. attributionsourceeventid, attributiondestination, attributionexpiry und andere Parameter). Die Werte dieser Parameter werden von der Anzeigentechnologie festgelegt.
Die Art und Weise, wie diese Parameter festgelegt werden, ändert sich.
Im vorherigen Vorschlag mussten die Parameter clientseitig eingefügt werden: entweder in den Anker-Tags als HTML-Attribute oder als Argumente eines JS-basierten Aufrufs. Die Parameter mussten zum Zeitpunkt des Klicks oder der Wiedergabe bekannt sein.
Im neuen Vorschlag wird der Wert dieser Parameter stattdessen auf dem AdTech-Server definiert.
Das hat eine Reihe von Vorteilen, insbesondere in Bezug auf die Sicherheit: Der Headermechanismus gibt dem Ursprung der Berichte (in der Regel eine AdTech-Lösung) die direkte Kontrolle darüber, ob eine Attributionsquelle in seinem Umfang registriert ist. Dadurch werden Betrugsrisiken teilweise gemindert, da ein echter Browser mit dieser Änderung niemals eine Quelle ohne die Einwilligung des Berichtsausgangs registriert.
Wie funktioniert die Quellenregistrierung?
- Für eine bestimmte Anzeige muss die AdTech-Technologie jetzt ein bestimmtes clientseitiges Attribut definieren
attributionsrc. Der Wert dieses Attributs ist eine URL, an die der Browser eine Anfrage sendet. Diese Anfrage enthält einen neuen HTTP-HeaderAttribution-Reporting-Source-Info, dessen Wertnavigationoderevent,angibt, ob es sich bei der Quelle um einen Klick oder eine Aufruf handelt. - Nach Erhalt dieser Anfrage sollte der Klick-/Aufruf-Tracking-Server mit einem HTTP-Header,
Attribution-Reporting-Register-Source, antworten, der die gewünschten Attributionsparameter enthält. Die Quelle, die diesen Header zurückgibt, ist jetzt die Berichtsquelle (früher als
attributionreporttodefiniert).HTTP-Antwortheader
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Weitere Informationen finden Sie in der technischen Erläuterung.
Attributionsquellen registrieren
An der öffentlichen Diskussion teilnehmen
Headerbasierter Attributionstrigger (Berichte auf Ereignisebene)
Was ändert sich und warum?
Ähnlich wie bei der Klick- oder Aufrufregistrierung wird mit dem neuen Vorschlag der Attributionstrigger geändert, wenn eine AdTech-Technologie den Browser anweist, eine Conversion zu erfassen. Stattdessen wird ein headerbasierter Ansatz verwendet.
Dieser Mechanismus ist mit der headerbasierten Quellenregistrierung abgestimmt und konventioneller als der zuvor verwendete Weiterleitungsmechanismus.
Außerdem ist im neuen Vorschlag das Attribut attributionsrc auf der Conversion-Seite erforderlich.
Der Grund dafür sind Berechtigungen: Im vorherigen Vorschlag hatte die Website, auf der der Trigger ausgelöst wird (in der Regel die Website eines Werbetreibenden), zwar eine allgemeine Kontrolle über die Funktion über einen Permissions-Policy-Header, aber keine detaillierte Kontrolle auf Elementebene, ob ein Element eine Anfrage an eine Partei senden kann, die letztendlich eine Attribution auslöst. attributionsrc ändert das: Mit dieser obligatorischen Markierung können Werbetreibende überwachen und somit steuern, welche Elemente eine Attribution auslösen können.
Auf der Quellseite (in der Regel eine Publisher-Website) gibt es eine seitenweite Steuerung über Permissions-Policy und eine elementweite Steuerung über attributionsrc.
Wie funktioniert ein Attributionstrigger?
Wenn eine AdTech-Plattform eine Pixelanfrage empfängt und entscheidet, dass sie als Conversion kategorisiert werden soll, sollte sie mit einem neuen HTTP
-Attribution-Reporting-Register-Event-Trigger-Header antworten.
Mit dem Wert dieses Headers wird angegeben, wie das Triggerereignis als JSON-Objekt behandelt werden soll. Das sind dieselben Informationen, die im vorherigen Vorschlag als Abfrageparameter definiert wurden.
HTTP-Antwortheader Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Weiterleitung (optional)
Optional kann der AdTech-Server die Antwort, die Attribution-Reporting-Register-Event-Trigger enthält, in eine Weiterleitungsantwort umwandeln.
So können Drittanbieter das Conversion-Ereignis beobachten und den Browser anweisen, es zuzuordnen.
Die Weiterleitung ist optional. Sie ist nicht erforderlich, wenn sowohl ein AdTech-Unternehmen als auch ein Drittanbieter Pixel auf der Seite haben.
Weitere Informationen finden Sie unter Berichte von Drittanbietern.
Weitere Informationen finden Sie in der technischen Erläuterung.
An der öffentlichen Diskussion teilnehmen
Kein Worklet (aggregierbare Berichte)
Was ändert sich und warum?
Beim vorherigen Vorschlag für aggregierbare Berichte war JavaScript-Zugriff erforderlich, um ein Worklet aufzurufen, einen JavaScript-basierten Mechanismus, mit dem diese Berichte generiert wurden.
Im neuen Vorschlag ist kein Worklet erforderlich. Stattdessen würde eine AdTech-Plattform deklarativ – über HTTP-Header – die Regeln definieren, die der Browser zum Generieren aggregierbarer Berichte verwenden soll.
Der neue Vorschlag bietet mehrere Vorteile:
- Browserimplementierung:Das neue Design ist im Gegensatz zum Worklet-Design wesentlich einfacher, da keine neue Ausführungsumgebung in Browsern erforderlich ist.
- Nutzerfreundlichkeit für Entwickler:Das neue Design basiert auf Headern, die von Entwicklern häufig verwendet und weithin bekannt sind – im Gegensatz zu Worklets. Außerdem entspricht sie weitgehend der API-Oberfläche für die Registrierung von Quellen, was die API leichter zu erlernen und zu verwenden macht.
- Akzeptanz: Mit dem neuen Design können mehr bestehende Analysesysteme aggregierbare Berichte verwenden. Viele Analysetools sind nur HTTP-basiert: Sie nutzen Bildanfragen (Pixelanfragen), für die kein JavaScript-Zugriff erforderlich ist. Da für den Worklet-Ansatz jedoch JavaScript-Zugriff erforderlich war, war die Migration von einigen bestehenden Analysesystemen möglicherweise schwierig.
- Robustheit:Das neue Design trägt dazu bei, Datenverluste zu vermeiden, da es sich leichter in
keepalive-Semantik einbinden lässt. Das ist beispielsweise der Fall, wenn ein Klick oder eine Aufrufereignis registriert wird, während ein Nutzer eine Seite verlässt.
Wie funktioniert der Mechanismus ohne Worklet?
Dieser deklarative Mechanismus basiert auf HTTP-Headern, genau wie die Quellenregistrierung auf Ereignisebene und der Attributionstrigger-Header. Weitere Informationen dazu finden Sie in den nächsten Abschnitten.
An der öffentlichen Diskussion teilnehmen
Headerbasierte Quellenregistrierung (aggregierbare Berichte)
Es wird ein neuer Mechanismus vorgeschlagen, um eine Quelle für einen aggregierbaren Bericht zu registrieren. Dieser Mechanismus entspricht der Registrierung von Quellen auf Ereignisebene.
Nur der Headername unterscheidet sich: Attribution-Reporting-Register-Aggregatable-Source.
Weitere Informationen finden Sie in der technischen Erläuterung.
Registrierung von Attributionsquellen
Header-basierter Attributionstrigger (aggregierbare Berichte)
Es wird ein neuer Mechanismus vorgeschlagen, um eine Quelle für einen aggregierbaren Bericht zu registrieren. Dieser Mechanismus entspricht dem Attributionstrigger auf Ereignisebene.
Nur der Headername unterscheidet sich: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Weitere Informationen finden Sie in der technischen Erläuterung.
Registrierung von Attributionstriggern
Neue Funktionen
Berichte von Drittanbietern (Berichte auf Ereignisebene und aggregierbare Berichte)
Was ändert sich und warum?
Zwei Aspekte des neuen Vorschlags tragen dazu bei, die Anwendungsfälle für Drittanbieterberichte besser zu unterstützen:
- Optional können Anbieter von Anzeigentechnologien Netzwerkanfragen an andere AdTech-Server weiterleiten. Dadurch können diese anderen AdTech-Anbieter ihre eigene Quelle und Trigger registrieren. Dies ist eine gängige Methode, wie Drittanbieter heute konfiguriert werden. Dadurch lässt sich die API leichter einbinden, unter anderem in bestehende Berichtssysteme von Drittanbietern.
- Für die Herkunftsquellen von Berichten (in der Regel AdTech-Anbieter) gelten die meisten Datenschutzeinschränkungen nicht mehr. So können mehrere AdTech-Anbieter mit denselben Publishern oder Werbetreibenden zusammenarbeiten.
Wie funktioniert die Meldung von Drittanbietern?
Im neuen Vorschlag basieren die reaktionsbasierte Registrierung und der Trigger der Quelle auf HTTP-Headern. Eine AdTech-Plattform kann für diese Anfragen HTTP-Weiterleitungen verwenden.
Wenn eine Klick-/Aufrufanfrage auf einer Publisher-Website (Quellregistrierung) an mehrere Parteien weitergeleitet wird, kann jede dieser Parteien diesen Aufruf oder Klick (Querereignis) registrieren.
Ähnlich kann eine AdTech-Plattform eine bestimmte Attributionsanfrage von der Website eines Werbetreibenden weiterleiten, sodass mehrere andere Parteien eine Conversion (Attributionstrigger) erfassen können.
Jede Partei kann auf ihre eigenen Berichte zugreifen und sie mit separaten Daten konfigurieren.
Mehrere Trigger ohne Weiterleitungen registrieren
Es ist auch möglich, mehrere Attributionstrigger ohne Weiterleitungen zu registrieren, indem Sie mehrere Pixelelemente auf Conversion-Seite hinzufügen (eines pro Trigger).
An der öffentlichen Diskussion teilnehmen
Messung von View-through-Conversions (Berichte auf Ereignisebene und aggregierbare Berichte)
Was ändert sich und warum?
Im neuen Vorschlag werden die Analyse der Aufrufe nach dem Betrachten von Anzeigen und die Analyse der Klicks auf Anzeigen einheitlich durchgeführt:
registerattributionsrc, das ansichtenspezifische Attribut, das den Browser anweist, Aufrufe zusammen mit Klicks zu erfassen, ist nicht mehr Teil des Vorschlags.- Die Datenschutzmechanismen sind jetzt für Klicks und Aufrufe einheitlich. Weitere Informationen finden Sie unter Rauschen und Transparenz.
Diese Änderung soll mit dem neuen headerbasierten Registrierungsmechanismus übereinstimmen. Außerdem wird die Arbeit der Entwickler erleichtert, wenn sie sowohl Klick- als auch Conversions nach dem Impressions-Tracking unterstützen möchten.
Wie funktioniert die Analyse von Conversions nach Aufruf?
Sowohl die Analyse von Conversions nach Aufruf als auch die Analyse von Conversions nach Klick basieren auf der headerbasierten Registrierung.
Weitere Informationen finden Sie in der technischen Erläuterung.
Berichte auf Ereignisebene (sowohl für Klicks als auch für Aufrufe)
An der öffentlichen Diskussion teilnehmen
Fehlerbehebung / Leistungsanalyse (Berichte auf Ereignisebene und aggregierbare Berichte)
Was ändert sich und warum?
Dem Vorschlag wurde ein Mechanismus zur Fehlerbehebung hinzugefügt, mit dem Entwickler Fehler erkennen und die Leistung von Attributionsberichten mit bestehenden cookiebasierten Analyselösungen vergleichen können.
Wie funktioniert die Fehlerbehebung?
Sowohl bei der Registrierung von Quellen als auch von Triggern wird ein neuer Parameter debug_key akzeptiert, ein 64-Bit-unsignierter Ganzzahlwert (d. h. eine große Zahl).
Wenn ein Bericht mit Debug-Schlüsseln für Quelle und Trigger erstellt wird und zum Zeitpunkt der Registrierung der Quelle und des Triggers ein Samesite=None ar_debug=1-Cookie im Cookie-Jar der Berichtsquelle vorhanden ist, wird ein Debug-Bericht (JSON) an einen .well-known/attribution-reporting/debug-Endpunkt gesendet:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Diese beiden neuen Parameter sind auch in Berichten auf Ereignisebene und aggregierten Berichten enthalten, damit sie dem richtigen Debug-Bericht zugeordnet werden können.
Weitere Informationen finden Sie in der technischen Erläuterung.
Optional: erweiterte Debugging-Berichte
An der öffentlichen Diskussion teilnehmen
Filterfunktionen (Berichte auf Ereignisebene und aggregierbare Berichte)
Was ändert sich und warum?
Da sie wichtige Anwendungsfälle im heutigen Werbesystem unterstützen, werden einige Anwendungsfälle jetzt sowohl in Berichten auf Ereignisebene als auch in Berichten mit zusammengefassten Daten unterstützt:
- Conversion-Filter:Sie können eine Conversion anhand von quellenseitigen Informationen filtern. Sie können beispielsweise unterschiedliche Triggerdaten (Conversion-Daten) für Anzeigenklicks und -aufrufe auswählen.
- Attributionsdiskrepanz:Mit dieser speziellen Art des Conversion-Filters können Sie nach Conversions filtern, die falsch zugeordnet wurden. Sie können beispielsweise Conversions herausfiltern, die aufgrund des Zielbereichs „ETLD+1“ in der API dem falschen Anzeigenklick oder der falschen Anzeigenaufruf zugeordnet werden.
Wie funktionieren die Filterfunktionen? (für Berichte auf Ereignisebene)
Mit einem optionalen source_data-Feld im JSON-Objekt auf der Quellseite können Elemente definiert werden, die anschließend vom Browser zur Anwendung der Filterlogik verwendet werden.
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
Bei der Triggerregistrierung wird jetzt ein optionaler Header Attribution-Reporting-Filters akzeptiert.
HTTP-Antwortheader Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Alternativ kann der Attribution-Reporting-Register-Event-Trigger-Header um ein filters-Feld erweitert werden, um selektiv zu filtern und trigger_data basierend auf source_data festzulegen.
Wenn Schlüssel in den JSON-Filtern mit Schlüsseln in source_data übereinstimmen, wird der Trigger
vollständig ignoriert, wenn die Schnittmenge leer ist.
Weitere Informationen finden Sie in der technischen Erläuterung.
An der öffentlichen Diskussion teilnehmen
Änderungen beim Datenschutz
Rauschen und Transparenz (Berichte auf Ereignisebene und aggregierbare Berichte)
Was ändert sich und warum?
Im neuen Vorschlag wurde einer der Datenschutzmechanismen für Berichte verbessert: Berichte unterliegen der Zufallsmix-Methode.
Das bedeutet, dass einige echte Conversions korrekt erfasst werden. In einem bestimmten Prozentsatz der Fälle werden einige echte Conversions unterdrückt oder gefälschte Conversions hinzugefügt.
Diese neue Technik bietet einige Vorteile:
- Der Datenschutzmechanismus für Klicks und Aufrufe wird vereinheitlicht.
- Er ist einfacher zu verstehen als ein Mechanismus, bei dem Triggerdaten (Conversion-Daten) und Rauschen im Trigger-Quell-Link getrennt werden.
- Es wird ein Datenschutzrahmen eingerichtet, der mit den richtigen Rauscheinstellungen dafür sorgen kann, dass keine Partei mithilfe der API mit Sicherheit feststellen kann, ob ein einzelner Nutzer eine bestimmte Anzeige aufgerufen hat oder nicht.
Dieser neue Mechanismus ersetzt den vorherigen Mechanismus, bei dem Triggerdaten (Conversion-Daten) in 5% der Fälle durch einen zufälligen Wert ersetzt wurden.
Außerdem wurde dem Berichtstext (Feld randomized_trigger_rate) der Wert für die Wahrscheinlichkeit der zufälligen Antwort hinzugefügt. In diesem Feld wird die Wahrscheinlichkeit (0 bis 1) angegeben, dass eine Quelle einer zufälligen Antwort unterliegt.
Das hat zwei Hauptvorteile:
- Das zugrunde liegende Browserverhalten wird für die Parteien, die die Berichte erhalten (in der Regel AdTech-Unternehmen), transparent.
- Das ist hilfreich für eine Zukunft, in der die API browserübergreifend unterstützt wird: Je nach Datenschutzzielen können verschiedene Browser unterschiedliche Rauschstufen anwenden. Die Parteien, die den Bericht verarbeiten, müssen dies sehen können.
Wie funktioniert Rauschen?
Beim neuen Vorschlag entscheidet der Browser zum Zeitpunkt der Registrierung einer Quelle (d.h. wenn ein Anzeigenklick oder -aufruf erfasst wird), ob er Conversions wahrheitsgemäß zuordnet und Berichte für diesen Anzeigenklick/-aufruf sendet oder stattdessen eine gefälschte Ausgabe generiert.
Die gefälschte Ausgabe kann folgendermaßen aussehen:
- Kein Bericht – unabhängig davon, ob der Nutzer eine Conversion ausführt;
- Eine oder mehrere gefälschte Meldungen – unabhängig davon, ob der Nutzer eine Conversion auslöst.
In gefälschten Berichten sind die Triggerdaten (Conversion-Daten) zufällig: ein zufälliger 3‑Bit-Wert für Klicks (eine beliebige Zahl zwischen 0 und 7) und ein zufälliger 1‑Bit-Wert für Aufrufe (0 oder 1).
Wie echte Berichte werden auch gefälschte Berichte nicht sofort nach der Conversion des Nutzers gesendet. Sie werden am Ende eines zufälligen Berichtszeitraums gesendet.
Für Klicks gibt es drei Berichtszeitraume: 2 Tage, 7 Tage oder 30 Tage nach dem Klick. Jeder gefälschte Bericht wird einem der Berichtszeitraume zufällig zugewiesen.
Wie bereits im vorherigen Vorschlag erwähnt, erfolgt die Reihenfolge der Berichte innerhalb eines Zeitraums nach dem Zufallsprinzip.
Weitere Informationen finden Sie in der technischen Erläuterung.
Beispiele für fehlerhafte gefälschte Conversions
An der öffentlichen Diskussion teilnehmen
Einschränkungen bei Berichten (Berichte auf Ereignisebene und aggregierbare Berichte)
Einschränkungen für die Berichtsquellen
Was ändert sich und warum?
Der neue Vorschlag beschränkt ausdrücklich, wie viele Parteien Ereignisse zwischen zwei Websites messen können.
- Die maximale Anzahl eindeutiger Berichtsquellen (in der Regel AdTech-Anbieter), die pro {publisher, advertiser} registriert werden können, soll auf 100 pro 30 Tage begrenzt werden. Dieser Zähler wird bei jedem Anzeigenklick oder -aufruf (Querereignis) erhöht, auch bei nicht zugeordneten.
- Die maximale Anzahl eindeutiger Berichtsquellen (in der Regel AdTech-Anbieter), die pro {publisher, advertiser} Berichte senden können, soll auf 10 pro 30 Tage begrenzt werden. Dieser Zähler wird für jede zugeordnete Conversion erhöht.
Diese Limits sollen hoch genug sein, um die Conversion-Analyse für alle Nutzer nicht zu beeinträchtigen, aber niedrig genug, um einige Formen von API-Missbrauch zu minimieren.
Wartezeit zwischen Berichten / Melderate
Was ändert sich und warum?
Die Wartezeit für die Berichterstellung ist ein Datenschutzmechanismus, mit dem die Gesamtmenge der Informationen, die in einem bestimmten Zeitraum über diese API für einen Nutzer gesendet werden, gedrosselt wird.
Im neuen Vorschlag können 100 Berichte pro {source site, destination, reporting origin} (in der Regel {publisher, advertiser, adtech}) über einen Zeitraum von 30 Tagen geplant werden.
Über dieses Limit hinaus plant der Browser keine Berichte mehr, die mit dieser {source site, destination, reporting origin} (in der Regel {publisher, advertiser, adtech}) übereinstimmen, bis die Anzahl der Berichte für die letzten 30 Tage für diese {source site, destination, reporting origin} unter 100 fällt.
Weitere Informationen finden Sie in der technischen Erläuterung.
Abklingzeit für Meldungen / Ratenlimits
Zielbegrenzung (nur Berichte auf Ereignisebene)
Was ändert sich und warum?
Die Begrenzung der Zielanzahl wird so geändert, dass die Berichtsquelle (in der Regel eine Anzeigentechnologie) in den Geltungsbereich einbezogen wird: Pro {publisher, adtech} sind 100 eindeutige ausstehende Ziele (in der Regel Werbetreibendenwebsites oder Websites, auf denen voraussichtlich Conversions stattfinden) zulässig.
Dies ist ein Datenschutzmechanismus, der die Rekonstruktion des Browserverlaufs einschränkt.
Weitere Informationen finden Sie in der technischen Erläuterung.
Anzahl der eindeutigen Ziele begrenzen, die von ausstehenden Quellen abgedeckt werden
Alle Ressourcen
- Weitere Informationen finden Sie unter Attributionsberichte.
- Weitere Informationen finden Sie unter Wichtige Informationen zur API.
Das Titelbild stammt von Diana Polekhina auf Unsplash.