Attributionsberichte für Mobilgeräte – Übersicht

Letzte Updates

• Die Liste der bevorstehenden Änderungen und bekannten Probleme wurde aktualisiert.

• Wir führen die Funktion „Erneute Anfrage“ ein, die voraussichtlich im 2. Halbjahr 2025 eingeführt wird. Durch erneutes Abfragen können Ad-Tech-Unternehmen Aggregationsdienstberichte mehrmals verarbeiten und so flexible Analysen für unterschiedliche Messanforderungen ermöglichen. Nehmen Sie an der Diskussion auf GitHub teil, um mehr zu erfahren und Feedback zu geben.

Übersicht

Heutzutage werden dienstleisterübergreifende 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 hat die folgenden strukturellen Mechanismen, die einen Rahmen für die Verbesserung des Datenschutzes bieten. Diese werden in den späteren Abschnitten auf dieser Seite genauer beschrieben:

• Beschränkt die Anzahl der für Berichte auf Ereignisebene verfügbaren Bits.

• Ermöglicht Conversion-Daten mit höherer Genauigkeit nur in aggregierbaren Berichten

• Es werden Ratenbeschränkungen für verfügbare Trigger (Conversions) und die Anzahl der Ad-Tech-Anbieter eingeführt, die mit einer einzelnen Attributionsquelle verknüpft werden können.

• Es werden verschiedene Techniken zum Hinzufügen von Rauschen verwendet.

Die oben genannten Mechanismen schränken die Möglichkeit ein, 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:Damit können Werbetreibende die Leistung ihrer Kampagnen messen. Dazu werden Conversion-Zahlen (Trigger) und Conversion-Werte (Trigger) für verschiedene Dimensionen wie Kampagne, Anzeigengruppe und Creative angezeigt.
• Optimierung:Berichte auf Ereignisebene mit Attributionsdaten auf Impressionsebene, die zum Trainieren von ML-Modellen verwendet werden können, unterstützen die Optimierung der Werbeausgaben.
• Erkennung unzulässiger Aktivitäten:Bereitstellung von Berichten, die zur Erkennung und Analyse von unzulässigem Traffic und Anzeigenbetrug verwendet werden können.

Auf hoher Ebene funktioniert die Attribution Reporting API so, wie in den späteren Abschnitten dieses Dokuments ausführlicher beschrieben:

1. Das AdTech-Unternehmen schließt einen Registrierungsprozess ab, um die Attribution Reporting API zu verwenden.
2. Die AdTech registriert Attributionsquellen – Anzeigenklicks oder ‑aufrufe – mit der Attribution Reporting API.
3. Die AdTech registriert Trigger – Nutzer-Conversions in der App oder auf der Website des Werbetreibenden – mit der Attribution Reporting API.
4. In der Attribution Reporting API werden Trigger mit Attributionsquellen abgeglichen (Conversion-Attribution). Ein oder mehrere Trigger werden über Berichte auf Ereignisebene und aggregierbare Berichte an AdTech-Unternehmen gesendet.

Zugriff auf die 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 Für ein Privacy Sandbox-Konto registrieren.

Attributionsquelle registrieren (Klick oder Aufruf)

In der Attribution Reporting API werden Anzeigenklicks und ‑aufrufe als Attributionsquellen bezeichnet. Rufen Sie registerSource() auf, um einen Anzeigenklick oder eine Anzeigenimpression zu registrieren. Für diese API sind die folgenden Parameter erforderlich:

• URI der Attributionsquelle:Die Plattform sendet eine Anfrage an diesen URI, um Metadaten abzurufen, die der Attributionsquelle zugeordnet 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 Ad-Tech-Plattform 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 (Anzeigenklick oder ‑aufruf) verknüpft sind. Muss eine 64-Bit-Ganzzahl ohne Vorzeichen sein, die als String formatiert ist.
• Ziel: Ein Ursprung, dessen eTLD+1 oder App-Paketname das Triggerereignis auslöst.
• Ablauf (optional): Ablaufzeit in Sekunden, nach der die Quelle vom Gerät gelöscht werden soll. Der Standardwert ist 30 Tage, der Mindestwert 1 Tag und der Höchstwert 30 Tage. Das Ergebnis wird auf den nächsten Tag gerundet. Kann als vorzeichenlose 64-Bit-Ganzzahl oder als String formatiert werden.
• Zeitraum für Ereignisberichte (optional): Dauer in Sekunden nach der Quellenregistrierung, in der Ereignisberichte für diese Quelle erstellt werden dürfen. Wenn das Zeitfenster für Ereignisberichte abgelaufen ist, die Ablaufzeit jedoch noch nicht, kann ein Trigger weiterhin mit einer Quelle abgeglichen werden. Für diesen Trigger wird jedoch kein Ereignisbericht gesendet. Darf nicht größer als das Ablaufdatum sein. Kann entweder als vorzeichenlose 64-Bit-Ganzzahl oder als String formatiert werden.
• Zeitraum für aggregierbare Berichte (optional): Dauer in Sekunden nach der Quellenregistrierung, in der aggregierbare Berichte für diese Quelle erstellt werden können. Darf nicht größer als das Ablaufdatum sein. Kann als 64-Bit-Ganzzahl ohne Vorzeichen oder als String formatiert werden.
• Quellpriorität (optional): Wird verwendet, um auszuwählen, welcher Attributionsquelle ein bestimmter Trigger zugeordnet werden soll, falls mehrere Attributionsquellen mit dem Trigger verknüpft werden könnten. Muss eine vorzeichenbehaftete 64-Bit-Ganzzahl sein, die als String formatiert ist.
  
   Wenn ein Trigger empfangen wird, sucht die API nach der übereinstimmenden Attributionsquelle mit dem höchsten Quellprioritätswert und generiert einen Bericht. Jede Ad-Tech-Plattform kann ihre eigene Priorisierungsstrategie definieren. Weitere Informationen dazu, wie sich die Priorität auf die Zuordnung auswirkt, finden Sie im Abschnitt Priorisierungsbeispiel.
  
   Höhere Werte bedeuten höhere Prioritäten.
• Attributionszeiträume für Installationen und Post-Install-Aktionen (optional): Werden verwendet, um die Attribution für Post-Install-Ereignisse zu bestimmen, die weiter unten auf dieser Seite beschrieben werden.
• Daten filtern (optional): Damit lassen sich bestimmte Trigger selektiv filtern und somit 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 Antwort mit Metadaten zur Attributionsquelle zusätzliche Daten im Header Attribution reporting redirects enthalten. Die Daten enthalten Weiterleitungs-URLs, die es mehreren Ad-Tech-Anbietern ermöglichen, eine Anfrage zu registrieren.

Das Entwicklerhandbuch enthält Beispiele, die zeigen, wie die Quellregistrierung akzeptiert wird.

Die folgenden Schritte zeigen einen Beispielworkflow:

1. Das Ad-Tech-SDK ruft die API auf, um die Registrierung der Attributionsquelle zu starten. Dabei wird ein URI für den API-Aufruf angegeben:

   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 mit einem der folgenden Header:

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

3. Der HTTPS-Server dieses Ad-Tech-Unternehmens 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. Über die API wird eine Anfrage an jede in Attribution-Reporting-Redirect angegebene URL gesendet. In diesem Beispiel werden zwei URLs von Ad-Tech-Partnern angegeben. Die API sendet also eine Anfrage an https://adtechpartner1.example?their_ad_click_id=567 und eine weitere Anfrage an https://adtechpartner2.example?their_ad_click_id=890.

5. Der HTTPS-Server dieses Ad-Tech-Unternehmens antwortet mit Headern, die Folgendes enthalten:

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

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

Attributionsquelle über WebView registrieren

WebView unterstützt den Anwendungsfall, in dem eine App eine Anzeige in einer WebView rendert. Dies wird von WebView übernommen, indem registerSource() direkt aufgerufen wird. Bei diesem Aufruf wird die Attributionsquelle der App anstelle des Ursprungs auf oberster Ebene zugeordnet. Die Registrierung von Quellen aus eingebetteten Webinhalten in einem Browserkontext wird ebenfalls unterstützt. Sowohl API-Aufrufer als auch Apps müssen dazu Einstellungen anpassen. Eine Anleitung für API-Aufrufer finden Sie unter Attributionsquelle und ‑trigger über WebView registrieren und eine Anleitung für Apps unter Attributionsquelle und ‑trigger über WebView registrieren.

Da Ad-Tech-Unternehmen gemeinsamen Code für Web und WebView verwenden, folgt WebView HTTP 302-Weiterleitungen und gibt 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 an uns, wenn Sie einen betroffenen Anwendungsfall haben.

