Attributionsberichte für Mobilgeräte – Übersicht

Hinweis : Dieses Dokument enthält die aktuellen Designvorschläge für die Privacy Sandbox für Android und kann sich noch ändern. Wir freuen uns auf Ihr Feedback und Ihre Kommentare, damit wir diese Bemühungen weiter vorantreiben können.

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 in registerWebSource, registerWebTrigger, registerAppSource und registerAppTrigger Strings für Felder verwendet werden, für die ein numerischer Wert erwartet wird (z. B. priority, source_event_id, debug_key, trigger_data und deduplication_key).

• Im 4. Quartal 2023 wird die Android Attribution Reporting API um Google Cloud-Unterstützung erweitert, damit Zusammenfassungsberichte mit dem Aggregation Service in Google Cloud erstellt werden können. Weitere Informationen finden Sie hier. Weitere Informationen zum Einrichten des Aggregationsdienstes mit Google Cloud finden Sie in der Bereitstellungsanleitung.

• Neue datenschutzfreundliche Ratenlimits für die Anzahl der eindeutigen Ziele.

• Im 1. Quartal 2024 werden die Funktionen für Triggerfilter für Lookback-Fenster aktualisiert. Weitere Informationen finden Sie in der entsprechenden Anmerkung.

Übersicht

Heutzutage werden Lösungen für dienstleisterübergreifende Nutzer-IDs 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. Dabei wird die Abhängigkeit von dienstleisterübergreifenden Nutzerkennungen entfernt und gleichzeitig werden wichtige Anwendungsfälle für die Attributions- und Conversion-Analyse in Apps und im Web unterstützt.

Diese API bietet die folgenden strukturellen Mechanismen, die ein Rahmenwerk für die Verbesserung des Datenschutzes bieten. Sie werden in den folgenden Abschnitten dieser Seite genauer beschrieben:

• Begrenzt die Anzahl der Bits, die für Berichte auf Ereignisebene verfügbar sind

• Conversion-Daten mit höherer Genauigkeit werden nur in aggregierbaren Berichten aktiviert.

• Einführung von Frequenzlimits für verfügbare Trigger (Conversions) und der Anzahl der Anzeigentechnologien, die einer einzelnen Attributionsquelle zugeordnet werden können

• Verschiedene Verfahren zum Hinzufügen von Rauschen

Die oben genannten Mechanismen beschränken die Möglichkeit, die Nutzeridentität über zwei verschiedene Apps oder Domains hinweg zu verknüpfen.

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

• Conversion-Berichte:Werbetreibende können die Leistung ihrer Kampagnen anhand von Conversion- und Trigger-Anzahl sowie Conversion- und Trigger-Werten nach verschiedenen Dimensionen messen, z. B. nach Kampagne, Anzeigengruppe und Creative.
• Optimierung:Berichte auf Ereignisebene, die die Optimierung von Werbeausgaben unterstützen, indem Attributionsdaten pro Impression bereitgestellt werden, die zum Trainieren von ML-Modellen verwendet werden können.
• Erkennung ungültiger Aktivitäten:Sie stellen Berichte zur Verfügung, die bei der Erkennung und Analyse ungültiger Zugriffe und Anzeigenbetrugs verwendet werden können.

Die Attribution Reporting API funktioniert im Wesentlichen so, wie in den folgenden Abschnitten dieses Dokuments beschrieben:

1. Das AdTech-Unternehmen führt einen Registrierungsprozess durch, um die Attribution Reporting API zu verwenden.
2. Das AdTech-Unternehmen registriert Attributionsquellen – Anzeigenklicks oder ‑aufrufe – mit der Attribution Reporting API.
3. Das AdTech-Unternehmen registriert Trigger – 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 ab (Conversion-Attribution). Anschließend werden ein oder mehrere Trigger über Berichte auf Ereignisebene und aggregierbare Berichte an AdTechs gesendet.

Hinweis: Weitere Informationen zur Implementierung dieses Designs für einen Anwendungsfall der App-zu-App-Attribution finden Sie im Abschnitt zur plattformübergreifenden Attribution des Entwicklerhandbuchs für die Attribution Reporting API. Informationen zum Implementieren eines App-zu-Web- oder Web-zu-App-Use-Cases finden Sie im Vorschlag für ein plattformübergreifendes Analysedesign für Apps und das Web.

Zugriff auf Attribution Reporting APIs erhalten

Anzeigentechnologie-Plattformen müssen sich registrieren, um auf die Attribution Reporting APIs zugreifen zu können. Weitere Informationen finden Sie unter Privacy Sandbox-Konto registrieren.

Attributionsquelle registrieren (Klick- oder Aufrufmessung)

In der Attribution Reporting API werden Anzeigenklicks und -aufrufe als Attributionsquellen bezeichnet. Wenn Sie einen Anzeigenklick oder eine Anzeigenaufruf registrieren möchten, rufen Sie registerSource() auf. Für diese API sind die folgenden Parameter erforderlich:

• 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 null (für ein Aufrufereignis).

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

