Attribution Reporting für Mobilgeräte – Übersicht

Hinweis : Dieses Dokument spiegelt die Privacy Sandbox für die aktuellen Designvorschläge von Android wider und kann noch geändert werden. Wir freuen uns über Ihr Feedback und Ihre Kommentare, um uns dabei zu unterstützen.

Feedback geben

Letzte Updates

• Die Liste der anstehenden Änderungen und bekannten Probleme wurde aktualisiert.
• Einführung der flexiblen Konfiguration auf Ereignisebene als Brücke zur vollständigen flexiblen Konfiguration auf Ereignisebene
• Ab September 2023 müssen registerWebSource, registerWebTrigger, registerAppSource und registerAppTrigger Strings für Felder verwenden, die einen numerischen Wert erwarten (z. B. priority, source_event_id, debug_key, trigger_data, deduplication_key usw.).
• Ab dem 4. Quartal 2023 wird Google Cloud-Unterstützung in der Android Attribution Reporting API hinzugefügt, um zusammenfassende Berichte mit dem Aggregationsdienst in Google Cloud zu generieren. Hier ist der Zeitpunkt entsprechend genauer. Weitere Informationen zum Einrichten des Aggregationsdienstes mit Google Cloud finden Sie im Bereitstellungsleitfaden.
• Neue datenschutzfreundliche Ratenbegrenzungen für die Anzahl eindeutiger Zielanwendungen.
• Aktualisierte Funktionen für Triggerfilter für Lookback-Windows sind im 1. Quartal 2024 verfügbar. Weitere Informationen finden Sie im Hinweis.

Überblick

Heutzutage werden Lösungen für parteiübergreifende Kennungen wie die Werbe-ID häufig für mobile Attributions- und Analyselösungen verwendet. Die Attribution Reporting API wurde entwickelt, um den Datenschutz für Nutzer zu verbessern, indem die Abhängigkeit von parteiübergreifenden Nutzerkennungen beseitigt wird. Außerdem unterstützt sie wichtige Anwendungsfälle für die Attribution und Conversion-Messung in Apps und im Web.

Diese API hat die folgenden strukturellen Mechanismen, die einen Rahmen für die Verbesserung des Datenschutzes bilden. Diese werden weiter unten auf dieser Seite ausführlicher beschrieben:

• Begrenzt die Anzahl der Bits, die für Berichte auf Ereignisebene verfügbar sind.
• Es werden hochwertigere Conversion-Daten nur in aggregierbaren Berichten aktiviert.
• Einführung von Ratenbegrenzungen für verfügbare Trigger (Conversions) und die Anzahl der Anzeigentechnologien, die einer einzelnen Attributionsquelle zugeordnet werden können
• Beinhaltet verschiedene Techniken zur Rauschunterdrückung

Die vorherigen Mechanismen schränken die Möglichkeit ein, die Nutzeridentität über zwei verschiedene Anwendungen oder Domains hinweg zu verknüpfen.

Die Attribution Reporting API unterstützt die folgenden Anwendungsfälle:

• Conversion-Berichte:Mit diesen Berichten können Werbetreibende die Leistung ihrer Kampagnen messen, indem sie die Anzahl der Conversions (Trigger) und die Conversion-Werte (Trigger) in verschiedenen Dimensionen sehen, z. B. nach Kampagne, Anzeigengruppe und Creative.
• Optimierung: Stellen Sie Berichte auf Ereignisebene bereit, mit denen sich die Werbeausgaben optimieren lassen, indem Sie Attributionsdaten pro Impression bereitstellen, die zum Trainieren von ML-Modellen verwendet werden können.
• Erkennung ungültiger Aktivitäten:Stellen Sie Berichte bereit, die zur Erkennung und Analyse von ungültigen Zugriffen und Anzeigenbetrug verwendet werden können.

Grundsätzlich funktioniert die Attribution Reporting API so, wie in späteren Abschnitten dieses Dokuments genauer beschrieben wird:

1. Der AdTech-Anbieter schließt eine Registrierung ab, um die Attribution Reporting API zu verwenden.
2. Die AdTech registriert Attributionsquellen, d. h. Anzeigenklicks oder -aufrufe, mit der Attribution Reporting API.
3. Die AdTech registriert Trigger, also Nutzer-Conversions in der App oder auf der Website des Werbetreibenden, mit der Attribution Reporting API.
4. Die Attribution Reporting API gleicht Trigger mit Attributionsquellen – einer Conversion-Attribution – ab, und mindestens ein Trigger wird über Berichte auf Ereignisebene und aggregierbare Berichte an Anzeigentechnologie-Anbieter gesendet.

Hinweis :Weitere Informationen zur Implementierung dieses Designs für einen Anwendungsfall der App-zu-App-Attribution finden Sie im Abschnitt zur netzwerkübergreifenden Attribution des Entwicklerhandbuchs zur Attribution Reporting API. Informationen zum Implementieren eines Anwendungsfalls für eine App-zu-Web- oder Web-zu-App-Implementierung finden Sie im Entwurf zur App- und Web-Messung.

Zugriff auf Attribution Reporting APIs erhalten

AdTech-Plattformen müssen sich für den Zugriff auf die Attribution Reporting APIs registrieren. Weitere Informationen finden Sie unter Für Privacy Sandbox-Konto registrieren.

Attributionsquelle registrieren (klicken oder ansehen)

In der Attribution Reporting API werden Anzeigenklicks und -aufrufe als Attributionsquellen bezeichnet. Rufen Sie registerSource() auf, um einen Anzeigenklick oder einen Anzeigenaufruf zu registrieren. Diese API erwartet die folgenden Parameter:

• URI der Attributionsquelle:Die Plattform sendet eine Anfrage an diesen URI, um Metadaten abzurufen, die mit der Attributionsquelle verknüpft sind.
• Eingabeereignis:Entweder ein InputEvent-Objekt (für ein Klickereignis) oder ein null (für ein Aufrufereignis).

Wenn die API eine Anfrage an den URI der Attributionsquelle stellt, sollte das AdTech-Team mit den Metadaten der Attributionsquelle in einem neuen HTTP-Header Attribution-Reporting-Register-Source mit den folgenden Feldern antworten:

• Quellereignis-ID: Dieser Wert steht für die Daten auf Ereignisebene, die mit dieser Attributionsquelle verknüpft sind (Anzeigenklick oder -aufruf). Muss eine vorzeichenlose 64-Bit-Ganzzahl als String formatiert sein.
• Ziel: Ein Ursprung, dessen eTLD+1 oder der Name des App-Pakets an dem das Trigger-Ereignis auftritt.
• Ablauf (optional): Das Ablaufdatum in Sekunden, nach dem die Quelle vom Gerät gelöscht werden soll. Der Standardwert beträgt 30 Tage. Der Mindestwert beträgt 1 Tag und der Höchstwert 30 Tage. Dieser Wert wird auf den nächsten Tag gerundet. Kann als vorzeichenlose 64-Bit-Ganzzahl oder -String formatiert werden.
• Ereignisberichtsfenster (optional): Dauer in Sekunden nach der Registrierung der Quelle, in der Ereignisberichte für diese Quelle erstellt werden können. Wenn das Fenster für den Ereignisbericht abgelaufen ist, der Ablauf aber noch nicht abgelaufen ist, kann ein Trigger noch einer Quelle zugeordnet werden. Es wird jedoch kein Ereignisbericht für diesen Trigger gesendet. Darf nicht größer als „Ablaufdatum“ sein. Kann entweder als vorzeichenlose 64-Bit-Ganzzahl oder als String formatiert werden.
• Fenster für aggregierbare Berichte (optional): Dauer in Sekunden nach der Registrierung der Quelle, während der aggregierte Berichte für diese Quelle erstellt werden können. Darf nicht größer als „Ablaufdatum“ sein. Kann als unsignierte 64-Bit-Ganzzahl oder als String formatiert werden.
• Priorität der Quelle (optional): Wird verwendet, um auszuwählen, mit welcher Attributionsquelle ein bestimmter Trigger verknüpft werden soll, falls dem Trigger mehrere Attributionsquellen zugeordnet werden können. Muss eine als String formatierte 64-Bit-Ganzzahl mit Vorzeichen sein.
  
  Wenn ein Trigger empfangen wird, ermittelt die API die entsprechende Attributionsquelle mit der höchsten Quellpriorität und erstellt einen Bericht. Jede AdTech-Plattform kann ihre eigene Priorisierungsstrategie definieren. Weitere Informationen dazu, wie sich die Priorität auf die Attribution auswirkt, finden Sie im Abschnitt Beispiel für die Priorisierung.
  
  Höhere Werte bedeuten höhere Prioritäten.
• Attributionszeiträume nach Installationen und Installation (optional): Wird verwendet, um die Attribution für Ereignisse nach der Installation zu bestimmen, wie weiter unten auf dieser Seite beschrieben.
• Daten filtern (optional): Wird verwendet, um einige Trigger selektiv zu filtern und effektiv zu ignorieren. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Triggerfilter.
• Aggregationsschlüssel (optional): Geben Sie die Segmentierung an, die für aggregierbare Berichte verwendet werden soll.

Optional kann die Metadatenantwort der Attributionsquelle zusätzliche Daten im Header Weiterleitungen der Attributionsberichte enthalten. Die Daten enthalten Weiterleitungs-URLs, über die mehrere Anzeigentechnologie-Anbieter eine Anfrage registrieren können.

Der Entwicklerleitfaden enthält Beispiele, die zeigen, wie die Registrierung der Quellen akzeptiert wird.

Die folgenden Schritte zeigen einen Beispielworkflow:

1. Das Ad Tech SDK ruft die API auf, um die Registrierung der Attributionsquelle zu initiieren, und gibt einen URI an, den die API aufrufen soll:

   registerSource(
       Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
       myClickEvent);
   

2. Die API stellt mit einem der folgenden Header eine Anfrage an https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA:

   <!-- For click events -->
   Attribution-Reporting-Source-Info: navigation
   
   <!-- For view events -->
   Attribution-Reporting-Source-Info: event
   

3. Der HTTPS-Server dieser Werbetechnologie antwortet mit Headern, die Folgendes enthalten:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "234",
       "expiry": "60000",
       "priority": "5"
   }
   Attribution-Reporting-Redirect:
   https://adtechpartner1.example?their_ad_click_id=567
   Attribution-Reporting-Redirect:
   https://adtechpartner2.example?their_ad_click_id=890
   

4. Die API stellt eine Anfrage an jede in Attribution-Reporting-Redirect angegebene URL. In diesem Beispiel werden zwei URLs von AdTech-Partnern angegeben. Die API sendet eine Anfrage an https://adtechpartner1.example?their_ad_click_id=567 und eine andere Anfrage an https://adtechpartner2.example?their_ad_click_id=890.

5. Der HTTPS-Server dieser Werbetechnologie antwortet mit Headern, die Folgendes enthalten:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "789",
       "expiry": "120000",
       "priority": "2"
   }
   

   Hinweis :In den Antworten von Anzeigentechnologie-Anbietern können im Attribution-Reporting-Register-Source-Header unterschiedliche Metadaten angegeben werden.

Basierend auf den in den vorherigen Schritten angezeigten Anfragen werden drei Attributionsquellen für die Navigation (Klick) registriert.

Attributionsquelle aus WebView registrieren

