Attributionsberichte: App- und webübergreifende Messungen

Letzte Updates

Trigger-Pfade

Wie im Designvorschlag für die Attribution Reporting API beschrieben, ermöglicht die API die Zuordnung der folgenden Triggerpfade auf einem einzelnen Android-Gerät. Hier definieren wir Web als (1) einen eigenständigen Browser, der unter Android ausgeführt wird (z.B. Chrome), oder (2) eine WebView, die in einer Android-App ausgeführt wird.

  • 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 eine Conversion im Web aus.
  • Web-to-app::Der Nutzer sieht eine Anzeige im Web und führt dann eine Conversion in einer App aus.
  • Web-to-web::Der Nutzer sieht eine Anzeige im Web und führt dann eine Conversion im Web aus.

Die oben genannten Triggerpfade entsprechen den folgenden Anforderungen:

  • Für AdTech-Unternehmen: Aktualisierungen von API-Aufrufen und Berichten, um App-zu-Web-Pfade zu ermöglichen.
  • Für Apps und Browser: Möglichkeit, die Registrierung von Web-Attributionsquellen und Web-Triggern an Android zu übergeben.

In diesem Dokument wird erläutert, wie die Attribution Reporting API erweitert wird, um App-zu-Web-, Web-zu-App- und Web-zu-Web-Triggerpfade zu unterstützen. Außerdem wird beschrieben, welche Änderungen Ad-Tech-Unternehmen und Apps vornehmen müssen, um die Anforderungen für die Unterstützung dieser Triggerpfade zu erfüllen.

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.

Sobald die Registrierung abgeschlossen ist, wird sie von der API verworfen, wenn ein nicht registrierter Registrierungsaufruf empfangen wird.

Bei der Registrierung sollten Ad-Tech-Plattformen darauf achten, dass sie alle Server-URLs verwenden, die sie möglicherweise in Apps und im Web verwenden, um Attributionsquellen und ‑trigger zu registrieren. Es werden mehrere Serverregistrierungs-URLs unterstützt, aber nur ein Berichterstellungsursprung. Dieser Berichtsursprung wird aus der Domain einer der Serverregistrierungs-URLs abgeleitet.

Änderungen für Anzeigentechnologien

In diesem Abschnitt werden Änderungen für AdTechs beschrieben, die die Attribution Reporting API verwenden.

Änderungen bei Registrierung und Attribution

Beim Registrieren einer Attributionsquelle geben Ad-Tech-Unternehmen ein Zielfeld an, das dem App-Paketnamen entspricht, in dem das Triggerereignis auftritt. Um die Messung von App zu Web zu ermöglichen, planen wir, ein App-Zielfeld (App-Paketname) und ein Web-Zielfeld (eTLD+1) zu unterstützen.

Beim Registrieren von Quellen oder Triggern für die Webzuordnung werden Weiterleitungen von der API nicht unterstützt, da jede App, die Webinhalte hostet, ihr eigenes Berechtigungsmodell haben kann. Jede App ist dafür verantwortlich, Weiterleitungen zu folgen (sofern unterstützt) und die Webkontext-APIs für jeden Weiterleitungssprung aufzurufen.

Außerdem können Anzeigentechnologien durch diese Integration appspezifische Attributionslogik für Web-Attributionsquellen verwenden. Sie können jetzt beispielsweise Post-Install-Attributionszeiträume für eine Web-Attributionsquelle angeben.

App- und Webberichte erhalten

Mit der Android Attribution Reporting API können Berichte für App- und Web-Conversions gesendet werden. Wenn Ad-Tech-Unternehmen Triggerdaten und Aggregationsschlüsselwerte nicht für Web- und App-Oberflächen abstimmen möchten, können sie zwischen einer Web- und einer App-Conversion unterscheiden:

  • Für Berichte auf Ereignisebene wird ein Zielfeld unterstützt, in dem angegeben wird, ob der Trigger im Web (Ziel ist eine eTLD+1) oder in einer App (Ziel ist ein App-Paketname) ausgelöst wurde.
  • Bei aggregierbaren Berichten wird das Ziel in Klartext gesendet.

