Implementierungsleitfaden für die Attribution Reporting API für Websites und Apps

Die Attribution Reporting API ermöglicht die App- und Web-Attribution für Quellen und Trigger, die auf demselben Gerät auftreten. Browser wie Chrome können sowohl Quell- als auch Triggerregistrierungen an die Attribution Reporting API für Android delegieren, anstatt diese Registrierungen im Browser zu verarbeiten. So kann Android Quellen und Triggern sowohl auf Websites als auch in Apps zuordnen.

In diesem Leitfaden erfahren Sie, wie Sie die App- und Web-Attribution einrichten.

Wenn Sie die Attributierung für Apps und Web einrichten, sollten Sie sich auch mit den verfügbaren Debugging-Lösungen vertraut machen, um zu prüfen, ob die Einrichtung wie vorgesehen funktioniert.

Quellen und Trigger beim Android-Betriebssystem registrieren

Die App- und Webattribution ist nur verfügbar, wenn die Attribution Reporting API sowohl im Browser als auch im Android-Betriebssystem auf demselben Gerät aktiviert ist. Die Verfügbarkeit der Android Attribution Reporting API wird über den Header „Attribution-Reporting-Support“ gesendet. Dieser Header gibt „os“, „web“ oder beides zurück, je nachdem, was auf dem Gerät verfügbar ist. Wenn beides verfügbar ist, können Ad-Tech-Unternehmen Webquellen und Web-Trigger entweder beim Browser oder beim Betriebssystem registrieren.

Die Ad-Tech-Plattform muss entscheiden, ob die Webquelle oder der Web-Trigger beim Browser oder Betriebssystem registriert werden soll.

• Bei reinen Webkampagnen können Anzeigentechnologie-Anbieter weiterhin sowohl Quellen als auch Trigger bei der Attribution Reporting API von Chrome registrieren oder beides an das Betriebssystem delegieren. Bei reinen Webkampagnen, bei denen entweder die Quelle oder der Trigger in einem WebView auftreten kann, müssen Ad-Tech-Anbieter sowohl die Quell- als auch die Triggerregistrierungen an das Betriebssystem delegieren. Weitere Informationen finden Sie im Abschnitt zu WebViews.

• AdTech-Unternehmen sollten vermeiden, Quellen und Trigger gleichzeitig mit den Chrome- und Android-APIs zu registrieren, um doppelte Attributionsberichte zu vermeiden.

• Die Zuordnung erfolgt separat für Browser und das Betriebssystem. Wenn eine Quelle im Browser registriert ist, der Trigger jedoch im Betriebssystem, können die beiden nicht abgeglichen werden und umgekehrt.

• Bei Quellen, die entweder einen App- oder einen Web-Trigger auslösen können, wird dringend empfohlen, dass die AdTech-Lösung die Registrierung von Webquellen und ‑Triggern an die Android Attribution Reporting API delegiert.

• Bei Triggern, die möglicherweise von App-basierten Quellen ausgelöst wurden, kann der AdTech-Anbieter die Registrierung von Web-Triggern an die Android Attribution Reporting API delegieren.

• Bei Kampagnen, bei denen sowohl die Quelle als auch der Trigger in einer App erfolgen, müssen beide bei der Attribution Reporting API des Betriebssystems registriert werden.

App-Quelle und Web-Trigger registrieren

Bei einigen Kampagnen kann die Quelle in einer App und der Trigger auf einer Website im mobilen Browser auf demselben Gerät erfolgen.

Beispiel