• Ereignis-ID der Quelle: Dieser Wert steht für die Daten auf Ereignisebene, die mit dieser Attributionsquelle (Anzeigenklick oder -aufruf) verknüpft sind. Muss eine 64-Bit-nicht signierte Ganzzahl sein, die als String formatiert ist.
• Ziel: Ein Ursprung, dessen eTLD+1 oder App-Paketname das Auslöse-Ereignis enthält.
• Ablaufzeit (optional): Ablaufzeit in Sekunden, nach der die Quelle vom Gerät gelöscht werden soll. Der Standardwert ist 30 Tage. Der Mindestwert ist 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.
• Zeitraum für Ereignisberichte (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 Ereignisberichte abgelaufen ist, aber das Ablaufdatum noch nicht erreicht wurde, kann ein Trigger weiterhin mit einer Quelle abgeglichen werden. Für diesen Trigger wird jedoch kein Ereignisbericht gesendet. Darf nicht größer als „Expiry“ sein. Kann als vorzeichenlose 64-Bit-Ganzzahl oder String formatiert werden.
• Zeitraum für aggregierbare Berichte (optional): Dauer in Sekunden nach der Registrierung der Quelle, während der aggregierbare Berichte für diese Quelle erstellt werden können. Darf nicht größer als „Expiry“ sein. Kann als 64-Bit-unsignierte Ganzzahl oder String formatiert werden.
• Quellenpriorität (optional): Damit wird ausgewählt, welcher Attributionsquelle ein bestimmter Trigger zugeordnet werden soll, falls dem Trigger mehrere Attributionsquellen zugeordnet werden können. Muss eine 64‑Bit-Ganzzahl mit Vorzeichen sein, die als String formatiert ist.
  
  Wenn ein Trigger empfangen wird, sucht die API die übereinstimmende Attributionsquelle mit dem höchsten Wert für die Quellenpriorität und generiert einen Bericht. Jede AdTech-Plattform kann eine 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 eine höhere Priorität.
• Attributionsfenster für Installationen und nach der Installation (optional): Damit wird die Attribution für Ereignisse nach der Installation bestimmt, die weiter unten auf dieser Seite beschrieben werden.
• Daten filtern (optional): Damit können einige Trigger selektiv herausgefiltert und so effektiv ignoriert werden. 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 Antwort mit den Metadaten der Attributionsquelle zusätzliche Daten im Header Attribution reporting redirects enthalten. Die Daten enthalten Weiterleitungs-URLs, über die mehrere Anzeigentechnologien eine Anfrage registrieren können.

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

Die folgenden Schritte zeigen einen Beispiel-Workflow:

1. Das AdTech-SDK ruft die API auf, um die Registrierung der Attributionsquelle zu starten, und gibt einen URI für den API-Aufruf an:

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

2. Die API sendet eine Anfrage an https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA und verwendet dabei einen der folgenden Header:

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

3. Der HTTPS-Server dieser Anzeigentechnologie 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 sendet eine Anfrage an jede in Attribution-Reporting-Redirect angegebene URL. In diesem Beispiel sind zwei URLs von AdTech-Partnern angegeben. Die API sendet also eine Anfrage an https://adtechpartner1.example?their_ad_click_id=567 und eine weitere an https://adtechpartner2.example?their_ad_click_id=890.

5. Der HTTPS-Server dieser Anzeigentechnologie 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 Anbietern von Anzeigentechnologien können im Attribution-Reporting-Register-Source-Header andere Metadaten angegeben werden.

Anhand der Anfragen aus den vorherigen Schritten werden drei Navigations- (Klick-)Attributionsquellen registriert.

Attributionsquelle über WebView registrieren

WebView unterstützt den Anwendungsfall, bei dem eine App eine Anzeige in einer WebView rendert. Das wird von WebView verwaltet, das registerSource() direkt als Hintergrundanfrage aufruft. Bei diesem Aufruf wird die Attributionsquelle der App und nicht der Ursprung auf oberster Ebene zugeordnet. Das Registrieren von Quellen aus eingebetteten Webinhalten in einem Browserkontext wird ebenfalls unterstützt. Dazu müssen sowohl API-Aufrufer als auch Apps die Einstellungen anpassen. Eine Anleitung für API-Aufrufer finden Sie unter Attributionsquelle und Trigger über WebView registrieren. Eine Anleitung für Apps finden Sie unter Attributionsquelle und Trigger über WebView registrieren.

Da Anzeigentechnologien gemeinsamen Code für Web und WebView verwenden, folgt WebView HTTP-302-Weiterleitungen und leitet die gültigen Registrierungen an die Plattform weiter. Wir planen nicht, den Attribution-Reporting-Redirect-Header für dieses Szenario zu unterstützen. Wenden Sie sich jedoch an uns, wenn Sie einen davon betroffenen Anwendungsfall haben.

Hinweis: Damit WebViews die Attribution Reporting API verwenden können, muss die eingebettete App mit den richtigen Berechtigungen konfiguriert werden.

Trigger (Conversion) registrieren

Anbieter von Anzeigentechnologien können mit der registerTrigger()-Methode Trigger registrieren, also Conversions wie Installationen oder Ereignisse nach der Installation.

Für die Methode registerTrigger() ist der Parameter Trigger-URI erforderlich. 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 muss einen HTTP-Header namens Attribution-Reporting-Register-Trigger enthalten, der Informationen zu einem oder mehreren registrierten Triggern enthält. Der Inhalt des Headers muss JSON-codiert sein und die folgenden Felder enthalten:

• Triggerdaten:Daten zur Identifizierung des Triggerereignisses (3 Bits für Klicks, 1 Bit für Aufrufe). Muss eine vorzeichenbehaftete 64‑Bit-Ganzzahl sein, die als String formatiert ist.

• Triggerpriorität (optional): Die Priorität dieses Trigger im Vergleich zu anderen Triggern für dieselbe Attributionsquelle. Muss eine 64‑Bit-Ganzzahl mit Vorzeichen sein, die als String formatiert ist. Weitere Informationen dazu, wie sich die Priorität auf die Berichte auswirkt, finden Sie im Abschnitt Priorisierung.

• Deduplizierungsschlüssel (optional): Wird verwendet, um Fälle zu identifizieren, in denen derselbe Trigger von derselben AdTech-Plattform mehrmals 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 sind, und für die aggregierbaren Berichte, deren Wert aggregiert werden soll.

• Aggregationswerte (optional): Eine Liste von Werten, die zu jedem Schlüssel beitragen.

• Filter (optional): Damit lassen sich Trigger oder Triggerdaten selektiv filtern. 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 enthalten. Die Daten enthalten Weiterleitungs-URLs, über die mehrere Anzeigentechnologien eine Anfrage registrieren können.

Mehrere Anzeigentechnologien können dasselbe Triggerereignis registrieren, entweder über Weiterleitungen im Feld Attribution-Reporting-Redirect oder über mehrere Aufrufe der Methode registerTrigger(). Wir empfehlen die Verwendung des Felds Deduplizierungsschlüssel, um zu vermeiden, dass Berichte doppelte Trigger enthalten, wenn dieselbe Anzeigentechnologie mehrere Antworten für dasselbe Triggerereignis liefert. Weitere Informationen zur Verwendung eines Deduplizierungsschlüssels

Das Entwicklerhandbuch enthält Beispiele, die zeigen, wie die Registrierung von Triggern akzeptiert wird.

Die folgenden Schritte zeigen einen Beispiel-Workflow:

1. Das AdTech-SDK ruft die API auf, um die Triggerregistrierung mit einem vorab registrierten URI zu starten. Weitere Informationen finden Sie unter Privacy Sandbox-Konto registrieren.

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

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

3. Der HTTPS-Server dieser Anzeigentechnologie 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 sendet eine Anfrage an jede in Attribution-Reporting-Redirect angegebene URL. In diesem Beispiel ist nur eine URL angegeben. Daher sendet die API eine Anfrage an https://adtechpartner.example?app_install=567.

5. Der HTTPS-Server dieser Anzeigentechnologie 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 mit Attributionsquellen abgleicht.

Algorithmus für die priorisierte Attribution nach Quelle angewendet

Die Attribution Reporting API verwendet einen Quellenpriorisierten Attributionsalgorithmus, um einen Trigger (Conversion) mit einer Attributionsquelle abzugleichen.

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

• Sie können bestimmten Anzeigenereignissen Trigger zuordnen. Sie können beispielsweise Klicks stärker gewichten als Aufrufe oder sich auf Ereignisse aus bestimmten Kampagnen konzentrieren.
• Sie können die Attributionsquelle und den Trigger so konfigurieren, dass Sie bei Erreichen der Ratenlimits mit höherer Wahrscheinlichkeit die für Sie wichtigsten Berichte erhalten. So können Sie beispielsweise dafür sorgen, dass in diesen Berichten mit höherer Wahrscheinlichkeit gebotsfähige Conversions oder Conversions mit hohem Wert berücksichtigt werden.

Wenn mehrere Anzeigentechnologien eine Attributionsquelle registrieren, wie weiter unten auf dieser Seite beschrieben, erfolgt diese Attribution unabhängig für jede Anzeigentechnologie. Für jede Anzeigentechnologie wird das Triggerereignis der 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 werden, werden verworfen und können nicht mehr für die zukünftige Trigger-Attribution verwendet werden.

Triggerfilter

Die Registrierung von Quellen und Triggern umfasst zusätzliche optionale Funktionen, mit denen Sie Folgendes tun können:

• Einige Trigger selektiv herausfiltern und so effektiv ignorieren
• Wählen Sie Triggerdaten für Berichte auf Ereignisebene basierend auf Quelldaten aus.
• Sie können einen Trigger aus Berichten auf Ereignisebene ausschließen.

Um Trigger selektiv zu filtern, kann die Anzeigentechnologie bei der Registrierung von Quellen und Triggern Filterdaten aus Schlüsseln und Werten angeben. Wenn für die Quelle und den Trigger derselbe Schlüssel angegeben ist, wird der Trigger ignoriert, wenn die Überschneidung 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 kein Triggerfilterschlüssel mit product übereinstimmt, werden die Filter ignoriert.

Ein weiteres Szenario, in dem Anbieter von Anzeigentechnologien Trigger selektiv filtern möchten, ist die Erzwingung eines kürzeren Ablaufzeitraums. Bei der Triggerregistrierung kann ein Anbieter von Anzeigentechnologien ein Lookback-Window (in Sekunden) ab dem Zeitpunkt der Conversion angeben. Ein Lookback-Window von 7 Tagen würde 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 hier beschriebene Logik und Funktionsweise des Lookback-Filters wird im 1. Quartal 2024 eingeführt. Hier finden Sie weitere Informationen zum Veröffentlichungszeitpunkt. Bei der bisherigen Logik mussten Lookback-Windows sowohl auf Seiten der Quelle als auch des Trigger in Stunden angegeben werden. Diese aktualisierte Funktionslogik ist nicht abwärtskompatibel. Das bedeutet, dass Quellen, die den vorherigen Schlüssel „_lookback_window“ verwenden, nicht registriert werden.

Anbieter von Anzeigentechnologien können Triggerdaten auch anhand von Daten zu Quell-Ereignissen auswählen. Beispiel: source_type wird von der API automatisch als navigation oder event generiert. Bei der Triggerregistrierung kann trigger_data als Wert für "source_type": ["navigation"] und als anderer Wert für "source_type": ["event"] festgelegt werden.

Auslöser werden aus Berichten auf Ereignisebene ausgeschlossen, wenn eine der folgenden Bedingungen zutrifft:

• trigger_data ist nicht angegeben.
• Für Quelle und Trigger ist derselbe Filterschlüssel angegeben, die Werte stimmen jedoch nicht überein. In diesem Fall wird der Trigger sowohl für Berichte auf Ereignisebene als auch für aggregierbare Berichte ignoriert.

Attribution nach der Installation

In einigen Fällen müssen Trigger nach der Installation derselben Attributionsquelle zugeordnet werden, die zur Installation geführt hat, auch wenn es andere infrage kommende Attributionsquellen gibt, die vor Kurzem verwendet wurden.

Die API kann diesen Anwendungsfall unterstützen, indem Anbieter von Anzeigentechnologien einen Attributionszeitraum nach der Installation festlegen können:

• Geben Sie beim Registrieren einer Attributionsquelle ein Attributionsfenster für Installationen an, in dem Installationen erwartet werden (in der Regel 2–7 Tage, zulässiger Bereich: 1–30 Tage). Geben Sie dieses Zeitfenster in Sekunden an.
• Geben Sie beim Registrieren einer Attributionsquelle einen Zeitraum an, in dem alle Triggerereignisse nach der Installation der Attributionsquelle zugeordnet werden sollen, die zu der Installation geführt hat (in der Regel 7–30 Tage, zulässiger Bereich: 0–30 Tage). Geben Sie dieses Zeitfenster als Anzahl von Sekunden an.
• Die Attribution Reporting API prüft, ob eine App-Installation erfolgt, und ordnet die Installation intern der Attributionsquelle zu, die nach Priorität der Quelle ausgewählt wurde. Die Installation wird jedoch nicht an Anzeigentechnologien gesendet und nicht auf die jeweiligen Ratenlimits der Plattformen angerechnet.
• Die Validierung von App-Installationen ist für jede heruntergeladene App verfügbar.
• Alle zukünftigen Trigger, die innerhalb des Attributionsfensters nach der Installation auftreten, werden derselben Attributionsquelle wie die bestätigte Installation zugeordnet, sofern diese Attributionsquelle infrage kommt.

In Zukunft werden wir möglicherweise überlegen, das Design zu erweitern, um auch erweiterte Attributionsmodelle zu unterstützen.

In der folgenden Tabelle sehen Sie ein Beispiel dafür, wie Anbieter von 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.

Ereignis	Tag, an dem das Ereignis eintritt	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, diese Installationen gelten jedoch nicht als Trigger. Daher werden derzeit keine Berichte gesendet.
Trigger 1 (erstes Öffnen)	2	Erster Trigger, der von der Anzeigentechnologie registriert wurde. In diesem Beispiel steht er für ein erstes Öffnen, kann aber auch einen beliebigen Triggertyp darstellen. Klick 1 zugeordnet (entspricht der Attribution der bestätigten Installation).
Klicken Sie auf 2.	4	Für install_attribution_window und post_install_exclusivity_window werden dieselben Werte wie für Klick 1 verwendet.
Trigger 2 (nach der Installation)	5	Zweiter Trigger, der von der Anzeigentechnologie registriert wird. In diesem Beispiel steht er für eine Conversion nach der Installation, z. B. einen Kauf. Klick 1 zugeordnet (entspricht der Attribution der bestätigten Installation). Klick 2 wird verworfen und kann nicht für die zukünftige Attribution verwendet werden.

In der folgenden Liste finden Sie einige zusätzliche Hinweise zur Attribution nach der Installation:

• Wenn die bestätigte Installation nicht innerhalb der von install_attribution_window angegebenen Anzahl von Tagen erfolgt, wird die Attribution nach der Installation nicht angewendet.
• Bestätigte Installationen werden nicht von Anzeigentechnologien registriert und nicht in Berichten gesendet. Sie werden nicht auf die Ratenlimits einer Anzeigentechnologie angerechnet. Bestätigte Installationen werden nur verwendet, um die Attributionsquelle zu identifizieren, der die Installation zugeordnet wird.
• Im Beispiel in der vorherigen Tabelle stehen Trigger 1 und Trigger 2 für eine erste Öffnung und eine Conversion nach der Installation. AdTech-Plattformen können jedoch jeden Triggertyp registrieren. Mit anderen Worten: Der erste Trigger muss kein Trigger für das erste Öffnen sein.
• Wenn nach Ablauf der post_install_exclusivity_window weitere Trigger registriert werden, kann Klick 1 weiterhin zugeordnet werden, sofern er nicht abgelaufen ist und die Ratenlimits nicht erreicht wurden.
  • Klick 1 kann dennoch verloren gehen oder verworfen werden, wenn eine Attributionsquelle mit höherer Priorität registriert ist.
• Wenn die App des Werbetreibenden deinstalliert und wieder installiert wird, wird die Neuinstallation als neue bestätigte Installation gezählt.
• Wenn Klick 1 stattdessen ein Aufrufereignis war, werden ihm sowohl der Trigger „Erstes Öffnen“ als auch die Trigger nach der Installation zugeordnet. Die API schränkt die Attribution auf einen Trigger pro Aufruf ein, mit Ausnahme der Attribution nach der Installation, bei der bis zu zwei Trigger pro Aufruf zulässig sind. Bei der Attribution nach der Installation kann die Anzeigentechnologie zwei unterschiedliche Berichtsfenster erhalten (nach zwei Tagen oder nach Ablauf der Quelle).

Alle Kombinationen aus 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 sich eine Anzeige in einer App an 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 einem In-App-Browser eine Conversion aus.
• Web-to-app::Der Nutzer sieht eine Anzeige in einem mobilen Browser oder einem In-App-Browser und führt dann in einer App eine Conversion aus.
• Web-to-web::Der Nutzer sieht sich eine Anzeige in einem mobilen Browser oder In-App-Browser an und führt dann entweder im selben Browser oder in einem anderen Browser auf demselben Gerät eine Conversion aus.

Wir erlauben Webbrowsern, neue Webfunktionen zu unterstützen, z. B. Funktionen, die der Attribution Reporting API der Privacy Sandbox für das Web ähneln. Diese Funktionen können die Android APIs aufrufen, um die Attribution in Apps und im Web zu ermöglichen.

Hier erfahren Sie, welche Änderungen an Anzeigentechnologien und Apps vorgenommen werden müssen, um Triggerpfade für die App- und Webanalyse zu unterstützen.

Mehrere Trigger für eine einzelne Attributionsquelle priorisieren

Eine einzelne Attributionsquelle kann zu mehreren Triggern führen. Ein Kaufvorgang kann beispielsweise einen Trigger für die App-Installation, einen oder mehrere Trigger für das Hinzufügen zum Einkaufswagen und einen Trigger für den Kauf umfassen. Jeder Trigger wird gemäß dem Algorithmus für die quellenpriorisierte Attribution, der weiter unten auf dieser Seite beschrieben wird, einer oder mehreren Attributionsquellen zugeordnet.

Die Anzahl der Trigger, die einer einzelnen Attributionsquelle zugeordnet werden können, ist begrenzt. Weitere Informationen finden Sie weiter unten auf dieser Seite im Abschnitt Messdaten in Attributionsberichten ansehen.

Wenn es mehrere Trigger über diesen Limits gibt, ist es sinnvoll, eine Priorisierungslogik einzuführen, um die wertvollsten Trigger zurückzugeben. Die Entwickler einer Anzeigentechnologie können beispielsweise Trigger für „Kauf“ gegenüber Triggern für „In den Einkaufswagen legen“ priorisieren.

Um diese Logik zu unterstützen, kann für den Trigger ein separates Prioritätsfeld festgelegt werden. Die Trigger mit der höchsten Priorität werden dann innerhalb eines bestimmten Berichtszeitraums ausgewählt, bevor Limits angewendet werden.

Hinweis :Bei Triggern mit niedrigerer Priorität, die bereits erfasst wurden, wird das Budget immer in Anspruch genommen.

Mehreren Anzeigentechnologien das Registrieren von Attributionsquellen oder -triggern erlauben

Es ist üblich, dass mehrere Anzeigentechnologien Attributionsberichte erhalten, in der Regel zur netzwerkübergreifenden Deduplizierung. Daher können mit der API mehrere Anzeigentechnologien dieselbe Attributionsquelle oder denselben Trigger registrieren. Ein AdTech-Anbieter muss sowohl Attributionsquellen als auch Trigger registrieren, um Postbacks von der API zu erhalten. Die Attribution erfolgt dann anhand der Attributionsquellen und Trigger, die der AdTech-Anbieter bei der API registriert hat.

Werbetreibende, die die netzübergreifende Deduplizierung durch einen Drittanbieter durchführen lassen möchten, können dies weiterhin tun. Dazu wird ein Verfahren ähnlich dem folgenden verwendet:

• Sie richten einen internen Server ein, um Berichte von der API zu registrieren und zu empfangen.
• Einen vorhandenen Partner für mobile Messungen weiter verwenden

Attributionsquellen

Weiterleitungen auf Attributionsquellen werden von der registerSource()-Methode unterstützt:

1. Die Anzeigentechnologie, die die registerSource()-Methode aufruft, kann in ihrer Antwort ein zusätzliches Attribution-Reporting-Redirect-Feld angeben, das die Weiterleitungs-URLs der Anzeigentechnologie des Partners darstellt.
2. Die API ruft dann die Weiterleitungs-URLs auf, damit die Attributionsquelle von den Werbetechnologien des Partners registriert werden kann.

Im Feld Attribution-Reporting-Redirect können mehrere URLs von Anzeigentechnologien von Partnern aufgeführt werden. Anbieter von Anzeigentechnologien von Partnern können kein eigenes Feld Attribution-Reporting-Redirect angeben.

Außerdem können verschiedene Anzeigentechnologien registerSource() aufrufen.

Trigger

Bei der Triggerregistrierung werden Drittanbieter auf ähnliche Weise unterstützt: Anbieter von Anzeigentechnologien können entweder das zusätzliche Attribution-Reporting-Redirect-Feld verwenden oder die registerTrigger()-Methode aufrufen.

Wenn ein Werbetreibender mehrere Anzeigentechnologien verwendet, um dasselbe Triggerereignis zu erfassen, sollte ein Deduplizierungsschlüssel verwendet werden. Mit dem Deduplizierungsschlüssel können diese wiederholten Berichte zum selben Ereignis, die von derselben Anzeigentechnologieplattform erfasst wurden, voneinander unterschieden werden. So kann ein Anbieter von Anzeigentechnologien beispielsweise sein SDK so konfigurieren, dass die API direkt aufgerufen wird, um einen Trigger zu registrieren, und seine URL im Weiterleitungsfeld des Aufrufs einer anderen Anzeigentechnologie eingefügt wird. Wenn kein Schlüssel zur Deduplizierung angegeben wird, werden doppelte Trigger möglicherweise als eindeutig an jede Anzeigentechnologie zurückgemeldet.

Umgang mit doppelten Triggern

Eine Anzeigentechnologie kann denselben Trigger mehrmals bei der API registrieren. Beispiele für Szenarien:

• Der Nutzer führt dieselbe Aktion (Trigger) mehrmals aus. Beispiel: Der Nutzer sieht sich dasselbe Produkt mehrmals im selben Berichtszeitraum an.
• Die App des Werbetreibenden verwendet mehrere SDKs für die Conversion-Analyse, die alle auf dieselbe Anzeigentechnologie verweisen. Beispiel: Die App des Werbetreibenden verwendet zwei Analysepartner, MMP 1 und MMP 2. Beide MMPs leiten zu AdTech 3 weiter. Wenn ein Trigger ausgelöst wird, registrieren beide MMPs diesen Trigger bei der Attribution Reporting API. Die Anzeigentechnologie 3 erhält dann zwei separate Weiterleitungen – eine von MMP 1 und eine von MMP 2 – für denselben Trigger.

In diesen Fällen gibt es mehrere Möglichkeiten, Berichte auf Ereignisebene zu duplizierten Triggern zu unterdrücken, um das Risiko zu verringern, dass die Häufigkeitslimits für Berichte auf Ereignisebene überschritten werden. Wir empfehlen die Verwendung eines Deduplizierungsschlüssels.

Empfohlene Methode: Deduplizierungsschlüssel

Wir empfehlen, dass die App des Werbetreibenden einen eindeutigen Schlüssel zur Deduplizierung an alle Anzeigentechnologien oder SDKs weitergibt, die für die Conversion-Analyse verwendet werden. Wenn eine Conversion erfolgt, übergibt die App einen Deduplizierungsschlüssel an die Anzeigentechnologien oder SDKs. Diese Anzeigentechnologien oder SDKs geben den Deduplizierungsschlüssel dann mithilfe eines Parameters in den in Attribution-Reporting-Redirect angegebenen URLs an Weiterleitungen weiter.

Anbieter von Anzeigentechnologien können nur den ersten Trigger mit einem bestimmten Deduplizierungsschlüssel registrieren oder mehrere oder alle Trigger. Anbieter von Anzeigentechnologien können die deduplication_key angeben, wenn sie doppelte Trigger registrieren.

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

Alternative Methode: Anbieter von Anzeigentechnologien einigen sich auf Triggertypen pro Werbetreibendem

Wenn Anbieter von Anzeigentechnologien den Deduplizierungsschlüssel nicht verwenden möchten oder die App des Werbetreibenden keinen Deduplizierungsschlüssel übergeben kann, gibt es eine alternative Option. Alle Werbetechnologien, die Conversions für einen bestimmten Werbetreibenden erfassen, müssen zusammenarbeiten, um unterschiedliche Triggertypen für jeden Werbetreibenden zu definieren.

Anzeigentechnologien, die den Triggerregistrierungsaufruf initiieren, z. B. SDKs, fügen in Attribution-Reporting-Redirect angegebenen URLs einen Parameter hinzu, z. B. duplicate_trigger_id. Dieser duplicate_trigger_id-Parameter kann Informationen wie den SDK-Namen und den Triggertyp für diesen Werbetreibenden enthalten. Anbieter von Anzeigentechnologien können dann einen Teil dieser doppelten Trigger in Berichte auf Ereignisebene aufnehmen. Anbieter von Anzeigentechnologien können diese duplicate_trigger_id auch in ihre Aggregationsschlüssel aufnehmen.

Beispiel für die netzwerkübergreifende Attribution

In diesem Abschnitt wird ein Beispiel beschrieben, in dem der Werbetreibende zwei Werbetechnologieplattformen (Werbetechnologie A und Werbetechnologie B) und einen Analysepartner (MMP) verwendet.

Zuerst müssen AdTech A, AdTech B und die MMP jeweils die Registrierung für die Attribution Reporting API abschließen. Weitere Informationen finden Sie unter Privacy Sandbox-Konto registrieren.

In der folgenden Liste finden Sie eine hypothetische Reihe von Nutzeraktionen, die jeweils einen Tag auseinander liegen, und wie die Attribution Reporting API diese Aktionen in Bezug auf Anzeigentechnologie A, Anzeigentechnologie B und MMP verarbeitet:

Tag 1: Der Nutzer klickt auf eine Anzeige, die von Anzeigentechnologie A ausgeliefert wird.

Anzeigentechnologie A ruft registerSource() mit ihrem URI auf. Die API sendet eine Anfrage an den URI und der Klick wird mit den Metadaten aus der Serverantwort von Ad Tech A registriert.

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

Tag 2: Der Nutzer klickt auf eine Anzeige, die über Ad Tech B ausgeliefert wird.

Anzeigentechnologie B ruft registerSource() mit ihrem URI auf. Die API sendet eine Anfrage an den URI und der Klick wird mit den Metadaten aus der Serverantwort von Ad Tech B registriert.

Wie Anzeigentechnologie A hat auch Anzeigentechnologie B den URI der MMP in den Attribution-Reporting-Redirect-Header aufgenommen. Die API sendet eine Anfrage an die URI der MMP und der Klick wird mit den Metadaten aus der Serverantwort der MMP registriert.

Tag 3: Der Nutzer sieht sich eine Anzeige an, die von Ad Tech A ausgeliefert wird.

Die API reagiert genauso wie am ersten Tag, mit der Ausnahme, dass eine Datenansicht für die Anzeigentechnologie A und die MMP registriert ist.

4. Tag: Der Nutzer installiert die App, in der die MMP für die Conversion-Analyse verwendet wird

MMP ruft registerTrigger() mit seinem URI auf. Die API sendet eine Anfrage an die URL und die Conversion wird mit den Metadaten aus der Serverantwort der MMP registriert.

MMP enthält außerdem die URIs für Anzeigentechnologie A und Anzeigentechnologie B in der Attribution-Reporting-Redirect-Überschrift. Die API sendet Anfragen an die Server von Ad Tech A und Ad Tech B. Die Conversion wird dann entsprechend mit den Metadaten aus den Serverantworten registriert.

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

Beispiel für die Reaktion der Attribution Reporting API auf eine Reihe von Nutzeraktionen.

So funktioniert die Attribution:

• Die Anzeigentechnologie A setzt die Priorität von Klicks höher als die von Aufrufen. Daher wird die Installation dem Klick am ersten Tag zugeordnet.
• Die Installation wird am 2. Tag der Anzeigentechnologie B zugeordnet.
• MMP setzt die Priorität von Klicks über Aufrufe und die Installation wird dem Klick am 2. Tag zugeordnet. Der Klick am 2. Tag hat die höchste Priorität, da es sich um das letzte Anzeigenereignis handelt.

Netzwerkübergreifende Attribution ohne Weiterleitungen

Wir empfehlen die Verwendung von Weiterleitungen, damit mehrere Anzeigentechnologien Attributionsquellen und ‑trigger registrieren können. Es kann jedoch Fälle geben, in denen Weiterleitungen nicht möglich sind. In diesem Abschnitt wird beschrieben, wie Sie die netzwerkübergreifende Attribution ohne Weiterleitungen unterstützen.

Allgemeiner Ablauf

1. Bei der Quellregistrierung gibt das ausliefernde AdTech-Netzwerk seine Schlüssel für die Quellaggregation weiter.
2. Bei der Triggerregistrierung wählt der Werbetreibende oder Analysepartner aus, welche wichtigen datenquellenseitigen Informationen verwendet werden sollen, und gibt die Attributionskonfiguration an.
3. Die Attribution basiert auf der Attributionskonfiguration, freigegebenen Schlüsseln und allen Quellen, die tatsächlich von diesem Werbetreibenden oder Analysepartner registriert wurden (z.B. von einem anderen AdTech-Netzwerk für die Anzeigenbereitstellung, das Weiterleitungen aktiviert hat).
4. Wenn der Trigger einer Quelle aus einer Anzeigentechnologie zugeordnet wird, die keine Weiterleitungen auslöst, kann der Werbetreibende oder Analysepartner einen aggregierbaren Bericht erhalten, in dem die in Schritt 2 definierten Schlüsselelemente für Quelle und Trigger kombiniert werden.

Quellenregistrierung

Bei der Quellenregistrierung kann das AdTech-Netzwerk, das die Anzeigen ausliefert, seine Schlüssel für die Quellenaggregation oder einen Teil davon freigeben, anstatt weiterzuleiten. Die Anzeigentechnologie, über die Anzeigen ausgeliefert werden, muss diese Quellschlüssel nicht in ihren eigenen aggregierten Berichten verwenden. Sie kann sie bei Bedarf nur im Namen des Werbetreibenden oder des Analysepartners deklarieren.

Gemeinsam genutzte Aggregationsschlüssel sind für alle Anzeigentechnologien verfügbar, die einen Trigger für denselben Werbetreibenden registrieren. Die Entscheidung darüber, welche Aggregationsschlüssel erforderlich sind, wie sie heißen und wie sie in lesbare Dimensionen decodiert werden, liegt jedoch in der Verantwortung der Anzeigentechnologie für die Anzeigenbereitstellung und der Anzeigentechnologie für die Triggermessung.

Triggerregistrierung

Bei der Triggerregistrierung wählt die Messtechnologie aus, welche Quellschlüsselteile auf die einzelnen Triggerschlüsselteile angewendet werden sollen, einschließlich derjenigen, die von Technologien für die Anzeigenbereitstellung freigegeben werden.

Außerdem muss die AdTech-Plattform für die Analyse die Abfolge der Attributionslogik mit einem neuen API-Aufruf für die Attributionskonfiguration angeben. In dieser Konfiguration kann die Anzeigentechnologie die Quellenpriorität, das Ablaufdatum und Filter für Quellen angeben, die nicht sichtbar waren (z. B. Quellen ohne Weiterleitung).

Attribution

Die Attribution Reporting API führt eine nach Quelle priorisierte Attribution nach dem letzten Touchpoint für die Analyse-Werbetechnologie durch. Dabei werden die Attributionskonfiguration, freigegebene Schlüssel und alle registrierten Quellen berücksichtigt. Beispiel:

• Der Nutzer hat auf Anzeigen geklickt, die von den Anzeigentechnologien A, B, C und D ausgeliefert wurden. Der Nutzer hat dann die App des Werbetreibenden installiert, in der ein Analysepartner für Anzeigentechnologien (MMP) verwendet wird.
• Ad Tech A leitet seine Quellen an die MMP weiter.
• Die Anzeigentechnologien B und C führen nicht weiter, teilen aber ihre Aggregationsschlüssel.
• Die Anzeigentechnologie D leitet weder weiter noch gibt sie Aggregationsschlüssel weiter.

Die MMP registriert eine Quelle von Anzeigentechnologie A und definiert eine Attributionskonfiguration, die Anzeigentechnologie B und Anzeigentechnologie D umfasst.

Die Attribution für die MMP umfasst jetzt:

• Anzeigentechnologie A, da die MMP eine Quelle über die Weiterleitung dieser Anzeigentechnologie registriert hat.
• Anbieter B, da Anbieter B Schlüssel freigegeben hat und die MMP diese in die Attributionskonfiguration aufgenommen hat.

Die Attribution für die MMP umfasst nicht:

• Anzeigentechnologie C, da sie nicht in die Attributionskonfiguration der MMP aufgenommen wurde.
• Anbieter D, da er weder eine Weiterleitung durchgeführt noch Aggregationsschlüssel geteilt hat.

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

Debugging

Zur Unterstützung der Fehlerbehebung bei der netzwerkübergreifenden Attribution ohne Weiterleitungen steht Anbietern von Anzeigentechnologien bei der Quellenregistrierung ein zusätzliches Feld (shared_debug_key) zur Verfügung. Wenn Sie diese Option bei der Registrierung der ursprünglichen Quelle festlegen, wird sie bei der Triggerregistrierung auch für die entsprechende abgeleitete Quelle als debug_key festgelegt, um eine netzwerkübergreifende Attribution ohne Weiterleitungen zu ermöglichen. Dieser Debug-Schlüssel wird in Ereignis- und zusammengefassten Berichten als source_debug_key angehängt.

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

• App-zu-App-Analyse, bei der die AdId zulässig ist
• App-zu-Web-Analyse, bei der die Anzeigen-ID zulässig ist und sowohl in der App-Quelle als auch im Webtrigger übereinstimmt
• Web-zu-Web-Analyse (in derselben Browser-App), wenn ar_debug sowohl in der Quelle als auch im Trigger vorhanden ist

Schlüsselermittlung für die netzwerkübergreifende Attribution ohne Weiterleitungen

Die Schlüsselermittlung soll die Implementierung der Attributionskonfiguration von Anzeigentechnologien (in der Regel MMPs) für die netzwerkübergreifende Attribution vereinfachen, wenn eine oder mehrere Anzeigentechnologien für die Auslieferung gemeinsame Aggregationsschlüssel verwenden (wie oben unter Netzwerkübergreifende Attribution ohne Weiterleitungen beschrieben).

Wenn eine MMP den Aggregationsdienst abfragt, um Zusammenfassungsberichte für Kampagnen zu generieren, die abgeleitete Quellen enthalten, muss die MMP die Liste der möglichen Schlüssel als Eingabe für den Aggregationsjob angeben. In einigen Fällen kann die Liste der potenziellen Schlüssel für die Quellenaggregation sehr lang oder unbekannt sein. Große Listen mit möglichen Schlüsseln sind schwierig zu verfolgen und wahrscheinlich auch ziemlich komplex und teuer in der Verarbeitung. Betrachten Sie hierzu folgende Beispiele:

• Die Liste aller möglichen Schlüssel ist lang:
  • Ein Anzeigennetzwerk führt eine komplexe Initiative zur Nutzergewinnung durch, die 20 Kampagnen mit jeweils 10 Anzeigengruppen umfasst. Jede Anzeigengruppe enthält 5 Creatives, die jede Woche basierend auf der Leistung aktualisiert werden.
• Liste aller möglichen Schlüssel ist unbekannt:
  • Ein Werbenetzwerk liefert Anzeigen in vielen mobilen Apps aus, bei denen die vollständige Liste der App-IDs der Publisher zum Zeitpunkt der Kampagneneinrichtung nicht bekannt ist.
  • Ein Werbetreibender arbeitet mit mehreren Werbenetzwerken, die bei der Quellenregistrierung nicht zur MMP weiterleiten. Jedes Werbenetzwerk hat eine andere Schlüsselstruktur und andere Werte, die möglicherweise nicht vorab mit der MMP geteilt werden.

Durch die Einführung der Schlüsselerkennung:

• Für den Aggregationsdienst ist keine vollständige Aufzählung der möglichen Aggregationsschlüssel mehr erforderlich.
• Anstatt die vollständige Liste der möglichen Schlüssel angeben zu müssen, kann ein MMP einen leeren (oder teilweise leeren) Schlüsselsatz erstellen und einen Grenzwert festlegen, sodass nur (nicht vorab deklarierte) Schlüssel mit Werten, die den Grenzwert überschreiten, in die Ausgabe aufgenommen werden.
• MMP erhält einen Zusammenfassungsbericht mit Werten mit Rauschen für Schlüssel, deren Werte über dem festgelegten Grenzwert liegen. Der Bericht kann auch Schlüssel enthalten, die nicht mit Beiträgen echter Nutzer verknüpft sind und nur Rauschen enthalten.
• Das MMP verwendet das Feld x_network_bit_mapping bei der Triggerregistrierung, um zu ermitteln, welche Anzeigentechnologie welchem Schlüssel entspricht.
• Die MMP kann sich dann an die entsprechende Anzeigentechnologie wenden, um die Werte im Quellschlüssel zu erfahren.

Zusammenfassend lässt sich sagen, dass die Schlüsselermittlung es MMPs ermöglicht, Aggregationsschlüssel zu erhalten, ohne sie im Voraus zu kennen, und die Verarbeitung einer großen Anzahl von Quellschlüsseln zu vermeiden, was zu zusätzlichen Fehlern führen kann.

Hinweis: Diese Funktion befindet sich in der Vorschlagsphase und kann noch nicht getestet werden. Wir freuen uns auf Ihr Feedback und Ihre Kommentare.

Daisy-Chain-Weiterleitungen

Wenn ein Anbieter von Anzeigentechnologien mehrere Attribution-Reporting-Redirect-Header in einer HTTPS-Serverantwort für die Registrierung einer Quelle oder eines Triggers angibt, kann er mit der Attribution Reporting API mehrere Registrierungen von Quellen und Triggern mit einem einzigen API-Aufruf für die Registrierung ausführen.

In der Serverantwort kann die Anzeigentechnologie auch einen einzelnen Location-Header (302-Weiterleitung) mit einer URL enthalten, der wiederum zu einer weiteren Registrierung führt, bis zu einem festgelegten Limit.

Beide Arten von Headern sind optional. Wenn keine Weiterleitungen erforderlich sind, können auch keine angegeben werden. Es können entweder ein oder beide Arten von Headern angegeben werden. Bei Netzwerkausfällen werden Anfragen zur Registrierung von Quellen und Triggern (einschließlich Weiterleitungen) noch einmal versucht. Die Anzahl der Wiederholungsversuche pro Anfrage ist auf eine feste Anzahl beschränkt, um erhebliche Auswirkungen auf das Gerät zu vermeiden.

Weiterleitungen werden für „registerWebSource“ und „registerWebTrigger“ nicht akzeptiert. Weitere Informationen finden Sie im Leitfaden zur web- und appübergreifenden Implementierung.

Messdaten in Attributionsberichten ansehen

Mit der Attribution Reporting API können die folgenden Berichtstypen erstellt werden, die weiter unten auf dieser Seite genauer beschrieben werden:

• In Berichten auf Ereignisebene wird eine bestimmte Attributionsquelle (Klick oder Aufruf) mit wenigen High-Fidelity-Triggerdaten verknüpft.
• Zusammenfassungsfähige Berichte sind nicht unbedingt mit einer bestimmten Attributionsquelle verknüpft. Diese Berichte enthalten detailliertere 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 in einem der Zeitfenster für das Senden von Berichten an die Postback-URL der jeweiligen Anzeigentechnologie zurückgesendet werden kann. Weitere Informationen dazu finden Sie weiter unten auf dieser Seite.

Berichte auf Ereignisebene sind hilfreich, wenn nur sehr wenige Informationen zum Trigger erforderlich sind. Triggerdaten auf Ereignisebene sind auf 3 Bits für Klicks beschränkt, d. h. einem Trigger kann eine von acht Kategorien zugewiesen werden. Für Aufrufe ist nur 1 Bit verfügbar. Außerdem wird in Berichten auf Ereignisebene die Codierung von High-Fidelity-Triggerdaten wie einem bestimmten Preis oder einer bestimmten Triggerzeit nicht unterstützt. Da die Attribution auf Geräteebene erfolgt, werden in Berichten auf Ereignisebene keine geräteübergreifenden Analysen unterstützt.

Der Bericht auf Ereignisebene enthält unter anderem folgende Daten:

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

Datenschutzfreundliche Mechanismen, die auf alle Berichte angewendet werden

Die folgenden Limits werden angewendet, nachdem die Prioritäten für Attributionsquellen und Trigger berücksichtigt wurden.

Einschränkungen bei der Anzahl der Anzeigentechnologien

Die Anzahl der Anbieter von Anzeigentechnologien, die Berichte über die API registrieren oder empfangen können, ist begrenzt. Derzeit gilt Folgendes:

• 100 Anzeigentechnologien mit Attributionsquellen pro {source app, destination app, 30 days, device}.
• 10 Anzeigentechnologien mit zugeordneten Triggern pro {source app, destination app, 30 days, device}.
• 20 Anzeigentechnologien können eine einzelne Attributionsquelle oder einen einzelnen Trigger registrieren (über Attribution-Reporting-Redirect)

Limits für die Anzahl eindeutiger Ziele

Diese Einschränkungen erschweren es Werbetechnologien, sich zu verschwören, indem sie eine große Anzahl von Apps abfragen, um das App-Nutzungsverhalten eines bestimmten Nutzers zu ermitteln.

• Die API unterstützt für alle registrierten Quellen und alle Anzeigentechnologien nicht mehr als 200 eindeutige Ziele pro Quell-App und Minute.
• Für eine einzelne Anzeigentechnologie unterstützt die API für alle registrierten Quellen maximal 50 eindeutige Ziele pro Quell-App und Minute. So wird verhindert, dass eine einzelne Anzeigentechnologie das gesamte Budget des zuvor genannten Preislimits aufbraucht.

Abgelaufene Quellen werden nicht auf die Ratenlimits angerechnet.

Ein Berichtsorigin pro Quell-App und Tag

Eine bestimmte AdTech-Plattform kann nur eine Berichtsquelle verwenden, um Quellen in einer Publisher-App für ein bestimmtes Gerät am selben Tag zu registrieren. Diese Ratenbeschränkung verhindert, dass Anbieter von Anzeigentechnologien mehrere Berichtsquellen verwenden, um auf zusätzliches Datenschutzbudget zuzugreifen.

Stellen Sie sich folgendes Szenario vor: Eine einzelne Anzeigentechnologie möchte mehrere Berichtsquellen verwenden, um Quellen in einer Publisher-App für ein einzelnes Gerät zu registrieren.

1. Die Berichtsquelle 1 der Anzeigentechnologie A registriert eine Quelle in App B.
2. 12 Stunden später versucht der Berichts-Ursprung 2 der Anzeigentechnologie A, eine Quelle in App B zu registrieren.

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

Wartezeit und Ratenlimits

Um die Anzahl der Nutzeridentitäten, die zwischen einem {source, destination}-Paar weitergegeben werden, zu begrenzen, wird die Gesamtzahl der Informationen, die in einem bestimmten Zeitraum für einen Nutzer gesendet werden, von der API gedrosselt.

Derzeit wird vorgeschlagen, jede Anzeigentechnologie auf 100 zugeordnete Trigger pro {source app, destination app, 30 days, device} zu beschränken.

Anzahl der eindeutigen Ziele

Die API schränkt die Anzahl der Ziele ein, die eine Anzeigentechnologie messen kann. Je niedriger das Limit, desto schwieriger ist es für Anbieter von Anzeigentechnologien, mithilfe der API die Browseraktivitäten von Nutzern zu messen, die nicht mit ausgelieferten Anzeigen in Verbindung stehen.

Derzeit wird vorgeschlagen, jede Anzeigentechnologie auf 100 verschiedene Ziele mit nicht abgelaufenen Quellen pro Quell-App zu beschränken.

Datenschutzfreundliche Mechanismen für Berichte auf Ereignisebene

Begrenzte Genauigkeit von Triggerdaten

Die API bietet 1 Bit für Aufruf-Trigger und 3 Bits für Klick-Trigger. Attributionsquellen unterstützen weiterhin die vollen 64 Bit Metadaten.

Sie sollten prüfen, ob und wie Sie die in Triggern enthaltenen Informationen reduzieren können, damit sie mit der begrenzten Anzahl von Bits in Berichten auf Ereignisebene funktionieren.

Framework für Differential Privacy-Rauschen

Ein Ziel dieser API besteht darin, die Anforderungen an die lokale Differentiale Privatsphäre bei der Messung auf Ereignisebene zu erfüllen. Dazu werden k-zufällige Antworten verwendet, um für jedes Quellereignis eine verrauschte Ausgabe zu generieren.

Die Zufallszahlen werden angewendet, wenn ein Ereignis der Attributionsquelle nicht korrekt erfasst wird. Eine Attributionsquelle wird auf dem Gerät mit der Wahrscheinlichkeit 1 – p als normal registriert und mit der Wahrscheinlichkeit p wählt das Gerät zufällig einen der möglichen Ausgabestatus der API aus (einschließlich der Option, gar nichts zu melden oder mehrere gefälschte Berichte zu senden).

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

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

Bei niedrigen Werten von ε wird die tatsächliche Ausgabe durch den k-zufälligen Antwortmechanismus geschützt. Die genauen Rauschparameter sind noch in der Entwicklungsphase und können sich auf Grundlage von Feedback ändern. Derzeit wird Folgendes vorgeschlagen:

• 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 begrenzt. Derzeit gilt Folgendes:

• 1–2 Trigger für Attributionsquellen für Anzeigenaufrufe (2 Trigger sind nur bei der Attribution nach der Installation verfügbar)
• 3 Trigger für Quellen für die Klickattribution bei Anzeigen

Hinweis :Hier wird das Standard-API-Verhalten für die Anzahl der Attributionen pro Quelle beschrieben, die Berichte auf Ereignisebene verwenden. Mit der Einführung von flexiblen Berichten auf Ereignisebene im Oktober 2023 können Anbieter von Anzeigentechnologien diese Dimension ihrer Berichte jetzt so konfigurieren, wie es 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, darf aber nicht kürzer als 1 Tag oder länger als 30 Tage sein. Wenn einer Anzeigenaufruf-Attributionsquelle zwei Trigger zugeordnet werden (über die Attribution nach der Installation), können Berichte auf Ereignisebene in den folgenden Berichtszeitraumintervallen gesendet werden.

Berichte auf Ereignisebene für Quellen der Attribution von Anzeigenklicks können nicht konfiguriert werden. Sie werden vor oder nach Ablauf der Quelle zu bestimmten Zeitpunkten relativ zum Zeitpunkt der Registrierung gesendet. Der Zeitraum zwischen der Attributionsquelle und dem Ablauf wird in mehrere Berichtszeitraume unterteilt. Für jedes Berichtszeitraum gibt es eine Frist (ab der Zeit der Attributionsquelle). Am Ende jedes Berichtszeitraums erfasst das Gerät alle Trigger, die seit dem vorherigen Berichtszeitraum aufgetreten sind, und sendet einen geplanten Bericht. Die API unterstützt die folgenden Berichtszeitraume:

• 2 Tage:Auf dem Gerät werden alle Trigger erfasst, die höchstens zwei Tage nach der Registrierung der Attributionsquelle aufgetreten sind. Der Bericht wird 2 Tage und 1 Stunde nach der Registrierung der Attributionsquelle gesendet.
• 7 Tage:Auf dem Gerät werden alle Trigger erfasst, die mehr als 2 Tage, aber nicht mehr als 7 Tage nach der Registrierung der Attributionsquelle aufgetreten sind. Der Bericht wird 7 Tage und 1 Stunde nach der Registrierung der Attributionsquelle gesendet.
• Eine benutzerdefinierte Zeitspanne,die durch das Attribut „expiry“ einer Attributionsquelle definiert wird. Der Bericht wird eine Stunde nach dem angegebenen Ablaufdatum gesendet. Dieser Wert darf nicht kleiner als 1 Tag oder größer als 30 Tage sein.

Hinweis :Hier wird das standardmäßige API-Verhalten für Berichtszeitraum auf Ereignisebene beschrieben. Mit der Einführung von flexiblen Berichten auf Ereignisebene im Oktober 2023 können Anbieter von Anzeigentechnologien diese Dimension ihrer Berichte jetzt so konfigurieren, wie es für ihren Anwendungsfall am besten geeignet ist.

Flexible Konfiguration auf Ereignisebene

Die Standardkonfiguration für Berichte auf Ereignisebene wird Werbetreibenden empfohlen, wenn sie mit Nutzwerttests beginnen. Sie ist jedoch möglicherweise nicht für alle Anwendungsfälle ideal. Die Attribution Reporting API unterstützt optionale und flexiblere Konfigurationen, damit Anbieter von Anzeigentechnologien die Struktur ihrer Berichte auf Ereignisebene besser steuern und die Daten optimal nutzen können.

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

• Phase 1: Leichtgewichtige flexible Konfiguration auf Ereignisebene
  • Diese Version bietet einen Teil der Funktionen und kann unabhängig von Phase 2 verwendet werden.
• Phase 2: Vollständige Version der flexiblen Konfiguration auf Ereignisebene

Phase 1 (eingeschränkte flexible Ereignisebene) kann für Folgendes verwendet werden:

• Häufigkeit von Berichten durch Angabe der Anzahl der Berichtszeiträume variieren
• Anzahl der Attributionen pro Quellregistrierung variieren
• Reduzieren Sie den Gesamtgeräuschpegel, indem Sie die oben genannten Parameter verringern.
• Berichtszeitraum konfigurieren, anstatt die Standardeinstellungen zu verwenden

In Phase 2 (vollständig flexible Ereignisebene) können alle Funktionen von Phase 1 verwendet werden und:

• Kardinalität der Triggerdaten in einem Bericht ändern
• Reduzieren Sie die Gesamtmenge an Rauschen, indem Sie die Kardinalität der Triggerdaten verringern.

Wenn eine Dimension der Standardkonfiguration reduziert wird, kann die Anzeigentechnologie eine andere Dimension erhöhen. Alternativ lässt sich der Gesamtanteil an Rauschen in einem Bericht auf Ereignisebene reduzieren, indem die oben genannten Parameter insgesamt verringert werden.

Zusätzlich zu den dynamisch festgelegten Rauschpegelwerten, die auf der ausgewählten Konfiguration der Anzeigentechnologie basieren, werden wir einige Parameterlimits festlegen, um hohe Rechenkosten und Konfigurationen mit zu vielen Ausgabezuständen zu vermeiden, bei denen sich der Rauschpegel erheblich erhöht. Hier ist ein Beispiel für Einschränkungen: Wir freuen uns über Feedback zum [Designvorschlag][50]:

• Maximal 20 Berichte insgesamt, global und pro „trigger_data“
• Maximal 5 mögliche Berichtszeiträume pro „trigger_data“
• Maximal 32 Triggerdaten mit Kardinalität (nicht zutreffend für Phase 1: Lite-Flexible Event Level)

Wenn Sie diese Funktion verwenden, sollten Sie beachten, dass die Verwendung von Extremwerten zu einer großen Menge an Rauschen führen oder die Registrierung fehlschlagen kann, wenn die Datenschutzebenen nicht erfüllt sind.

Hinweis :Phase 1 (Lite-flexible Ereignisebene) wurde im Oktober 2023 als Betaversion veröffentlicht. Phase 2 (vollständig flexible Ereignisebene) soll im 1. Quartal 2024 als Betaversion veröffentlicht werden.

Aggregierbare Berichte

Bevor Sie aggregierbare Berichte verwenden können, müssen Sie Ihr Cloud-Konto einrichten und aggregierbare Berichte erhalten.

Aggregierbare Berichte liefern schneller und genauere Triggerdaten vom Gerät als Berichte auf Ereignisebene. Diese Daten mit höherer Auflösung können nur zusammengefasst erfasst werden und sind keinem bestimmten Trigger oder Nutzer zugeordnet. Aggregationsschlüssel können bis zu 128 Bit lang sein. So können Berichte mit zusammengefassten Daten folgende Anwendungsfälle unterstützen:

• Berichte zu Triggerwerten wie Umsatz
• Mehr Triggertypen verarbeiten

Außerdem wird in aggregierten Berichten dieselbe Attributionslogik mit Quellenpriorisierung verwendet wie in Berichten auf Ereignisebene. Sie unterstützen jedoch mehr Conversions, die einem Klick oder einer Aufrufe zugeordnet werden.

Im Diagramm ist dargestellt, wie die Attribution Reporting API aggregierbare Berichte vorbereitet und sendet:

1. Das Gerät sendet verschlüsselte aggregierbare Berichte an die Anzeigentechnologie. In einer Produktionsumgebung können diese Berichte nicht direkt verwendet werden.
2. Die Anzeigentechnologie sendet eine Reihe von aggregierbaren Berichten zur Aggregation an den Aggregationsdienst.
3. Der Aggregationsdienst liest eine Reihe von aggregierbaren Berichten, entschlüsselt sie und aggregiert sie.
4. Die endgültigen zusammengefassten Daten werden in einem Zusammenfassungsbericht an die Anzeigentechnologie gesendet.

Prozess, mit dem die Attribution Reporting API aggregierbare 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 Ereignis eingetreten ist, das durch die Attributionsquelle dargestellt wird.
• 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 Funktionen zur Datenaggregation und schützen vor unbefugtem Zugriff auf aggregierte Daten.

Diese Dienste werden von verschiedenen Anbietern verwaltet, die weiter unten auf dieser Seite genauer beschrieben werden:

• Der Aggregationsdienst ist der einzige, den Anbieter von Anzeigentechnologien bereitstellen müssen.
• Die Dienste zur Schlüsselverwaltung und zur aggregierbaren Berichtserfassung werden von vertrauenswürdigen Dritten namens Koordinatoren ausgeführt. Diese Koordinatoren bestätigen, dass der Code, mit dem der Aggregationsdienst ausgeführt wird, der öffentlich verfügbare Code von Google ist und dass für alle Nutzer des Aggregationsdienstes derselbe Schlüssel und dieselben aggregierbaren Berichtserfassungsdienste verwendet werden.

Aggregationsdienst

Anbieter von Anzeigentechnologien müssen vorab einen Aggregationsdienst bereitstellen, der auf von Google bereitgestellten Binärdateien basiert.

Dieser Aggregationsdienst wird in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) ausgeführt, die in der Cloud gehostet wird. TEEs bieten folgende Sicherheitsvorteile:

• So wird sichergestellt, dass der im TEE ausgeführte Code die von Google angebotene Binärdatei ist. Andernfalls kann der Aggregationsdienst nicht auf die Entschlüsselungsschlüssel zugreifen, die er für seinen Betrieb benötigt.
• Sie bietet Sicherheit für den laufenden Prozess und isoliert ihn von externer Überwachung oder Manipulation.

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

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

Key Management Service

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

Berichtserfassung, die aggregiert werden kann

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

Aggregatable Reports API

Die API zum Erstellen von Beiträgen zu aggregierten Berichten verwendet dieselbe Basis-API wie beim Registrieren 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 sendet, kann die Anzeigentechnologie eine Liste von Aggregationsschlüsseln mit dem Namen histogram_contributions registrieren, indem sie im HTTP-Header Attribution-Reporting-Register-Source mit einem neuen Feld namens aggregation_keys antwortet, wobei key_name als Schlüssel und key_piece als Wert verwendet wird:

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

Der endgültige Histogramm-Bucket-Schlüssel wird zum Zeitpunkt des Auslösers vollständig definiert, indem auf diese und die Trigger-Seiten-Teile ein binärer OR-Vorgang angewendet wird.

Die endgültigen Schlüssel sind auf maximal 128 Bit beschränkt. Längere Schlüssel werden abgeschnitten. Hexadezimalstrings in JSON sollten also auf maximal 32 Ziffern beschränkt sein.

