Attributionsberichte: App- und webübergreifende Messungen

Hinweis : Dieses Dokument bezieht sich auf die Privacy Sandbox für die aktuellen Designvorschläge von Android und kann jederzeit geändert werden. Wir freuen uns über Ihr Feedback und Ihre Kommentare, um uns dabei zu unterstützen.

Feedback geben

Letzte Updates

• Es wurde ein Abschnitt zu Berichten zur vorübergehenden Fehlerbehebung hinzugefügt.
• Eine Anleitung zum Beitreten einer Zulassungsliste zum Registrieren von Webquellen wurde hinzugefügt.

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:

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

Webinhalte sind Webinhalte, die in einer App angezeigt werden. Webinhalte können im Kontext einer mobilen Browser-App oder als eingebettete Websites in Nicht-Browser-Apps angezeigt werden.

Die vorherigen Triggerpfade entsprechen den folgenden Anforderungen:

• Für Anzeigentechnologien: Aktualisierung von API-Aufrufen und Berichten zur Aktivierung von App-zu-Web-Pfaden
• Für Apps und Browser: Möglichkeit, Registrierung von Webattributionsquellen und Web-Triggern an Android zu übergeben

In diesem Dokument wird erläutert, wie die Attribution Reporting API um die Unterstützung von App-zu-Web-, Web-zu-App- und Web-zu-Web-Trigger-Pfaden erweitert wird. Außerdem werden die Änderungen beschrieben, die Anzeigentechnologien und Apps vornehmen müssen, um die Anforderungen für die Unterstützung dieser Triggerpfade zu erfüllen.

Zugriff auf Attribution Reporting APIs erhalten

AdTech-Plattformen müssen sich für den Zugriff auf die Attribution Reporting APIs registrieren. Weitere Informationen finden Sie unter Für Privacy Sandbox-Konto registrieren.

Nach Abschluss des Registrierungsprozesses verwirft die API die Registrierung, wenn ein Aufruf für eine nicht registrierte Registrierung eingeht.

AdTech-Plattformen sollten bei der Registrierung sicherstellen, dass sie sich mit allen Server-URLs registrieren, die sie in der App und im Web verwenden können, um Attributionsquellen und Trigger zu registrieren. Es werden mehrere Serverregistrierungs-URLs unterstützt, aber nur eine Quelle für die Berichterstellung wird unterstützt. Dieser Berichtsort wird von der Domain einer der Serverregistrierungs-URLs abgeleitet.

Änderungen für Anzeigentechnologien

Änderungen an Registrierung und Attribution

Beim Registrieren einer Attributionsquelle geben Anzeigentechnologie-Anbieter derzeit ein Zielfeld an. Das ist der Name des App-Pakets, in dem das Triggerereignis auftritt. Um App-zu-Web-Messungen zu ermöglichen, werden ein App-Zielfeld (App-Paketname) und ein Web-Zielfeld (eTLD+1) unterstützt.

Beim Registrieren von Webattributionsquellen oder ‐Triggern unterstützt die API keine Weiterleitungen, da jede App, die Webinhalte hostet, ein eigenes Berechtigungsmodell haben kann. Jede Anwendung ist dafür verantwortlich, Weiterleitungen zu folgen (falls unterstützt) und die Web Context APIs für jeden Weiterleitungs-Hop aufzurufen.

Darüber hinaus können Anzeigentechnologie-Anbieter durch diese Integration die App-spezifische Attributionslogik in Webattributionsquellen nutzen. Beispielsweise können Sie jetzt Attributionsfenster nach der Installation für eine Webattributionsquelle angeben.

App- und Webberichte erhalten

Mit der Android Attribution Reporting API können Sie Berichte zu App- und Web-Conversions senden. Wenn AdTech-Unternehmen die Triggerdaten und die Aggregation von Schlüssel/Wert-Paaren über die Web- und App-Oberflächen nicht abstimmen möchten, können sie zwischen einer Web- und einer App-Conversion unterscheiden:

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