Auswirkungen der Web-zu-Web-Analyse

Apps entscheiden, wann die Registrierung an die Attribution Reporting API übergeben wird. Dabei sind einige Aspekte zu berücksichtigen:

  • Ist die Attribution Reporting API auf diesem Gerät verfügbar? Wir stellen Apps ein neues Signal zur Verfügung, das zurückgibt, ob die Attribution Reporting API auf dem jeweiligen Gerät verfügbar ist. Weitere Informationen dazu, wie Apps die Registrierung für die Attribution Reporting API bestehen können, finden Sie im Abschnitt zu App-Änderungen.
  • Welcher Teil der Attributionsquellen und ‑auslöser sollte an die API übergeben werden? Die Entscheidung hierfür liegt bei der jeweiligen App oder bei der AdTech-Lösung, sofern die App eine Auswahl zulässt. Wenn die App eine eigene Analyselösung hat, sollten Sie diese eventuell stattdessen verwenden. Wenn Sie alle Quell- und Triggerregistrierungen an die Android Attribution Reporting API übergeben, sofern verfügbar, ist die Attribution über App und Web hinweg am genauesten.

Das folgende Beispiel zeigt, wie Browser-Apps mit der Attribution Reporting API zusammenarbeiten können, um genaue Analysen zu ermöglichen, wenn der Nutzer sowohl in einer Browser-App als auch in einer Nicht-Browser-App auf eine Anzeige klickt:

Beispiele für Nutzerklicks und ‑conversions über einen Zeitraum von drei Tagen.
Beispiel für die Registrierung von Quelle und Trigger in einem Browser und einer App
  • Am ersten Tag klickt der Nutzer in der Browser-App auf eine Anzeige.
    • Die Browser-App kann entweder eine eigene Analyselösung verwenden oder die Registrierung des Webanzeigenklicks an die Attribution Reporting API übergeben.
  • Am zweiten Tag klickt der Nutzer auf eine Anzeige in einer Nicht-Browser-App.
    • Der Klick wird als Attributionsquelle bei der API registriert. Die Browser-App kann diesen Klick nicht sehen, da das Ereignis in einer anderen App stattgefunden hat.
  • Tag 3: Der Nutzer führt in der Browser-App eine Conversion durch.
    • Wenn die Browser-App sowohl den Klick als auch die Conversion mit ihrer eigenen Analyselösung erfasst und diese Informationen an die Attribution Reporting API übergibt, ist es unwahrscheinlich, dass ein Ad-Tech-Unternehmen Conversion-Berichte über verschiedene Analyselösungen hinweg deduplizieren kann. Außerdem kann ein AdTech-Anbieter sowohl die Ratenbegrenzungen für Browser-Apps als auch die Ratenbegrenzungen für die Attribution Reporting API nutzen. Daher empfehlen wir, dass Apps alle Anzeigenereignisse und Conversions, die in der API registriert werden sollen, an die API übergeben, wenn sie verfügbar ist.

Attributionsquelle und Trigger über WebView registrieren

Wenn in der App mit WebView Webinhalte anstelle einer Android-Anzeige präsentiert werden, kann die App eine Anfrage stellen, um der Zulassungsliste beizutreten für registerWebSource(). Dabei muss der Top-Level-Ursprung der Website angegeben werden, die der Attributionsquelle zugeordnet werden soll, und nicht der Paketname der App.

Ähnlich wie bei Browsern unterstützt WebView registerWebTrigger() für Triggerregistrierungen, wodurch der Trigger dem Top-Level-Ursprung zugeordnet wird. Es gibt keine Unterstützung für WebView zum Registrieren eines App-Triggers. Wenden Sie sich an uns, wenn Sie einen Anwendungsfall dafür haben. Eine vollständige Liste der von WebView unterstützten Kombinationen finden Sie unter Attributionsquelle und Triggerregistrierung über WebView.

