Diese Seite wurde von der Cloud Translation API übersetzt.

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

Die Attribution Reporting API ermöglicht die app- und webübergreifende Attribution für Quellen und Trigger, die auf demselben Gerät auftreten. Browser wie Chrome kann Quell- und Triggerregistrierungen an Attribution Reporting delegieren. API für Android, anstatt diese Registrierungen im Browser zu verarbeiten. Dadurch kann Android Quellen und Trigger auf Websites und in Apps abgleichen.

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

Wenn Sie die App- und Web-Attribution einrichten, sollten Sie unbedingt auch Machen Sie sich mit den verfügbaren Fehlerbehebungslösungen vertraut, um sicherzustellen, wie vorgesehen funktioniert.

Quellen und Trigger mit dem Android-Betriebssystem registrieren

Die App- und Web-Attribution ist nur verfügbar, wenn die Attribution Die Reporting API ist sowohl für den Browser als auch für das Android-Betriebssystem auf demselben . Die Verfügbarkeit der Android Attribution Reporting API wird gesendet über den Header „Attribution-Reporting-Support“. Dieser Header gibt os zurück, oder beides, je nachdem, was auf dem Gerät verfügbar ist. Wenn beide haben Anzeigentechnologie-Anbieter die Möglichkeit, entweder mit dem Browser oder dem Betriebssystem ausgelöst wird.

Der AdTech-Anbieter muss entscheiden, ob die Webquelle oder der Webtrigger registriert werden soll mit dem Browser oder Betriebssystem.

Bei reinen Webkampagnen können Anzeigentechnologie-Anbieter dennoch sowohl Quellen als auch Auslöser registrieren. mit der Attribution Reporting API von Chrome oder Sie delegieren beide an das Betriebssystem. Bei reinen Webkampagnen, bei denen entweder die Quelle oder der Trigger in einem WebView müssen Anzeigentechnologie-Anbieter sowohl die Quelle als auch die Registrierungen an des Betriebssystems. Weitere Informationen finden Sie im Abschnitt zu WebViews.
Anzeigentechnologie-Anbieter sollten weder im Chrome-Browser und Android-APIs gleichzeitig nutzen, um eine doppelte Zuordnung zu vermeiden. Berichte.
Die Attribution erfolgt für Browser und Betriebssystem separat. Wenn eine Quelle im Browser registriert, der Trigger aber im Betriebssystem registriert ist, nicht zugeordnet werden kann und umgekehrt.
Für Quellen, die zu einem App- oder Web-Trigger führen können, empfohlen, damit AdTech die Webquelle delegieren und Registrierungen auslösen kann die Android Attribution Reporting API.
Bei Triggern, die möglicherweise von App-basierten Quellen ausgelöst wurden, kann die Anzeigentechnologie Web-Trigger-Registrierung an die Android Attribution Reporting delegieren der API erstellen.
Bei Kampagnen, bei denen sowohl die Quelle als auch der Trigger in einer App ausgeführt werden, geschieht Folgendes: müssen bei der OS Attribution Reporting API registriert sein.

App-Quelle und Web-Trigger registrieren

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

Beispiel

Eine nutzende Person liest Artikel in ihrer bevorzugten Nachrichten-App. Er sieht eine Anzeige für günstige Flüge nach Paris und klicken auf die Schaltfläche zum Buchen. Die Anzeigentechnologie Die Nachrichten-App registriert die Klickquelle bei der Android Attribution Reporting API. Der Nutzer wird zur Webseite des Werbetreibenden in Chrome weitergeleitet, auf der er Folgendes tun kann: Conversion ausführen. Die Anzeigentechnologie auf der Website des Werbetreibenden prüft, ob die OS Level API und das ist es. Die Anzeigentechnologie registriert den Conversion-Trigger wird Chrome angewiesen, die Registrierung an das Betriebssystem zu delegieren, statt sich zu registrieren direkt mit der Attribution Reporting API von Chrome. Zuordnung auf Betriebssystemebene Die Reporting API kann die App-Quelle und den Web-Trigger abgleichen und die relevanten Berichte.

App-zu-Web-Attributionsablauf — App-zu-Web-Attributionsfluss

Registrierung der App-Quelle:

Das Anzeigentechnologie-SDK in der Android-App "Daily News" registriert den Klick mithilfe von registerSource()
Die Attribution Reporting API für Android sendet eine Anfrage an den AdTech-Server URL für registerSource() angegeben
Der AdTech-Server antwortet mit der Attribution-Reporting-Register-Source. um die Registrierung der Quelle abzuschließen.

Web-Triggerregistrierung:

Der Anzeigentechnologie-Anbieter registriert einen Trigger und prüft die Verfügbarkeit des Betriebssystems in der Attribution Reporting API
Die Web-ARA gibt Informationen darüber zurück, welche Plattform unterstützt wird
Der Header OS-Trigger weist die Web ARA API an, die OS ARA API aufzurufen registerWebTrigger()-Funktion
Der Anruf bei registerWebTrigger() erfolgt im Hintergrund und der Entwickler muss registerWebTrigger() nicht direkt über das Betriebssystem aufrufen.
Die OS-ARA übernimmt die Übernahme und sendet eine Anfrage an die AdTech-Server-URL, die von der Attribution-Reporting-Register-OS-Trigger-Header
Der Anzeigentechnologie-Anbieter schließt die Trigger-Registrierung bei der OS API ab
Die OS-ARA führt die Attribution nach derselben Logik durch, die auf App-Attribution und die gleichen Berichte

Workflow

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

Die Anzeigentechnologie der App registriert eine Quelle über die Attribution von Android. Reporting API mit den folgenden Anpassungen:
- Um eine App-Quelle zu registrieren, die voraussichtlich auf einer Website eine Conversion ausführt, Der Antwortheader Attribution-Reporting-Register-Source sollte eine Web-URL enthalten Ziel (eTLD+1) anstelle eines App-Ziels.
```
Attribution-Reporting-Register-Source: {
    "web_destination": "https://advertiser.example",
    ...
}
```
Hinweis: Für Kampagnen, die entweder in einem ODER ein App-Ziel festlegen, siehe den Abschnitt zu dualen Zielen
- Einige Werbetreibende nutzen möglicherweise mehrere Anbieter für Messungen, z. B. Analyse- oder Analysetool) mithilfe von 302-Weiterleitungsketten. In einigen Fällen folgt die Attribution Reporting API dem Weiterleitungspfad im Hintergrund und unter Ausführung des 302-Weiterleitungspfads für bestehende Navigationsanfragen. Diese Anfragen gehen an dieselbe URL und können zu beim Drittanbieter für Messungen die Registrierungen doppelt gezählt werden. Bis Doppelzählungen von Registrierungen verhindern, Anzeigentechnologie-Anbieter können das Weiterleitungsverhalten ändern um die Registrierung für die Attribution Reporting API noch an eine andere deterministische URL.
- Um dieses Verhalten zu ermöglichen, müssen Anzeigentechnologie-Anbieter einen neuen HTTP-Header einfügen, auf eine Registrierungsanfrage antworten:
  - Die Überschrift lautet „Attribution-Reporting-Redirect-Config“
  - Der Wert des Headers sollte „redirect-302-to-well-known“ lauten.
```
"Attribution-Reporting-Redirect-Config": "redirect-302-to-well-known"
```
  Hinweis: Alle nachfolgenden Weiterleitungen, die auf diesen Header folgen wird am Anfang des Pfads des Weiterleitungs-URI durch .well-known angehängt.
- Der Rest des Prozesses der Quellenregistrierung entspricht dem Standard Registrierung von App-zu-App-Quellen.
Hinweis :Wenn Sie oder die veröffentlichende App WebView verwenden Informationen zur Auslieferung einer nativen Anzeige in einer Android-App finden Sie im Abschnitt WebView
.
Die Anzeigentechnologie auf der Website des Werbetreibenden registriert den Trigger, indem sie So delegieren Sie in Chrome die Registrierung an die Android Attribution Reporting API:
- Sobald ein Nutzer eine Conversion auf einer Website ausführt, Anfrage zum Registrieren des Triggers bei Chrome
  1. Eine Pixel- oder fetch()-Anfrage kann verwendet werden, um die Anfrage zum Registrieren eines Trigger
  2. Der Anfrageheader „Attribution-Reporting-Support“ wird von Chrome zurückgegeben für die Anzeigentechnologie. Wenn die API sowohl im Chrome-Browser als auch im Android-Gerät gibt der Header os, web zurück