Weitere Informationen zur Struktur und Konfiguration von Aggregationsschlüsseln

Im folgenden Beispiel erhebt eine Anzeigentechnologie mithilfe der API Folgendes:

• Conversion-Anzahl auf Kampagnenebene zusammenfassen
• 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 Triggerregistrierung umfasst zwei zusätzliche Felder.

Im ersten Feld wird eine Liste von Aggregationsschlüsseln auf der Triggerseite registriert. Die Anzeigentechnologie sollte mit dem Feld aggregatable_trigger_data im HTTP-Header Attribution-Reporting-Register-Trigger antworten und für jeden zusammengefassten Schlüssel in der Liste die folgenden Felder enthalten:

• Schlüsselelement: Ein Bitstringwert für den Schlüssel.
• Quellschlüssel:Eine Liste von Strings mit den Namen der Schlüssel auf Attributionsquellenseite, mit denen der Triggerschlüssel kombiniert werden soll, um die endgültigen Schlüssel zu bilden.

Im zweiten Feld wird eine Liste von Werten registriert, die zu jedem Schlüssel beitragen sollen. Die Anzeigentechnologie sollte mit dem Feld aggregatable_values im HTTP-Header Attribution-Reporting-Register-Trigger antworten. Im zweiten Feld wird eine Liste von Werten registriert, die zu jedem Schlüssel beitragen sollen. Dies können Ganzzahlen im Bereich $ [1, 2^{16}] $ sein.