Im Gegensatz zu Browsern unterstützt WebView die Registrierung beim Betriebssystem im Header Attribution-Reporting-Eligible nur, wenn die Attribution Reporting API von Android verfügbar ist. Wenn die Attribution Reporting API von Android nicht verfügbar ist, wird in WebView kein Attribution-Reporting-Eligible-Header festgelegt und es werden keine Registrierungen vorgenommen.

So registrieren Sie eine Attributionsquelle oder einen Trigger über das Betriebssystem:

  • Ad-Tech-Unternehmen sollten auf Quellregistrierungen mit dem Header Attribution-Reporting-Register-OS-Source antworten. Dadurch wird ein sekundärer API-Aufruf von der WebView an registerSource() oder registerWebSource() initiiert.
  • Ad-Tech-Anbieter können auch mit dem Header Attribution-Reporting-Register-OS-Trigger auf Triggerregistrierungen reagieren. Dadurch wird ein sekundärer API-Aufruf von der WebView zu registerWebTrigger() oder registerTrigger() initiiert.

Wenn die Antwort die vorherigen Header nicht enthält oder auch die Header Attribution-Reporting-Register-Source / Attribution-Reporting-Register-Trigger enthält, obwohl das Web nicht unterstützt wird, schlägt die gesamte Registrierung fehl.

Weitere Informationen dazu, ob WebView registerSource() / registerWebSource() und registerTrigger() / registerWebTrigger() verwendet und wie Sie dieses Verhalten ändern können, finden Sie unter Attributionsquelle und Triggerregistrierung über WebView.

Übergangsberichte zum Debugging

Die Attribution Reporting API unterstützt ein optionales Feature namens Übergangs-Debuggingberichte. Damit können Ad-Tech-Unternehmen mehr Informationen zu Attributionsberichten erhalten, wenn eine Werbe-ID verfügbar ist. Es gibt zwei Arten von Debugging-Berichten: attribution-success und verbose. Diese Berichte werden für die App- und Web-Attribution unterstützt. Beide Berichtstypen enthalten dieselben Informationen. Der einzige Unterschied besteht in den Berechtigungen, die festlegen, wann Debugging-Berichte gesendet werden.

Für die Web-zu-Web-Attribution innerhalb einer einzelnen App (z. B. in derselben Browser-App) sind Erfolgs- und ausführliche Berichte nur verfügbar, wenn Drittanbieter-Cookies verfügbar sind. Sie basieren nicht auf der Verfügbarkeit der Werbe-ID.

Für die App-zu-Web-, Web-zu-App- und Web-zu-Web-App-übergreifende Attribution sind Erfolgs- und ausführliche Berichte verfügbar, wenn die AdID auf der App-Seite verfügbar ist und die Ad-Tech-Plattform dieselbe (richtige) AdID auf der Web-Seite übergeben kann.

In einem späteren Beispiel für App-zu-Web-Conversion-Tracking erfolgt die Quelle in einer Publisher-App, der Trigger jedoch auf einer Werbetreibenden-Website in einer Browser-App.

Damit ein Debugging-Bericht zum Erfolg der Zuordnung für App-zu-Web aktiviert werden kann, müssen die folgenden Bedingungen erfüllt sein:

  • Der Nutzer darf die Personalisierung über die Werbe-ID nicht deaktiviert haben.
  • In der Publisher-App müssen AdID-Berechtigungen deklariert sein
  • Die Ad-Tech-Lösung muss den AdID-Wert bei der Triggerregistrierung (aus einem Webkontext) übergeben.

So aktivieren Sie ausführliche Debugging-Berichte für App-to-Web:

  • Für ausführliche Quellberichte sind nur Berechtigungen auf Publisherseite erforderlich. Damit ausführliche Quellberichte gesendet werden können, darf der Nutzer die Personalisierung mit der Werbe-ID nicht deaktiviert haben und in der Publisher-App müssen Berechtigungen für die Werbe-ID deklariert sein.
  • Ausführliche Berichte für Trigger hängen nur von den Berechtigungen der Triggerseite ab (in diesem Beispiel Web). Drittanbieter-Cookies müssen im Browser verfügbar sein, damit ausführliche Berichte gesendet werden können.
  • Bei ausführlichen Berichten zu Triggern, die optional eine source_debug_key enthalten können, wird die source_debug_key eingefügt, wenn die Werbe-ID für die Publisher-App verfügbar ist.