Trigger (Conversion) registrieren

Ad-Tech-Plattformen können Trigger – Conversions wie Installationen oder Post-Install-Ereignisse – mit der registerTrigger()-Methode registrieren.

Für die Methode registerTrigger() ist der Parameter Trigger-URI erforderlich. Die API sendet eine Anfrage an diesen URI, um Metadaten abzurufen, die mit dem Trigger verknüpft sind.

Die API folgt Weiterleitungen. Die Antwort des Ad-Tech-Servers sollte einen HTTP-Header namens Attribution-Reporting-Register-Trigger enthalten, der Informationen zu einem oder mehreren registrierten Triggern enthält. 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.

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

• Schlüssel für die Deduplizierung (optional): Wird verwendet, um Fälle zu identifizieren, in denen derselbe Trigger von derselben Ad-Tech-Plattform für dieselbe Attributionsquelle mehrmals registriert wird. Muss eine vorzeichenbehaftete 64-Bit-Ganzzahl sein, die als String formatiert ist.

• Aggregationsschlüssel (optional): Eine Liste von Schlüssel/Wert-Paaren, die Aggregationsschlüssel angibt und für welche aggregierbaren Berichte der Wert aggregiert werden soll.

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

• Filter (optional): Dienen dazu, Trigger oder Triggerdaten selektiv zu filtern. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Triggerfilter.

Optional kann die Antwort des Ad-Tech-Servers zusätzliche Daten im Header Attribution Reporting Redirects enthalten. Die Daten enthalten Weiterleitungs-URLs, über die mehrere Ad-Tech-Unternehmen eine Anfrage registrieren können.

Mehrere Ad-Tech-Anbieter können dasselbe Triggerereignis registrieren. Dazu können sie entweder Weiterleitungen im Feld Attribution-Reporting-Redirect oder mehrere Aufrufe der Methode registerTrigger() verwenden. Wir empfehlen, das Feld Deduplizierungsschlüssel zu verwenden, um zu vermeiden, dass doppelte Trigger in Berichte aufgenommen werden, wenn dieselbe Ad-Tech-Lösung mehrere Antworten für dasselbe Triggerereignis liefert. Weitere Informationen zur Verwendung eines Deduplizierungsschlüssels

Das Entwicklerhandbuch enthält Beispiele, die zeigen, wie Sie die Registrierung von Triggern akzeptieren.

Die folgenden Schritte zeigen einen Beispielworkflow:

1. Das AdTech-SDK ruft die API auf, um die Triggerregistrierung mit einem vorab registrierten URI zu starten. Weitere Informationen

   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 dieses Ad-Tech-Unternehmens 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
   

4. Über die API wird eine Anfrage an jede in Attribution-Reporting-Redirect angegebene URL gesendet. In diesem Beispiel wird nur eine URL angegeben, sodass die API eine Anfrage an https://adtechpartner.example?app_install=567 sendet.

5. Der HTTPS-Server dieses Ad-Tech-Unternehmens antwortet mit Headern, die Folgendes enthalten:

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

   Auf Grundlage der Anfragen in den vorherigen Schritten werden zwei Trigger registriert.

Attributionsfunktionen

In den folgenden Abschnitten wird beschrieben, wie die Attribution Reporting API Conversion-Trigger mit Attributionsquellen abgleicht.

Quellenpriorisierter Attributionsalgorithmus angewendet

Die Attribution Reporting API verwendet einen quellenpriorisierten Attributionsalgorithmus, um einen Trigger (Conversion) einer Attributionsquelle zuzuordnen.

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

• Sie können Triggern bestimmte Anzeigenereignisse zuordnen. Sie können beispielsweise mehr Wert auf Klicks als auf Aufrufe legen oder sich auf Ereignisse aus bestimmten Kampagnen konzentrieren.
• Sie können die Attributionsquelle und den Trigger so konfigurieren, dass Sie bei Erreichen von Ratenbeschränkungen eher die Berichte erhalten, die für Sie wichtiger sind. So können Sie beispielsweise dafür sorgen, dass gebotsfähige Conversions oder Conversions mit hohem Wert in diesen Berichten häufiger angezeigt werden.

Wenn mehrere AdTech-Unternehmen eine Attributionsquelle registrieren, wie später auf dieser Seite beschrieben, erfolgt die Zuordnung unabhängig für jedes AdTech-Unternehmen. Für jedes AdTech-Unternehmen 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 wurden, werden verworfen und können nicht mehr für die Trigger-Attribution verwendet werden.

Triggerfilter

Die Registrierung von Quelle und Trigger umfasst zusätzliche optionale Funktionen für Folgendes:

• Sie können bestimmte Trigger herausfiltern und so 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 Ad-Tech-Plattform während der Quell- und Triggerregistrierung Filterdaten angeben, die aus Schlüsseln und Werten bestehen. Wenn derselbe Schlüssel sowohl für die Quelle als auch für den Trigger angegeben wird, 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 Schlüssel für den Triggerfilter mit product übereinstimmt, werden die Filter ignoriert.

Ein weiteres Szenario, in dem Ad-Tech-Plattformen Trigger selektiv filtern möchten, ist, ein kürzeres Ablaufzeitfenster zu erzwingen. Bei der Triggerregistrierung kann ein AdTech-Unternehmen ein Lookback-Window (in Sekunden) ab dem Zeitpunkt der Conversion angeben. Ein 7-Tage-Lookback-Window würde beispielsweise so definiert: "_lookback_window": 604800 // 7d

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

Ad-Tech-Plattformen können auch Triggerdaten auf Grundlage von Quellereignisdaten auswählen. Beispiel: source_type wird von der API automatisch als navigation oder event generiert. Bei der Triggerregistrierung kann trigger_data als ein Wert für "source_type": ["navigation"] und als ein anderer Wert für "source_type": ["event"] festgelegt werden.

Trigger werden aus Berichten auf Ereignisebene ausgeschlossen, wenn eine der folgenden Bedingungen zutrifft:

• Es ist kein trigger_data angegeben.
• Für Quelle und Trigger wird derselbe Filterschlüssel angegeben, aber die Werte stimmen 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 Post-Install-Trigger derselben Attributionsquelle zugeordnet werden, die den Install ausgelöst hat, auch wenn es andere infrage kommende Attributionsquellen gibt, die erst später aufgetreten sind.

Die API kann diesen Anwendungsfall unterstützen, indem sie es Ad-Tech-Unternehmen ermöglicht, einen Zeitraum für die Attribution nach der Installation festzulegen:

• Geben Sie bei der Registrierung einer Attributionsquelle einen Zeitraum für die Installationsattribution an, in dem Installationen erwartet werden (in der Regel 2 bis 7 Tage, akzeptierter Bereich 1 bis 30 Tage). Geben Sie diesen Zeitraum als Anzahl von Sekunden an.
• Geben Sie beim Registrieren einer Attributionsquelle einen Zeitraum für die Exklusivität der Attribution nach der Installation an, in dem alle Triggerereignisse nach der Installation der Attributionsquelle zugeordnet werden sollen, die die Installation ausgelöst hat (in der Regel 7 bis 30 Tage, akzeptierter Bereich 0 bis 30 Tage). Geben Sie dieses Zeitfenster als Anzahl von Sekunden an.
• Die Attribution Reporting API validiert, wann eine App-Installation erfolgt, und ordnet die Installation intern der quellpriorisierten Attributionsquelle zu. Die Installation wird jedoch nicht an Ad-Tech-Unternehmen gesendet und nicht auf die jeweiligen Ratenbegrenzungen der Plattformen angerechnet.
• Die Validierung von App-Installationen ist für alle heruntergeladenen Apps verfügbar.
• Alle zukünftigen Trigger, die innerhalb des Attributionszeitraums nach der Installation erfolgen, werden derselben Attributionsquelle wie die validierte Installation zugeordnet, sofern diese Attributionsquelle infrage kommt.

Möglicherweise werden wir das Design in Zukunft erweitern, um komplexere Attributionsmodelle zu unterstützen.

In der folgenden Tabelle sehen Sie ein Beispiel dafür, wie Ad-Tech-Unternehmen die Attribution nach der Installation verwenden können. Angenommen, alle Attributionsquellen und Trigger werden vom selben Ad-Tech-Netzwerk registriert und alle Prioritäten sind gleich.