Jeder Trigger kann mehrere Beiträge zu den aggregierten Berichten leisten. Die Gesamtzahl der Beiträge zu einem bestimmten Quellereignis ist durch einen $ L1 $-Parameter begrenzt. Das ist die maximale Summe der Beiträge (Werte) aller zusammengefassten Schlüssel für eine bestimmte Quelle. $ L1 $ bezieht sich auf die L1-Empfindlichkeit oder Norm der Histogramm-Beiträge pro Quellereignis. Wenn Sie diese Limits überschreiten, werden zukünftige Beiträge automatisch gelöscht. Der ursprüngliche Vorschlag besteht darin, $ L1 $ auf $ 2^{16} $ (65.536) festzulegen.

Das Rauschen im Aggregationsdienst wird proportional zu diesem Parameter skaliert. Daher wird empfohlen, die für einen bestimmten zusammengefassten Schlüssel gemeldeten Werte entsprechend dem zugewiesenen Anteil des L1-Budgets zu skalieren. So wird sichergestellt, dass die zusammengefassten Berichte bei der Anwendung von Rauschen möglichst genau bleiben. 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 auf beide aufgeteilt 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
    }
}

Das vorherige Beispiel generiert die folgenden Histogramm-Beiträge:

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

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

Die Skalierungsfaktoren können umgekehrt werden, um die richtigen Werte zu erhalten, bezogen auf den angewendeten Rauschen:

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