Hinweis: In jedem Fall muss die Ad-Tech-Firma dem Empfang ausführlicher Debugging-Berichte über das debug_reporting-Wörterbuchfeld in den Headern für die Quell- und Triggerregistrierung zustimmen.

Änderungen für Apps

Wir unterstützen die Attribution über App- und Weboberflächen hinweg, indem Apps die Registrierung von Web-Attributionsquellen und Web-Triggern mithilfe einer neuen Reihe von API-Aufrufen für den Webkontext an die Attribution Reporting API in Android übergeben können.

Nachdem Sie die Registrierungsschritte in den folgenden Abschnitten ausgeführt haben, werden App- und Web-Attributionsquellen und ‑trigger auf dem Gerät gespeichert. Die Attribution Reporting API kann dann die nach Quelle priorisierte Attribution nach letzter Interaktion für App- und Weboberflächen durchführen.

Ein Beispiel dafür, wie Browser in die Attribution Reporting API von Android eingebunden werden können, um App- und Web-übergreifende Messungen zu ermöglichen, finden Sie im Vorschlag für die Privacy Sandbox für das Web. Der Browser fügt dem Vorschlag die folgenden Anfrageheader hinzu:

  • Attribution-Reporting-Eligible gibt an, ob Unterstützung auf Betriebssystemebene für die Attribution verfügbar ist. In diesem Fall gibt der Header an, ob die Attribution Reporting API von Android verfügbar ist.
  • Falls verfügbar, können Anbieter von Anzeigentechnologien optional mit Attribution-Reporting-Register-OS-Source antworten. Dadurch wird ein sekundärer API-Aufruf von der Browser-App an registerWebSource() initiiert.
  • AdTech-Unternehmen können auch mit dem Header Attribution-Reporting-Register-OS-Trigger auf Triggerregistrierungen reagieren. Dadurch wird ein sekundärer API-Aufruf von der Browser-App an registerWebTrigger() initiiert.

Registrierung der Attributionsquelle

Beim Registrieren einer Attributionsquelle können Apps registerWebSource() aufrufen. Diese Funktion erwartet die folgenden Parameter:

  • Quell-URIs für die Zuordnung: Die Plattform sendet eine Anfrage an jeden URI in dieser Liste, um Metadaten abzurufen, die der Zuordnungsquelle zugeordnet sind.

    Jeder URI sollte von einem booleschen Debug-Flag begleitet werden, um anzugeben, ob die von den Technikern bereitgestellten Debug-Schlüssel in den Bericht aufgenommen werden sollen.
  • Eingabeereignis: Entweder ein InputEvent-Objekt (für ein Klickereignis) oder null (für ein Aufrufereignis)
  • Quellursprung: Ursprung, an dem die Quelle aufgetreten ist (Publisher-Website).
  • Ziel-Betriebssystem: Ein App-Paketname, unter dem das Triggerereignis stattfindet.
  • Webziel: Eine eTLD+1, auf der das Triggerereignis stattfindet.
  • Bestätigtes Ziel: Intent für den Betriebssystem- oder Webziel-URI, der für die Navigation bei Nutzerklicks verwendet wird.

