Diese Seite wurde von der Cloud Translation API übersetzt.

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

Mit der Attribution Reporting API ist eine App- und webübergreifende Attribution für Quellen und Trigger möglich, die auf demselben Gerät auftreten. Browser wie Chrome können sowohl die Quellen- als auch die Triggerregistrierung an die Attribution Reporting API für Android delegieren, anstatt diese Registrierungen im Browser zu verarbeiten. So können Android-Geräte Quellen und Trigger sowohl auf Websites als auch 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 sich auch mit den verfügbaren Debugging-Lösungen vertraut machen, damit die Einrichtung wie vorgesehen funktioniert.

Quellen und Trigger beim Android-Betriebssystem registrieren

Die App- und Web-Attribution 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 Attribution Reporting API für Android wird über den „Attribution-Reporting-Support“-Header gesendet. Dieser Header gibt „os“, „web“ oder beides zurück, je nachdem, was auf dem Gerät verfügbar ist. Wenn beide verfügbar sind, haben Anbieter von Anzeigentechnologien die Möglichkeit, Webquellen und Webtrigger entweder beim Browser oder beim Betriebssystem zu registrieren.

Die Anzeigentechnologie muss entscheiden, ob die Webquelle oder der Webtrigger beim Browser oder beim Betriebssystem registriert werden soll.

Bei reinen Webkampagnen können Anbieter von Anzeigentechnologien weiterhin sowohl Quellen als auch Trigger mit der Attribution Reporting API von Chrome registrieren oder beide an das Betriebssystem delegieren. Bei reinen Webkampagnen, bei denen die Quelle oder der Trigger in einer WebView auftreten kann, müssen Anbieter von Anzeigentechnologien sowohl die Registrierung der Quelle als auch die des Triggers an das Betriebssystem delegieren. Weitere Informationen finden Sie im Abschnitt zu WebViews.
AdTech-Anbieter sollten Quellen und Trigger nicht gleichzeitig über die Chrome- und die Android APIs registrieren, um doppelte Attributionsberichte zu vermeiden.
Die Attribution erfolgt separat für Browser und Betriebssystem. Wenn eine Quelle beim Browser registriert ist, der Trigger aber beim Betriebssystem, können sie nicht abgeglichen werden. Das gilt auch umgekehrt.
Bei Quellen, die zu einem App- oder Webtrigger führen können, wird dringend empfohlen, die Registrierung von Webquellen und Triggern an die Android Attribution Reporting API zu delegieren.
Bei Triggern, die möglicherweise von appbasierten Quellen ausgelöst wurden, kann die AdTech-Lösung die Registrierung von Webtriggern an die Android Attribution Reporting API delegieren.
Bei Kampagnen, bei denen sowohl die Quelle als auch der Trigger in einer App auftreten, müssen beide bei der Attribution Reporting API des Betriebssystems registriert werden.

App-Quelle und Webtrigger registrieren

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

Beispiel

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

Registrierung der App-Quelle:

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

Registrierung von Webtriggern:

Das AdTech-Unternehmen registriert einen Trigger und prüft in der Attribution Reporting API, ob das Betriebssystem verfügbar ist.
Die Web-ARA gibt Informationen zur unterstützten Plattform zurück.
Der OS-Trigger-Header weist die Web-ARA API an, die Funktion registerWebTrigger() der OS ARA API aufzurufen.
Der Aufruf von registerWebTrigger() erfolgt im Hintergrund und der Entwickler muss registerWebTrigger() nicht direkt über das Betriebssystem aufrufen.
Die OS ARA übernimmt und sendet eine Anfrage an die AdTech-Server-URL, die im Attribution-Reporting-Register-OS-Trigger-Header angegeben ist.
Die AdTech-Plattform führt die Triggerregistrierung über die Betriebssystem-API durch.
Die OS ARA führt die Attribution gemäß derselben Logik durch, die auch für die App-zu-App-Attribution verwendet wird, und sendet dieselben Berichte.

