Wir haben einige Änderungen an der Attribution Reporting API vorgenommen, um auf das Feedback der Community einzugehen. Hierzu zählen beispielsweise Änderungen am API-Mechanismus oder neue Funktionen.
Änderungsprotokoll
- 7. Februar 2022: Der Abschnitt Header-Trigger-Weiterleitung wurde hinzugefügt.
- 27. Januar 2022: Artikel wurde erstmals veröffentlicht.
An wen richtet sich dieser Beitrag?
Dieser Beitrag richtet sich an dich:
- Wenn Sie die API bereits verstehen, z. B. wenn Sie an den Diskussionen über das WICG-Repository beobachtet oder daran teilgenommen haben und die Änderungen nachvollziehen möchten, die im Januar 2022 am Vorschlag vorgenommen wurden.
- Sie verwenden die Attribution Reporting API in einer Demo oder in einem Test in der Produktion.
Wenn Sie diese API zum ersten Mal verwenden und/oder noch nicht damit experimentiert haben, lesen Sie stattdessen direkt die Einführung in die API.
Migration steht bevor
Nach der Implementierung dieser Änderungen in Chrome gilt Folgendes: Wenn Sie Berichte auf Ereignisebene der Attribution Reporting API in einer Demo oder in einem Produktionstest (Ursprungstest) verwenden, müssen Sie den Code bearbeiten, damit die API weiterhin funktioniert. Sie können auch die neuen Funktionen in Betracht ziehen.
In diesem Artikel werden auch Änderungen für aggregierte Berichte beschrieben. Wenn diese Änderungen implementiert werden, sind jedoch keine Maßnahmen oder Migrationen erforderlich, da zum Zeitpunkt der Veröffentlichung dieses Dokuments noch keine Browserimplementierung für aggregierte Berichte vorhanden ist.
Namensänderungen
Zusammenfassungsberichte und zusammengefasste Berichte
Zusammengefasste Berichte heißen jetzt Zusammenfassungsberichte.
Zusammenfassungsberichte sind das endgültige Ergebnis der Aggregation mehrerer aggregierbarer Berichte (früher „Beiträge“ oder „Histogrammbeiträge“).
Änderungen des API-Mechanismus
Headerbasierte Quellenregistrierung (Berichte auf Ereignisebene)
Was ändert sich und warum?
Wenn der Nutzer eine Anzeige sieht oder darauf klickt, zeichnet der Browser – lokal auf dem Gerät des Nutzers – dieses Ereignis auf, zusammen mit Parametern, die speziell für Attributionsberichte vorgesehen sind (z. B. attributionsourceeventid, attributiondestination, attributionexpiry). Die Werte dieser Parameter werden von AdTech festgelegt.
Die Art und Weise, wie diese Parameter festgelegt werden, ändert sich.
Im vorherigen Vorschlag mussten die Parameter clientseitig eingefügt werden: entweder als HTML-Attribute in den Anchor-Tags oder als Argumente eines JS-basierten Aufrufs. Die Parameter mussten zum Zeitpunkt des Klicks oder Aufrufs bekannt sein.
Im neuen Angebot wird der Wert dieser Parameter stattdessen auf dem AdTech-Server definiert.
Dies hat eine Reihe von Vorteilen, insbesondere im Hinblick auf die Sicherheit: Der Header-Mechanismus gibt dem Ursprung der Berichterstellung – in der Regel einer AdTech – direkte Kontrolle darüber, ob eine Attributionsquelle in ihrem Umfang registriert ist. Damit werden Betrugsbedenken teilweise gemindert, da durch diese Änderung ein echter Browser keine Quelle ohne die Zustimmung des Berichtsursprungs registriert.
Wie funktioniert die Registrierung von Quellen?
- Für eine bestimmte Anzeige müsste das AdTech-Team nun ein bestimmtes clientseitiges Attribut
attributionsrcdefinieren. 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 die Quelle ein Klick bzw. ein Aufruf war. - Nach Erhalt dieser Anfrage sollte der Klick-/Aufruf-Tracking-Server mit dem HTTP-Header
Attribution-Reporting-Register-Sourceantworten, der die gewünschten Attributionsparameter enthält. Der Ursprung, der diesen Header zurückgibt, ist jetzt der Ursprung des Berichts (zuvor als
attributionreporttodefiniert).HTTP-Antwortheader
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
Weitere Informationen findest du in der technischen Erklärung
Attributionsquellen registrieren
An der öffentlichen Diskussion teilnehmen
Headerbasierter Attributionstrigger (Berichte auf Ereignisebene)
Was ändert sich und warum?
Genau wie die Registrierung von Klicks oder Aufrufen ändert das neue Angebot den Attributionstrigger – wenn ein AdTech den Browser anweist, eine Conversion zu erfassen – auf einen Header-basierten Ansatz.
Dieser Mechanismus entspricht der headerbasierten Quellregistrierung und ist konventioneller als der zuvor verwendete Weiterleitungsmechanismus.
Außerdem ist im neuen Angebot das Attribut attributionsrc auf der Conversion-Seite erforderlich.
Die Gründe hängen von den Berechtigungen ab: Im vorherigen Vorschlag hatte die Trigger-Seite – in der Regel die Website eines Werbetreibenden – über einen Permissions-Policy-Header allgemeine Kontrolle über das Feature, aber keine detaillierte Kontrolle auf Elementebene darüber, ob ein Element eine Anfrage an eine Partei senden kann, die letztendlich eine Attribution auslösen würde. Durch attributionsrc ändert sich das: Diese obligatorische Markierung gibt dem Werbetreibenden die Möglichkeit zu überwachen und somit zu steuern, welche Elemente eine Zuordnung auslösen können.
Auf der Quellseite – normalerweise auf einer Publisher-Website – sind ein Steuerelement für die gesamte Seite über Permissions-Policy sowie ein Steuerelement für das gesamte Element über attributionsrc vorhanden.
Wie funktionieren Attributionstrigger?
Nachdem eine Pixelanfrage eingeht und entschieden wurde, dass sie als Conversion kategorisiert werden soll, sollte ein AdTech-Unternehmen mit dem neuen
-HTTP-Header Attribution-Reporting-Register-Event-Trigger antworten.
Der Wert dieses Headers gibt an, wie das Triggerereignis als JSON-Objekt behandelt wird. Dies sind dieselben Informationen, die im vorherigen Angebot 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, als Weiterleitungsantwort verwenden.
So können Drittanbieter das Conversion-Ereignis beobachten und den Browser anweisen, es zuzuordnen.
Die Weiterleitung ist optional. Sie ist nicht erforderlich, wenn sowohl eine AdTech-Anzeige als auch ein Drittanbieter Pixel auf der Seite haben.
Weitere Informationen finden Sie unter Drittanbieterberichte.
Weitere Informationen findest du in der technischen Erklärung
An der öffentlichen Diskussion teilnehmen
Kein Worklet (aggregierbare Berichte)
Was ändert sich und warum?
Im vorherigen Vorschlag für aggregierbare Berichte war es erforderlich, ein JavaScript-Zugriffskonto aufzurufen, um ein Worklet aufzurufen – einen JavaScript-basierten Mechanismus –, der diese Berichte generieren würde.
Im neuen Angebot ist kein Worklet erforderlich. Stattdessen würden AdTech die Regeln, die der Browser zum Generieren aggregierter Berichte verwenden soll, deklarativ – über HTTP-Header – definieren.
Das neue Angebot bietet mehrere Vorteile:
- Browserimplementierung:Das neue Design ist im Gegensatz zum Worklet-Design wesentlich einfacher, da es keine neue Ausführungsumgebung in Browsern erfordert.
- Für Entwickler: Das neue Design beruht im Gegensatz zu Worklets auf Headern, die von Entwicklern häufig verwendet und allgemein bekannt sind. Außerdem ist sie eng mit der API-Oberfläche für die Registrierung von Quellen abgestimmt, wodurch die API einfacher zu erlernen und zu verwenden ist.
- Einführung:Durch das neue Design können mehr vorhandene Messsysteme aggregierte Berichte verwenden. Viele Analysetools nutzen nur HTTP: Sie beruhen auf Bildanfragen – also Pixelanfragen –, für die kein JavaScript-Zugriff erforderlich ist. Da für den Worklet-Ansatz jedoch JavaScript-Zugriff erforderlich war, war es möglicherweise schwierig, von einigen vorhandenen Messsystemen zu migrieren.
- Robustheit:Das neue Design minimiert Datenverluste, da sich die
keepalive-Semantik leichter einbinden lässt, z. B. wenn ein Klick oder eine Ansicht registriert wird, wenn ein Nutzer eine Seite verlässt.
Wie funktioniert der Worklet-kostenlose Mechanismus?
Dieser deklarative Mechanismus basiert auf HTTP-Headern – genau wie die Quellenregistrierung auf Ereignisebene und der Trigger-Header für die Attribution. Weitere Informationen dazu finden Sie in den nächsten Abschnitten.
An der öffentlichen Diskussion teilnehmen
Header-basierte Quellenregistrierung (aggregierbare Berichte)
Ein neuer Mechanismus wird vorgeschlagen, um eine Quelle für einen aggregierbaren Bericht zu registrieren. Dieser Mechanismus ist mit der Quellenregistrierung auf Ereignisebene identisch.
Nur der Headername ist unterschiedlich: Attribution-Reporting-Register-Aggregatable-Source.
Weitere Informationen findest du in der technischen Erklärung
Registrierung der Attributionsquelle
Headerbasierter Attributionstrigger (aggregierbare Berichte)
Ein neuer Mechanismus wird vorgeschlagen, um eine Quelle für einen aggregierbaren Bericht zu registrieren. Dieser Mechanismus ist mit dem Attributionstrigger auf Ereignisebene identisch.
Nur der Headername ist unterschiedlich: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
Weitere Informationen findest du in der technischen Erklärung
Registrierung von Attributionstriggern
Neue Funktionen
Drittanbieterberichte (Berichte auf Ereignisebene und aggregierte Berichte)
Was ändert sich und warum?
Zwei Aspekte des neuen Angebots tragen zu einer besseren Unterstützung der Anwendungsfälle von Drittanbieterberichten bei:
- Optional können AdTechs Netzwerkanfragen an andere AdTech-Server weiterleiten, sodass diese anderen AdTechs ihre eigene Quelle ausführen und die Registrierung auslösen können. Dies ist eine gängige Konfiguration von Drittanbietern. Dies vereinfacht die Einbindung der API unter anderem in vorhandenen Drittanbieter-Berichtssystemen.
- Für die Ursprünge der Berichte – in der Regel AdTech-Unternehmen – gelten nicht mehr die meisten Datenschutzbeschränkungen. Dies unterstützt Anwendungsfälle, in denen mehrere AdTechs mit denselben Publishern oder Werbetreibenden zusammenarbeiten.
Wie funktionieren Drittanbieterberichte?
Im neuen Angebot basieren die antwortbasierte Quellenregistrierung und der Trigger auf HTTP-Headern. AdTech kann für solche Anfragen HTTP-Weiterleitungen nutzen.
Wenn eine Klick- oder Aufrufanfrage auf der Website eines Publishers (Registrierung der Quelle) anschließend an mehrere Parteien weitergeleitet wird, kann jede dieser Parteien diese Ansicht oder diesen Klick (Quellereignis) registrieren.
In ähnlicher Weise kann ein AdTech-Unternehmen eine bestimmte Attributionsanfrage weiterleiten, die von einer Advertiser-Website stammt, sodass mehrere andere Parteien eine Conversion registrieren können (Attributionsauslöser).
Jede Partei kann auf ihre eigenen Berichte zugreifen und diese mit separaten Daten konfigurieren.
Mehrere Trigger ohne Weiterleitungen registrieren
Es ist auch möglich, mehrere Attributionstrigger ohne Weiterleitungen zu registrieren, indem Sie auf der Conversion-Seite mehrere Pixelelemente hinzufügen (eines pro Trigger).
An der öffentlichen Diskussion teilnehmen
View-through-Messung (Berichte auf Ereignisebene und aggregierte Berichte)
Was ändert sich und warum?
Im neuen Angebot funktionieren View-through-Messung und Klick-Messung einheitlich:
registerattributionsrc, das ansichtsspezifische Attribut, das den Browser anweist, Aufrufe zusammen mit Klicks aufzuzeichnen, ist nicht mehr Teil des Angebots.- Die Datenschutzmechanismen für Klicks und Aufrufe sind jetzt vereinheitlicht. Weitere Informationen finden Sie unter Rauschen und Transparenz.
Diese Änderung soll dem neuen header-basierten Registrierungsmechanismus entsprechen. Außerdem vereinfacht es die Arbeit für Entwickler, wenn sie sowohl die Klick- als auch die View-through-Messung unterstützen möchten.
Wie funktioniert die View-through-Messung?
View-through-Messung und Klick-Messung basieren beide auf einer header-basierten Registrierung.
Weitere Informationen findest du in der technischen Erklärung
Berichte auf Ereignisebene (für Klicks und Aufrufe)
An der öffentlichen Diskussion teilnehmen
Fehlerbehebung / Leistungsanalyse (Berichte auf Ereignisebene und aggregierbare Berichte)
Was ändert sich und warum?
Der Vorschlag wurde um einen Mechanismus zur Fehlerbehebung erweitert, mit dem Entwickler Fehler erkennen und die Leistung von Attribution Reporting mit vorhandenen cookiebasierten Analysetools vergleichen können.
Wie funktioniert die Fehlerbehebung?
Sowohl die Quell- als auch die Triggerregistrierung akzeptieren den neuen Parameter debug_key, eine vorzeichenlose 64-Bit-Ganzzahl (eine große Zahl).
Wenn ein Bericht mit Schlüsseln zur Fehlerbehebung für die Quelle und den Trigger erstellt wird und in der Cookie-JAR-Datei des Berichtsherkunfts zum Zeitpunkt der Registrierung und Registrierung ein Samesite=None ar_debug=1-Cookie vorhanden ist, wird ein Debug-Bericht (JSON) an einen .well-known/attribution-reporting/debug-Endpunkt gesendet:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Berichte auf Ereignisebene und aggregierte Daten enthalten ebenfalls diese beiden neuen Parameter, damit sie dem richtigen Debug-Bericht zugeordnet werden können.
Weitere Informationen findest du in der technischen Erklärung
Optional: Erweiterte Debugging-Berichte
An der öffentlichen Diskussion teilnehmen
Filterfunktionen (Berichte auf Ereignisebene und aggregierte Berichte)
Was ändert sich und warum?
Da sie wichtige Anwendungsfälle im heutigen Werbesystem unterstützen, werden jetzt eine Reihe von Anwendungsfällen sowohl in Berichten auf Ereignisebene als auch in aggregierten Berichten unterstützt:
- Conversion-Filterung:Filtern Sie eine Conversion basierend auf quellenseitigen Informationen. Sie können beispielsweise unterschiedliche Triggerdaten (Conversion-Daten) für Anzeigenklicks und Anzeigenaufrufe auswählen.
- Nicht übereinstimmende Attribution:Es werden falsch zugeordnete Conversions herausgefiltert. Dies ist eine bestimmte Art der Conversion-Filterung. Filtern Sie beispielsweise Conversions heraus, die aufgrund des Zielbereichs „etld+1“ in der API einem falschen Anzeigenklick oder einer falschen Anzeigenaufruf zugeordnet werden.
Wie funktionieren Filter? (für Berichte auf Ereignisebene)
Mit einem optionalen source_data-Feld im quellseitigen JSON-Objekt können Elemente definiert werden, die der Browser zum Zeitpunkt der Konvertierung verwendet, um die Filterlogik anzuwenden.
{
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"}
}
}
Für die Trigger-Registrierung wird jetzt der optionale 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 mit einem filters-Feld erweitert werden, um selektives Filtern zu ermöglichen 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 findest du in der technischen Erklärung
An der öffentlichen Diskussion teilnehmen
Änderungen beim Datenschutz
Rauschen und Transparenz (Berichte auf Ereignisebene und aggregierte Berichte)
Was ändert sich und warum?
Im neuen Vorschlag wurde einer der Datenschutzmechanismen für Berichte verbessert: Berichte unterliegen einer zufälligen Antwort.
Das bedeutet, dass einige echte Conversions korrekt erfasst werden. Zu einem bestimmten Prozentsatz der Zeit werden einige echte Conversions unterdrückt oder gefälschte Conversions hinzugefügt.
Diese neue Technik bietet einige Vorteile:
- Es vereinheitlicht den Datenschutzmechanismus für Klicks und Aufrufe.
- Diese Methode ist einfacher als ein Mechanismus, bei dem Triggerdaten (Conversion-Daten) und Linkrauschen auf Trigger-Quelle getrennt werden.
- Dabei wird ein Datenschutz-Framework eingerichtet, das mit den richtigen Einstellungen dafür sorgt, dass sich niemand auf die API verlassen kann, um mit Gewissheit zu wissen, dass ein einzelner Nutzer für eine bestimmte Anzeige eine Conversion ausgeführt hat oder nicht.
Dieser neue Mechanismus ersetzt den vorherigen Mechanismus, bei dem 5% der Trigger-Daten (Conversion-Daten) durch einen zufälligen Wert ersetzt wurden.
Außerdem wurde der randomisierte Wert für die Antwortwahrscheinlichkeit dem Berichtstext (Feld randomized_trigger_rate) hinzugefügt. Dieses Feld gibt die Wahrscheinlichkeit (0 bis 1) an, mit der eine Quelle einer zufälligen Antwort unterliegt.
Das hat zwei wesentliche Vorteile:
- Dadurch wird das zugrunde liegende Browserverhalten für die Empfänger der Berichte (normalerweise AdTech-Unternehmen) transparent.
- Dies ist hilfreich für eine Zukunft, in der die API browserübergreifend unterstützt wird: Verschiedene Browser können je nach ihren Datenschutzzielen unterschiedliche Rauschpegel anwenden. Die Parteien, die den Bericht bearbeiten, benötigen Einblick in dies.
Wie funktioniert Lärm?
Wenn im neuen Angebot eine Quelle registriert wird (d. h. ein Anzeigenklick oder ein Anzeigenaufruf erfasst wird), entscheidet der Browser nach dem Zufallsprinzip, ob Conversions wahrheitsgemäß zugeordnet und Berichte zu diesem Anzeigenklick bzw. diesem Anzeigenaufruf gesendet werden oder ob stattdessen eine gefälschte Ausgabe generiert wird.
Die gefälschte Ausgabe kann so aussehen:
- Keine Berichte – unabhängig davon, ob der Nutzer eine Conversion ausführt
- Ein oder mehrere gefälschte Berichte – unabhängig davon, ob der Nutzer eine Conversion ausführt.
In gefälschten Berichten sind die Trigger-Daten (Conversion-Daten) zufällig: ein 3-Bit-Zufallswert für Klicks (eine beliebige Zahl zwischen 0 und 7) und ein zufälliger 1-Bit-Wert für Aufrufe (0 oder 1).
Genau wie echte Berichte werden gefälschte Berichte nicht sofort gesendet, nachdem der Nutzer eine Conversion ausgeführt hat. Sie werden am Ende eines zufälligen Berichtszeitraums gesendet.
Für Klicks gibt es drei Berichtszeitraum: 2 Tage, 7 Tage oder 30 Tage nach dem Klick. Jeder gefälschte Bericht wird nach dem Zufallsprinzip einem der Meldefenster zugewiesen.
Wie im vorherigen Vorschlag bereits erwähnt, erfolgt die Reihenfolge der Berichte innerhalb eines Zeitfensters zufällig.
Weitere Informationen findest du in der technischen Erklärung
Beispiele für verrauschte falsche Conversions
An der öffentlichen Diskussion teilnehmen
Einschränkungen bei der Berichterstellung (Berichte auf Ereignisebene und aggregierte Berichte)
Limits für die Quelle von Berichten
Was ändert sich und warum?
Im neuen Vorschlag wird explizit eingeschränkt, wie viele Parteien Ereignisse zwischen zwei Websites messen können.
- Die maximale Anzahl einzelner Berichtquellen (in der Regel AdTech-Unternehmen), die Quellen pro {publisher, advertiser} registrieren können, wird voraussichtlich auf 100 pro 30 Tage begrenzt. Dieser Zähler wird bei jedem Anzeigenklick oder -aufruf (Quellereignis) erhöht, auch bei nicht zugeordneten Anzeigen.
- Die maximale Anzahl einzelner Berichtquellen (in der Regel AdTech-Unternehmen), die Berichte pro {publisher, advertiser} senden können, wird voraussichtlich auf 10 pro 30 Tage begrenzt. Dieser Zähler wird für jede zugeordnete Conversion erhöht.
Diese Limits sind so hoch, dass sie die Fähigkeit der Nutzer, Conversions zu messen, nicht einschränken. Sie sind aber so niedrig, dass sie einige Formen von API-Missbrauch abschwächen können.
Wartezeit bei Berichten / Ratenbegrenzungen
Was ändert sich und warum?
Die Wartezeit für Berichte ist ein Datenschutzmechanismus, der die Menge an Informationen drosselt, die in einem bestimmten Zeitraum für einen Nutzer über diese API gesendet werden.
Im neuen Angebot können 100 Berichte pro {Quellwebsite, Ziel, Quelle der Berichterstellung} (normalerweise {publisher, advertiser, adtech}) für einen Zeitraum von 30 Tagen geplant werden.
Wird diese Grenze überschritten, werden vom Browser keine Berichte mehr geplant, die mit {source site, destination, Reporting origin} (in der Regel {publisher, advertiser, adtech}) übereinstimmen, bis die Zahl der 30-Tage-Berichte für {source site, destination, Reporting origin} unter 100 fällt.
Weitere Informationen findest du in der technischen Erklärung
Sperrung der Berichte / Ratenbegrenzungen
Ziel-Capping (nur für Berichte auf Ereignisebene)
Was ändert sich und warum?
Das Ziel-Capping wird so geändert, dass der Ursprung der Berichte (in der Regel eine AdTech) im Geltungsbereich liegt: 100 eindeutige ausstehende Ziele (in der Regel Websites von Werbetreibenden oder Websites, auf denen Conversions erwartet werden) sind pro {publisher, adtech} zulässig.
Dies ist eine Datenschutzmaßnahme, um die Rekonstruktion des Browserverlaufs einzuschränken.
Weitere Informationen findest du in der technischen Erklärung
Begrenzen der Anzahl eindeutiger Ziele, die von ausstehenden Quellen abgedeckt werden
Alle Ressourcen
- Siehe Attributionsberichte.
- Lesen Sie Wissenswertes über die API.
Das Kopfzeilenbild stammt von Diana Polekhina auf Unsplash.