Wenn die API eine Anfrage an den URI der Attributionsquelle sendet, sollte die Ad-Tech-Plattform mit den Metadaten der Attributionsquelle in einem HTTP-Header, Attribution-Reporting-Register-Source, antworten. Dieser Header verwendet dieselben Felder wie die Quellregistrierung für die App-to-App-Zuordnung, mit einigen Änderungen:

  • Die API validiert die von der Ad-Tech-Firma angegebenen Ziele mit den von der App angegebenen Zielen. Wenn die Ziele unterschiedlich sind, wird die Registrierung der Attributionsquelle von der API verworfen.

    Apps müssen Webziele validieren, bevor sie die Web Context API aufrufen. Bei Klicks sollten Apps prüfen, ob das angegebene Ziel mit dem Ziel übereinstimmt, zu dem der Nutzer navigiert.
  • Die API ignoriert alle Weiterleitungs-URIs, die in Attribution-Reporting-Redirects angegeben sind. Apps sollten Weiterleitungen selbst folgen und registerWebSource() für jede Weiterleitung aufrufen, damit sie bei Bedarf ihre eigenen Berechtigungsrichtlinien anwenden können.

Apps müssen einer Zulassungsliste hinzugefügt werden, um registerWebSource() aufrufen zu können. Füllen Sie dieses Formular aus, um der Zulassungsliste beizutreten. Die Zulassungsliste soll Datenschutzbedenken im Zusammenhang mit dem Aufbau von Vertrauen für den Webkontext ausräumen.

Registrierung des Triggers (Conversion)

Bei der Triggerregistrierung können Apps registerWebTrigger() aufrufen. Diese Methode erwartet die folgenden Parameter:

  • Trigger-URIs: Die Plattform sendet eine Anfrage an jeden URI in dieser Liste, um Metadaten für den Trigger abzurufen.
  • Zielursprung: Ursprung, an dem der Trigger ausgelöst wurde (Website des Werbetreibenden)

Attributionsquelle und Triggerregistrierung über WebView

Standardmäßig verwendet WebView registerSource() und registerWebTrigger(). Dadurch werden Quellen mit der App und Trigger mit dem Ursprung der obersten Ebene der WebView verknüpft, wenn der Trigger ausgelöst wird.

Wenn eine App ein anderes Verhalten erfordert (z. B. Apps, die Webinhalte in einer WebView hosten), muss die Methode setAttributionRegistrationBehavior in der Klasse androidx.webkit.WebViewSettingsCompat verwendet werden. Mit dieser Methode wird angegeben, ob WebView registerWebSource() oder registerSource() und registerWebTrigger() oder registerTrigger() aufrufen soll.

Folgende Optionen sind für setAttributionRegistrationBehavior verfügbar:

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.
Hinweis: Apps, die diese Option verwenden, müssen sich für die Zulassungsliste bewerben, um registerWebSource() verwenden zu können.
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.
Der erste Netzwerkaufruf der Attributionsquellen- oder Trigger-URIs kann zwar weiterhin erfolgen, aber alle Antworten werden verworfen und nichts wird auf dem Gerät gespeichert.

Überlegungen zu Datenschutz und Sicherheit

In diesem Abschnitt werden Datenschutz- und Sicherheitsaspekte für Apps behandelt, die die Attribution Reporting API verwenden.

Auswirkungen auf Datenschutzmechanismen, die auf Berichte angewendet werden

Wie im Hauptdesignvorschlag beschrieben, wendet die API datenschutzfreundliche Ratenbeschränkungen auf Berichte an. Einige Limits sind auf Quell- und Ziel-Apps aufgeteilt. Wenn eine Web-Attributionsquelle oder ein Trigger registriert wird, wird das Ratenlimit nach der Quell- oder Zielwebsite anstelle der App partitioniert.

Wenn die App separate Ratenlimits hat, könnte ein Angreifer zusätzlich zu den API-Ratenlimits auch die app-spezifischen Ratenlimits nutzen. Um dieses Problem zu beheben, sollten Apps prüfen, ob eine bestimmte Attributionsquelle sowohl in der Analyselösung der App als auch in der Android Attribution Reporting API registriert ist.

Vertrauen für Webkontext aufbauen