Workflow

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

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, von der voraussichtlich eine Conversion auf einer Website erfolgt, sollte der Attribution-Reporting-Register-Source-Antwortheader ein Webziel (eTLD+1) anstelle eines App-Ziels enthalten.
```
Attribution-Reporting-Register-Source: {
    "web_destination": "https://advertiser.example",
    ...
}
```
Hinweis :Informationen zu Kampagnen, bei denen eine Conversion sowohl auf einer Website als auch in einer App erfolgen kann, finden Sie im Abschnitt zu dualen Zielvorhaben
.
- Einige Werbetreibende verwenden möglicherweise mehrere Analyseanbieter (z. B. ein Analysetool oder ein Analysetool eines Drittanbieters) mit 302-Weiterleitungsketten. In einigen Fällen folgt die Attribution Reporting API dem im Header „Attribution-Reporting-Redirect“ angegebenen Weiterleitungspfad im Hintergrund und gleichzeitig wird der 302-Weiterleitungspfad für vorhandene Navigationsanfragen im Vordergrund ausgeführt. Diese Anfragen werden an dieselbe URL gesendet und können dazu führen, dass der Analyseanbieter die Registrierungen doppelt zählt. Um eine doppelte Zählung von Registrierungen zu vermeiden, können Anbieter von Anzeigentechnologien das Weiterleitungsverhalten ändern, damit die Registrierung der Attribution Reporting API an eine alternative, aber deterministische URL gesendet wird.
- Um dieses Verhalten zu aktivieren, müssen Anbieter von Anzeigentechnologien bei der Beantwortung einer Registrierungsanfrage einen neuen HTTP-Header angeben:
  - 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