Ein Nutzer liest Artikel in seiner bevorzugten Nachrichten-App. Er sieht eine Anzeige für günstige Flüge nach Paris und klickt darauf, um zu buchen. Der AdTech-Anbieter, der die Anzeige in der Nachrichten-App bereitstellt, registriert die Klickquelle mit der Android Attribution Reporting API. Der Nutzer wird in Chrome zur Webseite des Werbetreibenden weitergeleitet, wo er eine Conversion ausführen kann. Die AdTech auf der Website des Werbetreibenden prüft, ob die API auf Betriebssystemebene verfügbar ist. Das ist der Fall. Die AdTech registriert den Conversion-Trigger, indem sie Chrome anweist, die Registrierung an das Betriebssystem zu delegieren, anstatt sie direkt mit der Attribution Reporting API von Chrome zu registrieren. Die Attribution Reporting API auf Betriebssystemebene kann dann die App-Quelle und den Web-Trigger abgleichen und die entsprechenden Berichte senden.

Registrierung der App-Quelle:

1. Das AdTech-SDK in der Daily News Android-App registriert den Klick mit registerSource()

2. Die Attribution Reporting API für Android sendet eine Anfrage an die URL des AdTech-Servers, die für registerSource() angegeben wurde.

3. Der Ad-Tech-Server antwortet mit dem Header „Attribution-Reporting-Register-Source“, um die Quellregistrierung abzuschließen.

Registrierung von Web-Triggern:

1. Der AdTech-Anbieter registriert einen Trigger und prüft die Verfügbarkeit des Betriebssystems in der Attribution Reporting API.

2. Die Web-ARA gibt Informationen dazu zurück, welche Plattform unterstützt wird.

3. Der OS-Trigger-Header weist die Web-ARA-API an, die registerWebTrigger()-Funktion der Betriebssystem-ARA-API aufzurufen.

4. Der Aufruf von registerWebTrigger() erfolgt im Hintergrund und der Entwickler muss registerWebTrigger() nicht direkt mit dem Betriebssystem aufrufen.

5. Das Betriebssystem-ARA übernimmt und sendet eine Anfrage an die Ad-Tech-Server-URL, die vom Attribution-Reporting-Register-OS-Trigger-Header bereitgestellt wird.

6. Die Ad-Tech-Firma schließt die Triggerregistrierung mit der Betriebssystem-API ab.

7. Die OS-ARA führt die Zuordnung nach derselben Logik wie bei der App-zu-App-Zuordnung durch und sendet dieselben Berichte.

Workflow

Die folgenden Schritte enthalten weitere Details zur Ausführung der Aufgabe:

1. Die Anzeigentechnologie der App registriert eine Quelle mit der Attribution Reporting API von Android mit den folgenden Anpassungen:

   • Wenn Sie eine App-Quelle registrieren möchten, die voraussichtlich auf einer Website konvertiert, sollte der Antwortheader Attribution-Reporting-Register-Source ein Webziel (eTLD+1) anstelle eines App-Ziels enthalten.

   Attribution-Reporting-Register-Source: {
       "web_destination": "https://advertiser.example",
       ...
   }
   

   • Einige Werbetreibende verwenden möglicherweise mehrere Analyseanbieter (z. B. ein Drittanbieter-Analysetool oder ein Analysetool) mit 302-Weiterleitungsketten. In einigen Fällen folgt die Attribution Reporting API dem im Header „Attribution-Reporting-Redirect“ angegebenen Weiterleitungspfad im Hintergrund. Gleichzeitig wird der 302-Weiterleitungspfad im Vordergrund für bestehende Navigationsanfragen ausgeführt. Diese Anfragen werden an dieselbe URL gesendet und können dazu führen, dass der Drittanbieter für die Analyse Registrierungen doppelt zählt. Um zu verhindern, dass Registrierungen doppelt gezählt werden, können AdTech-Unternehmen das Weiterleitungsverhalten so ändern, dass die Registrierung der Attribution Reporting API an eine alternative, aber deterministische URL gesendet wird.

   • Damit dieses Verhalten aktiviert wird, müssen Ad-Tech-Unternehmen beim Beantworten einer Registrierungsanfrage einen neuen HTTP-Header einfügen:

     • Der Header lautet Attribution-Reporting-Redirect-Config.
     • Der Wert des Headers sollte „redirect-302-to-well-known“ sein.

     Attribution-Reporting-Redirect-Config: redirect-302-to-well-known
     

   • Der restliche Prozess zur Quellregistrierung entspricht der Standardregistrierung von App-zu-App-Quellen.