Die folgende Liste enthält 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 erfasst und nicht in Berichten angegeben. Sie werden nicht auf die Ratenbegrenzungen einer Ad-Tech-Plattform angerechnet. Bestätigte Installationen werden nur verwendet, um die Attributionsquelle zu ermitteln, der die Installation zugeordnet wird.
• Im Beispiel aus der vorherigen Tabelle stehen Trigger 1 und Trigger 2 für das erste Öffnen bzw. eine Conversion nach der Installation. Ad-Tech-Plattformen können jedoch beliebige Arten von Triggern registrieren. Der erste Trigger muss also nicht der Trigger für das erste Öffnen sein.
• Wenn nach Ablauf des post_install_exclusivity_window weitere Trigger registriert werden, kommt Klick 1 weiterhin für die Zuordnung infrage, sofern er nicht abgelaufen ist und die Ratenbegrenzungen nicht erreicht hat.
  • Klick 1 kann weiterhin verloren gehen oder verworfen werden, wenn eine Attributionsquelle mit höherer Priorität registriert wird.
• Wenn die App des Werbetreibenden deinstalliert und neu installiert wird, wird die Neuinstallation als neue bestätigte Installation gezählt.
• Wenn der erste Klick stattdessen ein Aufrufereignis war, werden sowohl das Ereignis vom Typ „Erstes Öffnen“ als auch die Trigger nach der Installation weiterhin diesem Ereignis zugeordnet. Die API beschränkt die Zuordnung auf einen Trigger pro Ansicht, mit Ausnahme der Zuordnung nach der Installation, bei der bis zu zwei Trigger pro Ansicht zulässig sind. Im Fall der Attribution nach der Installation kann die Ad-Tech-Plattform zwei verschiedene Berichtszeiträume erhalten (nach 2 Tagen 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 attribuiert werden:

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

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

Hier erfahren Sie, welche Änderungen Ad-Technologien und Apps vornehmen müssen, um Triggerpfade für app- und webübergreifende Analysen 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 einer oder mehreren Attributionsquellen gemäß dem quellenpriorisierten Attributionsalgorithmus zugeordnet, der weiter unten auf dieser Seite beschrieben wird.

Es gibt Beschränkungen für die Anzahl der Trigger, die einer einzelnen Attributionsquelle zugeordnet werden können. Weitere Informationen finden Sie weiter unten auf dieser Seite im Abschnitt Messdaten in Attributionsberichten ansehen.

Wenn es mehrere Trigger gibt, die über diese Grenzwerte hinausgehen, ist es sinnvoll, Priorisierungslogik einzuführen, um die wertvollsten Trigger zurückzugeben. Die Entwickler einer Ad-Tech-Lösung möchten beispielsweise lieber „Kauf“- als „In den Warenkorb“-Trigger erhalten.

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

Mehrere Ad-Tech-Unternehmen dürfen Attributionsquellen oder ‑trigger registrieren

Es ist üblich, dass mehr als eine Anzeigentechnologie Attributionsberichte erhält, in der Regel zur netzwerkübergreifenden Deduplizierung. Daher können mehrere Ad-Tech-Unternehmen dieselbe Attributionsquelle oder denselben Trigger registrieren. Ein AdTech-Unternehmen muss sowohl Attributionsquellen als auch Trigger registrieren, um Postbacks von der API zu erhalten. Die Zuordnung erfolgt zwischen den Attributionsquellen und Triggern, die das AdTech-Unternehmen bei der API registriert hat.

Werbetreibende, die einen Drittanbieter für die netzwerkübergreifende Deduplizierung verwenden möchten, können dies weiterhin tun. Dazu können sie eine ähnliche Technik wie die folgende nutzen:

• Einrichten eines internen Servers zum Registrieren und Empfangen von Berichten von der API.
• Sie verwenden weiterhin einen vorhandenen Partner für mobile Analysen.

Attributionsquellen

Weiterleitungen der Attributionsquelle werden in der Methode registerSource() unterstützt:

1. Die Ad-Tech-Plattform, die die registerSource()-Methode aufruft, kann in ihrer Antwort ein zusätzliches Attribution-Reporting-Redirect-Feld bereitstellen, das die Weiterleitungs-URLs der Ad-Tech-Plattform des Partners enthält.
2. Die API ruft dann die Weiterleitungs-URLs auf, damit die Attributionsquelle von den Ad-Tech-Partnern registriert werden kann.

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

Die API ermöglicht es auch, dass verschiedene Ad-Tech-Unternehmen registerSource() aufrufen.

Trigger

Für die Triggerregistrierung werden Drittanbieter auf ähnliche Weise unterstützt: Ad-Tech-Unternehmen können entweder das zusätzliche Feld Attribution-Reporting-Redirect verwenden oder die Methode registerTrigger() aufrufen.

Wenn ein Werbetreibender mehrere Anzeigentechnologien verwendet, um dasselbe Trigger-Ereignis zu erfassen, sollte ein Deduplizierungsschlüssel verwendet werden. Der Deduplizierungsschlüssel dient dazu, diese wiederholten Berichte desselben Ereignisses, die von derselben AdTech-Plattform erfasst wurden, zu unterscheiden. Beispiel: Eine Ad-Tech-Firma könnte ihr SDK die API direkt aufrufen lassen, um einen Trigger zu registrieren, und ihre URL im Weiterleitungsfeld des Aufrufs einer anderen Ad-Tech-Firma angeben. Wenn kein Deduplizierungsschlüssel angegeben wird, werden doppelte Trigger möglicherweise als eindeutig an die einzelnen Ad-Tech-Unternehmen gemeldet.

Doppelte Trigger verarbeiten

Eine Ad-Tech-Plattform kann denselben Trigger mehrmals bei der API registrieren. Szenarien umfassen Folgendes:

• Der Nutzer führt dieselbe Aktion (Trigger) mehrmals aus. Beispiel: Der Nutzer ruft dasselbe Produkt mehrmals im selben Berichtszeitraum auf.
• In der App des Werbetreibenden werden mehrere SDKs zur Conversion-Analyse verwendet, die alle zum selben Ad-Tech-Unternehmen weiterleiten. In der App des Werbetreibenden werden beispielsweise zwei Analysepartner verwendet: MMP #1 und MMP #2. Beide MMPs leiten zu AdTech 3 weiter. Wenn ein Trigger ausgelöst wird, registrieren beide MMPs ihn mit der Attribution Reporting API. Ad-Tech-Anbieter 3 erhält dann zwei separate Weiterleitungen für denselben Trigger – eine von MMP 1 und eine von MMP 2.

In diesen Fällen gibt es mehrere Möglichkeiten, Berichte auf Ereignisebene für doppelte Trigger zu unterdrücken, um die Wahrscheinlichkeit zu verringern, dass die Ratenbeschränkungen für Berichte auf Ereignisebene überschritten werden. Es wird empfohlen, einen Deduplizierungsschlüssel zu verwenden.

Empfohlene Methode: Deduplizierungsschlüssel

Die empfohlene Methode besteht darin, dass die App des Werbetreibenden einen eindeutigen Deduplizierungsschlüssel an alle Ad-Tech-Anbieter oder SDKs übergibt, die für die Conversion-Messung verwendet werden. Wenn eine Conversion erfolgt, übergibt die App einen Deduplizierungsschlüssel an die AdTech-Unternehmen oder SDKs. Diese Ad-Tech-Anbieter oder SDKs übergeben den Deduplizierungsschlüssel dann weiterhin über einen Parameter in den URLs, die in Attribution-Reporting-Redirect angegeben sind, an Weiterleitungen.

Ad-Tech-Unternehmen können nur den ersten Trigger mit einem bestimmten Deduplizierungsschlüssel oder mehrere oder alle Trigger registrieren. Ad-Tech-Unternehmen können die deduplication_key angeben, wenn sie doppelte Trigger registrieren.

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

Alternative Methode: Anzeigentechnologie-Anbieter einigen sich auf Trigger-Typen pro Werbetreibenden

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

Ad-Tech-Anbieter, die den Aufruf zur Triggerregistrierung initiieren, z. B. SDKs, fügen einen Parameter in URLs ein, die in Attribution-Reporting-Redirect angegeben sind, z. B. duplicate_trigger_id. Der Parameter duplicate_trigger_id kann Informationen wie den SDK-Namen und den Triggertyp für den jeweiligen Werbetreibenden enthalten. AdTechs können dann eine Teilmenge dieser doppelten Trigger an Berichte auf Ereignisebene senden. Ad-Tech-Unternehmen können duplicate_trigger_id auch in ihre Aggregationsschlüssel aufnehmen.

Beispiel für die netzwerkübergreifende Attribution

Im Beispiel in diesem Abschnitt verwendet der Werbetreibende zwei Ad-Serving-Werbetechnologieplattformen (Werbetechnologie A und Werbetechnologie B) und einen Analysepartner (MMP).

Zuerst müssen AdTech A, AdTech B und MMP die Registrierung abschließen, 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 finden Sie eine hypothetische Reihe von Nutzeraktionen, die jeweils einen Tag auseinander liegen, und wie die Attribution Reporting API diese Aktionen in Bezug auf Ad-Tech-A, Ad-Tech-B und MMP verarbeitet:

Tag 1: Der Nutzer klickt auf eine Anzeige, die von Ad-Tech-Unternehmen A ausgeliefert wird.

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

Ad-Tech-A nimmt auch den URI des MMP in den Attribution-Reporting-Redirect-Header auf. Die API sendet eine Anfrage an den URI des MMP und der Klick wird mit den Metadaten aus der Serverantwort des MMP registriert.

Tag 2: Der Nutzer klickt auf eine Anzeige, die von Ad-Tech-Unternehmen 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-Unternehmen B registriert.

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

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

Die API reagiert auf dieselbe Weise wie am ersten Tag, nur dass eine Impression für Ad-Tech-A und MMP registriert wird.

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

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

Der MMP enthält auch die URIs für Ad Tech A und Ad Tech B im Header Attribution-Reporting-Redirect. Die API sendet Anfragen an die Server von Ad-Tech-A und Ad-Tech-B. Die Conversion wird entsprechend mit den Metadaten aus den Serverantworten registriert.

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

Die Attribution funktioniert so:

• Bei Ad-Tech-A hat der Klick eine höhere Priorität als die Impression. Daher wird die Installation dem Klick am ersten Tag zugeordnet.
• Ad-Tech-Unternehmen B erhält die Installation am zweiten Tag.
• Das MMP weist Klicks eine höhere Priorität als Impressionen zu und ordnet die Installation dem Klick am zweiten Tag zu. Der Klick am zweiten Tag hat die höchste Priorität und ist das letzte Anzeigenereignis.

Netzwerkübergreifende Attribution ohne Weiterleitungen

Wir empfehlen zwar, Weiterleitungen zu verwenden, damit mehrere Ad-Tech-Anbieter Attributionsquellen und ‑trigger registrieren können, aber es gibt auch Szenarien, in denen Weiterleitungen nicht möglich sind. In diesem Abschnitt wird beschrieben, wie Sie die netzwerkübergreifende Zuordnung ohne Weiterleitungen unterstützen.

Allgemeiner Ablauf

1. Bei der Quellregistrierung gibt das Ad-Tech-Netzwerk, über das die Anzeige ausgeliefert wird, seine Quellaggregationsschlüssel weiter.
2. Bei der Triggerregistrierung wählt der Werbetreibende oder der Analysepartner aus, welche Quellschlüssel verwendet werden sollen, und gibt die Attributionskonfiguration an.
3. Die Zuordnung basiert auf der Attributionskonfiguration, den freigegebenen Schlüsseln und allen Quellen, die tatsächlich von diesem Werbetreibenden oder Messpartner registriert wurden (z.B. aus einem anderen Ad-Tech-Netzwerk, in dem Weiterleitungen aktiviert sind).
4. Wenn der Trigger einer Quelle aus einer Ad-Serving-Technologie ohne Weiterleitung zugeordnet wird, kann der Werbetreibende oder der Analysepartner einen aggregierbaren Bericht erhalten, in dem die in Schritt 2 definierten Quell- und Triggerschlüssel kombiniert werden.

Quellregistrierung

Bei der Quellregistrierung kann das Ad-Tech-Netzwerk, das die Anzeige bereitstellt, seine Quellaggregationsschlüssel oder eine Teilmenge seiner Quellaggregationsschlüssel freigeben, anstatt eine Weiterleitung vorzunehmen. Die Ad-Serving-Technologie muss diese Quellschlüssel nicht in ihren eigenen aggregierbaren Berichten verwenden und kann sie bei Bedarf nur im Namen des Werbetreibenden oder des Analysepartners deklarieren.

Gemeinsame Aggregationsschlüssel sind für alle Ad-Tech-Unternehmen verfügbar, die einen Trigger für denselben Werbetreibenden registrieren. Es liegt jedoch an der Ad-Tech für die Auslieferung und der Ad-Tech für die Trigger-Messung, zusammenzuarbeiten, um festzulegen, welche Arten von Aggregationsschlüsseln benötigt werden, wie sie heißen und wie die Schlüssel in lesbare Dimensionen decodiert werden.

Triggerregistrierung

Bei der Triggerregistrierung wählt die Ad-Tech-Plattform für Analysen aus, welche Quellschlüsselkomponenten auf die einzelnen Triggerschlüsselkomponenten angewendet werden sollen, einschließlich der Komponenten, die von Ad-Tech-Plattformen für die Anzeigenauslieferung gemeinsam genutzt werden.

Außerdem müssen die AdTech-Unternehmen für die Analyse ihre Waterfall-Attributionslogik mit einem neuen API-Aufruf für die Attributionskonfiguration angeben. In dieser Konfiguration kann die Ad-Tech-Plattform die Quellpriorität, das Ablaufdatum und Filter für Quellen angeben, die für sie nicht sichtbar waren (z. B. Quellen, bei denen keine Weiterleitung verwendet wurde).

Attribution

Die Attribution Reporting API führt die nach Quelle priorisierte Attribution nach letzter Interaktion für die Mess-AdTech-Anbieter basierend auf ihrer Attributionskonfiguration, den gemeinsam genutzten Schlüsseln und allen von ihnen registrierten Quellen durch. Beispiel:

• Der Nutzer hat auf Anzeigen geklickt, die von den Ad-Tech-Anbietern A, B, C und D ausgeliefert wurden. Der Nutzer hat dann die App des Werbetreibenden installiert, in der ein MMP (Measurement Ad Tech Partner) verwendet wird.
• AdTech A leitet seine Quellen an den MMP weiter.
• Die Ad-Tech-Anbieter B und C leiten nicht weiter, sondern geben ihre Aggregationsschlüssel weiter.
• Ad-Tech-Anbieter D leitet weder weiter noch gibt er Aggregationsschlüssel weiter.

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

Die Attribution für den MMP umfasst jetzt:

• Ad-Tech-Unternehmen A, da das MMP eine Quelle aus der Weiterleitung dieses Ad-Tech-Unternehmens registriert hat.
• Anzeigentechnologie B, da sie Schlüssel freigegeben hat und der MMP sie in seine Attributionskonfiguration aufgenommen hat.

Die Attribution für den MMP umfasst nicht:

• Ad-Tech-Unternehmen C, da es nicht in der Attributionskonfiguration des MMP enthalten ist.
• Ad-Tech-Unternehmen D, da es keine Weiterleitung vorgenommen und keine Aggregationsschlüssel weitergegeben hat.

Debugging

Zur Unterstützung des Debuggings für die netzwerkübergreifende Zuordnung ohne Weiterleitungen ist bei der Quellenregistrierung ein zusätzliches Feld (shared_debug_key) verfügbar, das von Anzeigentechnologien festgelegt werden kann. Wenn sie bei der Registrierung der ursprünglichen Quelle festgelegt wird, wird sie auch bei der Registrierung des Triggers für die netzwerkübergreifende Zuordnung ohne Weiterleitungen für die entsprechende abgeleitete Quelle als debug_key festgelegt. Dieser Debug-Schlüssel wird als source_debug_key an Ereignis- und aggregierte Berichte angehängt.

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

• App-zu-App-Messung, bei der die AdID zulässig ist
• App-zu-Web-Analyse, bei der die AdID zulässig ist und sowohl für die App-Quelle als auch für den Web-Trigger abgeglichen wird
• 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 für die netzwerkübergreifende Attribution durch Ad-Tech-Unternehmen (in der Regel MMPs) vereinfachen, wenn ein oder mehrere Ad-Tech-Unternehmen für die Auslieferung gemeinsame Aggregationsschlüssel verwenden (wie oben unter Netzwerkübergreifende Attribution ohne Weiterleitungen beschrieben).

Wenn ein MMP den Aggregationsdienst abfragt, um Zusammenfassungsberichte für Kampagnen mit abgeleiteten Quellen zu erstellen, muss er die Liste der möglichen Schlüssel als Eingabe für den Aggregationsjob angeben. In einigen Fällen kann die Liste der potenziellen Quellaggregationsschlüssel sehr lang oder unbekannt sein. Große Listen möglicher Schlüssel sind schwer zu verfolgen und die Verarbeitung ist wahrscheinlich sehr komplex und kostspielig. Hier einige Beispiele:

• Die Liste aller möglichen Schlüssel ist lang:
  • Ein Anzeigenbereitstellungsnetzwerk führt eine komplexe Initiative zur Nutzergewinnung durch, die 20 Kampagnen umfasst. Jede Kampagne hat 10 Anzeigengruppen und jede Anzeigengruppe 5 Creatives, die wöchentlich auf Grundlage der Leistung aktualisiert werden.
• Liste aller möglichen Schlüssel unbekannt:
  • Ein Werbenetzwerk liefert Anzeigen in vielen mobilen Apps aus, wobei die vollständige Liste der Publisher-App-IDs bei Kampagnenstart nicht bekannt ist.
  • Ein Werbetreibender arbeitet mit mehreren Ad-Serving-Netzwerken zusammen, die bei der Quellregistrierung nicht zum MMP weiterleiten. Jedes Ad-Serving-Netzwerk hat eine andere Schlüsselstruktur und andere Werte, die möglicherweise nicht im Voraus mit dem MMP geteilt werden.

Mit der 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üsseln angeben zu müssen, kann ein MMP eine leere (oder teilweise leere) Gruppe von Schlüsseln erstellen und einen Grenzwert festlegen, sodass nur (nicht vorab deklarierte) Schlüssel mit Werten, die den Grenzwert überschreiten, in die Ausgabe aufgenommen werden.
• Das MMP erhält einen zusammenfassenden Bericht mit ungenauen Werten für Schlüssel, deren Werte über dem festgelegten Schwellenwert liegen. Der Bericht kann auch Schlüssel enthalten, denen keine Beiträge von echten Nutzern zugeordnet sind und die nur mit Rauschen versehen wurden.
• Das MMP verwendet das Feld x_network_bit_mapping in der Triggerregistrierung, um zu bestimmen, welche AdTech welchem Schlüssel entspricht.
• Das MMP kann sich dann an die entsprechende Ad-Serving-Technologie wenden, um die Werte im Quellschlüssel zu ermitteln.

Zusammenfassend lässt sich sagen, dass MMPs durch die Schlüsselermittlung Aggregationsschlüssel erhalten können, ohne sie im Voraus zu kennen. So wird vermieden, dass eine große Menge an Quellschlüsseln verarbeitet wird, was zu zusätzlichem Rauschen führen würde.

Verkettete Weiterleitungen

Wenn in einer HTTPS-Antwort für die Quell- oder Triggerregistrierung mehrere Attribution-Reporting-Redirect-Header angegeben werden, kann eine Ad-Tech-Plattform mit einem einzigen Registrierungs-API-Aufruf mehrere Quell- und Triggerregistrierungen über die Attribution Reporting API durchführen.

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

Beide Arten von Headern sind optional. Wenn keine Weiterleitungen erforderlich sind, kann auch keiner angegeben werden. Es kann entweder einer oder beide Header angegeben werden. Registrierungsanfragen für Quelle und Trigger (einschließlich Weiterleitungen) werden bei einem Netzwerkfehler noch einmal gesendet. Die Anzahl der Wiederholungsversuche pro Anfrage ist auf eine feste Anzahl begrenzt, um eine erhebliche Beeinträchtigung des Geräts zu vermeiden.

Weiterleitungen werden für registerWebSource und registerWebTrigger, die von Browsern verwendet werden, nicht akzeptiert. Weitere Informationen finden Sie im Implementierungsleitfaden für Web und App.

Messdaten in Attributionsberichten ansehen

Die Attribution Reporting API ermöglicht die folgenden Arten von Berichten, die weiter unten auf dieser Seite genauer beschrieben werden:

• In Berichten auf Ereignisebene wird eine bestimmte Attributionsquelle (Klick oder Aufruf) mit einer begrenzten Anzahl von hochwertigen Triggerdaten verknüpft.
• Zusammenfassbare Berichte sind nicht unbedingt an eine bestimmte Attributionsquelle gebunden. Diese Berichte enthalten umfassendere Triggerdaten mit höherer Genauigkeit als Berichte auf Ereignisebene. Diese Daten sind jedoch nur in aggregierter 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 für das Senden von Berichten, die später auf dieser Seite genauer beschrieben werden, an die Postback-URL der jeweiligen AdTech gesendet werden kann.

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. Das bedeutet, dass einem Trigger eine von acht Kategorien zugewiesen werden kann. Für Aufrufe ist nur 1 Bit verfügbar. Außerdem wird in Berichten auf Ereignisebene keine Codierung von Triggerdaten mit hoher Genauigkeit unterstützt, z. B. ein bestimmter Preis oder eine Triggerzeit. Da die Attribution auf dem Gerät erfolgt, wird die geräteübergreifende Analyse in den Berichten auf Ereignisebene nicht unterstützt.

Der Bericht auf Ereignisebene enthält Daten wie die folgenden:

• Ziel:App-Paketname des Werbetreibenden oder eTLD+1, wo der Trigger ausgelöst wurde
• Attributionsquellen-ID:Dieselbe Attributionsquellen-ID, die zum Registrieren einer Attributionsquelle verwendet wurde.
• Auslösertyp:1 oder 3 Bit an Triggerdaten mit geringer Genauigkeit, je nach Art der 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.

Begrenzung der Anzahl von Ad-Tech-Anbietern

Es gibt Beschränkungen für die Anzahl der Ad-Tech-Unternehmen, die sich registrieren oder Berichte über die API erhalten können. Derzeit wird Folgendes vorgeschlagen:

• 100 Ad-Tech-Unternehmen mit Attributionsquellen pro {Quell-App, Ziel-App, 30 Tage, Gerät}.
• 10 Ad-Tech-Unternehmen mit zugeordneten Triggern pro {Quell-App, Ziel-App, 30 Tage, Gerät}.
• 20 Anzeigentechnologien können eine einzelne Attributionsquelle oder einen einzelnen Trigger (über Attribution-Reporting-Redirect) registrieren.

Limits für die Anzahl eindeutiger Ziele

Diese Beschränkungen erschweren es einer Reihe von Ad-Tech-Unternehmen, sich abzusprechen, 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 Ad-Techs maximal 200 eindeutige Ziele pro Quellanwendung und Minute.
• Für alle registrierten Quellen unterstützt die API für eine einzelne Ad-Tech-Lösung maximal 50 eindeutige Ziele pro Quellanwendung und Minute. Dieses Limit verhindert, dass eine AdTech-Lösung das gesamte Budget des oben genannten Ratenlimits aufbraucht.

Abgelaufene Quellen werden nicht auf die Ratenbeschränkungen angerechnet.

Ein Berichterstellungsursprung pro Quell-App und Tag

Eine bestimmte Ad-Tech-Plattform darf nur einen Berichterstellungsursprung verwenden, um Quellen in einer Publisher-App für ein bestimmtes Gerät am selben Tag zu registrieren. Dieses Ratenlimit verhindert, dass Ad-Tech-Unternehmen mehrere Berichterstellungsursprünge verwenden, um auf zusätzliches Datenschutzbudget zuzugreifen.

Stellen Sie sich das folgende Szenario vor, in dem ein einzelnes Ad-Tech-Unternehmen mehrere Ursprünge für Berichte verwenden möchte, um Quellen in einer Publisher-App für ein einzelnes Gerät zu registrieren.

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

Die zweite Quelle für den Berichterstellungsursprung 2 von Ad-Tech-A würde von der API abgelehnt. Der Ursprung 2 für die Berichterstellung von Ad-Tech-Unternehmen A kann erst am nächsten Tag eine Quelle auf demselben Gerät in App B registrieren.

Cooldown und Ratenbegrenzungen

Um die Menge der Nutzeridentitätslecks zwischen einem {Quelle, Ziel}-Paar zu begrenzen, wird die Menge der insgesamt gesendeten Informationen für einen Nutzer in einem bestimmten Zeitraum durch die API gedrosselt.

Der aktuelle Vorschlag sieht vor, jede Ad-Tech-Lösung 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 ein Ad-Tech-Unternehmen messen kann. Je niedriger das Limit, desto schwieriger ist es für ein Ad-Tech-Unternehmen, die API zu verwenden, um die Browsing-Aktivitäten von Nutzern zu erfassen, die nicht mit der Auslieferung von Anzeigen zusammenhängen.

Der aktuelle Vorschlag sieht vor, jede Ad-Tech-Plattform auf 100 unterschiedliche Ziele mit nicht abgelaufenen Quellen pro Quellanwendung zu beschränken.

Datenschutzfreundliche Mechanismen für Berichte auf Ereignisebene

Eingeschränkte Genauigkeit der Triggerdaten

Die API stellt 1 Bit für View-through-Trigger und 3 Bit für Click-through-Trigger bereit. Attributionsquellen unterstützen weiterhin die vollen 64 Bit an Metadaten.

Sie sollten prüfen, ob und wie Sie die in Triggern ausgedrückten 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 ist es, Messungen auf Ereignisebene zu ermöglichen, die den lokalen Anforderungen an die differenzielle Vertraulichkeit entsprechen. Dazu werden k-randomisierte Antworten verwendet, um für jedes Quellereignis eine verrauschte Ausgabe zu generieren.

Es wird Rauschen angewendet, um zu prüfen, ob ein Ereignis einer Attributionsquelle wahrheitsgemäß gemeldet wird. Eine Attributionsquelle wird auf dem Gerät mit einer Wahrscheinlichkeit von $ 1-p $ als normal registriert und mit einer Wahrscheinlichkeit von $ p $ wählt das Gerät zufällig einen der möglichen Ausgabezustände der API aus (einschließlich der Möglichkeit, nichts zu melden oder mehrere gefälschte Berichte zu melden).

Die k-randomisierte Antwort ist ein Algorithmus, der epsilon-differenziell privat ist, wenn die folgende Gleichung erfüllt ist:

Bei niedrigen Werten von ε wird die tatsächliche Ausgabe durch den k-randomisierten Antwortmechanismus geschützt. Die genauen Rauschparameter sind noch in Arbeit und können sich je nach Feedback ändern. Der aktuelle Vorschlag lautet:

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

Beschränkungen für verfügbare Trigger (Conversions)

Die Anzahl der Trigger pro Attributionsquelle ist begrenzt. Derzeit wird Folgendes vorgeschlagen:

• 1–2 Trigger für Attributionsquellen für Anzeigenaufrufe (2 Trigger nur bei Post-Install-Attribution verfügbar)
• 3 Auslöser für Quellen der Anzeigenzuordnung für Klicks

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 weniger als 1 Tag oder mehr als 30 Tage betragen. Wenn zwei Trigger einer Attributionsquelle für Anzeigenaufrufe zugeordnet werden (über die Attribution nach der Installation), können Berichte auf Ereignisebene in den folgenden angegebenen Intervallen für das Berichtszeitfenster gesendet werden.

Berichte auf Ereignisebene für Attributionsquellen für Anzeigenklicks können nicht konfiguriert werden. Sie werden vor oder beim Ablauf der Quelle zu bestimmten Zeitpunkten gesendet, die relativ zum Zeitpunkt der Registrierung der Quelle angegeben werden. Der Zeitraum zwischen der Attributionsquelle und dem Ablauf wird in mehrere Berichtszeiträume unterteilt. Für jedes Berichtszeitfenster gibt es eine Frist (ab dem Zeitpunkt 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 Berichtszeiträume:

• 2 Tage:Das Gerät erfasst alle Trigger, die höchstens 2 Tage nach der Registrierung der Attributionsquelle aufgetreten sind. Der Bericht wird 2 Tage und 1 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 7 Tage und 1 Stunde nach der Registrierung der Attributionsquelle gesendet.
• Ein benutzerdefinierter Zeitraum,der durch das Attribut „expiry“ einer Attributionsquelle definiert wird. Der Bericht wird eine Stunde nach dem angegebenen Ablaufdatum gesendet. Dieser Wert darf nicht weniger als 1 Tag und nicht mehr als 30 Tage betragen.

Flexible Konfiguration auf Ereignisebene

Die Standardkonfiguration für Berichte auf Ereignisebene wird AdTechs empfohlen, wenn sie mit dem Nützlichkeitstest beginnen. Sie ist jedoch möglicherweise nicht für alle Anwendungsfälle ideal. Die Attribution Reporting API unterstützt optionale und flexiblere Konfigurationen, sodass Ad-Tech-Unternehmen mehr Kontrolle über die Struktur ihrer Berichte auf Ereignisebene haben und den Nutzen der Daten maximieren können.

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

• Phase 1: Einfache flexible 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 Ereignisebene – Lite) kann für Folgendes verwendet werden:

• Häufigkeit von Berichten variieren, indem Sie die Anzahl der Berichtszeiträume angeben
• Anzahl der Zuordnungen pro Quellenregistrierung variieren
• Gesamtrauschen reduzieren, indem Sie die vorherigen Parameter verringern
• Berichtszeiträume konfigurieren, anstatt die Standardeinstellungen zu verwenden

In Phase 2 (Vollständig flexible Ereignisebene) können alle Funktionen aus Phase 1 genutzt werden. Außerdem sind folgende Möglichkeiten verfügbar:

• Kardinalität der Triggerdaten in einem Bericht variieren
• Gesamtrauschen reduzieren, indem die Kardinalität der Triggerdaten verringert wird

Wenn eine Dimension der Standardkonfiguration reduziert wird, kann die Ad-Tech-Lösung eine andere Dimension erhöhen. Alternativ kann die Gesamtmenge an Rauschen in einem Bericht auf Ereignisebene reduziert werden, indem die oben genannten Parameter netto verringert werden.

Neben der dynamischen Festlegung von Rauschpegeln basierend auf der ausgewählten Konfiguration einer Ad-Tech-Lösung werden wir einige Parameterlimits festlegen, um hohe Rechenkosten und Konfigurationen mit zu vielen Ausgabezuständen zu vermeiden (in denen der Rauschpegel erheblich ansteigt). Hier ist ein Beispiel für Einschränkungen. Wir freuen uns über Feedback zum Designvorschlag:

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

Wenn Ad-Tech-Unternehmen diese Funktion verwenden, sollten Sie beachten, dass die Verwendung von Extremwerten zu einer großen Menge an Rauschen oder zu einem Fehler bei der Registrierung führen kann, wenn die Datenschutzanforderungen nicht erfüllt werden.

Zusammenfassbare Berichte

Bevor Sie aggregierbare Berichte verwenden können, müssen Sie Ihr Cloud-Konto einrichten und mit dem Empfang aggregierbarer Berichte beginnen.

Aggregierbare Berichte liefern schnellere und genauere Triggerdaten vom Gerät als Berichte auf Ereignisebene. Diese Daten mit höherer Genauigkeit können nur aggregiert erfasst werden und sind nicht mit einem bestimmten Trigger oder Nutzer verknüpft. Aggregationsschlüssel haben eine Länge von bis zu 128 Bit. Dadurch können aggregierbare Berichte Berichterstellungsanwendungsfälle wie die folgenden unterstützen:

• Berichte für Trigger-Werte wie Umsatz
• Mehr Triggertypen verarbeiten

Außerdem wird in aggregierbaren Berichten dieselbe quellpriorisierte Attributionslogik wie in Berichten auf Ereignisebene verwendet. Es werden jedoch mehr Conversions unterstützt, die einem Klick oder Aufruf zugeordnet sind.

Das Gesamtdesign für die Vorbereitung und das Senden von aggregierbaren Berichten mit der Attribution Reporting API ist im Diagramm dargestellt und sieht so aus:

1. Das Gerät sendet verschlüsselte aggregierbare Berichte an den Anbieter von Anzeigentechnologien. In einer Produktionsumgebung können Anbieter von Anzeigentechnologien diese Berichte nicht direkt verwenden.
2. Der AdTech-Anbieter sendet einen Batch aggregierbarer Berichte zur Aggregation an den Aggregationsdienst.
3. Der Aggregationsdienst liest einen Batch aggregierbarer Berichte, entschlüsselt und aggregiert sie.
4. Die endgültigen zusammengefassten Daten werden in einem Zusammenfassungsbericht an die AdTech zurückgesendet.

Zusammenfassbare 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, das durch die Attributionsquelle dargestellt wird, stattgefunden hat.
• 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 unberechtigtem Zugriff auf aggregierte Daten.

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

• Der Aggregationsdienst ist der einzige, den Ad-Tech-Unternehmen bereitstellen müssen.
• Die Dienste für Schlüsselverwaltung und Zusammenfassungsberichte werden von vertrauenswürdigen Drittanbietern, sogenannten 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 Aggregationsdiensts derselbe Schlüssel und dieselben Abrechnungsdienste für aggregierbare Berichte verwendet werden.

Aggregationsdienst

Ad-Tech-Plattformen müssen im Voraus 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. Ein TEE bietet die folgenden 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 für den Betrieb erforderlich sind.
• Sie bietet Sicherheit für den laufenden Prozess, indem sie ihn vor externer Überwachung oder Manipulation schützt.

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

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

Key Management Service

Mit diesem Dienst wird überprüft, ob für einen Aggregationsdienst eine genehmigte Version des Binärprogramms ausgeführt wird. Anschließend werden dem Aggregationsdienst in der Ad-Tech-Plattform die richtigen Entschlüsselungsschlüssel für seine Triggerdaten bereitgestellt.

Zusammenfassbare Berichte

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

Aggregatable Reports API

Für die API zum Erstellen von Beiträgen zu aggregierbaren Berichten wird dieselbe Basis-API verwendet 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 Ad-Tech-Plattform eine Liste von Aggregationsschlüsseln mit dem Namen histogram_contributions registrieren, indem sie mit einem neuen Feld namens aggregation_keys im HTTP-Header Attribution-Reporting-Register-Source antwortet, wobei der Schlüssel key_name und der Wert key_piece ist:

• (Key) Schlüsselname:Ein String für den Namen des Schlüssels. Wird als Join-Schlüssel verwendet, um mit den Schlüssel der Triggerseite den endgültigen Schlüssel zu bilden.
• (Value) Key piece (Schlüsselteil): Ein Bitstring-Wert für den Schlüssel.

Der endgültige Schlüssel für den Histogramm-Bucket wird zum Zeitpunkt des Triggers vollständig definiert, indem eine binäre ODER-Operation für diese Teile und die Trigger-seitigen Teile ausgeführt wird.

Finale Schlüssel sind auf maximal 128 Bit beschränkt. Längere Schlüssel werden gekürzt. Das bedeutet, dass Hexadezimalstrings im JSON auf maximal 32 Ziffern begrenzt sein sollten.

Weitere Informationen zur Struktur von Aggregationsschlüsseln und zur Konfiguration von Aggregationsschlüsseln

Im folgenden Beispiel verwendet ein Ad-Tech-Unternehmen die API, um Folgendes zu erfassen:

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

// 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.

Mit dem ersten Feld wird eine Liste von Aggregationsschlüsseln auf der Triggerseite registriert. Die Ad-Tech-Plattform sollte mit dem Feld aggregatable_trigger_data im HTTP-Header Attribution-Reporting-Register-Trigger antworten. Für jeden aggregierten Schlüssel in der Liste sind die folgenden Felder erforderlich:

• Schlüsselkomponente:Ein Bitstring-Wert für den Schlüssel.
• Quellschlüssel:Eine Liste von Strings mit den Namen der Schlüssel auf der Attributionsquellseite, 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 Ad-Tech-Plattform 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. Das können Ganzzahlen im Bereich $ [1, 2^{16}] $ sein.

Jeder Trigger kann mehrere Beiträge zu den aggregierbaren Berichten leisten. Der Gesamtbetrag der Beiträge zu einem bestimmten Quellereignis ist durch einen $ L1 $-Parameter begrenzt. Dieser Parameter gibt die maximale Summe der Beiträge (Werte) für alle aggregierten Schlüssel für eine bestimmte Quelle an. $ L1 $ bezieht sich auf die L1-Sensitivität oder ‑Norm der Histogrammbeiträge pro Quellereignis. Wenn Sie diese Limits überschreiten, werden zukünftige Beiträge nicht mehr berücksichtigt. Der ursprüngliche Vorschlag ist, $ L1 $ auf $ 2^{16} $ (65536) festzulegen.

Das Rauschen im Aggregationsdienst wird proportional zu diesem Parameter skaliert. Daher wird empfohlen, die für einen bestimmten aggregierten Schlüssel gemeldeten Werte entsprechend dem Anteil des dafür zugewiesenen Budgets für Ebene 1 zu skalieren. So wird sichergestellt, dass die aggregierten Berichte auch nach dem Hinzufügen von Rauschen so genau wie möglich sind. Dieser Mechanismus ist sehr flexibel und kann viele Aggregationsstrategien unterstützen.

Im folgenden Beispiel wird das Datenschutzbudget gleichmäßig zwischen campaignCounts und geoValue aufgeteilt, indem der Beitrag von $ L1 $ für jede 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 Histogrammbeiträge:

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

Die Skalierungsfaktoren können invertiert werden, um die richtigen Werte zu erhalten, modulo dem angewendeten Rauschen:

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

Differential Privacy

Ein Ziel dieser API ist es, ein Framework zu schaffen, das differenziell private aggregierte Messungen unterstützt. Dies kann erreicht werden, indem dem Budget für die L1-Ebene proportionales Rauschen hinzugefügt wird, z. B. durch Auswahl von Rauschen mit der folgenden Verteilung:

Integration der Protected Audience API und der Attribution Reporting API

Die API-übergreifende Integration der Protected Audience API und der Attribution Reporting API ermöglicht es Ad-Tech-Unternehmen, die Attributionsleistung verschiedener Remarketing-Taktiken zu bewerten, um herauszufinden, mit welchen Zielgruppen der höchste ROI erzielt wird.

Durch diese API-übergreifende Integration haben Ad-Tech-Unternehmen folgende Möglichkeiten:

• Erstellen Sie eine Schlüssel/Wert-Zuordnung von URIs, die sowohl für 1) die Berichterstellung zu Interaktionen als auch für 2) die Quellenregistrierung verwendet werden sollen.
• Fügen Sie CustomAudience in die Schlüsselzuordnung auf der Quellseite für die Berichterstellung von aggregierten Zusammenfassungen (mit der Attribution Reporting API) ein.