Differential Privacy

Ein Ziel dieser API ist es, ein Framework zu haben, das die differenzielle private aggregierte Analyse unterstützt. Dies kann durch Hinzufügen von Rauschen erreicht werden, das proportional zum L1-Budget ist. Dazu kann beispielsweise Rauschen mit der folgenden Verteilung ausgewählt werden:

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

Protected Audience API und Attribution Reporting API – Integration

Durch die API-übergreifende Integration der Protected Audience API und der Attribution Reporting API können Anbieter von Anzeigentechnologien ihre Attributionsleistung für verschiedene Remarketing-Taktiken bewerten, um zu ermitteln, mit welchen Zielgruppenarten der höchste ROI erzielt wird.

Durch diese API-übergreifende Integration haben Anbieter von Anzeigentechnologien folgende Möglichkeiten:

• Erstellen Sie eine Schlüssel/Wert-Zuordnung von URIs, die sowohl für 1) Interaktionsberichte als auch 2) die Quellenregistrierung verwendet werden soll.
• Fügen Sie CustomAudience in die schlüsselseitige Zuordnung auf Quellseite für zusammengefasste Berichte (mit der Attribution Reporting API) ein.

Wenn ein Nutzer eine Anzeige sieht oder darauf klickt:

• Die URL, über die diese Interaktionen mithilfe der Protected Audience API erfasst werden, wird auch verwendet, um einen Aufruf oder Klick als berechtigte Quelle mit der Attribution Reporting API zu registrieren.
• Die Anzeigentechnologie kann „CustomAudience“ oder andere relevante kontextbezogene Informationen zur Anzeige wie Anzeigen-Placement oder Wiedergabedauer über diese URL übergeben, damit diese Metadaten in Zusammenfassungsberichte übernommen werden, wenn die Anzeigentechnologie die Gesamtleistung der Kampagne überprüft.

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