```
"Attribution-Reporting-Support": "os, web"
```
- Der AdTech-Anbieter sollte Chrome dann auffordern, die Attribution-Reporting-Register-OS-Trigger-Header, der:
  1. Weist Chrome an, die Registrierung an das Betriebssystem zu delegieren
  2. Chrome delegiert die Registrierung an das Betriebssystem, indem die API-Funktion des Betriebssystems aufgerufen wird registerWebTrigger()
    - Der Anruf an registerWebTrigger() findet im Hintergrund, der Anzeigentechnologie, statt muss registerWebTrigger() nicht direkt anrufen
  3. Die OS API initiiert einen sekundären API-Aufruf an den AdTech-URI, der übergeben wurde. über den Browser
```
"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 der Anzeigentechnologie-Anbieter trotzdem eine bevorzugte um die Triggerregistrierung zu verarbeiten, indem Sie den Parameter Attribution-Reporting-Info-Header. Der Schlüssel lautet bevorzugt-Plattform und der Zulässige Werte sind os und web. Der Browser verwendet die bevorzugte Plattform falls verfügbar und greift auf die Webplattform zurück, wenn das Betriebssystem nicht verfügbar.
Hinweis: Sowohl das Attribution-Reporting-Register-Trigger -Header mit den Informationen zur Webregistrierung und dem Attribution-Reporting-Register-OS-Trigger-Header, der die Betriebssystemregistrierung enthält Informationen sollten zurückgegeben werden, wenn eine bevorzugte Plattform angegeben wird, um die korrekte Plattformregistrierung stattfinden kann. Sowohl Betriebssystem- als auch Webregistrierungen müssen Wenn die bevorzugte Plattform nicht verfügbar ist, werden die Informationen die für die Fallback-Methode erforderlich ist.
```
Attribution-Reporting-Info: preferred-platform=os
```
- Zum Abschließen der Triggerregistrierung sollte der Endpunkt des Anzeigentechnologie-Anbieters antworten mithilfe des Antwortheaders an die Android Attribution Reporting API-Anfrage senden.
```
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 wird die Quelle möglicherweise auf einer Website in einem mobilen Browser angezeigt, während der wird in einer App auf demselben Gerät ausgelöst.

Beispiel

Ein Nutzer surft im Chrome-Browser auf seinem Android-Smartphone auf einer Website. Er sieht eine Anzeige für einen Pullover aus einem seiner Lieblingsgeschäfte. Sie klicken auf das und werden zur bereits heruntergeladenen App weitergeleitet. Die Anzeigentechnologie auf der Website, auf der die Anzeige geschaltet wurde, die Klickquelle durch die Anweisung die Registrierung an die Android Attribution Reporting API zu delegieren, über die Attribution Reporting API in Chrome. Die nutzende Person kauft den Pullover in in der Shopping-App. Die Anzeigentechnologie in der App des Werbetreibenden registriert dann Conversion-Trigger mit der Android Attribution Reporting API erstellen. Auf Betriebssystemebene kann die Attribution Reporting API die Webquelle und den App-Trigger die relevanten Berichte versenden.

Registrierung der Webquelle:

Der Anzeigentechnologie-Anbieter registriert eine Quelle und prüft die Verfügbarkeit des Betriebssystems in der Attribution Reporting API
Die Web-ARA gibt Informationen darüber zurück, welche Plattform unterstützt wird
Der Header OS-Source weist die Web ARA API an, die OS ARA API aufzurufen registerWebSource()-Funktion
Der Anruf bei registerWebSource() findet im Hintergrund statt und der Entwickler tut dies registerWebSource() muss nicht direkt über das Betriebssystem aufgerufen werden
Die OS-ARA übernimmt die Übernahme und sendet eine Anfrage an die angegebene AdTech-Server-URL durch den Attribution-Reporting-Register-OS-Source-Header
Die Anzeigentechnologie schließt die Registrierung der Quelle mit der OS API ab

Registrierung von App-Triggern:

Über das Anzeigentechnologie-SDK in der Android-App des Bekleidungsgeschäfts wird der Trigger mit die OS-ARA
Die Attribution Reporting API für Android sendet eine Anfrage an den AdTech-Server URL für registerTrigger() angegeben
Der AdTech-Server antwortet mit Attribution-Reporting-Register-Trigger Header zum Abschließen der Triggerregistrierung
Die OS-ARA führt die Attribution nach derselben Logik durch, die auf App-Attribution und die gleichen Berichte

Workflow

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

Die Anzeigentechnologie auf der Publisher-Website registriert die Quelle, indem sie So delegieren Sie in Chrome die Registrierung an die Android Attribution Reporting API:
- Bei einem Web-zu-App-Anwendungsfall wird bei der Registrierung einer Quelle die Zuordnung Der Quellparameter muss direkt angegeben werden, entweder über die Methode attributionsrc-Tag oder über die JavaScript-Registrierung
- Im folgenden Beispiel wird mit dem Tag attributionsrc der Parameter Quellparameter:
```
<img src="https://adtech.example/conversionpixel"
attributionsrc="https://adtech.example/register-source?purchase=12">
```
Der Anfrageheader Attribution-Reporting-Support wird von Chrome an den Anzeigentechnologie. Wenn die API sowohl im Chrome-Browser als auch auf dem Android-Gerät aktiviert ist, gibt der Header os, web zurück.
```
"Attribution-Reporting-Support": "os, web"
```
Hinweis: Die Attribution Reporting API muss aktiviert sein. auf dem Android-Betriebssystem, um erfolgreich in Apps und im Web zu messen.
Der AdTech-Anbieter sollte Chrome anweisen, die Delegierung an die API auf Betriebssystemebene mithilfe der Attribution-Reporting-Register-OS-Source-Header, der:
1. Weist Chrome an, die Registrierung an das Betriebssystem zu delegieren
2. Chrome delegiert die Registrierung an das Betriebssystem, indem die API-Funktion des Betriebssystems aufgerufen wird registerWebSource()
3. Der Aufruf an registerWebSource() erfolgt im Hintergrund, die Anzeigentechnologie registerWebSource() muss nicht direkt angerufen werden
4. Die OS API initiiert einen sekundären API-Aufruf an den AdTech-URI, der von der Browser
```
"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 Anzeigentechnologie eine bevorzugte Plattform für die Verarbeitung festlegen. die Quellregistrierung, indem Sie den Header Attribution-Reporting-Info einfügen. Der Schlüssel ist „preferred-platform“. Die zulässigen Werte sind os und web. Die verwendet der Browser die bevorzugte Plattform, falls verfügbar, und greift stattdessen auf wenn das Betriebssystem nicht verfügbar ist.
Hinweis: Sowohl das Attribution-Reporting-Register-Source -Header mit den Informationen zur Webregistrierung und dem Attribution-Reporting-Register-OS-Source-Header, der die Betriebssystemregistrierung enthält Informationen sollten zurückgegeben werden, wenn eine bevorzugte Plattform angegeben wird, um die korrekte Plattformregistrierung stattfinden kann. Sowohl Betriebssystem- als auch Webregistrierungen müssen Wenn die bevorzugte Plattform nicht verfügbar ist, werden die Informationen die für die Fallback-Methode erforderlich ist.
```
Attribution-Reporting-Info: preferred-platform=os
```
- Um die Registrierung der Quelle abzuschließen, sollte der Endpunkt der Anzeigentechnologie eine Antwort senden an die Android Attribution Reporting API-Anfrage mit dem Antwortheader Attribution-Reporting-Register-Source In der Antwort sollte auch ein App-Ziel im Feld „Ziel“ ein.
```
Attribution-Reporting-Register-Source {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    ...
}
```
- Um Weiterleitungen für Quellenregistrierungen zu unterstützen, folgt Chrome den Weiterleitungen und rufen die Web Context APIs für jeden Weiterleitungs-Hop auf.
- Der Rest der Quellregistrierung bleibt unverändert.
Die Anzeigentechnologie in der App des Werbetreibenden registriert einen Trigger beim Attribution Reporting API:
- Bei Triggern in Apps registrieren die Apps Trigger mit dem Android Attribution Reporting API wie gewohnt.

Kampagnen mit potenziellen Zielen für Apps und das Web

Zwei Ziele einrichten
- Einige Kampagnen können so eingerichtet sein, dass Conversions entweder in der App des Werbetreibenden oder auf der Webseite des Werbetreibenden abhängig von verschiedenen Faktoren, z. B. auf dem die App installiert ist.
- In diesen Fällen empfiehlt es sich, die Quellregistrierung an den Betriebssystem soweit verfügbar, damit die Quelle unabhängig davon korrekt zugeordnet werden kann. wo der Trigger erfolgt. Bei der Registrierung der Quelle mit dem Betriebssystem App und Webziel können in den entsprechenden Parametern angegeben werden.
- Das App-Ziel muss im Feld destination stehen
- Das Webziel muss im Feld web_destination angegeben werden
- Chrome-Entwickler sollten beachten, dass das Feld destination für das Betriebssystem Die Attribution Reporting API muss ein App-Paket und keine URL sein.
```
Attribution-Reporting-Register-Source {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    "web_destination": "https://example.advertiser"
    ...
}
```
- Im nächsten Abschnitt zur groben Berichterstellung wird erläutert, wie Sie zwei Ziele verwenden können. auf die Daten in Ihren Berichten auswirken.
Verwenden Sie grobe Berichte, um Rauschen in Berichten auf Ereignisebene für Zielquellen:
- Wenn in der Quelle sowohl ein Betriebssystem (App) als auch ein Webziel angegeben wurden geben Berichte auf Ereignisebene an, ob der in einem Web- oder App-Ziel. Um jedoch aufrechtzuerhalten, Datenschutzeinschränkungen, werden diesen Berichten zusätzliche Rauschen hinzugefügt.
- AdTechs können das Feld coarse_event_report_destinations unter der Attribution-Reporting-Register-Source-Header, um grobe Berichte zu aktivieren und Bildrauschen reduzieren. Wenn eine Quelle mit dem coarse_event_report_destinations das angegebene Feld die Attribution gewinnt, enthält der Bericht sowohl die App und Webadressen, ohne zu unterscheiden, wo der eigentliche mit geringerem Rauschen als bei Berichten, bei denen angegeben ist.
- Zusammengefasste Berichte bleiben unverändert.

Für Apps mit benutzerdefinierten Chrome-Tabs

Einige Apps verwenden möglicherweise benutzerdefinierte Tabs für das Rendern von Webinhalten. Benutzerdefinierte Tabs verhalten ähnlich wie bei einer herkömmlichen Webseite.

Registrieren Sie eine App-Quelle und einen Trigger für einen benutzerdefinierten Tab: <ph type="x-smartling-placeholder">
- Folgen Sie der Anleitung, um eine App-Quelle und einen Web-Trigger zu registrieren.
Quelle und App-Trigger eines benutzerdefinierten Tabs registrieren: <ph type="x-smartling-placeholder">
- Folgen Sie der Anleitung unter Webquelle und App-Trigger registrieren.
CCT-Quelle und CCT-Trigger registrieren <ph type="x-smartling-placeholder">
- Dies wird in Chrome wie jede Website-zu-Website-Webzuordnung behandelt.

Für Apps mit WebView

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

In WebView ist nur die Attribution auf Betriebssystemebene verfügbar. Die Der Attribution-Reporting-Support-Header gibt nur das Betriebssystem zurück, und zwar nur, wenn der Android Attribution Reporting API ist verfügbar.

Hinweis :Wenn Sie die Attribution in Chrome und WebView vornehmen möchten, Quellen- und Triggerregistrierungen in Chrome müssen an das Betriebssystem delegiert werden. da für WebView nur die betriebssystembasierte Attribution unterstützt wird.
Beim Delegieren an das Betriebssystem kann WebView registerSource oder registerWebSource und registerTrigger oder registerWebTrigger. Welche Methoden sind die von WebView verwendet werden, wird von der App festgelegt, die das WebView rendert, und wird anhand pro WebView.
- Wie unterscheiden sich registerSource und registerWebSource? als Publisher protokolliert. Mit registerSource wird die Anwendung protokolliert als Publisher; Ein Beispiel für die Verwendung von registerSource wäre ein Publisher-App, in der eine Anzeige zu sehen ist, die mit WebView gerendert wird. Mit registerWebSource, die in WebView gehostete Website wird als Publisher; Ein Beispiel für die Verwendung von registerWebSource wäre eine App, eine WebView hostet und die von der WebView gerenderte Website Anzeigen ausgeliefert werden. registerTrigger und registerWebTrigger verhalten sich ähnlich. Die Das Diagramm in Punkt 3 enthält die verschiedenen Szenarien, wenn ein App- oder SDK-Entwickler die API für die Verwendung von registerSource oder registerWebSource konfigurieren möchten, und registerTrigger oder registerWebTrigger.

Standardmäßig verwendet WebView registerSource und registerWebTrigger, wenn die Android Attribution Reporting API aufrufen. Dadurch werden Quellen mit und mit dem Ursprung der URL auf oberster Ebene in WebView ausgelöst wird, wenn der Trigger eintritt.

Wenn eine App ein anderes Verhalten erfordert, muss eine neue Methode verwendet werden setAttributionRegistrationBehavior für androidx.webkit.WebViewSettingsCompat . Diese Methode gibt an, ob WebView registerWebSource() aufrufen soll oder registerWebTrigger() statt registerSource() oder registerTrigger().
- Dieses Verhalten muss für jede WebView, die initiiert wird, festgelegt werden.
- Wenn WebView über das AdTech SDK initiiert wird, muss das SDK Folgendes festlegen: dieses Standardverhaltens.
- Für Apps, die registerWebSource() zum Verknüpfen der Quelle verwenden möchten auf der Website in WebView statt in der App registriert, müssen sie der WebApp-Zulassungsliste beitreten. Fülle dieses Formular aus, um der Zulassungsliste beizutreten. Die der Zulassungsliste sollen Datenschutzaspekte in Bezug auf Vertrauensstellung für den Webkontext.
Optionen für setAttributionRegistrationBehavior

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 eTLD+1 verknüpft sind) aus WebView zu registrieren.	Apps, die WebView zum Ausliefern von Anzeigen verwenden, statt das Surfen im Web zu ermöglichen
WEB_SOURCE_AND_WEB_TRIGGER	Ermöglicht Apps, Webquellen und Web-Trigger aus WebView zu registrieren.	WebView-basierte Browser-Apps, bei 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 aus 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 Quellen- und Triggerregistrierung von WebView.

Quell- und Triggerregistrierungen aus WebView
- Anzeigentechnologie-Anbieter sollten auf Quellenregistrierungen reagieren und die Attribution-Reporting-Register-OS-Source-Header. Basierend auf dem festgelegten Verhalten für das WebView wird dadurch entweder registerSource() oder registerWebSource() aufgerufen mit dem Betriebssystem und Initiieren eines sekundären API-Aufrufs über die Android Attribution Reporting API an den AdTech-URI.
  - Um die Registrierung der Quelle abzuschließen, sollte der Endpunkt des Anzeigentechnologie-Anbieters Folgendes tun: auf die Android Attribution Reporting API-Anfrage mit dem Parameter -Antwortheader.
```
Attribution-Reporting-Register-OS-Source {
    "source_event_id":"123001",
    "destination":"android-app://com.example.advertiser",
    ...
}
```
- Der Rest der Quellregistrierung bleibt unverändert.
Anzeigentechnologie-Anbieter sollten auf Trigger-Registrierungen reagieren – mit dem Attribution-Reporting-Register-OS-Trigger-Header. Basierend auf dem festgelegten Verhalten für das WebView wird dadurch entweder registerTrigger() oder registerWebTrigger() aufgerufen mit dem Betriebssystem und initiieren Sie einen sekundären API-Aufruf von Rb an den AdTech-URI.
- Damit die Triggerregistrierung abgeschlossen werden kann, muss der Endpunkt des Anzeigentechnologie-Anbieters auf die Android Attribution Reporting API-Anfrage mit der Antwort Header.
```
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 der Triggerregistrierung bleibt unverändert.

Fehlerbehebung

Bei der Einrichtung einer App-für-Web-Implementierung empfiehlt es sich, das Debugging , um zu prüfen, ob Quellen und Trigger korrekt registriert werden nicht registriert sind, um Informationen über den Grund zu erhalten.

Allgemeine Schritte zur Fehlerbehebung in Attribution Reporting finden Sie im Cookbook zur Fehlerbehebung.