2. Die AdTech auf der Website des Werbetreibenden registriert den Trigger, indem sie Chrome auffordert, die Registrierung an die Android Attribution Reporting API zu delegieren:

   • Sobald ein Nutzer eine Conversion auf einer Website durchführt, sendet die AdTech-Lösung eine Anfrage, um den Trigger bei Chrome zu registrieren.

     1. Eine Anfrage für ein Pixel oder fetch() kann verwendet werden, um die Anfrage zur Registrierung eines Triggers zu stellen.

     2. Der Anfrageheader Attribution-Reporting-Support wird von Chrome an die Ad-Tech-Plattform zurückgegeben. Wenn die API sowohl im Chrome-Browser als auch auf dem Android-Gerät aktiviert ist, wird im Header os, web zurückgegeben.

     Attribution-Reporting-Support: os, web
     

   • Die Ad-Tech-Plattform sollte Chrome dann mithilfe des Attribution-Reporting-Register-OS-Trigger-Headers an das Betriebssystem delegieren. Dieser Header:

     1. Weist Chrome an, die Registrierung an das Betriebssystem zu delegieren

     2. Chrome delegiert die Registrierung an das Betriebssystem, indem die Betriebssystem-API-Funktion registerWebTrigger() aufgerufen wird.

        • Der Aufruf von registerWebTrigger() erfolgt im Hintergrund. Die Ad-Tech-Lösung muss registerWebTrigger() nicht direkt aufrufen.

     3. Die OS API initiiert einen sekundären API-Aufruf an den Ad-Tech-URI, der vom Browser übergeben wird.

     Attribution-Reporting-Register-OS-Trigger: "https://adtech.example/register-trigger",
     "https://other-adtech.example/register-trigger"
     

   • In einigen Fällen ist der Attribution-Reporting-Support-Header nicht verfügbar und kann nicht gesendet werden. In diesem Fall kann die Ad-Tech-Plattform weiterhin eine bevorzugte Plattform für die Triggerregistrierung festlegen, indem sie den Attribution-Reporting-Info-Header einfügt. Der Schlüssel ist „preferred-platform“ und die zulässigen Werte sind os und web. Der Browser verwendet die bevorzugte Plattform, sofern verfügbar, und greift auf die Webplattform zurück, wenn das Betriebssystem nicht verfügbar ist.

   Attribution-Reporting-Info: preferred-platform=os
   

   • Damit die Triggerregistrierung abgeschlossen werden kann, muss der Endpunkt des Ad-Tech-Unternehmens mit dem Antwortheader auf die Anfrage der Android Attribution Reporting API antworten.

   Attribution-Reporting-Register-Trigger: {
       "event_trigger_data": [{"trigger_data":"1"}],
       "aggregatable_trigger_data": [
           {"key_piece":"0x400","source_keys":["campaignCounts"]},
           {"key_piece":"0xA80","source_keys":["geoValue"]}
       ],
       ...
   }
   

   • Der Rest der Triggerregistrierung bleibt unverändert.

Webquelle und App-Trigger registrieren

Bei einigen Kampagnen kann eine Quelle auf einer Website in einem mobilen Browser auftreten, während der Trigger in einer App auf demselben Gerät ausgelöst wird.

Beispiel

Ein Nutzer surft auf einer Website in seinem Chrome-Browser auf seinem Android-Smartphone. Sie sehen eine Anzeige für einen Pullover von einem ihrer Lieblingsgeschäfte. Der Nutzer klickt auf die Anzeige und wird zur App weitergeleitet, die er bereits heruntergeladen hat. Die AdTech auf der Website, auf der die Anzeige ausgeliefert wurde, registriert die Klickquelle, indem sie Chrome anweist, die Registrierung an die Android Attribution Reporting API zu delegieren, anstatt die Attribution Reporting API in Chrome zu verwenden. Der Nutzer kauft den Pullover in der Shopping-App. Die AdTech in der App des Werbetreibenden registriert dann den Conversion-Trigger bei der Android Attribution Reporting API. Die Attribution Reporting API auf Betriebssystemebene kann die Webquelle und den App-Trigger abgleichen und die entsprechenden Berichte senden.