Wenn ein Nutzer eine Anzeige sieht oder darauf klickt:

• Die URL, die zum Melden dieser Interaktionen mit Protected Audience verwendet wird, wird auch verwendet, um einen Aufruf oder Klick als zulässige Quelle mit der Attribution Reporting API zu registrieren.
• Die Anzeigentechnologie kann die benutzerdefinierte Zielgruppe (oder andere relevante Kontextinformationen zur Anzeige, z. B. Anzeigen-Placement oder Anzeigendauer) über diese URL übergeben, damit diese Metadaten in Zusammenfassungsberichte übernommen werden, wenn die Anzeigentechnologie die aggregierte Kampagnenleistung analysiert.

Weitere Informationen dazu, wie dies in Protected Audience aktiviert wird, finden Sie im entsprechenden Abschnitt des Protected Audience API Explainer.

Beispiele für Registrierungspriorität, Attribution und Berichterstellung

In diesem Beispiel werden eine Reihe von Nutzerinteraktionen und die Auswirkungen von Prioritäten für Attributionsquellen und Trigger auf zugeordnete Berichte dargestellt. In diesem Beispiel gehen wir von Folgendem aus:

• Alle Attributionsquellen und ‑auslöser werden von derselben Anzeigentechnologie für denselben Werbetreibenden registriert.
• Alle Attributionsquellen und ‑auslöser sind während des ersten Ereignisberichtszeitraums (innerhalb von zwei Tagen nach der ersten Auslieferung der Anzeigen in einer Publisher-App) aktiv.