Beispiele für Registrierungspriorität, Attribution und Berichte

In diesem Beispiel werden mehrere Nutzerinteraktionen gezeigt und wie sich die von der Anzeigentechnologie definierten Attributionsquellen- und Triggerprioritäten auf die zugeordneten Berichte auswirken können. 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 während des ersten Berichtszeitraums für Ereignisse erfasst (innerhalb von zwei Tagen nach der ersten Auslieferung der Anzeigen in einer Publisher-App).

Angenommen, ein Nutzer tut Folgendes:

1. Der Nutzer sieht eine Anzeige. Das AdTech-Unternehmen registriert eine Attributionsquelle mit der API und der Priorität 0 (Ansicht 1).
2. Der Nutzer sieht eine Anzeige mit der Priorität 0 (Aufruf 2).
3. Der Nutzer klickt auf eine Anzeige, die mit der Priorität 1 registriert wurde (Klick 1).
4. Der Nutzer tätigt eine Conversion (erreicht die Landingpage) in der App eines Werbetreibenden. Die Anzeigentechnologie 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.
   • Es sind drei Attributionsquellen verfügbar: Aufruf 1, Aufruf 2 und Klick 1. Die API ordnet diesen Trigger dem Klick 1 zu, da er die höchste Priorität hat und der jüngste ist.
   • Die Daten zu Datenaufruf 1 und Datenaufruf 2 werden verworfen und können nicht mehr für zukünftige Attributionen 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-Attribute dieses Triggers fordern zum Klicken auf 1 auf.
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-Attribute dieses Triggers fordern zum Klicken auf 1 auf.
7. Der Nutzer legt in der App des Werbetreibenden einen Artikel in den Einkaufswagen, der mit der Priorität 1 (Conversion 4) registriert ist.
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute dieses Triggers fordern zum Klicken auf 1 auf.
8. Der Nutzer tätigt einen Kauf in der App des Werbetreibenden, der mit der Priorität 2 (Conversion 5) registriert ist.
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute dieses Triggers fordern zum Klicken auf 1 auf.