Registrierung von Webquellen:

1. Der AdTech-Anbieter registriert eine Quelle und prüft die Verfügbarkeit des Betriebssystems in der Attribution Reporting API.

2. Die Web-ARA gibt Informationen dazu zurück, welche Plattform unterstützt wird.

3. Der OS-Source-Header weist die Web-ARA-API an, die registerWebSource()-Funktion der Betriebssystem-ARA-API aufzurufen.

4. Der Aufruf von registerWebSource() erfolgt im Hintergrund und der Entwickler muss registerWebSource() nicht direkt mit dem Betriebssystem aufrufen.

5. Das Betriebssystem-ARA übernimmt und sendet eine Anfrage an die Ad-Tech-Server-URL, die im Attribution-Reporting-Register-OS-Source-Header angegeben ist.

6. Die Ad-Tech-Plattform schließt die Quellregistrierung mit der Betriebssystem-API ab.

Registrierung von App-Triggern:

1. Das Ad-Tech-SDK in der Android-App des Bekleidungsgeschäfts registriert den Trigger bei der ARA des Betriebssystems.

2. Die Attribution Reporting API für Android sendet eine Anfrage an die URL des AdTech-Servers, die für registerTrigger() angegeben wurde.

3. Der Ad-Tech-Server antwortet mit dem Attribution-Reporting-Register-Trigger-Header, um die Triggerregistrierung abzuschließen.

4. Die OS-ARA führt die Zuordnung nach derselben Logik wie bei der App-zu-App-Zuordnung durch und sendet dieselben Berichte.

Workflow

Die folgenden Schritte enthalten weitere Details zur Ausführung der Aufgabe:

1. Die AdTech auf der Publisher-Website registriert die Quelle, indem Chrome angewiesen wird, die Registrierung an die Android Attribution Reporting API zu delegieren:

   • Bei einem Web-zu-App-Anwendungsfall muss beim Registrieren einer Quelle der Parameter „attribution source“ (Attributionsquelle) direkt angegeben werden, entweder mit dem attributionsrc-Tag oder mit der JavaScript-Registrierung.
   • Im folgenden Beispiel wird das Tag attributionsrc verwendet, um den Quellparameter anzugeben:

   <img src="https://adtech.example/conversionpixel"
   attributionsrc="https://adtech.example/register-source?purchase=12">
   

2. Der Anfrageheader Attribution-Reporting-Support wird von Chrome an die Ad-Tech-Plattform zurückgegeben. Wenn die API sowohl im Chrome-Browser als auch auf dem Android-Gerät aktiviert ist, wird im Header os, web zurückgegeben.

   Attribution-Reporting-Support: os, web
   