Angenommen, ein Nutzer tut Folgendes:

1. Der Nutzer sieht eine Anzeige. Das Ad-Tech-Unternehmen registriert eine Attributionsquelle mit der API mit der Priorität 0 (Aufruf 1).
2. Der Nutzer sieht eine Anzeige mit der Priorität 0 (Ansicht 2).
3. Der Nutzer klickt auf eine Anzeige, die mit der Priorität 1 registriert ist (Klick 1).
4. Der Nutzer führt eine Conversion aus (erreicht die Landingpage) in der App eines Werbetreibenden. Die Ad-Tech-Plattform registriert einen Trigger mit 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: Ansicht 1, Ansicht 2 und Klick 1. In der API wird dieser Trigger dem ersten Klick zugeordnet, da er die höchste Priorität hat und der letzte ist.
   • Ansicht 1 und Ansicht 2 werden verworfen und können nicht mehr für die Attribution verwendet werden.
5. Der Nutzer legt einen Artikel in den Einkaufswagen in der App des Werbetreibenden, die mit der Priorität 1 registriert ist (Conversion 2).
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute für diesen Trigger bis zum ersten Klick.
6. Der Nutzer legt in der App des Werbetreibenden einen Artikel in den Einkaufswagen. Die App ist mit der Priorität 1 registriert (Conversion 3).
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute für diesen Trigger bis zum ersten Klick.
7. Der Nutzer legt einen Artikel in der App des Werbetreibenden in den Einkaufswagen, die mit der Priorität 1 registriert ist (Conversion 4).
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute für diesen Trigger bis zum ersten Klick.
8. Der Nutzer tätigt einen Kauf in der App des Werbetreibenden, der mit der Priorität 2 registriert ist (Conversion 5).
   • Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute für diesen Trigger bis zum ersten Klick.