Auswirkungen der Web-zu-Web-Messung

Apps legen fest, 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? Apps werden ein neues Signal angezeigt, das angibt, ob die Attribution Reporting API auf dem jeweiligen Gerät verfügbar ist. Weitere Informationen dazu, wie Apps die Registrierung an die Attribution Reporting API übergeben können, finden Sie im Abschnitt zu App-Änderungen.
• Welcher Teil der Attributionsquellen und Trigger sollte an die API übergeben werden? Ob eine Entscheidung getroffen wird, trifft die jeweilige App bzw. die Anzeigentechnologie-Anbieter, sofern die App eine Auswahl zulässt. Falls die App ein eigenes Analysetool hat, kann es sinnvoll sein, stattdessen dieses zu verwenden. Durch die Übergabe aller Quell- und Triggerregistrierungen an die Android Attribution Reporting API, sofern verfügbar, erfolgt die genaueste Attribution in der App und im Web.

Im folgenden Beispiel sehen Sie, wie Browser-Apps zusammen mit der Attribution Reporting API eingesetzt werden können, um genaue Messungen zu erzielen, wenn Nutzer sowohl in einer Browser-App als auch in einer Nicht-Browser-App auf eine Anzeige klicken:

Beispiel für die Registrierung der Quelle und des Triggers für einen Browser und eine Anwendung

• Am ersten Tag klickt der Nutzer auf eine Anzeige in der Browser-App.
  • Die Browser-App kann ein eigenes Analysetool verwenden oder die Registrierung des Klicks auf Webanzeigen an die Attribution Reporting API übergeben.
• Am zweiten Tag klickt der Nutzer in einer nicht browsergestützten App auf eine Anzeige.
  • Der Klick wird bei der API als Attributionsquelle registriert. Die Browser-App hat keinen Einblick in diesen Klick, da das Ereignis in einer anderen App aufgetreten ist.
• Am dritten Tag führt der Nutzer in der Browser-App eine Conversion durch.
  • Wenn die Browser-App sowohl den Klick als auch die Conversion mit ihrer eigenen Messlösung registriert und diese Informationen an die Attribution Reporting API übergibt, ist es unwahrscheinlich, dass ein Anzeigentechnologie-Anbieter Conversion-Berichte über mehrere Analyselösungen hinweg deduplizieren kann. Außerdem kann ein Anzeigentechnologie-Anbieter sowohl die Ratenbegrenzungen für Browser-Apps als auch die Ratenbegrenzungen für die Attribution Reporting API nutzen. Wir empfehlen daher, dass Apps alle Anzeigenereignisse und Conversions übergeben, damit sie in der API registriert werden, wenn die API verfügbar ist.

Attributionsquelle und Trigger aus WebView registrieren

Wenn in der App WebView verwendet wird, um Webinhalte und keine native Android-Anzeige zu präsentieren, kann die App die Aufnahme in die Zulassungsliste für registerWebSource() beantragen und die Quelle der obersten Ebene der Website angeben, die mit der Attributionsquelle verknüpft werden soll, nicht den App-Paketnamen.

Ähnlich wie Browser unterstützt WebView registerWebTrigger() für Triggerregistrierungen, wodurch der Trigger dem Ursprung der obersten Ebene zugeordnet wird. Die Registrierung eines App-Triggers durch WebView wird nicht unterstützt. Wenden Sie sich an uns, wenn Sie einen entsprechenden Anwendungsfall haben. Eine vollständige Liste der von WebView unterstützten Kombinationen finden Sie unter Attributionsquelle und Trigger-Registrierung von WebView.

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

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

• Anzeigentechnologie-Anbieter sollten auf Quellregistrierungen mithilfe des Attribution-Reporting-Register-OS-Source-Headers reagieren, der einen sekundären API-Aufruf von WebView an registerSource() oder registerWebSource() initiiert.
• Anzeigentechnologie-Anbieter können auch mithilfe des Attribution-Reporting-Register-OS-Trigger-Headers auf ausgelöste Registrierungen reagieren, der einen sekundären API-Aufruf von WebView an registerWebTrigger() oder registerTrigger() initiiert.