WebView unterstützt den Anwendungsfall, in dem eine App eine Anzeige in einem WebView rendert. Dazu ruft WebView direkt registerSource() als Hintergrundanfrage auf. Bei diesem Aufruf wird die Attributionsquelle der App statt dem Ursprung der obersten Ebene zugeordnet. Die Registrierung von Quellen aus eingebetteten Webinhalten in einem Browserkontext wird ebenfalls unterstützt. Sowohl API-Aufrufer als auch Apps müssen dafür die Einstellungen anpassen. Anleitungen für API-Aufrufer finden Sie unter Attributionsquelle und Trigger aus WebView registrieren. Anleitungen für Apps finden Sie unter Attributionsquelle und Registrierung über WebView auslösen.

Da Anzeigentechnologie-Anbieter denselben Code für Web und WebView verwenden, folgt WebView HTTP 302-Weiterleitungen und gibt gültige Registrierungen an die Plattform weiter. Wir planen nicht, den Attribution-Reporting-Redirect-Header für dieses Szenario zu unterstützen. Wenn Sie einen betroffenen Anwendungsfall haben, kontaktieren Sie uns.

Trigger registrieren (Conversion)

AdTech-Plattformen können Trigger – Conversions wie Installationen oder Ereignisse nach der Installation – mit der registerTrigger()-Methode registrieren.

Die Methode registerTrigger() erwartet den Parameter Trigger-URI. Die API sendet eine Anfrage an diesen URI, um die mit dem Trigger verknüpften Metadaten abzurufen.

Die API folgt Weiterleitungen. Die Antwort des AdTech-Servers sollte den HTTP-Header Attribution-Reporting-Register-Trigger enthalten, der Informationen zu einem oder mehreren registrierten Triggern darstellt. Der Inhalt des Headers sollte JSON-codiert sein und die folgenden Felder enthalten:

• Triggerdaten:Daten zur Identifizierung des Triggerereignisses (3 Bit für Klicks, 1 Bit für Aufrufe). Muss eine vorzeichenbehaftete 64-Bit-Ganzzahl sein, die als String formatiert ist.
• Triggerpriorität (optional): Stellt die Priorität dieses Triggers im Vergleich zu anderen Triggern für dieselbe Attributionsquelle dar. Muss eine als String formatierte 64-Bit-Ganzzahl mit Vorzeichen sein. Weitere Informationen dazu, wie sich die Priorität auf die Berichterstellung auswirkt, finden Sie im Abschnitt Priorisierung.
• Deduplizierungsschlüssel (optional): Wird zur Identifizierung von Fällen verwendet, in denen derselbe Trigger mehrmals von derselben AdTech-Plattform für dieselbe Attributionsquelle registriert wird. Muss eine vorzeichenbehaftete 64-Bit-Ganzzahl sein, die als String formatiert ist.
• Aggregationsschlüssel (optional): Eine Liste von Wörterbüchern, in denen Aggregationsschlüssel angegeben werden und in welchen aggregierten Berichten ihre Werte zusammengefasst werden sollen.
• Aggregationswerte (optional): Eine Liste der Werte, die zu jedem Schlüssel beitragen.
• Filter (optional): Hiermit können Sie Trigger selektiv filtern oder Daten auslösen. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Triggerfilter.

Optional kann die Antwort des AdTech-Servers zusätzliche Daten im Header Attribution Reporting Redirects (Weiterleitungen für Attribution Reporting) enthalten. Die Daten enthalten Weiterleitungs-URLs, mit denen mehrere Anzeigentechnologien eine Anfrage registrieren können.

Mehrere Anzeigentechnologie-Anbieter können dasselbe Triggerereignis registrieren. Dazu werden Weiterleitungen im Feld Attribution-Reporting-Redirect oder mehrere Aufrufe der Methode registerTrigger() verwendet. Wir empfehlen, das Feld Deduplizierungsschlüssel zu verwenden. So vermeiden Sie doppelte Trigger in Berichten für den Fall, dass dieselbe Anzeigentechnologie mehrere Antworten für dasselbe Triggerereignis liefert. Weitere Informationen zur Verwendung eines Deduplizierungsschlüssels

Der Entwicklerleitfaden enthält Beispiele, die zeigen, wie die Triggerregistrierung akzeptiert wird.

Die folgenden Schritte zeigen einen Beispielworkflow:

1. Das Ad Tech SDK ruft die API auf, um die Trigger-Registrierung mit einem vorab registrierten URI zu initiieren. Weitere Informationen finden Sie unter Für ein Privacy Sandbox-Konto registrieren.

   registerTrigger(
       Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
   

2. Die API stellt eine Anfrage an https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA.

3. Der HTTPS-Server dieser Werbetechnologie antwortet mit Headern, die Folgendes enthalten:

   Attribution-Reporting-Register-Trigger: {
       "event_trigger_data": [{
       "trigger_data": "1122",
       // This returns 010 for click-through conversions (CTCs) and 0 for
       // view-through conversions (VTCs) in reports
       "priority": "3",
       "deduplication_key": "3344"
       }],
   }
   Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567
   

   Hinweis :Nur die Anzeigentechnologie, die den API-Aufruf initiiert, kann Partner in Attribution-Reporting-Redirect angeben.

4. Die API stellt eine Anfrage an jede in Attribution-Reporting-Redirect angegebene URL. Da in diesem Beispiel nur eine URL angegeben ist, stellt die API eine Anfrage an https://adtechpartner.example?app_install=567.

5. Der HTTPS-Server dieser Werbetechnologie antwortet mit Headern, die Folgendes enthalten:

   Attribution-Reporting-Register-Trigger: {
   "event_trigger_data":[{
     "trigger_data": "5566",
     "priority": "3",
     "deduplication_key": "3344"
   }]
   }
   

   Basierend auf den Anfragen in den vorherigen Schritten werden zwei Trigger registriert.

Attributionsfunktionen

In den folgenden Abschnitten wird erläutert, wie die Attribution Reporting API Conversion-Trigger und Attributionsquellen zuordnet.

Der quellenpriorisierte Attributionsalgorithmus wurde angewendet

Die Attribution Reporting API nutzt einen nach Quelle priorisierten Attributionsalgorithmus, um einen Trigger (Conversion) einer Attributionsquelle zuzuordnen.

Mit Prioritätsparametern können Sie die Attribution von Triggern zu Quellen anpassen:

• Sie können Trigger bestimmten Anzeigenereignissen gegenüber anderen zuordnen. So können Sie beispielsweise mehr Fokus auf Klicks statt auf Aufrufe legen oder den Schwerpunkt auf Ereignisse aus bestimmten Kampagnen legen.
• Sie können die Attributionsquelle und den Trigger so konfigurieren, dass Sie mit höherer Wahrscheinlichkeit die Berichte erhalten, die für Sie wichtiger sind, wenn Sie Ratenbegrenzungen erreichen. So lässt sich beispielsweise dafür sorgen, dass gebotsfähige Conversions oder hochwertige Conversions mit höherer Wahrscheinlichkeit in diesen Berichten auftauchen.

Wenn mehrere Anzeigentechnologien eine Attributionsquelle registrieren, wie weiter unten auf dieser Seite beschrieben, erfolgt diese Attribution für jede Anzeigentechnologie unabhängig. Bei jedem Anzeigentechnologie-Anbieter wird dem Triggerereignis die Attributionsquelle mit der höchsten Priorität zugeordnet. Wenn es mehrere Attributionsquellen mit derselben Priorität gibt, wählt die API die zuletzt registrierte Attributionsquelle aus. Alle anderen Attributionsquellen, die nicht ausgewählt sind, werden verworfen und kommen nicht mehr für die zukünftige Triggerattribution infrage.

Triggerfilter

Die Quell- und Triggerregistrierung umfasst zusätzliche optionale Funktionen für folgende Zwecke:

• Bestimmte Trigger werden selektiv gefiltert und ignoriert.
• Wählen Sie Triggerdaten für Berichte auf Ereignisebene basierend auf Quelldaten aus.
• Wählen Sie aus, ob Sie einen Trigger aus Berichten auf Ereignisebene ausschließen möchten.

Um Trigger selektiv zu filtern, kann die Anzeigentechnologie-Anbieter Filterdaten, die aus Schlüsseln und Werten bestehen, während der Registrierung von Quelle und Triggern angeben. Wenn für die Quelle und der Trigger derselbe Schlüssel angegeben ist, wird der Trigger ignoriert, wenn die Kreuzung leer ist. Eine Quelle kann beispielsweise "product": ["1234"] angeben, wobei product der Filterschlüssel und 1234 der Wert ist. Wenn der Triggerfilter auf "product": ["1111"] gesetzt ist, wird der Trigger ignoriert. Wenn es keinen Trigger-Filterschlüssel gibt, der mit product übereinstimmt, werden die Filter ignoriert.

Ein weiteres Szenario, in dem AdTech-Plattformen Trigger selektiv filtern möchten, ist ein kürzeres Ablaufdatum. Bei der Trigger-Registrierung kann ein Anzeigentechnologie-Anbieter ein Lookback-Window ab dem Zeitpunkt der Conversion angeben (in Sekunden). Ein Lookback-Window von 7 Tagen wird beispielsweise so definiert: "_lookback_window": 604800 // 7d

Um zu entscheiden, ob ein Filter übereinstimmt, prüft die API zuerst das Lookback-Window. Falls verfügbar, muss die Dauer seit der Registrierung der Quelle kleiner oder gleich der Dauer des Lookback-Windows sein.

Hinweis: Die beschriebene Logik und Funktionalität von Lookback-Filtern gelten ab F124. Weitere Informationen zum Veröffentlichungszeitpunkt Bei der bisherigen Logik mussten Lookback-Windows sowohl auf der Quell- als auch auf der Triggerseite nach Stunden angegeben werden. Diese aktualisierte Featurelogik ist abwärtsinkompatibel. Das bedeutet, dass Quellen, die den vorherigen Schlüssel „_lookback_window“ verwenden, nicht erfolgreich registriert werden.

AdTech-Plattformen können auch Triggerdaten auf Grundlage von Quellereignisdaten auswählen. Beispielsweise wird source_type automatisch von der API als navigation oder event generiert. Während der Trigger-Registrierung kann trigger_data als ein Wert für "source_type": ["navigation"] und als ein anderer Wert für "source_type": ["event"] festgelegt werden.

Trigger sind in Berichten auf Ereignisebene nicht enthalten, wenn eine der folgenden Bedingungen zutrifft:

• Es ist kein trigger_data angegeben.
• Quelle und Trigger geben denselben Filterschlüssel an, aber die Werte stimmen nicht überein. Beachten Sie, dass der Trigger in diesem Fall sowohl für Berichte auf Ereignisebene als auch für aggregierte Berichte ignoriert wird.

Attribution nach der Installation

In einigen Fällen ist es erforderlich, dass Trigger nach der Installation der Attributionsquelle zugeordnet werden, die zur Installation geführt hat, auch wenn es in letzter Zeit andere zulässige Attributionsquellen gibt.

Die API unterstützt diesen Anwendungsfall, da Anzeigentechnologie-Anbieter einen Attributionszeitraum nach der Installation festlegen können:

• Geben Sie beim Registrieren einer Attributionsquelle ein Zeitfenster für die Attribution von Installationen an, in dem Installationen zu erwarten sind (in der Regel 2–7 Tage, zulässiger Zeitraum: 1 bis 30 Tage). Geben Sie dieses Zeitfenster in Sekunden an.
• Geben Sie beim Registrieren einer Attributionsquelle ein Zeitfenster für die Exklusivität der Attribution nach der Installation an, in dem alle Triggerereignisse nach der Installation mit der Attributionsquelle verknüpft werden sollen, die die Installation ausgelöst hat (in der Regel 7 bis 30 Tage, zulässiger Zeitraum: 0 bis 30 Tage). Geben Sie dieses Zeitfenster in Sekunden an.
• Die Attribution Reporting API prüft, wann eine App-Installation erfolgt, und ordnet die Installation intern der Attributionsquelle mit der Zugriffsquellen zu. Die Installation wird jedoch nicht an Anzeigentechnologie-Anbieter gesendet und wird nicht auf die entsprechenden Ratenbegrenzungen der Plattformen angerechnet.
• Die Validierung von App-Installationen ist für jede heruntergeladene App verfügbar.
• Alle zukünftigen Trigger, die innerhalb des Attributionszeitraums nach der Installation auftreten, werden derselben Attributionsquelle wie die validierte Installation zugeordnet, sofern diese Attributionsquelle zulässig ist.

Zukünftig möchten wir das Design erweitern, um erweiterte Attributionsmodelle zu unterstützen.

Die folgende Tabelle zeigt ein Beispiel dafür, wie Anzeigentechnologien die Attribution nach der Installation verwenden können. Angenommen, alle Attributionsquellen und Trigger werden vom selben AdTech-Netzwerk registriert und alle Prioritäten sind gleich.

Veranstaltung	Tag, an dem das Ereignis stattfindet	Hinweise
Klick 1	1	install_attribution_window ist auf 172800 (2 Tage) und post_install_exclusivity_window auf 864000 (10 Tage) festgelegt
Verifizierte Installation	2	Die API ordnet verifizierte Installationen intern zu, sie werden aber nicht als Trigger betrachtet. Daher werden zu diesem Zeitpunkt keine Berichte gesendet.
Trigger 1 (Erstes Öffnen)	2	Erster von der Anzeigentechnologie registrierter Trigger. In diesem Beispiel stellt er ein erstes Öffnen dar, kann aber ein beliebiger Triggertyp sein. Zu Klick 1 zugeordnet (entspricht der Attribution der bestätigten Installation).
Klick 2	4	Verwendet dieselben Werte für install_attribution_window und post_install_exclusivity_window wie für Klick 1
Trigger 2 (nach der Installation)	5	Zweiter, von der Anzeigentechnologie registrierter Trigger. In diesem Beispiel steht er für eine Conversion nach der Installation, z. B. einen Kauf. Zu Klick 1 zugeordnet (entspricht der Attribution der bestätigten Installation). Klick 2 wird verworfen und kann nicht mehr für die zukünftige Attribution verwendet werden.

Die folgende Liste enthält einige zusätzliche Hinweise zur Attribution nach der Installation:

• Wenn die verifizierte Installation nicht innerhalb der in install_attribution_window angegebenen Anzahl von Tagen erfolgt, wird die Attribution nach der Installation nicht angewendet.
• Bestätigte Installationen werden nicht von Anzeigentechnologie-Anbietern registriert und nicht in Berichten gesendet. Sie werden nicht auf die Ratenbegrenzungen von Anzeigentechnologien angerechnet. Bestätigte Installationen werden nur verwendet, um die Attributionsquelle zu ermitteln, der die Installation zugeschrieben wird.
• Im Beispiel aus der vorherigen Tabelle stellen Trigger 1 und Trigger 2 eine Conversion nach dem ersten Öffnen bzw. eine Conversion nach der Installation dar. AdTech-Plattformen können jedoch jede Art von Trigger registrieren. Mit anderen Worten, der erste Trigger muss kein erster geöffneter Trigger sein.
• Wenn nach Ablauf von post_install_exclusivity_window weitere Trigger registriert werden, kommt Klick 1 weiterhin für die Attribution infrage, sofern er nicht abgelaufen ist und die Ratenbegrenzungen nicht erreicht hat.
  • Klick 1 kann trotzdem verloren gehen oder verworfen werden, wenn eine Attributionsquelle mit höherer Priorität registriert wird.
• Wenn die Werbetreibenden-App deinstalliert und neu installiert wird, wird diese Neuinstallation als neue bestätigte Installation gezählt.
• Wenn Klick 1 stattdessen ein Aufrufereignis war, werden sowohl der „erstes Öffnen“ als auch der Trigger nach der Installation diesem Ereignis zugeordnet. Die API beschränkt die Attribution auf einen Trigger pro Aufruf, es sei denn, bei der Attribution nach der Installation sind bis zu zwei Trigger pro Aufruf zulässig. Im Fall der Attribution nach der Installation kann der Anzeigentechnologie-Anbieter zwei verschiedene Berichtszeiträume erhalten (2 Tage oder nach Ablauf der Quelle).

Alle Kombinationen von app- und webbasierten Triggerpfaden werden unterstützt

Mit der Attribution Reporting API können die folgenden Triggerpfade auf einem einzelnen Android-Gerät zugeordnet werden:

• App-to-app::Der Nutzer sieht eine Anzeige in einer App und führt dann entweder in dieser App oder in einer anderen installierten App eine Conversion aus.
• App-to-web::Der Nutzer sieht eine Anzeige in einer App und führt dann in einem mobilen Browser oder in einem App-Browser eine Conversion aus.
• Web-to-app::Der Nutzer sieht eine Anzeige in einem mobilen Browser oder im Browser einer App und führt dann eine Conversion in einer App aus.
• Web-to-web::Der Nutzer sieht eine Anzeige in einem mobilen Browser oder in einem App-Browser und führt dann entweder im selben Browser oder in einem anderen Browser auf demselben Gerät eine Conversion aus.

Wir erlauben Webbrowsern, neue Funktionen zu unterstützen, die über das Web bereitgestellt werden. Dazu gehören Funktionen, die der Attribution Reporting API von Privacy Sandbox für das Web ähneln. Diese kann die Android APIs aufrufen, um die Attribution in App und Web zu ermöglichen.

Informieren Sie sich über die Änderungen, die Anzeigentechnologien und Apps vornehmen müssen, um Trigger-Pfade für App- und Webmessungen zu unterstützen.

Mehrere Trigger für eine Attributionsquelle priorisieren

Eine Attributionsquelle kann zu mehreren Triggern führen. Zum Beispiel könnte ein Kaufvorgang einen „App-Installation“-Trigger, einen oder mehrere „In den Einkaufswagen“-Trigger und einen „Kaufen“-Trigger umfassen. Jeder Trigger wird einer oder mehreren Attributionsquellen gemäß dem quellpriorisierten Attributionsalgorithmus zugeordnet, der weiter unten auf dieser Seite beschrieben wird.

Es gibt Beschränkungen dafür, wie viele Trigger einer einzelnen Attributionsquelle zugeordnet werden können. Weitere Informationen finden Sie weiter unten auf dieser Seite im Abschnitt Messdaten in Attributionsberichten aufrufen. In Fällen, in denen es mehrere Trigger jenseits dieser Limits gibt, ist es nützlich, eine Priorisierungslogik einzuführen, um die wertvollsten Trigger zurückzugeben. Beispielsweise möchten die Entwickler einer Werbetechnologie möglicherweise „Kauf“-Trigger gegenüber „In den Einkaufswagen“-Triggern priorisieren.

Zur Unterstützung dieser Logik kann ein separates Prioritätsfeld für den Trigger festgelegt werden. Die Trigger mit der höchsten Priorität werden innerhalb eines bestimmten Berichtsfensters ausgewählt, bevor Limits angewendet werden.

Hinweis: Bereits gemeldete Trigger mit niedrigerer Priorität verbrauchen immer das Budget.

Zulassen, dass mehrere Anzeigentechnologien Attributionsquellen oder Trigger registrieren

Es ist üblich, dass mehr als eine Anzeigentechnologie Attributionsberichte erhält. In der Regel erfolgt die Deduplizierung netzwerkübergreifend. Daher können mehrere Anzeigentechnologien über die API dieselbe Attributionsquelle oder denselben Trigger registrieren. Ein Anzeigentechnologie-Anbieter muss sowohl Attributionsquellen als auch Trigger registrieren, um Postbacks von der API zu erhalten. Die Attribution erfolgt unter den Attributionsquellen und löst aus, dass sich der Anzeigentechnologie-Anbieter bei der API registriert hat.

Werbetreibende, die die netzwerkübergreifende Deduplizierung mit einem Drittanbieter vornehmen möchten, können dies auch weiterhin mit einem Verfahren wie dem folgenden tun:

• Einen internen Server einrichten, um sich zu registrieren und Berichte von der API zu erhalten
• Sie nutzen weiterhin einen bestehenden Partner für mobile Messungen.

Attributionsquellen

Weiterleitungen über Attributionsquellen werden in der registerSource()-Methode unterstützt:

1. Die Anzeigentechnologie, mit der die Methode registerSource() aufgerufen wird, kann in der Antwort ein zusätzliches Attribution-Reporting-Redirect-Feld angeben, das die Weiterleitungs-URLs von Partner-Anzeigentechnologien darstellt.
2. Die API ruft dann die Weiterleitungs-URLs auf, damit die Attributionsquelle von den Anzeigentechnologie-Partnern registriert werden kann.

Im Feld Attribution-Reporting-Redirect können mehrere URLs von Partner-AdTech-Unternehmen aufgeführt werden und AdTech-Partner können kein eigenes Attribution-Reporting-Redirect-Feld angeben.

Außerdem ermöglicht die API, dass verschiedene Anzeigentechnologien registerSource() aufrufen können.

Trigger

Für die Trigger-Registrierung werden Drittanbieter auf ähnliche Weise unterstützt: Anzeigentechnologie-Anbieter können entweder das zusätzliche Feld Attribution-Reporting-Redirect verwenden oder beide die Methode registerTrigger() aufrufen.

Wenn ein Werbetreibender mehrere Anzeigentechnologien verwendet, um dasselbe Triggerereignis zu registrieren, sollte ein Deduplizierungsschlüssel verwendet werden. Mit dem Deduplizierungsschlüssel lassen sich diese wiederholten Berichte zu demselben Ereignis, das von derselben Anzeigentechnologie-Plattform registriert wurde, eindeutig unterscheiden. Beispielsweise könnte ein Anzeigentechnologie-Anbieter von seinem SDK die API direkt aufrufen, um einen Trigger zu registrieren und die URL des Anrufs eines anderen Anzeigentechnologie-Anbieters in das Weiterleitungsfeld aufzunehmen. Wenn kein Deduplizierungsschlüssel angegeben ist, werden doppelte Trigger möglicherweise als eindeutig an die einzelnen Anzeigentechnologien zurückgemeldet.

Umgang mit doppelten Triggern

Ein Anzeigentechnologie-Anbieter kann denselben Trigger mehrmals mit der API registrieren. Szenarien umfassen:

• Der Nutzer führt dieselbe Aktion (Trigger) mehrmals aus. Beispielsweise kann der Nutzer dasselbe Produkt im selben Berichtfenster mehrmals ansehen.
• Die Werbetreibenden-App verwendet mehrere SDKs für die Conversion-Analyse, die alle an dieselbe Anzeigentechnologie weiterleiten. Die Werbetreibenden-App verwendet beispielsweise zwei Analysepartner: MMP Nr. 1 und MMP Nr. 2. Beide MMPs leiten zur Anzeigentechnologie Nr. 3 weiter. Wenn ein Trigger eintritt, wird er von beiden MMPs in der Attribution Reporting API registriert. AdTech 3 erhält dann für denselben Trigger zwei separate Weiterleitungen – eine von MMP 1 und eine von MMP 2.

In diesen Fällen gibt es mehrere Möglichkeiten, Berichte auf Ereignisebene bei doppelten Triggern zu unterdrücken, um die Wahrscheinlichkeit zu verringern, dass die Ratenbegrenzungen für Berichte auf Ereignisebene überschritten werden. Wir empfehlen die Verwendung eines Deduplizierungsschlüssels.

Empfohlene Methode: Deduplizierungsschlüssel

Es wird empfohlen, dass die App des Werbetreibenden einen eindeutigen Deduplizierungsschlüssel an alle Anzeigentechnologien oder SDKs übergibt, die für die Conversion-Messung verwendet werden. Bei einer Conversion übergibt die App einen Deduplizierungsschlüssel an die Anzeigentechnologien oder SDKs. Diese Anzeigentechnologien oder SDKs leiten dann den Deduplizierungsschlüssel weiter an die Weiterleitungen weiter. Dazu wird ein Parameter in den in Attribution-Reporting-Redirect angegebenen URLs verwendet.

Anzeigentechnologie-Anbieter können wählen, ob nur der erste Trigger mit einem bestimmten Deduplizierungsschlüssel oder mehrere oder alle Trigger registriert werden soll. AdTech-Mitarbeiter können die deduplication_key angeben, wenn sie doppelte Trigger registrieren.

Wenn eine AdTech mehrere Trigger mit demselben Deduplizierungsschlüssel und derselben zugeordneten Quelle registriert, wird in den Berichten auf Ereignisebene nur der erste registrierte Trigger gesendet. Doppelte Trigger werden weiterhin in verschlüsselten aggregierten Berichten gesendet.

Alternative Methode: Anzeigentechnologie-Anbieter einigen sich auf die Triggertypen pro Werbetreibendem.

In Situationen, in denen Anzeigentechnologie-Anbieter den Deduplizierungsschlüssel nicht verwenden möchten oder die App des Werbetreibenden keinen Deduplizierungsschlüssel weitergeben kann, gibt es eine alternative Option. Alle Anzeigentechnologien, die Conversions für einen bestimmten Werbetreibenden messen, müssen zusammenarbeiten, um verschiedene Triggertypen für jeden Werbetreibenden zu definieren.

Anzeigentechnologien, die den Registrierungsaufruf auslösen, z. B. SDKs, enthalten einen Parameter in URLs, die in Attribution-Reporting-Redirect angegeben sind, z. B. duplicate_trigger_id. Der duplicate_trigger_id-Parameter kann Informationen wie den SDK-Namen und den Triggertyp des Werbetreibenden enthalten. AdTech-Teams können dann einen Teil dieser doppelten Trigger an Berichte auf Ereignisebene senden. Anzeigentechnologien können diese duplicate_trigger_id auch in ihre Aggregationsschlüssel aufnehmen.

Beispiel für netzwerkübergreifende Attribution

In dem in diesem Abschnitt beschriebenen Beispiel verwendet der Werbetreibende zwei AdTech-Plattformen (AdTech A und AdTech B) und einen Partner für Messungen.

Zuerst müssen AdTech A, AdTech B und MMP jedes Mal registriert werden, um die Attribution Reporting API verwenden zu können. Weitere Informationen finden Sie unter Für ein Privacy Sandbox-Konto registrieren.

In der folgenden Liste sind hypothetische Nutzeraktionen aufgeführt, die jeweils im Abstand von einem Tag stattfinden. Außerdem wird erläutert, wie die Attribution Reporting API diese Aktionen in Bezug auf AdTech A, AdTech B und MMP verarbeitet:

Tag 1: Der Nutzer klickt auf eine von AdTech A geschaltete Anzeige.

AdTech A ruft registerSource() mit der entsprechenden URI auf. Die API stellt eine Anfrage an den URI und der Klick wird mit den Metadaten aus der Serverantwort von AdTech A registriert.

AdTech A enthält außerdem den MMP-URI im Header Attribution-Reporting-Redirect. Die API stellt eine Anfrage an den URI des MMP und der Klick wird mit den Metadaten aus der Serverantwort der MMP registriert.

Tag 2: Der Nutzer klickt auf eine von Anzeigentechnologie B geschaltete Anzeige.

AdTech B ruft registerSource() mit der entsprechenden URI auf. Die API stellt eine Anfrage an den URI und der Klick wird mit den Metadaten aus der Serverantwort von AdTech B registriert.

Wie bei Anzeigentechnologie A enthält auch Anzeigentechnologie B den MMP-URI in den Attribution-Reporting-Redirect-Header. Die API stellt eine Anfrage an den URI des MMP und der Klick wird mit den Metadaten aus der Antwort des MMP-Servers registriert.

Tag 3: Der Nutzer sieht eine von Anzeigentechnologie A ausgelieferte Anzeige

Die API reagiert genauso wie an Tag 1, mit der Ausnahme, dass eine Ansicht für AdTech A und MMP registriert ist.

Tag 4: Der Nutzer installiert die App und verwendet für die Conversion-Analyse die MMP.

MMP ruft registerTrigger() mit dem zugehörigen URI auf. Die API stellt eine Anfrage an die URL und die Konvertierung wird mit den Metadaten aus der Serverantwort der MMP registriert.

Die MMP fügt außerdem die URIs für AdTech A und AdTech B in den Attribution-Reporting-Redirect-Header ein. Die API sendet Anfragen an die Server von AdTech A und AdTech B. Die Conversion wird entsprechend mit den Metadaten aus den Serverantworten registriert.

Das folgende Diagramm veranschaulicht den in der vorstehenden Liste beschriebenen Prozess:

Beispiel dafür, wie die Attribution Reporting API auf eine Reihe von Nutzeraktionen reagiert

Funktionsweise der Attribution:

• Mit AdTech A wird die Priorität von Klicks höher als die von Aufrufen festgelegt. Daher wird die Installation dem Klick an Tag 1 zugeordnet.
• AdTech B erhält die an Tag 2 zugeordnete Installation.
• Bei MMP wird die Priorität von Klicks höher als die von Aufrufen festgelegt und die Installation wird dem Klick an Tag 2 zugeordnet. Der Klick an Tag 2 hat die höchste Priorität, das letzte Anzeigenereignis.

Netzwerkübergreifende Attribution ohne Weiterleitungen

Wir empfehlen zwar die Verwendung von Weiterleitungen, damit mehrere Anzeigentechnologien Attributionsquellen und Trigger nutzen können. Uns ist jedoch bewusst, dass in bestimmten Fällen keine Weiterleitungen möglich sind. In diesem Abschnitt wird beschrieben, wie Sie die netzwerkübergreifende Attribution ohne Weiterleitungen unterstützen.

Allgemeiner Fluss

1. Bei der Registrierung der Quelle gibt das ausliefernde AdTech-Netzwerk seine Quellenaggregationsschlüssel weiter.
2. Bei der Trigger-Registrierung wählt der Werbetreibende oder Partner für die Messung aus, welche quellseitigen Schlüsselelemente verwendet werden sollen, und legt die Attributionskonfiguration fest.
3. Die Attribution basiert auf der Attributionskonfiguration, den freigegebenen Schlüsseln und allen Quellen, die von diesem Werbetreibenden oder Analysepartner tatsächlich registriert wurden (z.B. aus einem anderen ausliefernden AdTech-Netzwerk, für das Weiterleitungen aktiviert sind).
4. Wenn der Trigger einer Quelle einer Anzeigentechnologie ohne Weiterleitung zugeordnet wird, kann der Werbetreibende oder Partner für die Messung einen aggregierten Bericht erhalten, in dem die in Schritt 2 definierten Schlüsselelemente aus Quelle und Trigger kombiniert sind.

Quellenregistrierung

Bei der Registrierung der Quelle kann das bereitstellende AdTech-Netzwerk auswählen, dass es seine Quellaggregationsschlüssel oder eine Teilmenge seiner Quellaggregationsschlüssel freigeben, anstatt eine Weiterleitung vorzunehmen. Die Anzeigentechnologie-Anbieter müssen diese Quellenschlüssel nicht in ihren eigenen aggregierten Berichten verwenden und können sie bei Bedarf nur im Namen des Werbetreibenden oder Partners deklarieren.

Gemeinsame Aggregationsschlüssel sind für jede Anzeigentechnologie verfügbar, die einen Trigger für denselben Werbetreibenden registriert. Es liegt jedoch an der AdTech- und der Trigger-Messung, die gemeinsam erarbeitet, welche Arten von Aggregationsschlüsseln erforderlich sind, welche Namen sie haben und wie die Schlüssel in lesbare Dimensionen decodiert werden können.

Registrierung auslösen

Bei der Trigger-Registrierung wählt die Anzeigentechnologie für Messungen aus, welche quellenseitigen Schlüsselelemente auf die einzelnen Triggerschlüsselelemente angewendet werden sollen, einschließlich aller von der Bereitstellung von Anzeigentechnologien gemeinsam genutzten Schlüsselelemente.

Darüber hinaus muss die Anzeigentechnologie-Anbieter die abfolgebasierte Attributionslogik mithilfe eines neuen API-Aufrufs für die Attributionskonfiguration angeben. In dieser Konfiguration kann der AdTech-Anbieter die Priorität und das Ablaufdatum der Quelle sowie Filter für Quellen angeben, für die er keinen Einblick hatte (z. B. Quellen, für die keine Weiterleitung verwendet wurde).

Attribution

Die Attribution Reporting API führt für die Anzeigentechnologie für Messungen anhand der Attributionskonfiguration, der freigegebenen Schlüssel und aller registrierten Quellen eine nach der Quelle priorisierte Attribution der letzten Interaktion für die Anzeigentechnologie durch. Beispiel:

• Der Nutzer hat auf Anzeigen der Anzeigentechnologien A, B, C und D geklickt. Der Nutzer hat dann die App des Werbetreibenden installiert, die einen Technologiepartner für Messungen (Measurement Ad Tech Partner, MMP) verwendet.
• AdTech A leitet seine Quellen an den MMP weiter.
• Die AdTech-Teams B und C leiten nicht weiter, sondern teilen ihre Aggregationsschlüssel.
• AdTech D leitet keine Aggregationsschlüssel weiter und teilt sie auch nicht.

Der MMP registriert eine Quelle von AdTech A und definiert eine Attributionskonfiguration, die AdTech B und AdTech D umfasst.

Die Attribution für die MMP umfasst jetzt Folgendes:

• AdTech A, da der MMP eine Quelle aus der Weiterleitung dieser Anzeigentechnologie registriert hat
• AdTech B, da von AdTech B Schlüssel freigegeben und der MMP sie in die Attributionskonfiguration eingebunden hat.

Die Attribution für die MMP umfasst Folgendes nicht:

• AdTech C, da der MMP sie nicht in die Attributionskonfiguration aufgenommen hat
• AdTech D, da keine Weiterleitung durchgeführt oder Aggregationsschlüssel nicht geteilt wurden.

Hinweis :Weitere Informationen zur Implementierung dieses Designs finden Sie im Entwicklerleitfaden für die Attribution Reporting API.

Debugging

Anzeigentechnologien können bei der Registrierung der Quelle das zusätzliche Feld shared_debug_key festlegen, um das Debugging für die netzwerkübergreifende Attribution ohne Weiterleitungen zu unterstützen. Wenn die Richtlinie bei der ursprünglichen Registrierung der Quelle festgelegt ist, wird sie bei der Trigger-Registrierung für die netzwerkübergreifende Attribution ohne Weiterleitungen auch für die entsprechende abgeleitete Quelle als debug_key festgelegt. Dieser Schlüssel zur Fehlerbehebung wird in Ereignisberichten und zusammengefassten Berichten als source_debug_key angehängt.

Diese Debug-Funktion wird nur in den folgenden Szenarien für die netzwerkübergreifende Attribution ohne Weiterleitungen unterstützt:

• App-zu-App-Messung, bei der die Anzeigen-ID zulässig ist
• App-zu-Web-Messung, bei der die Anzeigen-ID zulässig ist und sowohl über die App-Quelle als auch über den Web-Trigger abgeglichen wird
• Web-zu-Web-Messung (in derselben Browser-App), wenn ar_debug sowohl in der Quelle als auch im Trigger vorhanden ist

Schlüsselerkennung für netzwerkübergreifende Attribution ohne Weiterleitungen

Die Schlüsselerkennung dient dazu, die Implementierung der Attributionskonfiguration für Anzeigentechnologien (in der Regel MMPs) für die netzwerkübergreifende Attribution zu optimieren, wenn ein oder mehrere bereitstellende Anzeigentechnologien gemeinsame Aggregationsschlüssel verwenden (wie oben unter Netzwerkübergreifende Attribution ohne Weiterleitungen beschrieben).

Wenn ein MMP den Aggregationsdienst abfragt, um zusammenfassende Berichte für Kampagnen zu generieren, die abgeleitete Quellen enthalten, muss der MMP die Liste möglicher Schlüssel als Eingabe für den Aggregationsjob angeben. In einigen Fällen kann die Liste der potenziellen Quellaggregationsschlüssel sehr groß oder unbekannt sein. Große Listen möglicher Schlüssel sind nur schwer nachzuverfolgen und außerdem recht komplex und kostspielig in ihrer Verarbeitung. Hier einige Beispiele:

• Die Liste aller möglichen Schlüssel ist lang:
  • Ein auslieferndes Werbenetzwerk führt eine komplexe Initiative zur Nutzergewinnung aus, die 20 Kampagnen mit jeweils 10 Anzeigengruppen und jede Anzeigengruppe mit 5 Creatives umfasst, die jede Woche basierend auf der Leistung aktualisiert werden.
• Die Liste aller möglichen Schlüssel ist unbekannt:
  • Über ein Werbenetzwerk, in dem Anzeigen ausgeliefert werden, werden Anzeigen in vielen mobilen Apps ausgeliefert, bei denen beim Start der Kampagne nicht die vollständige Liste der Publisher-App-IDs bekannt ist.
  • Ein Werbetreibender arbeitet mit mehreren ausliefernden Werbenetzwerken zusammen, die bei der Quellregistrierung keine Weiterleitung an die MMP durchführen. Jedes ausliefernde Werbenetzwerk hat eine andere Schlüsselstruktur und andere Werte, die möglicherweise nicht im Voraus an die MMP weitergegeben werden.

Mit Einführung der Schlüsselerkennung:

• Für den Aggregationsdienst ist keine vollständige Aufzählung möglicher Aggregationsschlüssel mehr erforderlich.
• Anstatt die vollständige Liste der möglichen Schlüssel angeben zu müssen, kann eine MMP einen leeren (oder teilweise leeren) Satz von Schlüsseln erstellen und einen Schwellenwert festlegen, sodass nur (nicht vorab deklarierte) Schlüssel mit Werten, die den Schwellenwert überschreiten, in die Ausgabe aufgenommen werden.
• MMP erhält einen zusammenfassenden Bericht, der Rauschwerte für Schlüssel enthält, die Werte über dem festgelegten Grenzwert beitragen. Der Bericht kann auch Schlüssel enthalten, denen keine echten Nutzerbeiträge zugeordnet sind und die nur verrauscht sind.
• MMP bestimmt anhand des Felds x_network_bit_mapping bei der Triggerregistrierung, welche Anzeigentechnologie welchem Schlüssel entspricht.
• MMP kann sich dann an die entsprechende AdTech wenden, um die Werte im Quellschlüssel zu ermitteln.

Zusammenfassend lässt sich sagen, dass MMPs durch die Schlüsselerkennung Aggregationsschlüssel abrufen können, ohne sie im Voraus zu kennen, und die Verarbeitung großer Mengen von Quellschlüsseln auf Kosten von zusätzlichem Rauschen vermeiden.

Hinweis :Diese Funktion befindet sich in der Angebotsphase und ist noch nicht für Tests verfügbar. Wir freuen uns über Ihr Feedback und Ihre Kommentare.

Messdaten in Attributionsberichten aufrufen

Mit der Attribution Reporting API werden die folgenden Berichtstypen aktiviert, die weiter unten auf dieser Seite ausführlicher beschrieben werden:

• Berichte auf Ereignisebene verknüpfen eine bestimmte Attributionsquelle (Klick oder Aufruf) mit einer begrenzten Anzahl an High-Fidelity-Triggerdaten.
• Zusammengefasste Berichte sind nicht unbedingt an eine bestimmte Attributionsquelle gebunden. Diese Berichte bieten umfangreichere und aussagekräftigere Triggerdaten als Berichte auf Ereignisebene. Sie sind jedoch nur in zusammengefasster Form verfügbar.

Diese beiden Berichtstypen ergänzen sich und können gleichzeitig verwendet werden.

Berichte auf Ereignisebene

Nachdem ein Trigger einer Attributionsquelle zugeordnet wurde, wird ein Bericht auf Ereignisebene generiert und auf dem Gerät gespeichert, bis er während eines der Zeiträume zum Senden von Berichten an die Postback-URL der einzelnen Anzeigentechnologien zurückgesendet werden kann. Diese werden weiter unten auf dieser Seite ausführlicher beschrieben.

Berichte auf Ereignisebene sind nützlich, wenn nur sehr wenige Informationen zum Trigger benötigt werden. Triggerdaten auf Ereignisebene sind auf 3 Bit für Triggerdaten für Klicks beschränkt. Ein Trigger kann also einer von acht Kategorien zugewiesen werden. Für Datenansichten darf 1 Bit angegeben werden. Darüber hinaus wird in Berichten auf Ereignisebene keine Codierung von High-Fidelity-Daten auf Triggerseite unterstützt, z. B. von einem bestimmten Preis oder einer bestimmten Triggerzeit. Da die Attribution auf dem Gerät erfolgt, werden geräteübergreifende Analysen in Berichten auf Ereignisebene nicht unterstützt.

Der Bericht auf Ereignisebene enthält folgende Daten:

• Ziel:Name des App-Pakets des Werbetreibenden oder eTLD+1, wo der Trigger ausgelöst wurde
• Attributionsquellen-ID:Dies ist die ID der Attributionsquelle, die für die Registrierung einer Attributionsquelle verwendet wurde.
• Triggertyp:1 oder 3 Bit Low-Fidelity-Triggerdaten, je nach Art der Attributionsquelle

Mechanismen zur Einhaltung des Datenschutzes, die auf alle Berichte angewendet werden

Die folgenden Limits werden angewendet, nachdem Prioritäten in Bezug auf Attributionsquellen und Trigger berücksichtigt wurden.

Maximale Anzahl von Anzeigentechnologien

Die Anzahl der Anzeigentechnologien, die Berichte von der API registrieren oder von ihr empfangen können, ist begrenzt. Derzeit wird Folgendes vorgeschlagen:

• 100 Anzeigentechnologien mit Attributionsquellen pro {Quell-App, Ziel-App, 30 Tage, Gerät}
• 10 Anzeigentechnologien mit zugeordneten Triggern pro {Quell-App, Ziel-App, 30 Tage, Gerät}
• 20 Anzeigentechnologie-Anbieter können eine einzige Attributionsquelle oder einen einzigen Trigger über Attribution-Reporting-Redirect registrieren

Maximale Anzahl eindeutiger Ziele

Diese Limits erschweren es für eine Reihe von Anzeigentechnologien, sich zu widersprechen, da eine große Anzahl von Apps abgefragt wird, um das App-Nutzungsverhalten eines bestimmten Nutzers zu verstehen.

• Die API unterstützt über alle registrierten Quellen und Anzeigentechnologien hinweg maximal 200 eindeutige Ziele pro Quell-App und Minute.
• Von allen registrierten Quellen aus unterstützt die API für eine einzelne Anzeigentechnologie maximal 50 eindeutige Ziele pro Quell-App und Minute. Dadurch wird verhindert, dass eine Anzeigentechnologie das gesamte Budget der zuvor genannten Ratenbegrenzung aufbraucht.

Abgelaufene Quellen werden nicht auf die Ratenbegrenzungen angerechnet.

Ein Berichtsursprung pro Quell-App und Tag

Eine AdTech-Plattform darf nur einen Berichtsursprung verwenden, um Quellen in einer Publisher-App für ein bestimmtes Gerät am selben Tag zu registrieren. Diese Ratenbegrenzung verhindert, dass Anzeigentechnologie-Anbieter mehrere Quellen für die Berichterstellung verwenden, um Zugriff auf zusätzliches Datenschutzbudget zu erhalten.

Stellen wir uns das folgende Szenario vor, in dem ein einzelner Anzeigentechnologie-Anbieter mehrere Berichtsquellen verwenden möchte, um Quellen in einer Publisher-App für ein einzelnes Gerät zu registrieren.

1. Der Berichtsursprung 1 von AdTech A registriert eine Quelle in App B
2. 12 Stunden später versucht der Berichtsursprung 2 der Anzeigentechnologie A, eine Quelle in App B zu registrieren.

Die zweite Quelle für den Berichtsursprung 2 von AdTech A wird von der API abgelehnt. Der Berichtsursprung 2 von AdTech A kann erst am nächsten Tag eine Quelle auf demselben Gerät in App B registrieren.

Cooldown und Ratenbegrenzungen

Die API drosselt die Gesamtmenge der Informationen, die in einem bestimmten Zeitraum für einen Nutzer gesendet werden, um das Ausmaß an Identitätslecks zwischen einem {source, destination}-Paar zu begrenzen.

Der aktuelle Vorschlag sieht vor, jede Anzeigentechnologie auf 100 zugeordnete Trigger pro {Quell-App, Ziel-App, 30 Tage, Gerät} zu beschränken.

Anzahl der eindeutigen Ziele

Die API begrenzt die Anzahl der Ziele, die eine Anzeigentechnologie messen kann. Je niedriger der Grenzwert, desto schwieriger wird es für einen Anzeigentechnologie-Anbieter, mit der API die Browseraktivitäten von Nutzern zu messen, die nicht mit eingeblendeten Werbung in Verbindung stehen.

Der aktuelle Vorschlag sieht vor, jede Anzeigentechnologie auf 100 verschiedene Ziele mit nicht abgelaufenen Quellen pro Quell-App zu beschränken.

Mechanismen zur Einhaltung des Datenschutzes für Berichte auf Ereignisebene

Eingeschränkte Genauigkeit der Triggerdaten

Die API bietet 1 Bit für View-through-Trigger und 3 Bit für Klick-Trigger. Attributionsquellen unterstützen weiterhin die gesamten 64 Bit von Metadaten.

Sie sollten überlegen, ob und wie die in Triggern ausgedrückten Informationen reduziert werden können, damit sie mit der begrenzten Anzahl von Bits funktionieren, die in Berichten auf Ereignisebene verfügbar sind.

Framework für Differential Privacy Noise

Ein Ziel dieser API ist es, eine Messung auf Ereignisebene zu ermöglichen, um lokale Differential Privacy-Anforderungen zu erfüllen, indem k-zufällige Antworten verwendet werden, um eine verrauschte Ausgabe für jedes Quellereignis zu generieren.

Es gibt Rauschen, ob ein Ereignis in der Attributionsquelle wahrheitsgemäß gemeldet wird. Eine Attributionsquelle wird auf dem Gerät mit der Wahrscheinlichkeit $ 1-p $ registriert, dass die Attributionsquelle als normal registriert ist, und mit der Wahrscheinlichkeit $ p $, dass das Gerät nach dem Zufallsprinzip aus allen möglichen Ausgabezuständen der API auswählt (z. B. dass überhaupt keine Meldungen gemeldet oder mehrere gefälschte Berichte gemeldet werden).

Die k-zufällige Antwort ist ein Algorithmus, der Epsilon differenziell privat ist, wenn die folgende Gleichung erfüllt wird:

\[ p = \frac{k}{k + e^ε - 1} \]

Bei niedrigen Werten von e wird die tatsächliche Ausgabe durch den k-zufälligen Antwortmechanismus geschützt. Die genauen Rauschparameter befinden sich noch in der Entwicklung und können sich je nach Feedback im Rahmen eines aktuellen Vorschlags für Folgendes ändern:

• p=0,24% für Navigationsquellen
• p=0,00025% für Ereignisquellen

Limits für verfügbare Trigger (Conversions)

Die Anzahl der Trigger pro Attributionsquelle ist bei derzeitem Vorschlag für Folgendes begrenzt:

• 1–2 Trigger für Attributionsquellen für Anzeigenaufrufe (zwei Trigger sind nur im Fall der Attribution nach der Installation verfügbar)
• 3 Trigger für Attributionsquellen für Klickanzeigen

Hinweis :Hier wird das API-Standardverhalten für die Anzahl der Attributionen pro Quelle in Berichten auf Ereignisebene beschrieben. Mit der Einführung der flexiblen Berichte auf Ereignisebene im Oktober 2023 können Anzeigentechnologie-Anbieter diese Berichtsdimension jetzt so konfigurieren, dass sie für ihren Anwendungsfall am besten geeignet ist.

Bestimmte Zeitfenster für das Senden von Berichten (Standardverhalten)

Berichte auf Ereignisebene für Attributionsquellen für Anzeigenaufrufe werden eine Stunde nach Ablauf der Quelle gesendet. Dieses Ablaufdatum kann konfiguriert werden, muss jedoch ein und drei Tage betragen. Wenn einer Attributionsquelle für Anzeigenaufrufe zwei Trigger zugeordnet werden (über Attribution nach der Installation), können Berichte auf Ereignisebene in den unten angegebenen Intervallen für Berichtszeiträume gesendet werden.

Berichte auf Ereignisebene für Attributionsquellen für Anzeigenklicks können nicht konfiguriert werden. Sie werden vor oder nach Ablauf der Quelle zu bestimmten Zeitpunkten gesendet, bezogen auf den Zeitpunkt, an dem die Quelle registriert wurde. Die Zeit zwischen Attributionsquelle und Ablauf wird in mehrere Berichtsfenster aufgeteilt. Für jedes Berichtsfenster gibt es eine Frist (ab der Zeit der Attributionsquelle). Am Ende jedes Berichtsfensters erfasst das Gerät alle Trigger, die seit dem vorherigen Berichtsfenster aufgetreten sind, und sendet einen geplanten Bericht. Die API unterstützt die folgenden Berichtszeiträume:

• 2 Tage:Das Gerät erfasst alle Trigger, die höchstens zwei Tage nach der Registrierung der Attributionsquelle aufgetreten sind. Der Bericht wird zwei Tage und eine Stunde nach der Registrierung der Attributionsquelle gesendet.
• 7 Tage:Das Gerät erfasst alle Trigger, die mehr als 2 Tage, aber nicht mehr als 7 Tage nach der Registrierung der Attributionsquelle aufgetreten sind. Der Bericht wird sieben Tage und eine Stunde nach der Registrierung der Attributionsquelle gesendet.
• Benutzerdefinierte Zeitspanne,die durch das Attribut „Ablauf“ einer Attributionsquelle definiert wird. Der Bericht wird 1 Stunde nach der angegebenen Ablaufzeit gesendet. Dieser Wert muss mindestens 1 Tag und nicht mehr als 30 Tage betragen.

Hinweis :Hier wird das API-Standardverhalten für Berichtsfenster auf Ereignisebene beschrieben. Mit der Einführung flexibler Berichte auf Ereignisebene im Oktober 2023 können Anzeigentechnologie-Anbieter diese Berichtsdimension jetzt so konfigurieren, dass sie für ihren Anwendungsfall am besten geeignet ist.

Flexible Konfiguration auf Ereignisebene

Die Standardkonfiguration für Berichte auf Ereignisebene wird von Anzeigentechnologie-Anbietern empfohlen, wenn sie mit Dienstprogrammtests beginnen. Sie ist jedoch möglicherweise nicht für alle Anwendungsfälle ideal. Die Attribution Reporting API unterstützt optionale und flexiblere Konfigurationen. Anzeigentechnologie-Anbieter haben damit mehr Kontrolle über die Struktur ihrer Berichte auf Ereignisebene und können die Daten optimal nutzen.

Diese zusätzliche Flexibilität wird in zwei Phasen in der Attribution Reporting API eingeführt:

• Phase 1: Flexible Lite-Konfiguration auf Ereignisebene
  • Diese Version bietet einen Teil der vollständigen Funktionen und kann unabhängig von Phase 2 verwendet werden.
• Phase 2: Vollständige Version der flexiblen Konfiguration auf Ereignisebene

Phase 1 (flexible Lite-Ereignisebene) könnte für Folgendes verwendet werden:

• Häufigkeit der Berichte durch Angabe der Anzahl der Berichtszeiträume variieren
• Anzahl der Zuordnungen je Quellenregistrierung variieren
• Reduzieren Sie die Menge des Gesamtrauschens, indem Sie die oben genannten Parameter verringern
• Berichtszeiträume konfigurieren, anstatt die Standardeinstellungen zu verwenden

Phase 2 (vollständige flexible Ereignisebene) könnte verwendet werden, um alle Funktionen in Phase 1 auszuführen und:

• Auslöserdatenkardinalität in einem Bericht variieren
• Reduzieren Sie das Gesamtrauschen, indem Sie die Triggerdatenkardinalität verringern

Wenn Sie eine Dimension der Standardkonfiguration reduzieren, kann die Anzeigentechnologie eine weitere Dimension erweitern. Alternativ kann das Rauschen in einem Bericht auf Ereignisebene durch eine Nettominderung der oben genannten Parameter reduziert werden.

Zusätzlich zur dynamischen Festlegung der Rauschpegel basierend auf der gewählten Konfiguration einer Anzeigentechnologie-Anbieterin gibt es einige Parameterlimits, um hohe Berechnungskosten und Konfigurationen mit zu vielen Ausgabezuständen zu vermeiden, bei denen das Rauschen stark zunimmt. Hier ist ein Beispiel für eine Gruppe von Einschränkungen. Feedback zu [Designvorschlag][50] ist willkommen:

• Maximal 20 Berichte, global und pro trigger_data
• Maximal fünf mögliche Berichtszeiträume pro „trigger_data“
• Maximal 32 Triggerdatenkardinalität (nicht zutreffend für Phase 1: flexible Ereignisebene: Lite)

Wenn AdTech-Unternehmen mit der Nutzung dieser Funktion beginnen, beachten Sie, dass die Verwendung von Extremwerten zu einer großen Menge an Rauschen führen kann. Unter Umständen werden auch keine Registrierungen vorgenommen, wenn die Datenschutzstufen nicht eingehalten werden.

Hinweis: Phase 1 (flexible Lite-Ereignisebene) wurde im Oktober 2023 als Betaversion veröffentlicht. Phase 2 (vollständige flexible Ereignisebene) wird später im 1. Quartal 2024 als Betaversion veröffentlicht.

Aggregierbare Berichte

Bevor Sie aggregierte Berichte verwenden können, müssen Sie Ihr Cloudkonto einrichten und zusammenfassende Berichte erhalten.

Aggregierbare Berichte liefern schneller hochwertigere Triggerdaten vom Gerät als Berichte auf Ereignisebene. Diese High-Fidelity-Daten können nur aggregiert erlernt werden und werden nicht mit einem bestimmten Trigger oder Nutzer verknüpft. Aggregationsschlüssel haben eine Länge von bis zu 128 Bit. Dies ermöglicht es, aggregierte Berichte für Berichtsanwendungsfälle wie die folgenden zu unterstützen:

• Berichte für Triggerwerte wie den Umsatz
• Mehr Triggertypen

Darüber hinaus verwenden aggregierte Berichte dieselbe quellenpriorisierte Attributionslogik wie Berichte auf Ereignisebene, unterstützen jedoch mehr Conversions, die einem Klick oder einer Ansicht zugeordnet werden können.

Die Attribution Reporting API erstellt und sendet zusammenfassende Berichte, die im Diagramm zu sehen sind, im Allgemeinen folgendermaßen:

1. Das Gerät sendet verschlüsselte aggregierte Berichte an die Anzeigentechnologie. In einer Produktionsumgebung können sie diese Berichte nicht direkt verwenden.
2. Das AdTech-Team sendet einen Batch zusammenfassender Berichte zur Aggregation an den Aggregationsdienst.
3. Der Aggregationsdienst liest einen Batch zusammenfassender Berichte, entschlüsselt sie und fasst sie zusammen.
4. Die endgültigen aggregierten Daten werden in einem zusammenfassenden Bericht an die Anzeigentechnologie zurückgesendet.

Prozess, mit dem die Attribution Reporting API aggregierte Berichte vorbereitet und sendet.

Aggregierbare Berichte enthalten die folgenden Daten zu Attributionsquellen:

• Ziel:Der Paketname der App oder die eTLD+1-Web-URL, unter der der Trigger ausgelöst wurde.
• Datum:Das Datum, an dem das durch die Attributionsquelle repräsentierte Ereignis aufgetreten ist.
• Nutzlast: Triggerwerte, die als verschlüsselte Schlüssel/Wert-Paare erfasst werden und im vertrauenswürdigen Aggregationsdienst zum Berechnen von Aggregationen verwendet werden.

Aggregationsdienste

Die folgenden Dienste bieten Aggregationsfunktionen und schützen vor unangemessenem Zugriff auf Aggregationsdaten.

Diese Dienste werden von verschiedenen Parteien verwaltet, die weiter unten auf dieser Seite ausführlicher beschrieben werden:

• Der Aggregationsdienst ist der einzige, der von Anzeigentechnologie-Anbietern bereitgestellt wird.
• Die Schlüsselverwaltung und die Buchhaltung für aggregierte Berichte werden von vertrauenswürdigen Seiten ausgeführt, die als Koordinatoren bezeichnet werden. Diese Koordinatoren bestätigen, dass der Code, der den Aggregationsdienst ausführt, der öffentlich verfügbare Code ist, der von Google bereitgestellt wird, und dass für alle Nutzer des Aggregationsdienstes der gleiche Schlüssel und die gleichen aggregierbaren Berichtsrechnungsdienste verwendet werden.

Aggregationsdienst

AdTech-Plattformen müssen im Voraus einen Aggregationsdienst bereitstellen, der auf den von Google bereitgestellten Binärprogrammen basiert.

Dieser Aggregationsdienst wird in einer in der Cloud gehosteten vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) ausgeführt. Ein T-Shirt bietet folgende Sicherheitsvorteile:

• Dadurch wird sichergestellt, dass der im TEE ausgeführte Code das von Google angebotene Binärprogramm ist. Sofern diese Bedingung nicht erfüllt ist, kann der Aggregationsdienst nicht auf die Entschlüsselungsschlüssel zugreifen, die er für seine Arbeit benötigt.
• Es bietet Sicherheit rund um den laufenden Prozess und isoliert ihn von externem Monitoring oder Manipulation.

Diese Sicherheitsvorteile machen es für einen Aggregationsdienst sicherer, vertrauliche Vorgänge wie den Zugriff auf verschlüsselte Daten auszuführen.

Weitere Informationen zum Design, zum Workflow und zu Sicherheitsaspekten des Aggregationsdienstes finden Sie im Dokument zum Aggregationsdienst auf GitHub.

Key Management Service

Dieser Dienst überprüft, ob ein Aggregationsdienst eine genehmigte Version des Binärprogramms ausführt, und stellt dann dem Aggregationsdienst in der Anzeigentechnologie die richtigen Entschlüsselungsschlüssel für die Triggerdaten zur Verfügung.

Aggregierbare Berichte – Berichte

Dieser Dienst erfasst, wie oft der Aggregationsdienst einer Anzeigentechnologie auf einen bestimmten Trigger zugreift, der mehrere Aggregationsschlüssel enthalten kann, und schränkt den Zugriff auf die entsprechende Anzahl von Entschlüsselungen ein. Weitere Informationen finden Sie im Designvorschlag Aggregation Service für die Attribution Reporting API.