```
  Hinweis :An den Anfang des Pfads des Weiterleitungs-URIs aller nachfolgenden Weiterleitungen, die dieser Überschrift folgen, wird .well-known angehängt.
- Der Rest des Registrierungsvorgangs für die Quelle entspricht dem einer standardmäßigen App-zu-App-Quellenregistrierung.
Hinweis :Wenn Sie oder die App, die veröffentlicht wird, WebView verwenden, um eine Anzeige in einer Android-App zu schalten, lesen Sie den Abschnitt zu WebView
.
Die Anzeigentechnologie 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 ausführt, sendet die Anzeigentechnologie eine Anfrage, um den Trigger in Chrome zu registrieren.
  1. Eine Pixel- oder fetch()-Anfrage kann verwendet werden, um einen Trigger zu registrieren.
  2. Die Attribution-Reporting-Support-Anfrageheader wird von Chrome an die Anzeigentechnologie zurückgegeben. Wenn die API sowohl im Chrome-Browser als auch auf dem Android-Gerät aktiviert ist, wird in der Kopfzeile os, web zurückgegeben.
```
Attribution-Reporting-Support: os, web
```
- Die Anzeigentechnologie sollte Chrome dann mithilfe der Attribution-Reporting-Register-OS-Trigger-Header-Anweisung anweisen, die Deaktivierung an das Betriebssystem zu delegieren. Dieser Header hat folgende Eigenschaften:
  1. Chrome wird angewiesen, die Registrierung an das Betriebssystem zu delegieren.
  2. Chrome delegiert die Registrierung an das Betriebssystem, indem die OS API-FunktionregisterWebTrigger() aufgerufen wird.
    - Der Aufruf von registerWebTrigger() erfolgt im Hintergrund. Die Anzeigentechnologie muss registerWebTrigger() nicht direkt aufrufen.
  3. Die OS API initiiert einen sekundären API-Aufruf an den vom Browser übergebenen AdTech-URI.
```
Attribution-Reporting-Register-OS-Trigger: "https://adtech.example/register-trigger",
"https://other-adtech.example/register-trigger"
```
- In einigen Fällen ist die Attribution-Reporting-Support-Überschrift nicht verfügbar und kann nicht gesendet werden. In diesem Fall kann die Anzeigentechnologie weiterhin eine bevorzugte Plattform für die Triggerregistrierung festlegen, indem der Attribution-Reporting-Info-Header eingefügt wird. Der Schlüssel ist „preferred-platform“ und die zulässigen Werte sind os und web. Der Browser verwendet die bevorzugte Plattform, wenn sie verfügbar ist, und greift auf die Webplattform zurück, wenn das Betriebssystem nicht verfügbar ist.
Hinweis :Sowohl der Attribution-Reporting-Register-Trigger-Header mit den Informationen zur Webregistrierung als auch der Attribution-Reporting-Register-OS-Trigger-Header mit den Informationen zur Betriebssystemregistrierung müssen zurückgegeben werden, wenn eine bevorzugte Plattform angegeben wird, damit die korrekte Plattformregistrierung erfolgen kann. Sowohl Betriebssystem- als auch Webregistrierungen müssen angegeben werden, damit für den Fall, dass die bevorzugte Plattform nicht verfügbar ist, die für die Fallback-Methode erforderlichen Informationen vorhanden sind.
```
Attribution-Reporting-Info: preferred-platform=os
```
- Um die Triggerregistrierung abzuschließen, muss der Endpunkt der AdTech-Plattform mit dem Antwortheader auf die Android Attribution Reporting API-Anfrage 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.

Webanwendung 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 im Chrome-Browser auf seinem Android-Smartphone. Sie sehen eine Anzeige für einen Pullover in einem ihrer Lieblingsgeschäfte. Er klickt auf die Anzeige und wird zur App weitergeleitet, die er bereits heruntergeladen hat. Die Anzeigentechnologie 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-Technologie 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.

Attributionsablauf für Web-zu-App-Kampagnen

Registrierung von Webquellen:

Das AdTech-Unternehmen registriert eine Quelle und prüft in der Attribution Reporting API, ob das Betriebssystem verfügbar ist.
Die Web-ARA gibt Informationen zur unterstützten Plattform zurück.
Der OS-Source-Header weist die Web-ARA API an, die Funktion registerWebSource() der OS ARA API aufzurufen.
Der Aufruf von registerWebSource() erfolgt im Hintergrund und der Entwickler muss registerWebSource() nicht direkt über das Betriebssystem aufrufen.
Der OS ARA übernimmt und sendet eine Anfrage an die AdTech-Server-URL, die im Attribution-Reporting-Register-OS-Source-Header angegeben ist.
Die Anzeigentechnologie führt die Quellenregistrierung mit der OS API durch.

Registrierung von App-Triggern:

Das Ad Tech-SDK in der Android-App des Bekleidungsgeschäfts registriert den Trigger bei der OS ARA.
Die Attribution Reporting API auf Android sendet eine Anfrage an die Anzeigentechnologie-Server-URL, die für registerTrigger() angegeben wurde.
Der AdTech-Server antwortet mit dem Attribution-Reporting-Register-Trigger-Header, um die Triggerregistrierung abzuschließen.
Die OS ARA führt die Attribution gemäß derselben Logik durch, die auch für die App-zu-App-Attribution verwendet wird, und sendet dieselben Berichte.

Workflow

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

Die Anzeigentechnologie auf der Publisher-Website registriert die Quelle, indem sie Chrome anweist, die Registrierung an die Android Attribution Reporting API zu delegieren:
- Bei einem Web-zu-App-Anwendungsfall muss der Attributionsquellenparameter bei der Registrierung einer Quelle direkt angegeben werden, entweder mit dem attributionsrc-Tag oder mit der JavaScript-Registrierung.
- Im folgenden Beispiel wird mit dem attributionsrc-Tag der Parameter „source“ angegeben:
```
<img src="https://adtech.example/conversionpixel"
attributionsrc="https://adtech.example/register-source?purchase=12">
```
Die Attribution-Reporting-Support-Anfrageheader wird von Chrome an die Anzeigentechnologie zurückgegeben. Wenn die API sowohl im Chrome-Browser als auch auf dem Android-Gerät aktiviert ist, wird os, web zurückgegeben.
```
Attribution-Reporting-Support: os, web
```
Hinweis :Die Attribution Reporting API muss unter Android aktiviert sein, damit eine App- und Webanalyse möglich ist.
Die AdTech-Technologie sollte Chrome anweisen, die Anfrage über den Attribution-Reporting-Register-OS-Source-Header an die API auf Betriebssystemebene zu delegieren. Dieser Header muss folgende Anforderungen erfüllen:
1. Chrome wird angewiesen, die Registrierung an das Betriebssystem zu delegieren.
2. Chrome delegiert die Registrierung an das Betriebssystem, indem die OS API-FunktionregisterWebSource() aufgerufen wird.
3. Der Aufruf von registerWebSource() erfolgt im Hintergrund. Die Anzeigentechnologie muss registerWebSource() nicht direkt aufrufen.
4. Die OS API initiiert einen sekundären API-Aufruf an den vom Browser übergebenen AdTech-URI.
```
Attribution-Reporting-Register-OS-Source: "https://adtech.example/register-source"
```
- In einigen Fällen ist die Überschrift Attribution-Reporting-Support nicht verfügbar. In diesem Fall kann die Anzeigentechnologie weiterhin eine bevorzugte Plattform für die Quellregistrierung festlegen, indem der Attribution-Reporting-Info-Header eingefügt wird. Der Schlüssel ist „preferred-platform“ und die zulässigen Werte sind os und web. Der Browser verwendet die bevorzugte Plattform, wenn sie verfügbar ist, und wechselt zur Webplattform, wenn das Betriebssystem nicht verfügbar ist.
Hinweis :Sowohl der Attribution-Reporting-Register-Source-Header mit den Informationen zur Webregistrierung als auch der Attribution-Reporting-Register-OS-Source-Header mit den Informationen zur Betriebssystemregistrierung müssen zurückgegeben werden, wenn eine bevorzugte Plattform angegeben wird, damit die korrekte Plattformregistrierung erfolgen kann. Sowohl Betriebssystem- als auch Webregistrierungen müssen angegeben werden, damit die für die Fallback-Methode erforderlichen Informationen vorhanden sind, falls die bevorzugte Plattform nicht verfügbar ist.
```
Attribution-Reporting-Info: preferred-platform=os
```
- Um die Quellenregistrierung abzuschließen, muss der Endpunkt der AdTech-Plattform auf die Android Attribution Reporting API-Anfrage mit dem Antwortheader Attribution-Reporting-Register-Source antworten. Die Antwort sollte außerdem ein App-Ziel im Zielfeld angeben.
```
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 ruft für jeden Weiterleitungs-Hop die Webkontext-APIs auf.
- Der Rest der Quellregistrierung bleibt unverändert.
Die Anzeigentechnologie in der App des Werbetreibenden registriert einen Trigger bei der Attribution Reporting API von Android:
- Bei Triggern, die in Apps auftreten, registrieren die Apps die Trigger wie gewohnt bei der Android Attribution Reporting API.