3. Die AdTech-Lösung muss Chrome anweisen, die API auf Betriebssystemebene zu delegieren. Dazu muss der Header Attribution-Reporting-Register-OS-Source verwendet werden, der:

   1. Weist Chrome an, die Registrierung an das Betriebssystem zu delegieren
   2. Chrome delegiert die Registrierung an das Betriebssystem, indem die Betriebssystem-API-Funktion registerWebSource() aufgerufen wird.
   3. Der Aufruf von registerWebSource() erfolgt im Hintergrund. Die Ad-Tech-Plattform muss registerWebSource() nicht direkt aufrufen.
   4. Die OS API initiiert einen sekundären API-Aufruf an den Ad-Tech-URI, der vom Browser übergeben wurde.

   Attribution-Reporting-Register-OS-Source: "https://adtech.example/register-source"
   

   • In einigen Fällen ist der Attribution-Reporting-Support-Header nicht verfügbar. In diesem Fall kann die Ad-Tech-Plattform weiterhin eine bevorzugte Plattform für die Verarbeitung der Quellregistrierung festlegen, indem sie den Attribution-Reporting-Info-Header einfügt. Der Schlüssel ist „preferred-platform“ und die zulässigen Werte sind os und web. Der Browser verwendet die bevorzugte Plattform, sofern verfügbar, und greift auf die Webplattform zurück, wenn das Betriebssystem nicht verfügbar ist.

   Attribution-Reporting-Info: preferred-platform=os
   

   • Um die Quellregistrierung abzuschließen, sollte der Endpunkt der Ad-Tech-Firma auf die Anfrage der Android Attribution Reporting API mit dem Antwortheader Attribution-Reporting-Register-Source antworten. In der Antwort sollte auch ein App-Ziel im Zielfeld angegeben werden.

   Attribution-Reporting-Register-Source: {
       "source_event_id":"123001",
       "destination":"android-app://com.example.advertiser",
       ...
   }
   

   • Um Weiterleitungen für Quellregistrierungen zu unterstützen, folgt Chrome den Weiterleitungen und ruft die Webkontext-APIs für jeden Weiterleitungssprung auf.
   • Der Rest der Quellregistrierung bleibt unverändert.

4. Die AdTech in der App des Werbetreibenden registriert einen Trigger bei der Android Attribution Reporting API:

   • Bei Triggern, die in Apps auftreten, registrieren Apps Trigger wie gewohnt mit der Android Attribution Reporting API.

Kampagnen mit potenziellen App- und Webzielen

1. Zwei Ziele einrichten

   • Bei einigen Kampagnen kann die Conversion je nach verschiedenen Faktoren, z. B. ob der Nutzer die App installiert hat, entweder in der App oder auf der Webseite des Werbetreibenden erfolgen.
   • In diesen Fällen empfiehlt es sich, die Quellregistrierung an das Betriebssystem zu delegieren, sofern verfügbar, damit die Quelle unabhängig davon, wo der Trigger erfolgt, korrekt zugeordnet werden kann. Bei der Registrierung der Quelle beim Betriebssystem können sowohl ein App- als auch ein Webziel in den entsprechenden Parametern angegeben werden.
   • Das Ziel der App muss im Feld destination angegeben werden.
   • Das Webziel muss im Feld web_destination angegeben werden.
   • Chrome-Entwickler sollten beachten, dass das Feld destination für die OS Attribution Reporting API ein App-Paket und keine URL sein sollte.

   Attribution-Reporting-Register-Source: {
       "source_event_id":"123001",
       "destination":"android-app://com.example.advertiser",
       "web_destination": "https://example.advertiser"
       ...
   }
   

   • Im nächsten Abschnitt zu aggregierten Berichten wird erläutert, wie sich die Verwendung von zwei Zielen auf das Rauschen in Ihren Berichten auswirken kann.

2. Mit der groben Berichterstellung lässt sich das Rauschen in Berichten auf Ereignisebene für Quellen mit zwei Zielorten reduzieren:

   • Wenn in der Quellregistrierung sowohl ein Betriebssystem (App) als auch ein Webziel angegeben wurden, wird in Berichten auf Ereignisebene standardmäßig angegeben, ob der Trigger in einem Webziel oder einem App-Ziel ausgelöst wurde. Um die Datenschutzgrenzen einzuhalten, wird diesen Berichten jedoch zusätzliches Rauschen hinzugefügt.
   • Ad-Tech-Unternehmen können das Feld coarse_event_report_destinations unter der Überschrift Attribution-Reporting-Register-Source verwenden, um die grobe Berichterstellung zu aktivieren und das Rauschen zu reduzieren. Wenn eine Quelle mit dem Feld coarse_event_report_destinations die Attribution gewinnt, enthält der resultierende Bericht sowohl die App- als auch die Webziele. Es wird nicht unterschieden, wo der tatsächliche Trigger aufgetreten ist. Allerdings ist das Rauschen geringer als bei Berichten, in denen das App- oder Webziel angegeben ist.
   • Zusammengefasste Berichte bleiben unverändert.