Aggregatable Reports API

Die API zum Erstellen von Beiträgen zu aggregierten Berichten verwendet dieselbe Basis-API wie bei der Registrierung einer Attributionsquelle für Berichte auf Ereignisebene. In den folgenden Abschnitten werden die Erweiterungen der API beschrieben.

Aggregierbare Quelldaten registrieren

Wenn die API eine Anfrage an den URI der Attributionsquelle stellt, kann der AdTech-Mitarbeiter eine Liste von Aggregationsschlüsseln mit dem Namen histogram_contributions registrieren. Dazu wird ein neues Feld namens aggregation_keys im HTTP-Header Attribution-Reporting-Register-Source mit dem Schlüssel key_name und dem Wert key_piece zurückgegeben:

• (Schlüssel) Schlüsselname:Ein String für den Namen des Schlüssels. Wird als Join-Schlüssel verwendet, um ihn mit Schlüsseln auf Triggerseite zu kombinieren, um den endgültigen Schlüssel zu bilden.
• (Wert)-Schlüsselelement: Ein Bitstring-Wert für den Schlüssel.

Der endgültige Histogramm-Bucket-Schlüssel wird zum Zeitpunkt des Triggers vollständig definiert. Dazu wird für diese Teile und für die Teile des Triggers ein binärer ODER-Vorgang ausgeführt.