Kampagnen mit potenziellen App- und Webzielen

Zwei Ziele einrichten
- Bei einigen Kampagnen kann festgelegt werden, dass Conversions entweder in der App oder auf der Website des Werbetreibenden erfolgen. Das hängt von verschiedenen Faktoren ab, z. B. davon, ob der Nutzer die App installiert hat.
- In diesen Fällen wird empfohlen, die Quellenregistrierung an das Betriebssystem zu delegieren, sofern verfügbar, damit die Quelle unabhängig davon, wo der Trigger auftritt, korrekt zugeordnet werden kann. Bei der Registrierung der Quelle beim Betriebssystem können in den entsprechenden Parametern sowohl eine App als auch ein Webziel angegeben werden.
- Das App-Ziel muss im Feld destination angegeben sein.
- Das Webziel muss im Feld web_destination angegeben sein.
- Chrome-Entwickler sollten beachten, dass das Feld destination für die Attribution Reporting API des Betriebssystems 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 groben Berichten wird erläutert, wie sich die Verwendung von zwei Zielen auf die Fehler in Ihren Berichten auswirken kann.
Verwenden Sie grobe Berichte, um den Rausch in Berichten auf Ereignisebene für Quellen mit zwei Zielen zu reduzieren:
- Wenn bei der Registrierung der Quelle sowohl ein Betriebssystem (App) als auch ein Webziel angegeben wurden, wird in Berichten auf Ereignisebene standardmäßig angegeben, ob der Trigger in einem Web- oder App-Ziel ausgelöst wurde. Um die Datenschutzanforderungen einzuhalten, werden diesen Berichten jedoch zusätzliche Störungen hinzugefügt.
- Mit dem Feld coarse_event_report_destinations unter der Überschrift Attribution-Reporting-Register-Source können Werbetechnologieexperten grobe Berichte aktivieren und Störfaktoren reduzieren. Wenn eine Quelle mit dem Feld coarse_event_report_destinations die Attribution erhält, enthält der resultierende Bericht sowohl App- als auch Webziele, ohne dass unterschieden wird, wo der tatsächliche Trigger ausgelöst wurde. Die Daten sind jedoch weniger fehlerbehaftet als in Berichten, in denen die App oder das Webziel angegeben ist.
- Zusammengefasste Berichte bleiben unverändert.