Berichte auf Ereignisebene haben folgende Merkmale:

• Standardmäßig werden die ersten drei Trigger, die einem Klick zugeordnet sind, und der erste Trigger, der einer Datenansicht zugeordnet ist, nach den entsprechenden Berichtszeiträumen gesendet.
• Wenn im Berichtszeitraum Trigger mit höherer Priorität registriert sind, haben diese Vorrang und ersetzen den jeweils letzten Trigger.
• Im vorherigen Beispiel erhält die Anzeigentechnologie nach dem Berichtszeitraum von zwei Tagen drei Ereignisberichte für Conversion 2, Conversion 3 und Conversion 5.
  • Alle fünf Trigger werden dem 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 von Conversion 1 (0). Der Ereignisbericht für Conversion 4 ersetzt den Ereignisbericht für Conversion 1, der gesendet wird.
  • Außerdem hat Conversion 5 (2) eine höhere Priorität als alle anderen Trigger. Der Ereignisbericht für Conversion 5 ersetzt den Bericht für Conversion 4, der gesendet wird.

Für Berichte, die zusammengefasst werden können, gelten die folgenden Eigenschaften:

• Verschlüsselte aggregierbare Berichte werden an die Anzeigentechnologie gesendet, sobald sie verarbeitet wurden, also einige Stunden nach der Registrierung der Trigger.

  Als Anbieter von Anzeigentechnologien erstellen Sie die Batches anhand der Informationen, die unverschlüsselt in Ihren aggregierbaren Berichten enthalten sind. Diese Informationen sind im Feld shared_info Ihres aggregierbaren Berichts enthalten und umfassen den Zeitstempel und den Berichtsoriginator. Sie können keine Batch-Dateien auf der Grundlage verschlüsselter Informationen in Ihren Aggregations-Schlüssel/Wert-Paaren erstellen. Sie können beispielsweise Berichte täglich oder wöchentlich im Batch erstellen. Idealerweise sollten die Batches jeweils mindestens 100 Berichte enthalten.

• Die Entscheidung, wann und wie die aggregierbaren Berichte in Batches zusammengefasst und an den Aggregationsdienst gesendet werden, liegt beim Anbieter der Anzeigentechnologie.

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

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

Berichte zur Übergangsphase

Die Attribution Reporting API ist eine neue und ziemlich komplexe Möglichkeit, Attributionsmessungen ohne appübergreifende IDs durchzuführen. Daher unterstützen wir einen Übergangsmechanismus, mit dem Sie mehr Informationen zu Attributionsberichten erhalten, wenn die Werbe-ID verfügbar ist (der Nutzer die Personalisierung mithilfe der Werbe-ID nicht deaktiviert hat und die App des Publishers oder Werbetreibenden die Berechtigungen für die Werbe-ID erklärt hat). So lässt sich die API während des Roll-outs vollständig verstehen, Fehler können leichter behoben und die Leistung einfacher mit datenbasierten Alternativen verglichen werden. Es gibt zwei Arten von Berichten zur Fehlerbehebung: „attribution-success“ und „verbose“.

In der Anleitung zu Berichten zur Fehlerbehebung in der Übergangsphase finden Sie weitere Informationen zu Berichten zur Fehlerbehebung mit App-zu-Web- und Web-zu-App-Messung.

Berichte zur Fehlerbehebung bei Attributionserfolg

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

Wenn ein Bericht sowohl mit Quell- als auch mit Trigger-Debugging-Schlüsseln erstellt wird, wird ein duplizierter Debugging-Bericht mit kurzer Verzögerung an einen .well-known/attribution-reporting/debug/report-event-attribution-Endpunkt gesendet. Die Debug-Berichte sind mit normalen Berichten identisch, einschließlich der beiden Debug-Schlüsselfelder. Wenn Sie diese Schlüssel in beiden einbinden, können Sie normale Berichte mit dem separaten Debug-Berichtsstream verknüpfen.

• Für Berichte auf Ereignisebene:
  • Duplikate von Debugberichten werden mit nur kurzer Verzögerung gesendet und daher nicht durch Einschränkungen der verfügbaren Trigger unterdrückt. So können Anbieter von Anzeigentechnologien die Auswirkungen dieser Einschränkungen auf Berichte auf Ereignisebene nachvollziehen.
  • Berichte auf Ereignisebene, die mit falsch ausgelösten Ereignissen verknüpft sind, enthalten keine trigger_debug_key. So können Anbieter von Anzeigentechnologien besser nachvollziehen, wie Rauschen in der API angewendet wird.
• Für aggregierbare Berichte:
  • Wir unterstützen das neue Feld debug_cleartext_payload, das die entschlüsselte Nutzlast enthält, nur dann, wenn sowohl source_debug_key als auch trigger_debug_key festgelegt sind.

Detaillierte Debugging-Berichte

Mit ausführlichen Debugging-Berichten können Entwickler bestimmte Fehler in der Attributionsquelle oder bei Triggerregistrierungen beobachten. Diese Berichte zur Fehlerbehebung werden nach der Registrierung einer Attributionsquelle oder eines Triggers mit einer kurzen Verzögerung an einen gesendet.well-known/attribution-reporting/debug/verbose-Endpunkt.

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

• Typ: Gibt an, was zum Generieren des Berichts geführt hat. Vollständige Liste der ausführlichen Berichtstypen
  • Im Allgemeinen gibt es ausführliche Berichte zu Quellen und ausführliche Berichte zu Triggern.
  • Für ausführliche Berichte zu Quellen muss die Werbe-ID für die Publisher-App verfügbar sein. Für ausführliche Berichte zu Auslösern 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 die source_debug_key enthalten. Diese Angabe ist nur zulässig, wenn die Werbe-ID auch für die Publisher-App verfügbar ist.
• Textkörper: Der Textkörper des Berichts, der vom Typ des Berichts abhängt.

Anbieter von Anzeigentechnologien müssen die Option zum Empfangen ausführlicher Debugging-Berichte aktivieren. Dazu müssen sie in den Attribution-Reporting-Register_Source- und Attribution-Reporting-Register-Trigger-Headern ein neues Wörterbuchfeld vom Typ debug_reporting hinzufügen.

• Für ausführliche Berichte zu Quellen ist nur eine Aktivierung in der Kopfzeile der Quellenregistrierung erforderlich.
• Für Berichte zum Debuggen von Triggern muss nur die Kopfzeile der Triggerregistrierung aktiviert werden.

Debug-Berichte verwenden

Wenn eine Conversion (gemäß Ihrem vorhandenen Analysesystem) stattgefunden hat und für diese Conversion ein Debug-Bericht empfangen wurde, wurde der Trigger erfolgreich registriert.

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

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

Funktioniert wie vorgesehen:

• Datenschutzfreundliche API-Verhaltensweisen:
  • Ein Nutzer erreicht die Obergrenze für die Berichtsrate, wodurch alle nachfolgenden Berichte im angegebenen Zeitraum nicht gesendet werden. Eine Quelle wird aufgrund des ausstehenden Ziellimits entfernt.
  • Bei Berichten auf Ereignisebene: Der Bericht ist zufälligen Antworten (Störungen) ausgesetzt und wird unterdrückt. Möglicherweise erhalten Sie einen zufälligen Bericht.
  • Für Berichte auf Ereignisebene: Die maximale Anzahl von drei Berichten (für Klicks) oder einem Bericht (für Aufrufe) wurde erreicht und für nachfolgende Berichte wurde keine explizite Priorität festgelegt oder die Priorität ist niedriger als die der vorhandenen Berichte.
  • Die Beitragslimits für aggregierbare Berichte wurden überschritten.
• Von der Anzeigentechnologie 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 ausschaltet)

Unbeabsichtigte Ursachen:

• Probleme bei der Implementierung:
  • Der Quellheader ist falsch konfiguriert.
  • Der Trigger-Header ist falsch konfiguriert.
  • Andere Konfigurationsprobleme.
• Geräte- oder Netzwerkprobleme:
  • Fehler aufgrund von Netzwerkbedingungen
  • Die Antwort auf die Registrierung der Quelle oder des Triggers erreicht den Client nicht.
  • API-Fehler.

Zukünftige Überlegungen und offene Fragen

Die Attribution Reporting API befindet sich noch in der Entwicklungsphase. Wir arbeiten auch an potenziellen zukünftigen Funktionen wie Attributionsmodellen, bei denen nicht nur der letzte Klick berücksichtigt wird, und geräteübergreifenden Analysefällen.

Außerdem möchten wir von der Community Feedback zu einigen Themen einholen:

1. Gibt es Anwendungsfälle, in denen Sie möchten, dass die API Berichte für die bestätigte Installation sendet? Diese Berichte werden auf die jeweiligen Ratenlimits der AdTech-Plattformen angerechnet.
2. Können Sie sich vorstellen, dass es Probleme geben könnte, die InputEvent von der App an die Anzeigentechnologie für die Quellenregistrierung weiterzuleiten?
3. Haben Sie spezielle Attributions-Anwendungsfälle für vorinstallierte oder neu installierte Apps?