Berichte auf Ereignisebene haben die folgenden Merkmale:

• Standardmäßig werden die ersten drei Trigger, die einem Klick zugeordnet sind, und der erste Trigger, der einer Impression zugeordnet ist, nach den entsprechenden Berichtszeiträumen gesendet.
• Wenn im Berichtszeitraum Trigger mit höherer Priorität registriert werden, haben diese Vorrang und ersetzen den letzten Trigger.
• Im vorherigen Beispiel erhält die Ad-Tech-Plattform nach dem zweitägigen Berichtszeitraum drei Ereignisberichte für Conversion 2, Conversion 3 und Conversion 5.
  • Alle fünf Trigger werden dem ersten Klick zugeordnet. Standardmäßig würde die API Berichte für die ersten drei Trigger senden: 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 werden soll.
  • Außerdem hat die Priorität von Conversion 5 (2) einen höheren Wert als alle anderen Trigger. Der Ereignisbericht für Conversion 5 ersetzt den Bericht für Conversion 4, der gesendet werden soll.

Zusammenfassbare Berichte haben die folgenden Merkmale:

• Verschlüsselte aggregierbare Berichte werden an die AdTech-Plattform gesendet, sobald sie verarbeitet wurden. Das ist einige Stunden nach der Registrierung der Trigger der Fall.

  Als Ad-Tech-Unternehmen erstellen Sie Ihre Batches anhand der Informationen, die unverschlüsselt in Ihren aggregierbaren Berichten enthalten sind. Diese Informationen sind im Feld shared_info Ihres aggregierbaren Berichts enthalten, einschließlich Zeitstempel und Berichterstellungsursprung. Sie können keine Batches auf Grundlage verschlüsselter Informationen in Ihren Schlüssel/Wert-Paaren für die Aggregation erstellen. Einige grundlegende Strategien, die Sie anwenden können, sind das tägliche oder wöchentliche Erstellen von Berichten. Idealerweise sollten Batches mindestens 100 Berichte enthalten.