Für Apps mit benutzerdefinierten Chrome-Tabs

Einige Apps verwenden möglicherweise benutzerdefinierte Tabs, um Webinhalte zu rendern. Benutzerdefinierte Tabs verhalten sich bei Messungen in Apps und auf mobilen Websites ähnlich wie eine normale Webseite.

App-Quelle und Trigger für benutzerdefinierten Tab registrieren:
- Folgen Sie der Anleitung zum Registrieren einer App-Quelle und eines Webtriggers.
So registrieren Sie eine Quelle für benutzerdefinierte Tabs und einen App-Trigger:
- Folgen Sie der Anleitung zum Registrieren einer Webquelle und eines App-Triggers.
CCT-Quelle und CCT-Trigger registrieren
- Dieser Vorgang wird wie jede Website-zu-Website-Webverknüpfung in Chrome behandelt.

Für Apps mit WebView

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

Damit WebViews die Attribution Reporting API verwenden können, muss die eingebettete App mit den richtigen Berechtigungen konfiguriert werden.
In WebView ist nur die Attribution auf Betriebssystemebene verfügbar. Der „Attribution-Reporting-Support“-Header gibt nur „os“ zurück und nur, wenn die Android Attribution Reporting API verfügbar ist.

Hinweis: Für die Attribution in Chrome und WebView müssen die Registrierungen von Quellen und Triggern in Chrome an das Betriebssystem delegiert werden, da für WebView nur die betriebssystembasierte Attribution unterstützt wird.

Beim Delegieren an das Betriebssystem verwendet WebView möglicherweise registerSource oder registerWebSource und registerTrigger oder registerWebTrigger. Welche Methoden von WebView verwendet werden, wird von der App festgelegt, die die WebView rendert. Die Entscheidung wird pro WebView getroffen.

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 ist 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, die eine WebView hostet und auf der Website, die von der WebView gerendert wird, Anzeigen ausgeliefert werden. registerTrigger und registerWebTrigger verhalten sich ähnlich. Das Diagramm in Punkt 3 zeigt verschiedene Szenarien, in denen ein App- oder SDK-Entwickler die API für die Verwendung von registerSource oder registerWebSource und registerTrigger oder registerWebTrigger konfigurieren möchte.