Wenn die Antwort die vorherigen Header nicht oder zusätzlich die Attribution-Reporting-Register-Source/Attribution-Reporting-Register-Trigger-Header enthält, obwohl 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 Trigger-Registrierung von WebView.

Berichte zur vorübergehenden Fehlerbehebung

Die Attribution Reporting API unterstützt eine optionale Funktion, die als Berichte zur vorübergehenden Fehlerbehebung bezeichnet wird. So erhalten AdTech-Teams mehr Informationen zu Attributionsberichten, sofern eine Werbe-ID verfügbar ist. Es gibt zwei Arten von Debugging-Berichten: Attribution erfolgreich und ausführlich. Diese Berichte werden für die App- und Webattribution unterstützt und beide Berichtstypen enthalten dieselben Informationen. Der einzige Unterschied besteht in den Berechtigungen, die beim Senden von Debugging-Berichten gelten.

Bei der Web-zu-Web-Attribution innerhalb einer App (z. B. innerhalb derselben Browser-App) sind ausführliche Berichte und Berichte nur verfügbar, wenn Drittanbieter-Cookies verfügbar sind. Sie basieren nicht auf der Verfügbarkeit von Werbe-IDs.

Für die App-zu-Web-, Web-zu-App- und Web-zu-Web-App-übergreifende Attribution sind Berichte zur erfolgreichen Attribution und ausführliche Berichte verfügbar, wenn AdID auf App-Seite verfügbar ist und die Anzeigentechnologie dieselbe (richtige) AdID auf der Webseite übergeben kann. Unten finden Sie ein App-zu-Web-Beispiel, bei dem die Quelle in einer Publisher-App erfolgt, der Trigger aber auf der Website eines Werbetreibenden innerhalb einer Browser-App erfolgt.

Wenn Sie einen Debugging-Bericht über eine erfolgreiche Attribution für App-zu-Web-Anzeigen aktivieren möchten, müssen alle drei folgenden Bedingungen erfüllt sein:

• Der Nutzer darf die Personalisierung anhand der Werbe-ID nicht deaktiviert haben.
• Die Publisher-App muss AdID-Berechtigungen deklariert haben
• Die Anzeigentechnologie muss den AdID-Wert bei der Trigger-Registrierung (aus einem Webkontext) übergeben.

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

• Ausführliche Quellenberichte hängen nur von den Berechtigungen der Publisher-Seite ab. Damit ausführliche Quellberichte gesendet werden können, darf der Nutzer die AdID-Personalisierung nicht deaktiviert haben und die Publisher-App muss AdID-Berechtigungen deklariert haben.
• Ausführliche Berichte können nur von Triggern auf der Triggerseite (in diesem Beispiel Web-Berechtigungen) ausgelöst werden. Drittanbieter-Cookies müssen im Browser verfügbar sein, damit ausführliche Triggerberichte gesendet werden können.
• Bei ausführlichen Triggerberichten, in denen optional ein source_debug_key-Element enthalten sein kann, wird source_debug_key angegeben, sofern die Werbe-ID für die Publisher-App verfügbar ist.

Hinweis: Der Anzeigentechnologie-Anbieter muss in jedem Fall den Empfang ausführlicher Fehlerbehebungsberichte über das Wörterbuchfeld debug_reporting in Quell- und Triggerregistrierungsheadern aktivieren.

Hinweis :Wenn Sie für die App- und Web-Attribution andere Daten als die Werbe-ID verwenden, wenden Sie sich mit Ihrem Anwendungsfall an, um die Teilnahme am Trusted Tester-Programm zu beantragen. Das Trusted Tester-Programm bietet eine alternative Möglichkeit, die oben beschriebenen Debugging-Berichte vorläufig zu erhalten. Das Trusted Tester-Programm ist auf Anzeigentechnologie-Anbieter mit nachgewiesenem Bedarf beschränkt, bei denen der Anwendungsfall zwar unterstützt wird, aber keine Werbe-ID für die Quelle angeben und die Registrierung auslösen kann.