Endgültige Schlüssel sind auf maximal 128 Bit beschränkt. Längere Schlüssel werden abgeschnitten. Das bedeutet, dass Hex-Strings im JSON-Format auf maximal 32 Ziffern begrenzt sein sollten.

Weitere Informationen zur Struktur von Aggregationsschlüsseln und ihrer Konfiguration

Im folgenden Beispiel erfasst ein Anzeigentechnologie-Anbieter die API, um folgende Daten zu erfassen:

• Conversion-Anzahl auf Kampagnenebene aggregieren
• Kaufwerte auf geografischer Ebene zusammenfassen

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

Aggregierbaren Trigger registrieren

Die Trigger-Registrierung umfasst zwei zusätzliche Felder.

Mit dem ersten Feld wird eine Liste von aggregierten Schlüsseln auf der Triggerseite registriert. Der AdTech-Mitarbeiter sollte mit dem Feld aggregatable_trigger_data im HTTP-Header Attribution-Reporting-Register-Trigger mit den folgenden Feldern für jeden aggregierten Schlüssel in der Liste antworten:

• Schlüsselelement:Ein Bitstring-Wert für den Schlüssel.
• Quellschlüssel: Eine Liste von Strings mit den Namen der Seitenschlüssel der Attributionsquelle, mit denen der Triggerschlüssel kombiniert werden soll, um die endgültigen Schlüssel zu bilden.