Standardmäßig verwendet WebView registerSource und registerWebTrigger, wenn die Android Attribution Reporting API aufgerufen wird. Dadurch werden Quellen mit der App und Trigger mit dem Ursprung der obersten Ebene der URL in der WebView verknüpft, wenn der Trigger ausgelöst wird.

Wenn für eine App ein anderes Verhalten erforderlich ist, muss die neue Methode setAttributionRegistrationBehavior in der Klasse androidx.webkit.WebViewSettingsCompat verwendet werden. Mit dieser Methode wird angegeben, ob WebView registerWebSource() oder registerWebTrigger() statt registerSource() oder registerTrigger() aufrufen soll.
Dieses Verhalten muss für jede gestartete WebView festgelegt werden.
Wenn das AdTech-SDK die WebView initiiert, muss das SDK dieses Standardverhalten festlegen.
Wenn Sie mit registerWebSource() Quellregistrierungen der Website in WebView statt der App zuordnen möchten, müssen Sie die Zulassungsliste für Webanwendungen beitreten. Füllen Sie dieses Formular aus, um auf die Zulassungsliste gesetzt zu werden. Mit der Zulassungsliste sollen Datenschutzaspekte beim Herstellen von Vertrauen für den Webkontext minimiert werden.

Wert	Beschreibung	Beispiel
APP_SOURCE_AND_WEB_TRIGGER (Standard)	Ermöglicht es Apps, App-Quellen (mit dem App-Paketnamen verknüpfte Quellen) und Webtrigger (mit der eTLD+1 verknüpfte Trigger) über WebView zu registrieren.	Apps, die WebView zum Ausliefern von Anzeigen statt zum Websurfen verwenden
WEB_SOURCE_AND_WEB_TRIGGER	Ermöglicht Apps, Webquellen und Webtrigger über WebView zu registrieren.	WebView-basierte Browser-Apps, bei denen Anzeigenimpressionen und Conversions sowohl auf Websites in WebView als auch in der App selbst 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.

Registrierungen aus WebView stammen
AdTech-Anbieter sollten auf Quellenregistrierungen mit dem Attribution-Reporting-Register-OS-Source-Header antworten. Je nach festgelegtem Verhalten für die WebView wird entweder registerSource() oder registerWebSource() über das Betriebssystem aufgerufen und ein sekundärer API-Aufruf von der Android Attribution Reporting API an die URI der Anzeigentechnologie initiiert.
- Damit die Quelle registriert werden kann, muss der Endpunkt der AdTech-Plattform mit dem Antwortheader auf die Android Attribution Reporting API-Anfrage antworten.
```
 Attribution-Reporting-Register-OS-Source: {
  "source_event_id":"123001",
  "destination":"android-app://com.example.advertiser",
  ...
}
```
Der Rest der Quellregistrierung bleibt unverändert.
AdTech-Anbieter sollten auf Triggerregistrierungen mit dem Attribution-Reporting-Register-OS-Trigger-Header reagieren. Je nach festgelegtem Verhalten für die WebView wird entweder registerTrigger() oder registerWebTrigger() über das Betriebssystem aufgerufen und ein sekundärer API-Aufruf von Rb an die AdTech-URI initiiert.
Damit die Triggerregistrierung abgeschlossen werden kann, muss der Endpunkt der AdTech-Plattform mit dem Antwortheader auf die Android Attribution Reporting API-Anfrage 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 der Triggerregistrierung bleibt unverändert.

Fehlerbehebung

Wenn Sie eine App für die Webimplementierung einrichten, sollten Sie Debugberichte einrichten, um zu prüfen, ob Quellen und Trigger richtig registriert werden. Falls nicht, erhalten Sie Informationen dazu, warum das der Fall ist.

Allgemeine Schritte zur Fehlerbehebung bei Attributionsberichten finden Sie im Debugging-Rezeptbuch.