Für Apps, die benutzerdefinierte Chrome-Tabs verwenden

Einige Apps verwenden möglicherweise benutzerdefinierte Tabs, um Webinhalte zu rendern. Benutzerdefinierte Tabs verhalten sich ähnlich wie eine normale Webseite, wenn Zugriffe auf Apps und mobile Websites erfasst werden.

1. App-Quelle und benutzerdefinierten Tab-Trigger registrieren:

   • Folgen Sie der Anleitung zum Registrieren einer App-Quelle und eines Web-Triggers.

2. Registrieren Sie eine benutzerdefinierte Tab-Quelle und einen App-Trigger:

   • Folgen Sie der Anleitung zum Registrieren einer Webquelle und eines App-Triggers.

3. CCT-Quelle und CCT-Trigger registrieren

   • Dies wird genauso behandelt wie jede andere Web-Attribution von Website zu Website in Chrome.

Für Apps, die WebView verwenden

In einigen Apps wird WebView möglicherweise verwendet, um Inhalte anzuzeigen. Es gibt eine Vielzahl von Anwendungsfällen für WebView, z. B. das Rendern von Anzeigen, das Hosten von Webinhalten oder benutzerdefinierte App-Funktionen, die besser für ein Webformat geeignet sind.

1. Damit WebViews die Attribution Reporting API verwenden können, muss die Einbettungs-App mit den richtigen Berechtigungen konfiguriert werden.

2. In WebView ist nur die Zuordnung auf Betriebssystemebene verfügbar. Der Header „Attribution-Reporting-Support“ gibt nur das Betriebssystem zurück und nur, wenn die Android Attribution Reporting API verfügbar ist.