Mit dem zweiten Feld wird eine Liste von Werten registriert, die zu jedem Schlüssel beitragen sollen. Der AdTech-Mitarbeiter sollte mit dem Feld aggregatable_values im HTTP-Header Attribution-Reporting-Register-Trigger antworten. Das zweite Feld wird verwendet, um eine Liste von Werten zu registrieren, die zu jedem Schlüssel beitragen sollen. Dabei kann es sich um Ganzzahlen im Bereich $ [1, 2^{16}] $ handeln.

Jeder Trigger kann mehrere Informationen zu den zusammengefassten Berichten liefern. Die Gesamtzahl der Beiträge zu einem bestimmten Quellereignis ist an einen $-L1-$-Parameter gebunden, der die maximale Summe von Beiträgen (Werten) für alle aggregierten Schlüssel für eine bestimmte Quelle ist. „$ L1 $“ bezieht sich auf die L1-Empfindlichkeit oder Norm der Histogrammbeiträge pro Quellereignis. Das Überschreiten dieser Limits führt dazu, dass künftige Beiträge ohne Meldung verworfen werden. Im ersten Vorschlag wird $ L1 $ auf 2^{16} $ (65536) festgelegt.

Das Rauschen im Aggregationsdienst wird proportional zu diesem Parameter skaliert. Daher wird empfohlen, die für einen bestimmten Aggregatschlüssel gemeldeten Werte entsprechend zu skalieren, basierend auf dem zugewiesenen Anteil des L1-$-Budgets von $ 1. Auf diese Weise wird dafür gesorgt, dass die aggregierten Berichte bei verrauschten Daten die höchstmögliche Genauigkeit erhalten. Dieser Mechanismus ist äußerst flexibel und kann viele Aggregationsstrategien unterstützen.

Im folgenden Beispiel wird das Datenschutzbudget gleichmäßig zwischen campaignCounts und geoValue aufgeteilt, indem der L1-$-Beitrag von $ L1 $ jeweils geteilt wird:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

Im vorherigen Beispiel werden die folgenden Histogrammbeiträge generiert:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

Hinweis: filters gilt weiterhin für aggregierte Berichte und auf jedes Wörterbuch in aggregatable_trigger_data können optional weiterhin Conversion-Filter angewendet werden, genau wie die Triggerfilter für Berichte auf Ereignisebene.

Die Skalierungsfaktoren können invertiert werden, um die richtigen Werte zu erhalten, das angewendete Modulo-Rauschen:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Differential Privacy

Ein Ziel dieser API ist ein Framework, das differenzielle private aggregierte Messungen unterstützen kann. Dies kann durch Hinzufügen von Rauschen proportional zum $ L1 $-Budget erreicht werden, z. B. durch Auswahl von Rauschen mit der folgenden Verteilung:

\[ Laplace(\frac{L1}{ε}) \]

Integration der Protected Audience API und der Attribution Reporting API

Dank der API-übergreifenden Integration in die Protected Audience API und Attribution Reporting API können AdTech-Unternehmen die Attributionsleistung über verschiedene Remarketing-Taktiken hinweg bewerten, um herauszufinden, welche Arten von Zielgruppen den höchsten ROI erzielen.

Durch diese API-übergreifende Integration können AdTechs:

• Erstellen Sie eine Schlüssel/Wert-Zuordnung von URIs, die sowohl für 1) Berichte zu Interaktionen als auch für die Registrierung der Quelle verwendet werden soll.
• Fügen Sie CustomAudience in die quellseitige Schlüsselzuordnung ein, um zusammengefasste Berichte mit der Attribution Reporting API zu erstellen.

Wenn ein Nutzer eine Anzeige sieht oder darauf klickt,

• Die URL, über die diese Interaktionen über die Protected Audience API gemeldet werden, wird auch verwendet, um eine Ansicht oder einen Klick als zulässige Quelle mit der Attribution Reporting API zu registrieren.
• Die Anzeigentechnologie kann CustomAudience (oder andere relevante Kontextinformationen zur Anzeige, wie Anzeigen-Placement oder Wiedergabedauer) über diese URL weitergeben, sodass diese Metadaten in zusammenfassenden Berichten weitergegeben werden können, wenn die Anzeigentechnologie die zusammengefasste Kampagnenleistung überprüft.

Weitere Informationen dazu, wie die Funktion in Protected Audience aktiviert wird, finden Sie im entsprechenden Abschnitt der Erläuterung der Protected Audience API.

Registrierungspriorität, Attribution und Beispiele für Berichte

Dieses Beispiel zeigt eine Reihe von Nutzerinteraktionen und zeigt, wie sich die von der Anzeigentechnologie definierte Attributionsquelle und die Triggerprioritäten auf zugeordnete Berichte auswirken könnten. In diesem Beispiel gehen wir von Folgendem aus:

• Alle Attributionsquellen und -trigger werden von derselben Anzeigentechnologie für denselben Werbetreibenden registriert.
• Alle Attributionsquellen und ‐trigger werden im ersten Ereignisberichtsfenster erfasst (innerhalb von zwei Tagen nach der ersten Auslieferung der Anzeigen in einer Publisher-App).

Betrachten Sie einen Fall, in dem Nutzende Folgendes tun:

1. Der Nutzer sieht eine Anzeige. AdTech registriert bei der API eine Attributionsquelle mit der Priorität 0 (Ansicht 1).
2. Dem Nutzer wird eine Anzeige präsentiert, die mit der Priorität 0 registriert ist (siehe Nr. 2).
3. Der Nutzer klickt auf eine Anzeige mit der Priorität 1 (Klick 1).
4. Der Nutzer führt in einer Werbetreibenden-App eine Conversion aus (erreicht die Landingpage). Die AdTech registriert einen Trigger bei der API mit der Priorität 0 (Conversion 1).
   • Wenn Trigger registriert werden, führt die API zuerst die Attribution durch, bevor Berichte generiert werden.
   • Ihnen stehen drei Attributionsquellen zur Verfügung: Ansicht 1, Ansicht 2 und Klick 1. Die API weist diesen Trigger mit Klick 1 zu, da er die höchste und neueste Priorität hat.
   • Datenansicht 1 und Datenansicht 2 werden verworfen und können nicht mehr für eine zukünftige Attribution verwendet werden.