• Es liegt im Ermessen des Anbieters von Anzeigentechnologien, wann und wie die aggregierbaren Berichte in Batches zusammengefasst und an den Aggregationsdienst gesendet werden.

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

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

Übergangsberichte zum Debugging

Die Attribution Reporting API ist eine neue und ziemlich komplexe Methode, um die Attributionsanalyse ohne appübergreifende IDs durchzuführen. Daher unterstützen wir einen Übergangsmechanismus, um weitere Informationen zu Attributionsberichten zu erhalten, 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). So kann die API während der Einführung vollständig nachvollzogen werden. Außerdem können Fehler leichter behoben und die Leistung besser mit Alternativen auf Basis der Werbe-ID verglichen werden. Es gibt zwei Arten von Debugging-Berichten: „Attribution-Success“ und „Verbose“.

Weitere Informationen zum Debuggen von Berichten mit App-zu-Web- und Web-zu-App-Analysen finden Sie im Leitfaden zu Debugging-Berichten für die Umstellung.

Berichte zum Debuggen von Attributionserfolgen

Bei der Quell- und Triggerregistrierung wird jeweils ein neues 64-Bit-Feld debug_key (als String formatiert) akzeptiert, das vom Ad-Tech-Unternehmen ausgefüllt wird. source_debug_key und trigger_debug_key werden sowohl in Berichten auf Ereignisebene als auch in aggregierten Berichten unverändert weitergegeben.