3. Bei der Delegierung an das Betriebssystem kann WebView registerSource oder registerWebSource und registerTrigger oder registerWebTrigger verwenden. Welche Methoden von WebView verwendet werden, wird von der App festgelegt, die die WebView rendert, und zwar für jede WebView einzeln.

   • Der Unterschied zwischen registerSource und registerWebSource besteht darin, welche Quelle als Publisher protokolliert wird. Bei registerSource wird die App als Publisher protokolliert. Ein Beispiel für die Verwendung von registerSource wäre eine Publisher-App, in der eine Anzeige mit WebView gerendert wird. Bei registerWebSource wird die in der WebView gehostete Website als Publisher protokolliert. Ein Beispiel für die Verwendung von registerWebSource ist eine App, in der eine WebView gehostet wird und auf der Website, die von der WebView gerendert wird, Anzeigen ausgeliefert werden. registerTrigger und registerWebTrigger verhalten sich ähnlich. Im Diagramm in Punkt 3 werden verschiedene Szenarien beschrieben, in denen ein App- oder SDK-Entwickler die API für die Verwendung von registerSource oder registerWebSource und registerTrigger oder registerWebTrigger konfigurieren sollte.
   • Standardmäßig werden in WebView registerSource und registerWebTrigger verwendet, wenn die Android Attribution Reporting API aufgerufen wird. Dadurch werden Quellen mit der App und Triggern mit dem Ursprung der obersten Ebene der URL in der WebView verknüpft, wenn der Trigger ausgelöst wird.

     • Wenn eine App ein anderes Verhalten erfordert, muss sie die neue Methode setAttributionRegistrationBehavior in der Klasse androidx.webkit.WebViewSettingsCompat verwenden. Mit dieser Methode wird angegeben, ob WebView registerWebSource() oder registerWebTrigger() anstelle von registerSource() oder registerTrigger() aufrufen soll.

     • Dieses Verhalten muss für jede initiierte WebView festgelegt werden.

     • Wenn das Ad-Tech-SDK die WebView initiiert, muss das SDK dieses Standardverhalten festlegen.

     • Apps, die registerWebSource() verwenden möchten, um Quellregistrierungen in WebView der Website anstelle der App zuzuordnen, müssen auf die WebApp-Zulassungsliste gesetzt werden. Füllen Sie dieses Formular aus, um sich auf die Zulassungsliste setzen zu lassen. Die Zulassungsliste soll Datenschutzbedenken im Zusammenhang mit dem Aufbau von Vertrauen für den Webkontext ausräumen.

     Wert	Beschreibung	Anwendungsbeispiel
     APP_SOURCE_AND_WEB_TRIGGER (Standard)	Ermöglicht Apps, App-Quellen (Quellen, die mit dem App-Paketnamen verknüpft sind) und Web-Trigger (Trigger, die mit der eTLD+1 verknüpft sind) über WebView zu registrieren.	Apps, die WebView zum Ausliefern von Anzeigen verwenden, anstatt das Surfen im Web zu ermöglichen
     WEB_SOURCE_AND_WEB_TRIGGER	Ermöglicht Apps, Webquellen und Web-Trigger über WebView zu registrieren.	WebView-basierte Browser-Apps, in denen sowohl Anzeigenimpressionen als auch Conversions auf Websites in WebView erfolgen können.
     APP_SOURCE_AND_APP_TRIGGER	Ermöglicht Apps, App-Quellen und App-Trigger über WebView zu registrieren.	WebView-basierte Apps, bei denen Anzeigenimpressionen und ‑conversions immer der App und nicht der eTLD+1 der WebView zugeordnet werden sollten.
     DEAKTIVIERT	Deaktiviert die Registrierung von Quellen und Triggern über WebView.

   1. Registrierungen über WebView erfassen und auslösen

   2. AdTechs sollten auf Quellregistrierungen mit dem Attribution-Reporting-Register-OS-Source-Header antworten. Je nach dem für die WebView festgelegten Verhalten wird entweder registerSource() oder registerWebSource() mit dem Betriebssystem aufgerufen und ein sekundärer API-Aufruf von der Android Attribution Reporting API an den Ad-Tech-URI initiiert.

      • Damit die Quellenregistrierung abgeschlossen werden kann, sollte der Endpunkt der Ad-Tech-Firma auf die Anfrage der Android Attribution Reporting API mit dem Antwortheader reagieren.

       Attribution-Reporting-Register-OS-Source: {
        "source_event_id":"123001",
        "destination":"android-app://com.example.advertiser",
        ...
      }
      

   3. Der Rest der Quellregistrierung bleibt unverändert.

   4. AdTechs sollten auf Triggerregistrierungen mit dem Attribution-Reporting-Register-OS-Trigger-Header reagieren. Je nach dem festgelegten Verhalten für die WebView wird entweder registerTrigger() oder registerWebTrigger() mit dem Betriebssystem aufgerufen und ein sekundärer API-Aufruf von Rb zum Ad-Tech-URI initiiert.

   5. Damit die Triggerregistrierung abgeschlossen werden kann, sollte der Endpunkt der Ad-Tech-Firma auf die Anfrage der Android Attribution Reporting API mit dem Antwortheader antworten.

   Attribution-Reporting-Register-OS-Trigger: {
       "event_trigger_data": [{"trigger_data":"1"}],
       "aggregatable_trigger_data": [
           {"key_piece":"0x400","source_keys":["campaignCounts"]},
           {"key_piece":"0xA80","source_keys":["geoValue"]}
       ],
       ...
   }
   

   • Der Rest des Registrierungsprozesses für Trigger bleibt unverändert.

Fehlerbehebung

Beim Einrichten einer App-zu-Web-Implementierung empfiehlt es sich, Debug-Berichte einzurichten, um zu prüfen, ob Quellen und Trigger richtig registriert werden. Wenn sie nicht registriert werden, erhalten Sie Informationen dazu, warum.

Allgemeine Schritte zur Fehlerbehebung bei Attribution Reporting finden Sie im Debugging-Kochbuch.