5. Der Nutzer legt in der App des Werbetreibenden einen Artikel in den Einkaufswagen, der mit der Priorität 1 registriert ist (Conversion 2).
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API weist diesem Trigger auf Klick Nr. 1 zu.
6. Der Nutzer legt in der App des Werbetreibenden einen Artikel in den Einkaufswagen, der mit der Priorität 1 registriert ist (Conversion 3).
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API weist diesem Trigger auf Klick Nr. 1 zu.
7. Der Nutzer legt in der App des Werbetreibenden einen Artikel in den Einkaufswagen, der mit der Priorität 1 registriert ist (Conversion 4).
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API weist diesem Trigger auf Klick Nr. 1 zu.
8. Der Nutzer tätigt in der Werbetreibenden-App einen Kauf und registriert mit der Priorität 2 (Conversion 5).
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API weist diesem Trigger auf Klick Nr. 1 zu.

Berichte auf Ereignisebene haben folgende Merkmale:

• Standardmäßig werden die ersten drei Trigger, die einem Klick zugeordnet sind, und der erste Trigger, der einer Ansicht zugeordnet ist, nach den entsprechenden Berichterstellungszeiträumen gesendet.
• Innerhalb des Berichtsfensters haben Trigger, die mit einer höheren Priorität registriert sind, Vorrang und ersetzen den neuesten Trigger.
• Im vorherigen Beispiel erhält die AdTech-Abteilung nach Ablauf des 2-tägigen Berichtszeitraums drei Ereignisberichte für Conversion 2, Conversion 3 und Conversion 5.
  • Alle fünf Trigger werden Klick 1 zugeordnet. Standardmäßig sendet die API Berichte für die ersten drei Trigger: Conversion 1, Conversion 2 und Conversion 3.
  • Die Priorität von Conversion 4 (1) ist jedoch höher als die Priorität von Conversion 1 (0). Der Ereignisbericht von Conversion 4 ersetzt den zu sendenden Ereignisbericht von Conversion 1.
  • Außerdem ist die Priorität von Conversion 5 (2) höher als bei jedem anderen Trigger. Der Ereignisbericht von Conversion 5 ersetzt den zu sendenden Bericht von Conversion 4.

Aggregierbare Berichte haben die folgenden Merkmale:

• Verschlüsselte aggregierte Berichte werden an den Anzeigentechnologie-Anbieter gesendet, sobald sie verarbeitet wurden – ein paar Stunden nach der Registrierung der Trigger.

  Als AdTech erstellen Sie deren Batches anhand der Informationen, die in Ihren aggregierten Berichten unverschlüsselt sind. Diese Informationen sind im Feld shared_info des aggregierbaren Berichts enthalten und umfassen den Zeitstempel und den Ursprung der Berichterstellung. Es ist nicht möglich, einen Batch auf Grundlage verschlüsselter Informationen in den Aggregations-Schlüssel/Wert-Paaren auszuführen. Sie können die täglichen oder wöchentlichen Berichte z. B. zusammenfassen. Idealerweise sollten Batches jeweils mindestens 100 Berichte enthalten.

• Die AdTech-Teams entscheiden, wann und wie die aggregierbaren Berichte in Batches zusammengefasst und an den Aggregationsdienst gesendet werden.

• Im Vergleich zu Berichten auf Ereignisebene können einer Quelle in verschlüsselten aggregierten Berichten mehr Trigger zugeordnet werden.

• Im vorherigen Beispiel werden fünf zusammengefasste Berichte gesendet, einer für jeden registrierten Trigger.

Berichte zur vorübergehenden Fehlerbehebung

Die Attribution Reporting API bietet eine neue und relativ komplexe Möglichkeit für die Attributionsmessung ohne appübergreifende Kennungen. Daher unterstützen wir einen Übergangsmechanismus, über den Sie mehr Informationen zu Attributionsberichten erhalten können, wenn die Werbe-ID verfügbar ist (der Nutzer hat die Personalisierung mit der Werbe-ID nicht deaktiviert und die Publisher- oder Werbetreibenden-App hat AdID-Berechtigungen deklariert). Dadurch wird sichergestellt, dass die API während des Roll-outs vollständig verstanden werden kann, Fehler identifiziert und die Leistung leichter mit Alternativen auf Basis von Werbe-IDs verglichen werden kann. Es gibt zwei Arten von Debugging-Berichten: erfolgreiche Attribution und ausführliche.

Weitere Informationen zur Fehlerbehebung in Berichten mit App-zu-Web- und Web-zu-App-Messungen finden Sie im Leitfaden zu Berichten zur vorübergehenden Fehlerbehebung.

Debugging-Berichte für Attribution

Sowohl Quell- als auch Triggerregistrierungen akzeptieren ein neues 64-Bit-debug_key-Feld (als String formatiert), das von der Anzeigentechnologie ausgefüllt wird. source_debug_key und trigger_debug_key werden in Berichten auf Ereignisebene und in zusammengefassten Berichten unverändert übergeben.

Wird ein Bericht mit Schlüsseln zur Fehlerbehebung sowohl für die Quelle als auch für den Trigger erstellt, wird ein duplizierter Debug-Bericht mit begrenzter Verzögerung an einen .well-known/attribution-reporting/debug/report-event-attribution-Endpunkt gesendet. Die Debug-Berichte sind identisch mit den normalen Berichten, einschließlich der beiden Schlüsselfelder für die Fehlerbehebung. Wenn Sie diese Schlüssel in beide verwenden, können normale Berichte mit dem separaten Stream von Fehlerbehebungsberichten verknüpft werden.

• Für Berichte auf Ereignisebene:
  • Doppelte Fehlerbehebungsberichte werden mit begrenzter Verzögerung gesendet und daher nicht durch die Limits für verfügbare Trigger unterdrückt. So kann AdTech die Auswirkungen dieser Limits auf Berichte auf Ereignisebene nachvollziehen.
  • Berichte auf Ereignisebene, die mit falschen Triggerereignissen verknüpft sind, enthalten keine trigger_debug_key-Werte. So kann AdTech besser verstehen, wie Rauschen in der API angewendet wird.
• Für aggregierte Berichte:
  • Wir unterstützen nur dann ein neues debug_cleartext_payload-Feld, das die entschlüsselte Nutzlast enthält, wenn sowohl source_debug_key als auch trigger_debug_key festgelegt sind.

Ausführliche Debugging-Berichte

Mit ausführlichen Debugging-Berichten können Entwickler bestimmte Fehler in der Attributionsquelle überwachen oder Registrierungen auslösen. Diese Debugging-Berichte werden mit begrenzter Verzögerung gesendet, nachdem die Attributionsquelle oder eine Registrierung ausgelöst wurde.well-known/attribution-reporting/debug/verbose-Endpunkt.

Jeder ausführliche Bericht enthält die folgenden Felder:

• Typ: Der Grund für die Generierung des Berichts Hier finden Sie eine vollständige Liste der ausführlichen Berichtstypen.
  • Im Allgemeinen gibt es ausführliche Quellberichte und lösen ausführliche Berichte aus.
  • Bei ausführlichen Quellberichten muss die Werbe-ID für die Publisher-App verfügbar sein. Um ausführliche Berichte auslösen zu können, muss die Werbe-ID für die App des Werbetreibenden verfügbar sein.
  • Ausführliche Berichte (mit Ausnahme von trigger-no-matching-source) können optional den source_debug_key enthalten. Dieser kann nur angegeben werden, wenn die Werbe-ID auch für die Publisher-App verfügbar ist.
• Text: Der Textkörper des Berichts, abhängig vom Typ.

Anzeigentechnologie-Anbieter müssen ausführliche Debugging-Berichte aktivieren, indem sie ein neues debug_reporting-Wörterbuchfeld in den Attribution-Reporting-Register_Source- und Attribution-Reporting-Register-Trigger-Headern verwenden.

• Ausführliche Quellenberichte müssen nur für den Quellregistrierungs-Header aktiviert werden.
• Trigger-Debug-Berichte erfordern die Aktivierung nur für den Trigger-Registrierungsheader.

Fehlerbehebungsberichte verwenden

Wenn eine Konvertierung (laut Ihrem vorhandenen Messsystem) stattgefunden hat und ein Debug-Bericht für diese Conversion empfangen wurde, bedeutet dies, dass der Trigger erfolgreich registriert wurde.

Prüfen Sie für jeden Debug-Attributionsbericht, ob Sie einen regulären Attributionsbericht erhalten, der mit den beiden Fehlerbehebungsschlüsseln übereinstimmt.

Wenn keine Übereinstimmung gefunden wird, kann das verschiedene Gründe haben.

Funktioniert wie vorgesehen:

• Datenschutzfreundliches API-Verhalten:
  • Ein Nutzer erreicht die Ratenbegrenzung für Meldungen. Dadurch werden alle nachfolgenden Berichte innerhalb des Zeitraums nicht gesendet oder eine Quelle wird aufgrund des ausstehenden Ziellimits entfernt.
  • Bei Berichten auf Ereignisebene gilt: Der Bericht unterliegt einer zufälligen Antwort (Rauschen) und wird unterdrückt. Alternativ erhalten Sie einen zufälligen Bericht.
  • Bei Berichten auf Ereignisebene: Das Limit von drei Berichten (für Klicks) bzw. einem Bericht (für Aufrufe) wurde erreicht. Für nachfolgende Berichte wurde keine explizite Priorität festgelegt oder eine niedrigere Priorität als bestehende Berichte.
  • Die Beitragslimits für aggregierte Berichte wurden überschritten.
• AdTech-definierte Geschäftslogik:
  • Ein Trigger wird über Filter oder Prioritätsregeln herausgefiltert.
• Zeitverzögerungen oder Interaktionen mit der Netzwerkverfügbarkeit (z. B. wenn der Nutzer sein Gerät für einen längeren Zeitraum abschaltet)

Unbeabsichtigte Ursachen:

• Probleme bei der Implementierung:
  • Der Quellheader ist falsch konfiguriert.
  • Der Triggerheader ist falsch konfiguriert.
  • Sonstige Konfigurationsprobleme.
• Geräte- oder Netzwerkprobleme:
  • Fehler aufgrund von Netzwerkbedingungen.
  • Die Quell- oder Trigger-Registrierungsantwort erreicht den Client nicht.
  • API-Fehler.

Zukünftige Überlegungen und offene Fragen

Die Attribution Reporting API ist noch in der Entwicklung. Außerdem erörtern wir potenzielle neue Funktionen wie Attributionsmodelle, die nicht auf dem letzten Klick basieren, und Anwendungsfälle für geräteübergreifende Messungen.

Außerdem bitten wir die Community um Feedback zu einigen Themen:

1. Gibt es Anwendungsfälle, bei denen Sie möchten, dass die API Berichte für die bestätigte Installation sendet? Diese Berichte werden auf die jeweiligen Ratenbegrenzungen für Anzeigentechnologie-Plattformen angerechnet.
2. Seht ihr Probleme bei der Übergabe von InputEvent von der App an die Anzeigentechnologie zur Registrierung der Quelle?
3. Gibt es besondere Attributionsanwendungsfälle für vorinstallierte oder neu installierte Apps?