Wenn ein Bericht mit Quell- und Trigger-Debug-Schlüsseln erstellt wird, wird ein doppelter Debug-Bericht mit geringer Verzögerung an einen .well-known/attribution-reporting/debug/report-event-attribution-Endpunkt gesendet. Die Debug-Berichte sind mit normalen Berichten identisch und enthalten beide Debug-Schlüsselfelder. Wenn Sie diese Schlüssel in beide einfügen, können Sie normale Berichte mit dem separaten Stream von Debug-Berichten verknüpfen.

• Für Berichte auf Ereignisebene:
  • Doppelte Debug-Berichte werden mit geringer Verzögerung gesendet und daher nicht durch Beschränkungen für verfügbare Trigger unterdrückt. So können AdTech-Unternehmen die Auswirkungen dieser Beschränkungen auf Berichte auf Ereignisebene nachvollziehen.
  • Berichte auf Ereignisebene, die mit Ereignissen für fälschlicherweise ausgelöste Trigger verknüpft sind, enthalten keine trigger_debug_key. So können Anzeigentechnologie-Plattformen besser nachvollziehen, wie Rauschen in der API angewendet wird.
• Für zusammenfassbare Berichte:
  • Wir unterstützen ein neues debug_cleartext_payload-Feld, das die entschlüsselte Nutzlast enthält, nur wenn sowohl source_debug_key als auch trigger_debug_key festgelegt sind.

Ausführliche Debugging-Berichte

Mithilfe von ausführlichen Debugging-Berichten können Entwickler bestimmte Fehler bei der Registrierung von Attributionsquellen oder Triggern beobachten. Diese Debugging-Berichte werden mit geringer Verzögerung nach der Registrierung von Attributionsquelle oder Trigger an eine gesendet.well-known/attribution-reporting/debug/verbose-Endpunkt

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

• Typ: Gibt an, wodurch der Bericht generiert wurde. 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 Quellberichte muss die Werbe-ID in der Publisher-App verfügbar sein. Für ausführliche Triggerberichte muss die Werbe-ID in der Werbetreibenden-App verfügbar sein.
  • Ausführliche Berichte für Trigger (mit Ausnahme von trigger-no-matching-source) können optional die source_debug_key enthalten. Diese kann nur angegeben werden, wenn die Werbe-ID auch für die Publisher-App verfügbar ist.
• Body: Der Hauptteil des Berichts, der vom Typ des Berichts abhängt.

Ad-Tech-Anbieter müssen sich dafür entscheiden, ausführliche Debugging-Berichte zu erhalten. Dazu müssen sie ein neues debug_reporting-Wörterbuchfeld in den Headern Attribution-Reporting-Register_Source und Attribution-Reporting-Register-Trigger verwenden.

• Für ausführliche Quellberichte ist nur eine Einwilligung im Header der Quellregistrierung erforderlich.
• Für Trigger-Debug-Berichte ist nur eine Aktivierung in der Kopfzeile der Triggerregistrierung erforderlich.

Fehlerberichte verwenden

Wenn eine Conversion (gemäß Ihrem vorhandenen Analysesystem) stattgefunden hat und ein Debug-Bericht für diese Conversion empfangen wurde, bedeutet das, 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 Debug-Schlüsseln übereinstimmt.

Wenn es keine Übereinstimmung gibt, kann das verschiedene Gründe haben.

Funktioniert wie vorgesehen:

• Datenschutzfreundliches API-Verhalten:
  • Ein Nutzer erreicht das Limit für die Berichtsrate, sodass alle nachfolgenden Berichte im Zeitraum nicht gesendet werden. Oder eine Quelle wird aufgrund des ausstehenden Ziellimits entfernt.
  • Bei Berichten auf Ereignisebene: Der Bericht unterliegt der Methode der zufälligen Antwort (Rauschen) und wird unterdrückt oder Sie erhalten einen zufälligen Bericht.
  • Bei Berichten auf Ereignisebene: Das Limit 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 eine Priorität, die niedriger ist als die vorhandener Berichte.
  • Die Beitragslimits für aggregierbare Berichte wurden überschritten.
• Geschäftslogik, die von Ad-Tech-Unternehmen definiert wird:
  • Ein Trigger wird mithilfe von Filtern oder Prioritätsregeln herausgefiltert.
• Zeitverzögerungen oder Interaktionen mit der Netzwerkverfügbarkeit (z.B. wenn der Nutzer sein Gerät über einen längeren Zeitraum ausschaltet).

Unerwünschte 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 ist noch in der Entwicklung. Wir arbeiten auch an zukünftigen potenziellen Funktionen wie Attributionsmodellen, bei denen nicht nur der letzte Klick berücksichtigt wird, und geräteübergreifenden Analyseanwendungsfällen.

Außerdem möchten wir die Community um Feedback zu einigen Problemen bitten:

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 Ratenbegrenzungen von Ad-Tech-Plattformen angerechnet.
2. Erwartest du Schwierigkeiten bei der Übergabe der InputEvent von der App an die Ad-Tech-Plattform zur Quellregistrierung?
3. Haben Sie spezielle Attributionsanwendungsfälle für vorinstallierte oder neu installierte Apps?