Änderungen für Apps

Wir unterstützen die Attribution über App- und Web-Plattformen hinweg. Dazu können Apps mithilfe neuer Web Context API-Aufrufe die Registrierung von Web-Attributionsquellen und Web-Triggern an die Attribution Reporting API für Android übergeben.

Nach Abschluss der Registrierungsschritte in den folgenden Abschnitten werden Quellen und Trigger für die App- und Web-Attribution auf dem Gerät gespeichert. Die Attribution Reporting API kann dann eine nach der Quelle priorisierte Attribution nach letzter Interaktion in App- und Web-Oberflächen durchführen.

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

• Attribution-Reporting-Eligible sendet an, ob die Attribution auf Betriebssystemebene 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 Anzeigentechnologie-Anbieter optional mit Attribution-Reporting-Register-OS-Source antworten. Dadurch wird ein sekundärer API-Aufruf von der Browser-App an registerWebSource() initiiert.
• Anzeigentechnologien können auch über den Attribution-Reporting-Register-OS-Trigger-Header auf Triggerregistrierungen reagieren, der einen sekundären API-Aufruf von der Browser-App an registerWebTrigger() initiiert.

Registrierung der Attributionsquelle

Beim Registrieren einer Attributionsquelle können Apps registerWebSource() aufrufen. Dafür werden die folgenden Parameter erwartet:

• Attributionsquellen-URIs: Die Plattform sendet eine Anfrage an jeden URI in dieser Liste, um Metadaten abzurufen, die mit der Attributionsquelle verknüpft sind.
  
  Jeder URI sollte mit einem booleschen Debug-Flag versehen sein, das angibt, ob die von den Technikern bereitgestellten Fehlerbehebungsschlüssel im Bericht enthalten sein sollen.
• Eingabeereignis: Entweder ein InputEvent-Objekt (für ein Klickereignis) oder null (für ein Anzeigeereignis)
• Ursprung der Quelle: Der Ursprung der Quelle (Website des Publishers).
• Ziel des Betriebssystems: Ein App-Paketname, in dem das Triggerereignis auftritt.
• Webziel: Eine eTLD+1, an der das Triggerereignis auftritt.
• Bestätigtes Ziel: URI-Intent des Betriebssystems oder Webziels, der beim Klicken des Nutzers für die Navigation verwendet wird.

Wenn die API eine Anfrage an den URI der Attributionsquelle stellt, sollte das AdTech-Team mit den Metadaten der Attributionsquelle im HTTP-Header Attribution-Reporting-Register-Source antworten. Dieser Header verwendet dieselben Felder wie bei der Registrierung der App-zu-App-Attributionsquelle, mit einigen Änderungen:

• Die API validiert die von der Anzeigentechnologie angegebenen Ziele mit den von der App angegebenen Zielen. Bei unterschiedlichen Zielen wird die Registrierung der Attributionsquelle von der API verworfen.
  
  Apps müssen Webziele validieren, bevor die Web Kontext API aufgerufen wird. 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 für jede Weiterleitung registerWebSource() aufrufen, damit sie bei Bedarf ihre eigenen Berechtigungsrichtlinien anwenden können.

Apps müssen auf eine Zulassungsliste gesetzt werden, um registerWebSource() aufrufen zu können. Füllen Sie dieses Formular aus, um der Zulassungsliste beizutreten. Mit der Zulassungsliste sollen datenschutzbezogene Aspekte zur Einrichtung von Vertrauen in den Webkontext abgeschwächt werden.

Registrierung (Conversion) auslösen

Bei der Trigger-Registrierung können Anwendungen registerWebTrigger() aufrufen. Dafür werden die folgenden Parameter erwartet:

• Trigger-URIs: Die Plattform sendet eine Anfrage an jeden URI in dieser Liste, um die mit dem Trigger verknüpften Metadaten abzurufen.
• Ursprung des Ziels: Ursprung des Triggers (Website des Werbetreibenden)

Attributionsquelle und Registrierung über WebView auslösen

Standardmäßig verwendet WebView registerSource() und registerWebTrigger(). Dadurch werden Quellen der App zugeordnet und beim Auslösen des Triggers mit dem Ursprung der obersten Ebene des WebView ausgelöst.

Wenn eine App ein anderes Verhalten erfordert (z. B. wenn sie Webinhalte in einer WebView hosten), muss die Methode setAttributionRegistrationBehavior in der Klasse androidx.webkit.WebViewSettingsCompat verwendet werden. Diese Methode gibt an, ob WebView registerWebSource() oder registerSource() und registerWebTrigger() oder registerTrigger() aufrufen soll.

Für setAttributionRegistrationBehavior sind folgende Optionen verfügbar:

Wert	Beschreibung	Anwendungsbeispiel
APP_SOURCE_AND_WEB_TRIGGER (Standardeinstellung)	Ermöglicht Apps, App-Quellen (mit dem App-Paketnamen verknüpfte Quellen) und Web-Trigger (mit der eTLD+1 verknüpfte Trigger) aus WebView zu registrieren.	Apps, die WebView zur Anzeigenbereitstellung nutzen, statt das Surfen im Web zu ermöglichen
WEB_SOURCE_AND_WEB_TRIGGER	Ermöglicht Apps, Webquellen und Web-Trigger aus WebView zu registrieren. Hinweis: Apps, für die diese Option verwendet wird, müssen einen Antrag auf Aufnahme in die Zulassungsliste für die Verwendung von registerWebSource() stellen.	WebView-basierte Browser-Apps, bei denen Anzeigenimpressionen und Conversions auf Websites in WebView erzielt werden 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 mit der App und nicht mit der eTLD+1 des WebView verknüpft sein sollten.
DEAKTIVIERT	Deaktiviert die Quelle und das Auslösen der Registrierung über WebView. Hinweis: Der erste Netzwerkaufruf an die Attributionsquelle oder an den Trigger-URI kann trotzdem erfolgen. Antworten werden jedoch verworfen und nichts auf dem Gerät gespeichert.

Hinweis :setAttributionRegistrationBehavior gilt für jede WebView-Implementierung der jeweiligen App. Wenn deine App mehrere WebViews unterstützt, kannst du für jede ein unterschiedliches Verhalten festlegen. setAttributionRegistrationBehavior verhindert oder ändert weder die Quelle noch die Registrierung von der App selbst oder einer anderen App.

Datenschutz und Sicherheit

Auswirkungen auf den Datenschutz bei Berichten

Wie im Hauptentwurf beschrieben, wendet die API datenschutzfreundliche Ratenbegrenzungen auf Berichte an. Einige Limits sind nach Quell- und Zielanwendungen aufgeteilt. Wenn eine Webattributionsquelle oder ein Trigger registriert wird, wird die Ratenbegrenzung nach der Quell- oder Zielwebsite und nicht nach der App partitioniert.

Wenn für die App unterschiedliche Ratenbegrenzungen gelten, könnte ein Angreifer zusätzlich zu den API-Limits auch appspezifische Ratenbegrenzungen nutzen. Um dies zu vermeiden, sollten Apps dafür sorgen, dass eine bestimmte Attributionsquelle nicht sowohl im Analysetool der App als auch in der Android Attribution Reporting API registriert ist.

Vertrauen in den Webkontext aufbauen

Bei API-Aufrufen des Webkontexts vertraut die API der Anwendung, um die Quell- und Zielursprünge zu erkennen und anzugeben. Dies kann zu potenziellen Datenschutz- und Sicherheitsaspekten führen:

• Ein Angreifer kann behaupten, eigene Websites zu hosten, um die Ratenbegrenzungen für die Menge an Informationen zu umgehen, die jede Quelle übertragen kann.
• Mehrere Angreifer können sich zusammentun, um separate Attributionsquellen zu registrieren und dieselbe Quellwebsite zu beanspruchen. Dies kann dazu führen, dass die Quellwebsite die Ratenbegrenzungen für Anzeigentechnologie-Plattformen erreicht und verhindert, dass die tatsächliche Quellwebsite legitime Attributionsquellen registriert.

Um dies zu umgehen, beschränken wir die Browser oder Apps, die registerWebSource() an Browser oder Apps aufrufen können, die bestätigen, dass die bei der Registrierung verwendete Quellwebsite der tatsächlichen Website entspricht, die dem Nutzer angezeigt wird. Füllen Sie dieses Formular aus, um auf die Zulassungsliste für den Aufruf von registerWebSource() zu setzen.

Jede Anwendung könnte registerWebTrigger() aufrufen, da die Datenschutz- und Sicherheitsaspekte auf der Triggerseite ohne quellenseitige Kollusion nicht anwendbar sind.

Nutzersteuerung

Anwendungen können weiterhin Nutzersteuerungen oder Berechtigungsrichtlinien unterstützen, solange diese bei der Registrierung definiert werden können. Wenn Apps beispielsweise Berechtigungen auf Website- oder Nutzerebene zulassen, sollte die App diese bewerten und bestimmen, ob die Web Context APIs aufgerufen werden sollen.

Außerdem wird ein neuer API-Aufruf von Apps unterstützt, mit dem alle Attributionsquellen, Trigger und ausstehenden Berichte gelöscht werden, die für diese App auf dem Gerät gespeichert sind. Wenn ein Nutzer beispielsweise in einer App seinen Browserverlauf löschen kann, kann er 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 App-zu-Web-Interoperabilität für die Attribution Reporting API ist noch in der Entwicklung. Wir würden gern von der Community Feedback zu einigen Ideen einholen:

1. Wie können Sie auf einem Gerät, das die Privacy Sandbox für Android unterstützt, Browsermesslösungen mit der Android Attribution Reporting API verwenden? Möchtest du lieber alles an Android weitergeben?
2. Gibt es Bedenken hinsichtlich des potenziellen Erhalts von zwei Pings für jede Attributionsquelle und jeden Trigger, einen aus dem Browser/die App und einen von der Attribution Reporting API?
3. Wie können wir Ihnen die Fehlerbehebung in verschiedenen APIs erleichtern?
4. Das Angebot umfasst nicht die Validierung, dass Anwendungs- und Webziele miteinander verbunden sind. In Zukunft werden wir diese Ziele möglicherweise validieren können, indem wir Verknüpfungen mit Digital Asset Links überprüfen. Würde das einen Ihrer Anwendungsfälle blockieren? Ist es sinnvoll, für diese Validierung Digital Asset Links zu verwenden?
5. Beim Registrieren einer Attributionsquelle müssen Sie ein Ziel angeben. Im Web-zu-App-Fall können Sie einen App-Link angeben. Welche Formate verwenden Sie, um diesen App-Link anzugeben?
6. Wenn Sie eine App-zu-Web-Attributionsquelle registrieren, muss dieses Quellereignis in der App mit der Android Attribution Reporting API registriert werden. Wenn der Nutzer beispielsweise auf eine Anzeige klickt und der Klick in einem Browser oder auf dem benutzerdefinierten Tab eines Browsers geöffnet wird, sollte dieser Klick (Quellereignis) in der App und nicht im Browserkontext registriert werden. Bitte wenden Sie sich an uns, wenn Sie diesbezüglich Bedenken haben oder es andere Anwendungsfälle gibt, die nicht in die Kategorien dieses Problems zur Beschreibung der unterstützten Abläufe fallen.