Bei API-Aufrufen im Webkontext vertraut die API der App, die Quell- und Zielursprünge zu erkennen und anzugeben. Dies kann potenzielle Datenschutz- und Sicherheitsrisiken mit sich bringen:

  • Ein Angreifer kann behaupten, Websites zu hosten, die ihm gehören, um Ratenbegrenzungen für die Menge an Informationen zu umgehen, die von einer Quelle übertragen werden können.
  • Mehrere Angreifer können sich zusammentun, um separate Attributionsquellen zu registrieren und dieselbe Quellwebsite zu beanspruchen. Dadurch kann es passieren, dass die Quellwebsite Ratenbeschränkungen für Ad-Tech-Plattformen erreicht und keine legitimen Attributionsquellen registriert werden.

Um dies zu verhindern, schränken wir ein, welche Browser oder Apps registerWebSource() aufrufen können. Dies ist nur für Browser oder Apps möglich, die bestätigen, dass die bei der Registrierung verwendete Quellwebsite die tatsächliche Website ist, die dem Nutzer angezeigt wird. Füllen Sie das Anmeldeformular für Berichte zur Web-to-App-Attribution aus, um der Zulassungsliste für den Aufruf von registerWebSource() beizutreten.

Jede App kann registerWebTrigger() aufrufen, da die Datenschutz- und Sicherheitsaspekte auf der Triggerseite ohne Absprachen auf der Quellseite nicht gelten.

Nutzersteuerung

Apps können weiterhin Nutzerkontrollen oder Berechtigungsrichtlinien unterstützen, sofern sie bei der Registrierung definiert werden können. Wenn Apps beispielsweise Berechtigungen auf Website- oder Nutzerebene zulassen, sollten sie diese auswerten und festlegen, ob die Webkontext-APIs aufgerufen werden sollen.

Außerdem unterstützen wir einen neuen API-Aufruf von Apps, um alle Attributionsquellen, Trigger und ausstehenden Berichte zu löschen, die für diese App auf dem Gerät gespeichert sind. Wenn Apps dem Nutzer beispielsweise erlauben, seinen Browserverlauf zu löschen, möchten sie möglicherweise die API aufrufen, um Attributionsquellen, Trigger und ausstehende Berichte zu löschen, die für diese App auf dem Gerät des Nutzers gespeichert sind.

Zukünftige Überlegungen und offene Fragen

Die Interoperabilität zwischen Apps und Web für die Attribution Reporting API ist noch in Arbeit. Wir möchten uns von der Community Feedback zu einigen Ideen holen:

  1. Wie werden Sie auf einem Gerät, das die Android Privacy Sandbox unterstützt, Browser-Analysefunktionen mit der Android Attribution Reporting API verwenden? Möchten Sie alles an Android weiterleiten?
  2. Gibt es Bedenken, dass möglicherweise zwei Pings für jede Attributionsquelle und jeden Trigger empfangen werden, eines vom Browser oder der App und eines von der Attribution Reporting API?
  3. Wie können wir Ihnen das Debuggen verschiedener APIs erleichtern?
  4. Der Vorschlag enthält keine Validierung, dass App- und Webziele miteinander verknüpft sind. In Zukunft können wir diese Ziele möglicherweise validieren, indem wir Verknüpfungen mit Digital Asset Links prüfen. Würde das einen Ihrer Anwendungsfälle blockieren? Ist es sinnvoll, Digital Asset Links für diese Validierung zu verwenden?
  5. Wenn Sie eine Attributionsquelle registrieren, müssen Sie ein Ziel angeben. Im Fall von Web-to-App-Kampagnen sollten Sie möglicherweise einen App-Link angeben. Welche Formate verwenden Sie, um diesen App-Link anzugeben?
  6. Wenn Sie eine Attributionsquelle für App-zu-Web-Traffic registrieren, muss dieses Quellereignis über die Android Attribution Reporting API in der App registriert werden. Wenn der Nutzer beispielsweise auf eine Anzeige klickt und der Klick in einem Browser oder einem benutzerdefinierten Tab eines Browsers geöffnet wird, sollte dieser Klick (Quellereignis) in der App und nicht im Browserkontext registriert werden. Wenden Sie sich an uns, wenn Sie Bedenken haben oder andere Anwendungsfälle vorliegen, die nicht in die Kategorien fallen, die in dieser Problembeschreibung für unterstützte Abläufe behandelt werden.