Diese Seite wurde von der Cloud Translation API übersetzt.

Attribution Reporting für Mobilgeräte – Übersicht

Letzte Updates

Die Liste der anstehenden Änderungen und bekannten Probleme wurde aktualisiert.
Einführung der flexiblen Lite-Konfiguration auf Ereignisebene als Brücke zum vollen Funktionsumfang flexible Konfiguration auf Ereignisebene
Ab September 2023, registerWebSource, registerWebTrigger, registerAppSource und registerAppTrigger müssen Strings für Felder verwenden, wird ein numerischer Wert erwartet (z. B. priority, source_event_id, debug_key, trigger_data, deduplication_key usw.)
Im 4. Quartal 2023 wird die Google Cloud-Unterstützung in der Android Attribution Reporting API kann hinzugefügt werden, um Zusammenfassungsberichte mit dem Zusammenfassungsdienst auf Google zu generieren Cloud, genauerer Timing hier. Weitere Informationen finden Sie im Bereitstellungsleitfaden. Informationen zum Einrichten des Aggregationsdienstes mit Google Cloud
Neue datenschutzfreundliche Ratenbegrenzungen für die Anzahl einzelner Ziele.
Die aktualisierte Funktion für Triggerfilter für Lookback-Windows ist im 1. Quartal 2024 geplant. Weitere Informationen finden Sie im Hinweis.

Übersicht

Heutzutage werden mobile Attributions- und Analyselösungen Drittanbieterkennungen wie die Werbe-ID. Attribution Reporting API wurde entwickelt, um den Datenschutz für Nutzer zu verbessern, indem die Abhängigkeit von websiteübergreifenden Nutzerkennungen und zur Unterstützung wichtiger Anwendungsfälle für Attribution und Conversion in verschiedenen Apps und im Web.

Diese API verfügt über die folgenden strukturellen Mechanismen, die ein Framework für zum Verbessern des Datenschutzes, was in späteren Abschnitten auf dieser Seite ausführlicher beschrieben wird. Details:

Begrenzt die Anzahl der Bits, die für Berichte auf Ereignisebene
Aktiviert genauere Conversion-Daten nur in aggregierbare Berichte
Einführung von Ratenbegrenzungen für verfügbare Trigger (Conversions) und die Anzahl der Anzeigentechnologien können mit einer einzelnen Attributionsquelle verknüpft werden.
Verwendet verschiedene Techniken zum Hinzufügen von Rauschen

Die vorherigen Mechanismen schränken die Möglichkeit ein, die User-Identität über zwei verschiedene für verschiedene Apps oder Domains.

Die Attribution Reporting API unterstützt folgende Anwendungsfälle:

Conversion-Berichte:Sie helfen Werbetreibenden, die Leistung ihrer Kampagnen, indem Sie die Conversion-Anzahl (Trigger) und die Conversion (Trigger-Werte) für verschiedene Dimensionen, etwa nach Kampagne, Anzeigengruppe, und Anzeigen-Creatives.
Optimierung: Stellen Sie Berichte auf Ereignisebene bereit, die die Optimierung von Werbeausgaben. Dazu werden Attributionsdaten pro Impression bereitgestellt, die für ML-Modelle trainieren.
Erkennung ungültiger Aktivitäten:Stellen Sie Berichte zur Verfügung, die bei Erkennung und Analyse von Werbebetrug und Werbung.

Grundsätzlich funktioniert die Attribution Reporting API so: in diesem Dokument ausführlicher beschrieben:

Die Anzeigentechnologie unternimmt einen Registrierungsprozess, die Attribution Reporting API verwenden.
Mit der Anzeigentechnologie werden Attributionsquellen registriert (Anzeige) Klicks oder Aufrufe – mit der Attribution Reporting API.
Die Anzeigentechnologie registriert Trigger – Nutzer-Conversions auf der App oder Website eines Werbetreibenden erstellen – mit der Attribution Reporting API.
Die Attribution Reporting API ordnet Trigger den Attributionsquellen zu: Conversion-Zuordnung und mindestens ein Trigger werden über event-level und aggregierbare Berichte an AdTech-Teams.

Zugriff auf Attribution Reporting APIs erhalten

AdTech-Plattformen müssen sich registrieren, um auf die Attribution Reporting APIs zugreifen zu können. Weitere Informationen finden Sie unter Registrieren Sie sich für ein Privacy Sandbox-Konto, um weitere Informationen zu erhalten.

Attributionsquelle registrieren (Klick oder Aufruf)

In der Attribution Reporting API werden Anzeigenklicks und -aufrufe als Attribution Quellen. Rufen Sie registerSource() auf, um einen Anzeigenklick oder einen Anzeigenaufruf zu registrieren. Diese API erwartet die folgenden Parameter:

URI der Attributionsquelle:Die Plattform sendet eine Anfrage an diesen URI in um mit der Attributionsquelle verknüpfte Metadaten abzurufen.
Eingabeereignis:Entweder ein InputEvent-Objekt (für ein Klickereignis) oder null (für ein Aufrufereignis).

Wenn die API eine Anfrage an den URI der Attributionsquelle sendet, sollte die Anzeigentechnologie: mit den Metadaten der Attributionsquelle in einem neuen HTTP-Header antworten Attribution-Reporting-Register-Source mit den folgenden Feldern:

Quellereignis-ID: Dieser Wert steht für die Daten auf Ereignisebene, die mit dieser Attributionsquelle (Anzeigenklick oder Aufruf) verknüpft sind. Muss eine unsignierte 64-Bit-Version sein als String formatierte Ganzzahl.
Ziel: Ein Ursprung, dessen eTLD+1 oder App-Paketname, wobei der auslösen.
Ablauf (optional): Ablauf in Sekunden für den Zeitpunkt, an dem die Quelle sein soll. gelöscht wurde. Die Standardeinstellung ist 30 Tage, mit einem Mindestwert von 1 Tag und ein Höchstwert von 30 Tagen. Dieser Wert wird auf den nächsten Tag aufgerundet. Kann sein als vorzeichenlose 64-Bit-Ganzzahl oder Zeichenfolge formatiert.
Fenster mit Ereignisbericht (optional): Dauer in Sekunden nach der Quelle Registrierung, während der das Ereignis Berichte für diese Quelle erstellt werden können. Wenn das Ereignisbericht-Fenster ist verstrichen, aber das Ablaufdatum ist noch nicht verstrichen, ein kann zwar einer Quelle zugeordnet werden, die für diesen Trigger gesendet wurden. Darf nicht größer als das Ablaufdatum sein. Kann formatiert werden als entweder eine vorzeichenlose 64-Bit-Ganzzahl oder ein String.
Fenster für aggregierte Berichte (optional): Dauer in Sekunden nach der Quelle Registrierung, in der aggregierte Berichte für diese Quelle. Darf nicht größer als das Ablaufdatum sein. Kann als 64-Bit-Format formatiert werden. Vorzeichenlose Ganzzahl oder String.
Priorität der Quelle (optional): Wird verwendet, um auszuwählen, welche Attributionsquelle mit dem der jeweilige Trigger verknüpft werden soll, falls Mehrfachattribution mit dem Trigger verknüpft werden. Muss mit 64-Bit signiert sein als String formatierte Ganzzahl.

Wenn ein Trigger empfangen wird, sendet die API findet die übereinstimmende Attributionsquelle mit der höchsten Prioritätsstufe. und erstellt einen Bericht. Jede AdTech-Plattform kann ihre eigenen Priorisierungsstrategie. Weitere Informationen zu den Auswirkungen der Priorität Informationen zur Attribution finden Sie im Abschnitt Beispiel für die Priorisierung.

höher deuten auf höhere Prioritäten hin.
Attributionsfenster für die Installation und nach der Installation (optional): Wird für die Attribution für Ereignisse nach der Installation festlegen, die weiter unten auf dieser Seite beschrieben werden.
Daten filtern (optional): Wird zum selektiven Filtern einiger Trigger verwendet. sie effektiv zu ignorieren. Weitere Informationen finden Sie in der Trigger-Filter auf dieser Seite.
Aggregationsschlüssel (optional): Geben Sie Segmentierung für aggregierbare Berichte.

Optional kann die Metadatenantwort der Attributionsquelle zusätzliche Daten enthalten im Header Weiterleitungen der Attributionsberichte. Die Daten enthalten Weiterleitungen URLs, die Zulassen, dass mehrere Anzeigentechnologie-Anbieter eine Anfrage registrieren.

Der Entwicklerleitfaden enthält Beispiele, Quellregistrierung akzeptieren.

Die folgenden Schritte zeigen einen Beispielworkflow:

Das AdTech SDK ruft die API auf, um die Registrierung der Attributionsquelle zu starten. und geben einen URI für die aufzurufende API an:
```
registerSource(
    Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
    myClickEvent);
```
Die API sendet eine Anfrage an https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA, Verwenden Sie dazu einen der folgenden Header:
```

Attribution-Reporting-Source-Info: navigation


Attribution-Reporting-Source-Info: event
```

Der HTTPS-Server dieser Anzeigentechnologie antwortet mit Headern, die Folgendes enthalten:

Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "234",
    "expiry": "60000",
    "priority": "5"
}
Attribution-Reporting-Redirect:
https://adtechpartner1.example?their_ad_click_id=567
Attribution-Reporting-Redirect:
https://adtechpartner2.example?their_ad_click_id=890

Die API stellt eine Anfrage an jede URL, die in den Attribution-Reporting-Redirect In diesem Beispiel werden zwei URLs von Anzeigentechnologie-Partnern angegeben sind, sodass die API eine Anfrage an https://adtechpartner1.example?their_ad_click_id=567 und eine weitere Anfrage an https://adtechpartner2.example?their_ad_click_id=890.
Der HTTPS-Server dieser Anzeigentechnologie antwortet mit Headern, die Folgendes enthalten:
```
Attribution-Reporting-Register-Source: {
    "destination": "android-app://com.advertiser.example",
    "source_event_id": "789",
    "expiry": "120000",
    "priority": "2"
}
```
Hinweis : Antworten können unterschiedliche Metadaten im Attribution-Reporting-Register-Source-Header

Drei Navigations-Attributionsquellen werden basierend auf dem die in den vorherigen Schritten angezeigt wurden.

Attributionsquelle aus WebView registrieren

WebView unterstützt den Anwendungsfall, bei dem eine App eine Anzeige innerhalb einer WebView Dies wird von WebView gehandhabt, wenn WebView registerSource() direkt als im Hintergrund. Bei diesem Aufruf wird die Attributionsquelle mit der App verknüpft anstelle des Ursprungs der obersten Ebene. Quellen von eingebetteten Webinhalten registrieren in einem Browserkontext werden ebenfalls unterstützt. müssen sowohl API-Aufrufer als auch Anwendungen die entsprechenden Einstellungen. Siehe Zuordnungsquelle registrieren und auslösen von WebView. Dort finden Sie Anleitungen für API-Aufrufer und Weitere Informationen finden Sie unter Attributionsquelle und Triggerregistrierung von WebView für Apps.

Da Anzeigentechnologie-Anbieter für Web und WebView denselben Code verwenden, folgt WebView HTTP 302. und leitet die gültigen Registrierungen an die Plattform weiter. Wir planen nicht, um den Attribution-Reporting-Redirect-Header in diesem Szenario zu unterstützen, aber Wenden Sie sich an uns, wenn Sie einen Anwendungsfall haben.

Trigger registrieren (Conversion)

Anzeigentechnologie-Plattformen können Trigger registrieren, also Conversions wie Installationen oder nach der Installation mit der Methode registerTrigger().

Die Methode registerTrigger() erwartet den Parameter Trigger-URI. Die API stellt eine Anfrage an diesen URI, um mit dem Trigger verknüpfte Metadaten abzurufen.

Die API folgt Weiterleitungen. Die Antwort des AdTech-Servers sollte eine HTTP- mit dem Namen Attribution-Reporting-Register-Trigger, der für Informationen zu einem oder mehreren registrierten Triggern. Der Inhalt der Kopfzeile sollte JSON-codiert und die folgenden Felder enthalten:

Triggerdaten:Daten zum Identifizieren des Triggerereignisses (3 Bit für Klicks, 1 für Aufrufe). Muss eine 64-Bit-Ganzzahl mit Vorzeichen sein, die als String formatiert ist.
Triggerpriorität (optional): Stellt die Priorität dieses Triggers dar. im Vergleich zu anderen Triggern für dieselbe Attributionsquelle. Muss eine 64-Bit-Version sein eine signierte Ganzzahl im Format eines Strings. Weitere Informationen zur auf die Berichterstellung auswirken, siehe Abschnitt Priorisierung.
Deduplizierungsschlüssel (optional): Wird verwendet, um Fälle zu identifizieren, in denen die gleichen mehrere Male von derselben AdTech-Plattform registriert wird, und zwar über dieselbe Attributionsquelle. Muss eine 64-Bit-Ganzzahl mit Vorzeichen im Format .
Aggregationsschlüssel (optional): A Liste von Wörterbüchern, die Aggregationsschlüssel angeben und in welchen Berichten der Wert aggregiert werden soll.
Aggregationswerte (optional): Eine Liste von Werten, die zu jedem Schlüssel beitragen.
Filter (optional): zum selektiven Filtern Trigger oder Trigger-Daten. Weitere Informationen finden Sie in der Trigger-Filter auf dieser Seite.

Optional kann die Antwort des AdTech-Servers zusätzliche Daten im Feld Weiterleitungen für Attributionsberichte. Die Daten enthalten Weiterleitungs-URLs, welche Zulassen, dass mehrere Anzeigentechnologie-Anbieter eine Anfrage registrieren.

Mehrere Anzeigentechnologie-Anbieter können mithilfe von Weiterleitungen in das Feld Attribution-Reporting-Redirect oder mehrere Aufrufe des registerTrigger()-Methode. Wir empfehlen die Verwendung des Deduplizierungsschlüssels um doppelte Trigger in Berichten zu vermeiden, falls dieselben AdTech liefert mehrere Antworten für dasselbe Trigger-Ereignis. Weitere Informationen über Wie und wann ein Deduplizierungsschlüssel verwendet wird

Der Entwicklerleitfaden enthält Beispiele, Triggerregistrierung akzeptieren.

Die folgenden Schritte zeigen einen Beispielworkflow:

Das AdTech SDK ruft die API auf, um die Trigger-Registrierung mit einem einen vorab registrierten URI. Weitere Informationen finden Sie unter Für ein Privacy Sandbox-Konto registrieren. Informationen.
```
registerTrigger(
    Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
```
Die API sendet eine Anfrage an https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA

Der HTTPS-Server dieser Anzeigentechnologie antwortet mit Headern, die Folgendes enthalten:

Attribution-Reporting-Register-Trigger: {
    "event_trigger_data": [{
    "trigger_data": "1122",
    // This returns 010 for click-through conversions (CTCs) and 0 for
    // view-through conversions (VTCs) in reports
    "priority": "3",
    "deduplication_key": "3344"
    }],
}
Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567

Die API stellt eine Anfrage an jede URL, die in den Attribution-Reporting-Redirect In diesem Beispiel ist nur eine URL angegeben, sodass die API eine Anfrage an https://adtechpartner.example?app_install=567
Der HTTPS-Server dieser Anzeigentechnologie antwortet mit Headern, die Folgendes enthalten:
```
Attribution-Reporting-Register-Trigger: {
"event_trigger_data":[{
  "trigger_data": "5566",
  "priority": "3",
  "deduplication_key": "3344"
}]
}
```
Zwei Trigger werden basierend auf den Anfragen in den vorherigen Schritten registriert.

Attributionsfunktionen

In den folgenden Abschnitten wird erläutert, wie die Zuordnung durch die Attribution Reporting API erfolgt. Conversion-Trigger den Attributionsquellen zuordnen.

Quellenpriorisierter Attributionsalgorithmus angewendet

Bei der Attribution Reporting API wird eine quellenpriorisierte Attribution , um einen Trigger (Conversion) einer Attributionsquelle zuzuordnen.

Mit Prioritätsparametern lässt sich die Attribution von Triggern an die Quellen:

Trigger können bestimmten Anzeigenereignissen Vorrang vor anderen geben. Beispiel: liegt der Schwerpunkt auf Klicks statt auf Aufrufen oder für Ereignisse aus bestimmten Kampagnen.
Sie können die Attributionsquelle und den Trigger so konfigurieren, dass erhalten Sie mit größerer Wahrscheinlichkeit Berichte, die die für Sie am wichtigsten sind. Sie können beispielsweise sicherstellen, dass gebotsfähige oder hochwertige Conversions mit höherer Wahrscheinlichkeit in diesen Berichte.

Für den Fall, dass Mehrere Anzeigentechnologien registrieren eine Attributionsquelle, wie weiter unten beschrieben, erfolgt diese Zuordnung unabhängig für jede Anzeigentechnologie. Für jede Anzeigentechnologie die Attributionsquelle mit der höchsten Priorität dem Triggerereignis zugeordnet ist. Wenn es mehrere Attributionsquellen gibt Priorität haben, wählt die API die zuletzt registrierte Attributionsquelle aus. Alle anderen Attributionsquellen, die nicht ausgewählt wurden, werden verworfen kann nicht mehr für zukünftige Trigger-Attribution verwendet werden.

Triggerfilter

Die Quelle- und Trigger-Registrierung enthält zusätzliche optionale Funktionen. Folgendes:

Einige Trigger werden selektiv gefiltert und ignoriert.
Triggerdaten für Berichte auf Ereignisebene basierend auf Quelldaten auswählen.
Sie können einen Trigger aus Berichten auf Ereignisebene ausschließen.

Zum selektiven Filtern von Triggern kann die Anzeigentechnologie Filterdaten angeben, die aus folgenden Elementen bestehen: von Schlüsseln und Werten während der Quell- und Triggerregistrierung. Wenn derselbe Schlüssel sowohl für die Quelle als auch für den Trigger angegeben ist, wird der Trigger ignoriert, Schnittmenge ist leer. Eine Quelle kann beispielsweise "product": ["1234"], Dabei ist product der Filterschlüssel und 1234 der Wert. Wenn der Triggerfilter auf "product": ["1111"] gesetzt ist, wird der Trigger ignoriert. Wenn keine einen Filterschlüssel auslösen, der mit product übereinstimmt, dann werden die Filter ignoriert.

Ein weiteres Szenario, bei dem AdTech-Plattformen Trigger selektiv filtern möchten ist das Erzwingen eines kürzeren Zeitfensters. Nach der Trigger-Registrierung kann ein Anzeigentechnologie-Anbieter ein Lookback-Window in Sekunden ab dem Zeitpunkt der Conversion angeben für Ein Lookback-Window von 7 Tagen wird beispielsweise so definiert: "_lookback_window": 604800 // 7d

Um zu entscheiden, ob ein Filter übereinstimmt, prüft die API zuerst das Lookback-Window. Wenn verfügbar ist, muss die Dauer seit der Registrierung der Quelle kleiner oder gleich sein mit der Dauer des Lookback-Windows.

AdTech-Plattformen können außerdem Triggerdaten basierend auf Quellereignisdaten auswählen. Für Beispiel: source_type wird von der API automatisch als navigation oder event. Während der Triggerregistrierung kann trigger_data festgelegt werden als ein Wert für "source_type": ["navigation"] und als unterschiedlicher Wert für "source_type": ["event"]

Trigger sind aus Berichten auf Ereignisebene ausgeschlossen, wenn einer der folgenden Punkte zutrifft:

Es ist kein trigger_data angegeben.
Quelle und Trigger geben denselben Filterschlüssel an, aber die Werte stimmen nicht überein. Beachten Sie, dass der Trigger in diesem Fall sowohl auf Ereignisebene als auch aggregierte Berichte.

Attribution nach der Installation

In einigen Fällen müssen Trigger nach der Installation dem die zur Installation geführt hat, auch wenn es andere geeignete vor Kurzem aufgetretenen Attributionsquellen.

Die API kann diesen Anwendungsfall unterstützen, da Anzeigentechnologie-Anbieter eine Einstellung nach der Installation festlegen können. Attributionszeitraum:

Geben Sie beim Registrieren einer Attributionsquelle eine Attribution für die Installationen an. Zeitraum, in dem Installationen erwartet werden (normalerweise 2–7 Tage, akzeptiert) 1 bis 30 Tage). Geben Sie dieses Zeitfenster in Sekunden an.
Beim Registrieren einer Attributionsquelle muss eine Attribution nach der Installation angegeben werden Exklusivitätsfenster, in dem alle Triggerereignisse nach der Installation die mit der Attributionsquelle verknüpft sind, die die Installation ausgelöst hat (in der Regel 7–30 Tage, zulässig zwischen 0 und 30 Tagen). Geben Sie dieses Zeitfenster als Anzahl der Sekunden.
Die Attribution Reporting API prüft, wann eine App installiert wird und Die Installation wird intern der quellenpriorisierten Attribution zugeordnet. Quelle. Die Installation wird jedoch nicht an die Anzeigentechnologie-Anbieter gesendet und der Plattformen die entsprechenden Ratenbegrenzungen.
Die Überprüfung der App-Installation ist für alle heruntergeladenen Apps verfügbar.
Alle zukünftigen Trigger, die innerhalb des Attributionszeitraums nach der Installation erfolgen derselben Attributionsquelle wie die validierte Installation zugeordnet werden, vorausgesetzt, die Attributionsquelle ist geeignet.

Zukünftig möchten wir eventuell das Design erweitern, um fortgeschrittenere Attributionsmodelle.

Die folgende Tabelle zeigt ein Beispiel dafür, wie Anzeigentechnologie-Anbieter nach der Installation Namensnennung. Angenommen, alle Attributionsquellen und Trigger werden von im selben AdTech-Netzwerk und alle Prioritäten sind gleich.

Ereignis	Tag, an dem das Ereignis eintritt	Hinweise
Klick 1	1	`install_attribution_window` ist auf `172800` (2 Tage) festgelegt und `post_install_exclusivity_window` ist auf `864000` (10 Tage) festgelegt
Installation verifiziert	2	Die API ordnet verifizierte Installationen intern zu, aber diese Installationen werden nicht als Trigger betrachtet. Daher werden an dieser Stelle keine Berichte gesendet. Punkt.
Trigger 1 (erstes Öffnen)	2	Erster Trigger, der von der Anzeigentechnologie registriert wurde. In diesem Beispiel stellt es eine kann ein beliebiger Triggertyp sein. Klick 1 zugeordnet (entspricht Zuordnung der bestätigten Installation).
Klick 2	4	Verwendet dieselben Werte für `install_attribution_window` und `post_install_exclusivity_window` als Klick 1
Trigger 2 (nach der Installation)	5	Zweiter Trigger, der von der Anzeigentechnologie registriert wird In diesem Beispiel stellt es eine wie etwa ein Kauf. Klick 1 zugeordnet (entspricht Zuordnung der bestätigten Installation). Klick 2 wird verworfen und kann nicht für eine zukünftige Attribution verwendet werden.

Die folgende Liste enthält einige zusätzliche Hinweise zur Nach der Installation. Zuordnung:

Wenn die bestätigte Installation nicht innerhalb der angegebenen Anzahl von Tagen erfolgt bis zum install_attribution_window erfolgt, wird keine Attribution nach der Installation angewendet.
Bestätigte Installationen werden nicht von Anzeigentechnologie-Anbietern registriert und nicht an Berichte. Sie werden nicht auf die Ratenbegrenzungen eines Anzeigentechnologie-Anbieters angerechnet. Bestätigte Installationen werden nur verwendet, um die Attributionsquelle zu identifizieren, der die installieren.
Im Beispiel aus der vorhergehenden Tabelle stellen Trigger 1 und Trigger 2 eine eine Conversion nach der Installation. Die Anzeigentechnologie Plattformen können beliebige Triggertypen registrieren. Mit anderen Worten: Die erste muss kein „First Open“-Trigger sein.
Wenn nach dem post_install_exclusivity_window weitere Trigger registriert werden Klick 1 ist immer noch für die Attribution geeignet, sofern er nicht abgelaufen ist und die Ratenbegrenzung noch nicht erreicht hat.
- Klick 1 kann weiterhin verloren gehen oder verworfen werden, wenn eine höhere Priorität Attributionsquelle ist registriert.
Wird die App des Werbetreibenden deinstalliert und neu installiert, erfolgt die Neuinstallation wird als neue bestätigte Installation gezählt.
Wenn der Klick 1 stattdessen ein Aufrufereignis war, und nach der Installation immer noch Trigger zugeordnet werden. Die API beschränkt die Attribution auf einen Trigger pro Aufruf, außer im Fall der Attribution nach der Installation, sind zwei Trigger pro Aufruf zulässig. Bei der Attribution nach der Installation Für die Anzeigentechnologie kann es zwei verschiedene Berichtszeiträume geben (zwei Tage oder an der Quelle). verfallen.

Alle Kombinationen von app- und webbasierten Triggerpfaden werden unterstützt

Mit der Attribution Reporting API können die folgenden Triggerpfade zugeordnet werden auf einem einzelnen Android-Gerät:

App-to-app::Der Nutzer sieht eine Anzeige in einer App und führt dann eine Conversion in einer der beiden Apps aus. oder eine andere installierte App.
App-to-web::Der Nutzer sieht eine Anzeige in einer App und führt dann auf einem Mobilgerät oder App-Browser.
Web-to-app::Der Nutzer sieht eine Anzeige in einem mobilen oder App-Browser und dann in einer App eine Conversion ausführt.
Web-to-web::Der Nutzer sieht eine Anzeige in einem mobilen oder App-Browser und dann die Conversion entweder im selben Browser oder in einem anderen Browser auf demselben Gerät erfolgt.

Wir ermöglichen es Webbrowsern, neue Funktionen zu unterstützen, die über das Internet sichtbar sind, z. B. eine ähnliche Funktion wie die Privacy Sandbox für die Attribution Reporting API des Webs mit dem die Android-APIs aufgerufen werden können, um die App- und Web-Attribution zu ermöglichen.

Informieren Sie sich über die Änderungen, die Anzeigentechnologien und -Apps vornehmen müssen, um Triggerpfade für App- und Web-Messung.

Mehrere Trigger für eine einzelne Attributionsquelle priorisieren

Eine einzelne Attributionsquelle kann zu mehreren Triggern führen. Beispiel: kann der Kaufvorgang eine App-Installation beinhalten, Trigger, mindestens einen „In den Einkaufswagen“ Trigger und ein „Kauf“, auslösen. Jeder Trigger ist einem oder mehreren Attributionsquellen gemäß den Algorithmus für die quellenpriorisierte Attribution die weiter unten auf dieser Seite beschrieben werden.

Die Anzahl der Trigger, die einer einzelnen Attribution zugeordnet werden können, ist begrenzt. source; Weitere Informationen finden Sie im Abschnitt Messdaten in Attributionsberichte weiter unten auf dieser Seite. In Fällen, in denen Trigger über diese Grenzwerte hinaus ausgelöst werden, sollte eine Priorisierung durchgeführt werden, um die wertvollsten Trigger zurückzugeben. So müssen z. B. die Entwickelnden Anzeigentechnologie-Anbieter möglicherweise wird auf „In den Einkaufswagen“ ausgelöst Trigger.

Zur Unterstützung dieser Logik kann ein separates Prioritätsfeld am Trigger festgelegt werden. werden die Trigger mit der höchsten Priorität ausgewählt, bevor Limits angewendet werden. Berichtsfensters verfügbar sind.

Registrierung von Attributionsquellen oder -triggern durch mehrere Anzeigentechnologien zulassen

Häufig erhalten mehrere Anzeigentechnologien Attributionsberichte, um netzwerkübergreifende Deduplizierung durchzuführen. Daher ermöglicht die API mehrere um dieselbe Attributionsquelle oder denselben Trigger zu registrieren. Eine Anzeigentechnologie muss Registrieren Sie sowohl Attributionsquellen als auch Trigger, um Postbacks vom API und die Attribution erfolgt zwischen den Attributionsquellen und löst aus, dass der die sich bei der API registriert haben.

Werbetreibende, die mit einem Drittanbieter netzwerkübergreifend arbeiten möchten kann die Deduplizierung mit einer Technik ähnlich der folgenden weiterhin durchgeführt werden:

Einrichten eines internen Servers zum Registrieren und Empfangen von Berichten von der API
Sie arbeiten weiterhin mit einem vorhandenen Partner für mobile Analysen zusammen.

Attributionsquellen

Weiterleitungen an die Attributionsquelle werden in der registerSource()-Methode unterstützt:

Die Anzeigentechnologie, mit der die Methode registerSource() aufgerufen wird, kann eine zusätzliches Attribution-Reporting-Redirect-Feld in ihrer Antwort, steht für die Weiterleitungs-URLs der Anzeigentechnologie von Partnern.
Die API ruft dann die Weiterleitungs-URLs auf, damit die Attributionsquelle die von den Anzeigentechnologie-Partnern registriert wurden.

Im Bereich „Anzeigentechnologie“ von Partnern können mehrere URLs Das Feld Attribution-Reporting-Redirect und die Anzeigentechnologie-Anbieter von Partnern können keine eigenes Attribution-Reporting-Redirect-Feld.

Über die API können auch verschiedene Anzeigentechnologien jeden registerSource()-Aufruf verwenden.

Trigger

Für die Registrierung als Trigger werden Drittanbieter auf ähnliche Weise unterstützt: Anzeigentechnologien können entweder das zusätzliche Feld Attribution-Reporting-Redirect verwenden oder kann jeder die Methode registerTrigger() aufrufen.

Wenn ein Werbetreibender mehrere Anzeigentechnologien nutzt, um dasselbe Trigger-Ereignis zu registrieren, Deduplizierungsschlüssel verwendet werden. Der Deduplizierungsschlüssel dient dazu, diese wiederholten Meldungen desselben Ereignisses, das von derselben Anzeigentechnologie registriert wurde Plattform. Beispielsweise kann ein Anzeigentechnologie-Anbieter die API direkt aufrufen, um einen Trigger registrieren und die URL in das Weiterleitungsfeld der aufrufen. Wenn kein Deduplizierungsschlüssel angegeben wird, werden möglicherweise doppelte Trigger gemeldet als einzigartig sein.

Umgang mit doppelten Triggern

Ein Anzeigentechnologie-Anbieter kann denselben Trigger mehrmals mit der API registrieren. Scenarios umfassen Folgendes:

Der Nutzer führt dieselbe Aktion (Trigger) mehrmals aus. Beispiel: Der Nutzer sieht sich in einem Bericht mehrmals dasselbe Produkt an. .
In der App des Werbetreibenden werden mehrere SDKs für die Conversion-Analyse verwendet. die alle zur selben Anzeigentechnologie weiterleiten. In der Werbetreibenden-App werden zum Beispiel MMP Nr. 1 und MMP Nr. 2. Beide MMPs leiten zu AdTech #3 weiter. Wenn ein Trigger eintritt, wird er von beiden MMPs über die Attribution registriert. Reporting API AdTech #3 erhält dann zwei separate Weiterleitungen, eine von MMP 1 und eine von MMP 2 – für denselben Trigger.

In diesen Fällen gibt es mehrere Möglichkeiten, Berichte auf Ereignisebene zu unterdrücken. doppelten Trigger, um die Wahrscheinlichkeit zu verringern, Ratenbegrenzungen für Berichte auf Ereignisebene. Es wird empfohlen, einen Deduplizierungsschlüssel zu verwenden.

Empfohlene Methode: Deduplizierungsschlüssel

Es wird empfohlen, dass die App des Werbetreibenden eine eindeutige Deduplizierung für die Conversion-Analyse verwendet wird. Wenn ein Conversion erfolgt, übergibt die App einen Deduplizierungsschlüssel an die AdTechs oder SDKs. Diese AdTechs oder SDKs fahren dann mit der Übergabe des Deduplizierungsschlüssels an die Weiterleitungen fort. mithilfe eines Parameters in den in Attribution-Reporting-Redirect angegebenen URLs.

Anzeigentechnologie-Anbieter können festlegen, dass nur der erste Trigger mit einer bestimmten Deduplizierungsschlüssel verwenden oder mehrere oder alle Trigger registrieren. Anzeigentechnologie-Anbieter können bei der Registrierung eines Duplikats die deduplication_key angeben. Trigger.

Wenn eine Anzeigentechnologie mehrere Trigger mit demselben Deduplizierungsschlüssel zugeordneter Quelle wird nur der erste registrierte Trigger auf Ereignisebene gesendet. Berichte. Doppelte Trigger werden weiterhin in verschlüsselten aggregierten Berichten gesendet.

Alternative Methode: Anzeigentechnologie-Anbieter einigen sich auf Trigger-Typen pro Werbetreibendem

In Situationen, in denen AdTech-Teams den Deduplizierungsschlüssel nicht verwenden möchten Die Werbetreibenden-App kann keinen Deduplizierungsschlüssel übergeben. Es gibt eine alternative Option. Alle Anzeigentechnologien, die Conversions für einen bestimmten Werbetreibenden erfassen, müssen zusammenarbeiten. um unterschiedliche Triggertypen für jeden Werbetreibenden zu definieren.

AdTechs, die den Trigger-Registrierungsaufruf initiieren, z. B. SDKs, enthalten einen Parameter in URLs, die in Attribution-Reporting-Redirect angegeben werden, z. B. duplicate_trigger_id. Dieser duplicate_trigger_id-Parameter kann Folgendes enthalten: etwa den SDK-Namen und den Triggertyp für diesen Werbetreibenden. Anzeigentechnologie kann dann einen Teil dieser doppelten Trigger an Berichte auf Ereignisebene senden. Anzeigentechnologie-Anbieter können diese duplicate_trigger_id auch in ihre Aggregationsschlüssel aufnehmen.

Beispiel für netzwerkübergreifende Attribution

In dem in diesem Abschnitt beschriebenen Beispiel verwendet der Werbetreibende zwei (Anzeigentechnologie A und Anzeigentechnologie B) sowie einen Partner für die Analyse.

Zuerst müssen die Anzeigentechnologie A, die Anzeigentechnologie B und der MMP registriert sein, um die Attribution Reporting API Weitere Informationen finden Sie unter Privacy Sandbox-Konto registrieren. erhalten Sie weitere Informationen.

Die folgende Liste enthält eine hypothetische Reihe von Aktionen der Nutzenden, und wie diese Aktionen in der Attribution Reporting API verarbeitet werden. in Bezug auf Anzeigentechnologie A, Anzeigentechnologie B und MMP:

Tag 1: Der Nutzer klickt auf eine von AdTech A ausgelieferte Anzeige

Adtech A ruft registerSource() mit seinem URI auf. Die API sendet eine Anfrage an URI und der Klick wird mit den Metadaten der Anzeigentechnologie A registriert. Serverantwort.

Anzeigentechnologie A enthält außerdem den MMP-URI im Attribution-Reporting-Redirect Header. Die API sendet eine Anfrage an den MMP-URI und der Klick wird registriert mit den Metadaten aus der MMP-Serverantwort.

Tag 2: Der Nutzer klickt auf eine von AdTech B ausgelieferte Anzeige

AdTech B ruft registerSource() mit seinem URI auf. Die API sendet eine Anfrage an URI und der Klick wird mit den Metadaten der Anzeigentechnologie B registriert. Serverantwort.

Wie bei der Anzeigentechnologie A hat auch die Anzeigentechnologie B den URI des MMP in den Parameter Attribution-Reporting-Redirect-Header. Die API sendet eine Anfrage an die MMPs. URI und der Klick wird mit den Metadaten vom MMP-Server registriert. Antwort.

Tag 3: Der Nutzer sieht eine von AdTech A ausgelieferte Anzeige

Die API reagiert genauso wie an Tag 1, mit der Ausnahme, dass eine Datenansicht AdTech A und MMP registriert.

Tag 4: Der Nutzer installiert die App, die den MMP für die Conversion-Analyse verwendet.

MMP ruft registerTrigger() mit dem entsprechenden URI auf. Die API sendet eine Anfrage an den und die Conversion wird mit den Metadaten vom MMP-Server registriert. Antwort.

Die MMP enthält außerdem die URIs für Anzeigentechnologie A und Anzeigentechnologie B in der Attribution-Reporting-Redirect-Header. Über die API werden Anfragen an Anzeigentechnologie A gesendet. und der Server von AdTech B. Die Conversion wird dann die Metadaten aus den Serverantworten.

Das folgende Diagramm veranschaulicht den in der vorherigen Liste beschriebenen Prozess:

Beispiel für die Attribution Reporting API auf eine Reihe von Nutzeraktionen reagiert.

Die Attribution funktioniert so:

Bei Anzeigentechnologie A ist die Priorität von Klicks höher als der von Aufrufen. die dem Klick am Tag 1 zugeschriebene Installation.
Für Anzeigentechnologie B wird die Installation an Tag 2 zugeordnet.
Mit MMP ist die Priorität von Klicks höher als der von Aufrufen und die Anzahl der Installationen dem Klick am Tag 2 zugeschrieben. Der Klick an Tag 2 hat die höchste Priorität. letztes Anzeigenereignis.

Netzwerkübergreifende Attribution ohne Weiterleitungen

Wir empfehlen zwar, Weiterleitungen zu verwenden, damit sich mehrere Anzeigentechnologie-Anbieter registrieren können. Attributionsquellen und -auslöser erkennen, kann es Szenarien geben, mit Weiterleitungen nicht möglich ist. In diesem Abschnitt erfahren Sie, wie Sie netzwerkübergreifende Attribution ohne Weiterleitungen.

Hoher Datenfluss

Bei der Registrierung der Quelle gibt das Anzeigentechnologie-Netzwerk seine Quelle frei Aggregationsschlüssel.
Bei der Registrierung wählt der Werbetreibende oder Partner für die Messung aus, zu verwendende Schlüsselelemente auf Quellseite und gibt ihre Attributionskonfiguration an.
Die Attribution basiert auf der Attributionskonfiguration, freigegebenen Schlüsseln und allen Quellen die von diesem Werbetreibenden oder Partner für Messungen registriert wurden. (z.B. von einem anderen ausliefernden AdTech-Netzwerk, das Weiterleitungen aktiviert hat).
Trigger wird einer Quelle einer Anzeige zugeordnet, die keine Weiterleitung hat kann der Werbetreibende oder Partner für Messungen Bericht erstellt, in dem die in Schritt 2 definierten Quelle- und Trigger-Elemente miteinander kombiniert sind.

Quellenregistrierung

Bei der Quellenregistrierung kann das Anzeigentechnologie-Netzwerk auswählen, Quellaggregationsschlüssel oder eine Teilmenge ihrer Quellaggregationsschlüssel anstelle von Weiterleitung. Die Anzeigentechnologie ist nicht erforderlich, um diese Quellen tatsächlich zu verwenden eigenen zusammengefassten Berichten verwenden und sie nur im Namen von den Werbetreibenden oder den Partner für Messungen.

Gemeinsame Aggregationsschlüssel stehen allen Anzeigentechnologien zur Verfügung, die einen Trigger für über denselben Werbetreibenden. Es liegt jedoch an der Anzeigentechnologie und dem Trigger für die Analyse der Anzeigentechnologie, um zu bestimmen, welche Arten von Aggregationsschlüsseln erforderlich sind, ihre Namen und wie die Schlüssel in lesbare Dimensionen decodiert werden können.

Registrierung auslösen

Bei der Registrierung des Triggers wählt die Anzeigentechnologie aus, welcher quellseitige Schlüssel verwendet wird Teile, die auf die einzelnen Trigger-Schlüsselelemente angewendet werden sollen, einschließlich der von der Auslieferungsanzeige freigegebenen Elemente zu entwickeln.

Außerdem muss die Anzeigentechnologie für Messungen die Vermittlungsabfolge Attributionslogik mithilfe eines neuen API-Aufrufs für die Attributionskonfiguration an. In dieser Konfiguration kann die Anzeigentechnologie die Priorität der Quelle, das Ablaufdatum und Filter für Quellen festlegen, nicht sichtbar waren (z. B. Quellen ohne Weiterleitung).

Attribution

Über die Attribution Reporting API werden quellenpriorisierte, letzte Touch-Gesten ausgeführt. für die Analyse-Anzeigentechnologie auf Grundlage ihrer Attributionskonfiguration. freigegebene Schlüssel und alle von ihnen registrierten Quellen. Beispiel:

Der Nutzer hat auf die Anzeigen der Anzeigentechnologien A, B, C und D geklickt. Die Nutzenden Sie haben die App des Werbetreibenden installiert, die einen Anzeigentechnologie-Partner für Messungen nutzt. (MMP).
Anzeigentechnologie A leitet ihre Quellen an den MMP weiter.
Die Anzeigentechnologien B und C leiten keine Weiterleitungen weiter, sondern teilen ihre Aggregationsschlüssel.
Die Anzeigentechnologie D leitet die Schlüssel nicht weiter und gibt auch keine Aggregationsschlüssel frei.

Über den MMP wird eine Quelle von Anzeigentechnologie A registriert und eine Attributionskonfiguration definiert. einschließlich Anzeigentechnologie B und Anzeigentechnologie D.

Die Attribution für das MMP umfasst jetzt:

Anzeigentechnologie A, da der MMP eine Quelle über die Weiterleitung dieser Anzeigentechnologie registriert hat.
Anzeigentechnologie B, da Anzeigentechnologie B Schlüssel freigegeben hat und diese im MMP Attributionskonfiguration.

Die Attribution für das MMP umfasst Folgendes nicht:

Anzeigentechnologie C, da sie vom MMP nicht in der Attributionskonfiguration berücksichtigt wurde.
Anzeigentechnologie D, da sie weder weitergeleitet noch Aggregationsschlüssel verwendet

Debugging

Um das Debugging für die netzwerkübergreifende Attribution ohne Weiterleitungen zu unterstützen, steht AdTech-Experten das zusätzliche Feld „shared_debug_key“ zur Verfügung Registrierung der Quelle. Wenn sie für die ursprüngliche Quellregistrierung festgelegt wurde, gilt sie auch für Für die entsprechende abgeleitete Quelle während der Triggerregistrierung als debug_key festgelegt für netzwerkübergreifende Attribution ohne Weiterleitungen. Dieser Fehlerbehebungsschlüssel wird angehängt als source_debug_key in Ereignis- und aggregierten Berichten.

Diese Debugging-Funktion wird nur für die netzwerkübergreifende Attribution ohne Weiterleitungen in folgenden Fällen:

App-zu-App-Messung, wenn die Werbe-ID Zulässig
App-zu-Web-Messung, wenn die Anzeigen-ID zulässig ist, und der Abgleich in sowohl die App-Quelle als auch der Web-Trigger
Web-zu-Web-Messung (auf der gleichen Browser-App), wenn ar_debug sowohl in der Quelle als auch im Trigger vorhanden ist

Schlüsselerkennung für netzwerkübergreifende Attribution ohne Weiterleitungen

Ziel der Schlüsselerkennung ist es, die Implementierung von Anzeigentechnologien (in der Regel MMPs) zu optimieren. für die netzwerkübergreifende Attribution verwenden, oder mehrere Anzeigentechnologie-Anbieter für die Anzeigenbereitstellung gemeinsam genutzte Aggregationsschlüssel verwenden (wie in den Netzwerkübergreifende Attribution ohne Weiterleitungen.

Wenn ein MMP den Aggregationsdienst abfragt, um zusammenfassende Berichte für die abgeleitete Quellen enthalten, muss das MMP gibt die Liste der möglichen Schlüssel als Eingabe für den Aggregationsjob an. In einigen kann die Liste potenzieller Aggregationsschlüssel für die Quelle sehr groß sein. unbekannt. Große Listen möglicher Schlüssel sind schwer zu verfolgen sehr komplex und kostspielig sein. Hier einige Tipps: Beispiele:

Die Liste aller möglichen Schlüssel ist lang: <ph type="x-smartling-placeholder">
- Ein auslieferndes Werbenetzwerk führt eine komplexe Initiative zur Nutzergewinnung durch umfasst 20 Kampagnen mit jeweils 10 Anzeigengruppen und jede Anzeigengruppe mit 5 Creatives, die jede Woche je nach Leistung aktualisiert werden.
Die Liste aller möglichen Schlüssel ist unbekannt: <ph type="x-smartling-placeholder">
- Ein auslieferndes Werbenetzwerk schaltet Anzeigen in vielen mobilen Apps, in denen Die vollständige Liste der Publisher-App-IDs ist zum Start der Kampagne nicht bekannt.
- Ein Werbetreibender arbeitet mit mehreren ausliefernden Werbenetzwerken, die Bei der Quellenregistrierung werden keine Weiterleitungen zum MMP durchgeführt. jede ausgelieferte Anzeige unterschiedliche Schlüsselstrukturen und -werte, die nicht unbedingt vorab an das MMP weitergegeben werden.

Mit der Einführung der Schlüsselerkennung:

Für den Aggregationsdienst ist keine vollständige Aufzählung möglicher Aggregationsschlüssel.
Anstatt die vollständige Liste möglicher Schlüssel angeben zu müssen, kann ein MMP ein leerer (oder teilweise leerer) Schlüsselsatz und legen einen Schwellenwert fest, sodass nur (nicht vorab deklarierte) Schlüssel mit Werten, die den Grenzwert überschreiten, werden in die Ausgabe.
MMP erhält einen zusammenfassenden Bericht mit verrauschten Werten für Schlüssel, die haben Werte über dem festgelegten Grenzwert. Der Bericht kann auch Schlüssel, denen keine echten Nutzerbeiträge zugeordnet sind, und die rein verrauscht sind.
MMP verwendet das Feld x_network_bit_mapping in der Triggerregistrierung, um welche Anzeigentechnologie zu welchem Schlüssel passen.
MMP kann sich dann an den entsprechenden Anzeigentechnologie-Anbieter wenden, um die Werte zu verstehen. im Quellschlüssel.

Zusammenfassend lässt sich sagen, dass MMPs Aggregationsschlüssel ohne im Voraus bekannt und es vermeiden, eine große Menge an Quellschlüsseln zu verarbeiten. auf Kosten zusätzlichen Lärm.

Messdaten in Attributionsberichten abrufen

Mit der Attribution Reporting API stehen folgende Berichtstypen zur Verfügung: genauer auf diese Seite eingehen:

In Berichten auf Ereignisebene wird ein Attributionsquelle (Klick oder Ansicht) mit wenigen High-Fidelity-Bits Trigger-Daten.
Aggregierbare Berichte sind nicht unbedingt verknüpft. mit einer bestimmten Attributionsquelle. Diese Berichte bieten umfassendere, Genauere Triggerdaten als Berichte auf Ereignisebene, aber diese Daten in aggregierter Form zur Verfügung.

Diese beiden Berichtstypen ergänzen sich gleichzeitig.

Berichte auf Ereignisebene

Nachdem ein Trigger einer Attributionsquelle zugeordnet wurde, wird ein Bericht auf Ereignisebene generiert und auf dem Gerät gespeichert, bis sie an das die Postback-URL während eines Zeitfenster für das Senden von Berichten, die wir später auf dieser Seite genauer beschreiben.

Berichte auf Ereignisebene sind nützlich, wenn nur wenige Informationen zum auslösen. Triggerdaten auf Ereignisebene sind auf 3 Bit an Triggerdaten für Klicks – was bedeutet, dass einem Trigger eine von acht Kategorien zugewiesen werden kann, und für Aufrufe. Darüber hinaus unterstützen Berichte auf Ereignisebene keine Codierung von Trigger-seitige High-Fidelity-Daten wie einen bestimmten Preis oder eine Auslösungszeit. Da die Attribution auf dem Gerät erfolgt, wird die geräteübergreifende Analysen in Berichten auf Ereignisebene.

Der Bericht auf Ereignisebene enthält u. a. folgende Daten:

Ziel:Paketname der Werbetreibenden-App oder eTLD+1, bei dem der Trigger passierte
ID der Attributionsquelle:Dieselbe ID der Attributionsquelle, die für Attributionsquelle registrieren
Triggertyp:1 oder 3 Bit Low-Fidelity-Triggerdaten, je nach Typ der Attributionsquelle

Datenschutzmechanismen, die auf alle Berichte angewendet werden

Die folgenden Limits werden nach Prioritäten in Bezug auf Attributionsquellen angewendet und Trigger berücksichtigt werden.

Begrenzung der Anzahl der Anzeigentechnologien

Die Anzahl der Anzeigentechnologie-Anbieter, die sich registrieren oder Berichte empfangen können, ist begrenzt aus der API mit einem aktuellen Vorschlag für Folgendes:

100 Anzeigentechnologien mit Attributionsquellen pro {Quell-App, Ziel-App, 30 Tage, Gerät}.
10 Anzeigentechnologien mit zugeordneten Triggern pro {Quell-App, Ziel-App, 30 Tage, Gerät}.
20 Anzeigentechnologien können eine einzige Attributionsquelle oder einen einzelnen Trigger registrieren (über Attribution-Reporting-Redirect)

Beschränkungen für die Anzahl eindeutiger Ziele

Diese Begrenzungen erschweren es einer Reihe von Anzeigentechnologien, durch die Abfrage eines App-Nutzungsverhalten eines Nutzers ermitteln.

Über alle registrierten Quellen und Anzeigentechnologien hinweg unterstützt die API keine als 200 eindeutige Ziele pro Quell-App und Minute.
Für alle registrierten Für eine einzelne Anzeigentechnologie unterstützt die API maximal 50 eindeutige Ziele, pro Quell-App und Minute. Durch dieses Limit wird verhindert, das gesamte Budget aus der zuvor erwähnten Ratenbegrenzung aufzubrauchen.

Abgelaufene Quellen werden nicht auf die Ratenbegrenzungen angerechnet.

Eine Quelle für Berichte pro Quell-App und Tag

Eine Anzeigentechnologie-Plattform darf nur eine einzige Meldequelle für die Registrierung von Quellen verwenden in einer Publisher-App auf einem bestimmten Gerät am selben Tag. Dieses Ratenlimit verhindert, dass Anzeigentechnologie-Anbieter mehrere Berichtsquellen verwenden, um auf zusätzliche des Datenschutzbudgets.

Stellen Sie sich folgendes Szenario vor, in dem ein einzelner Anzeigentechnologie-Anbieter mehrere um Quellen in einer Publisher-App für ein einzelnes Gerät zu registrieren.

Mit der Berichtsquelle 1 von Anzeigentechnologie A wird eine Quelle in App B registriert
Zwölf Stunden später versucht AdTech A, Berichtsquelle 2, eine Quelle zu registrieren. in App B

Die zweite Quelle, für die Berichtsquelle 2 von Anzeigentechnologie A, wird vom der API erstellen. Mit Ursprung 2 der Anzeigentechnologie A kann kein auf demselben Gerät in App B.

Cooldown- und Ratenbegrenzungen

Um das Risiko von Datenlecks zwischen {source, destination} zu begrenzen -Paar, drosselt die API die Gesamtmenge der in einer bestimmten Zeit gesendeten Informationen. für einen Nutzer festzulegen.

Aktuell wird vorgeschlagen, jede Anzeigentechnologie auf 100 zugeordnete Trigger pro {Quell-App, Ziel-App, 30 Tage, Gerät}.

Anzahl der eindeutigen Ziele

Die API begrenzt die Anzahl der Ziele, die ein Anzeigentechnologie-Anbieter messen kann. Je niedriger das Limit, desto schwieriger ist es für Anzeigentechnologie-Anbieter, mit der API zu versuchen, um Browseraktivitäten von Nutzern zu erfassen, die nicht mit der bereitgestellten Werbung verknüpft sind.

Der aktuelle Vorschlag sieht vor, jede Anzeigentechnologie auf 100 verschiedene Ziele zu beschränken, Nicht abgelaufene Quellen pro Quell-App.

Datenschutzmechanismen, die auf Berichte auf Ereignisebene angewendet werden

Eingeschränkte Genauigkeit der Triggerdaten

Die API bietet 1 Bit für View-through-Trigger und 3 Bit für Klicks Trigger. Attributionsquellen unterstützen weiterhin die vollen 64 Bits an Metadaten.

Sie sollten prüfen, ob und wie Sie die in Triggern ausgedrückten Informationen reduzieren können sodass sie mit der begrenzten Anzahl von Bits arbeiten, die in Berichten auf Ereignisebene verfügbar sind.

Framework für Differential Privacy Noise

Mit dieser API soll eine Messung auf Ereignisebene Differential Privacy-Anforderungen. Dabei wird mithilfe von k-zufälligen Antworten eine für jedes Quellereignis eine verrauschte Ausgabe.

Rauschen wird darauf angewendet, ob ein Ereignis der Attributionsquelle wahrheitsgemäß gemeldet wird. Eine Attributionsquelle ist auf dem Gerät mit der Wahrscheinlichkeit $ 1-p $ registriert, die wird die Zuordnungsquelle wie gewohnt registriert. Das Gerät wählt nach dem Zufallsprinzip aus allen möglichen Ausgabezuständen der API aus (z. B. überhaupt nichts oder mehrere gefälschte Meldungen melden).

Bei der k-zufälligen Antwort handelt es sich um einen Algorithmus, der die Epsilon-Differenz privat, wenn die folgende Gleichung erfüllt ist:

\[ p = \frac{k}{k + e^ε - 1} \]

Bei niedrigen EE-Werten wird die wahre Ausgabe durch die k-zufällige Reaktionsmechanismus. Die genauen Rauschparameter sind noch in der Entwicklung und unterliegen basierend auf dem Feedback mit einem aktuellen Vorschlag der folgenden Punkte:

p=0,24% für Navigationsquellen
p=0,00025% für Ereignisquellen

Limits für verfügbare Trigger (Conversions)

Die Anzahl der Trigger pro Attributionsquelle ist begrenzt. aktuellen Vorschlag:

Ein bis zwei Trigger für Attributionsquellen für Anzeigenaufrufe (zwei Trigger nur in im Fall der Attribution nach der Installation)
3 Trigger für Attributionsquellen für Klickanzeigen

Bestimmte Zeitfenster für das Senden von Berichten (Standardverhalten)

Berichte auf Ereignisebene für Attributionsquellen für Anzeigenaufrufe werden eine Stunde nach dem Gültigkeit der Quelle abläuft. Dieses Ablaufdatum kann konfiguriert werden, muss aber nicht weniger als 1 sein Tag oder mehr als 30 Tage. Wenn zwei Trigger einer Anzeigenansicht zugeordnet sind (über die Attribution nach der Installation) können Berichte auf Ereignisebene in den folgenden Intervallen gesendet werden.

Berichte auf Ereignisebene für Attributionsquellen für Anzeigenklicks können nicht konfiguriert werden und werden vor oder wenn die Quelle zu bestimmten Zeitpunkten relativ bis die Quelle registriert wurde. Die Zeit zwischen der Attributionsquelle und wird in mehrere Berichtszeiträume aufgeteilt. Jedes Berichtsfenster hat ein Frist (ab der Zeit der Attributionsquelle). Am Ende jedes Berichts erfasst das Gerät alle Trigger, die seit der vorherigen Berichtsfensters und sendet einen geplanten Bericht. Die API unterstützt die folgenden Berichtszeiträumen:

2 Tage:Das Gerät erfasst alle Trigger, die höchstens zwei aufgetreten sind. Tage nach der Registrierung der Attributionsquelle. Der Bericht wird 2 Tage gesendet. und 1 Stunde nach der Registrierung der Attributionsquelle.
7 Tage:Auf dem Gerät werden alle Trigger erfasst, die mehr als zwei Mal ausgelöst wurden. Tage, jedoch nicht später als sieben Tage nach der Registrierung der Attributionsquelle. Der Bericht wird 7 Tage und 1 Stunde nach der registriert.
Ein benutzerdefinierter Zeitraum,der durch das „Ablaufdatum“ definiert wird Attribut eines Attributionsquelle. Der Bericht wird 1 Stunde nach dem angegebenen Ablaufdatum gesendet . Dieser Wert kann nicht kleiner als 1 Tag oder mehr als 30 Tage sein.

Flexible Konfiguration auf Ereignisebene

Für Anzeigentechnologien wird die Standardkonfiguration für Berichte auf Ereignisebene empfohlen die zu Beginn des Dienstprogrammtests beginnen, sind aber nicht unbedingt für alle Anwendungsfälle geeignet. Cases. Die Attribution Reporting API unterstützt optionale und flexiblere damit AdTechs mehr Kontrolle über die Struktur Berichte auf Ereignisebene erstellen und den Nutzen der Daten maximieren.

Diese zusätzliche Flexibilität wird in Attribution Reporting eingeführt. API in zwei Phasen:

Phase 1: Flexible Lite-Konfiguration auf Ereignisebene <ph type="x-smartling-placeholder">
- Diese Version bietet einen Teil des gesamten Funktionsumfangs und kann unabhängig von Phase 2 verwendet werden.
Phase 2: Vollständige Version der flexiblen Konfiguration auf Ereignisebene

Phase 1 (flexible Lite-Ereignisebene) kann für Folgendes verwendet werden:

Sie können die Häufigkeit der Berichte variieren, indem Sie die Anzahl der Berichtszeiträume angeben.
Variieren Sie die Anzahl der Zuordnungen pro Quellenregistrierung
Reduzieren Sie das Gesamtrauschen, indem Sie die oben genannten Parameter verringern.
Berichtsfenster konfigurieren, anstatt die Standardeinstellungen zu verwenden

Phase 2 (Voll flexible Ereignisebene) kann verwendet werden, um alle Funktionen in Phase 1 und:

Kardinalität der Triggerdaten in einem Bericht variieren
Reduzieren Sie die Menge des Gesamtrauschens, indem Sie die Kardinalität der Triggerdaten verringern

Wenn Sie eine Dimension der Standardkonfiguration reduzieren, kann die Anzeigentechnologie um eine weitere Dimension zu erhöhen. Alternativ kann die Gesamtmenge des Rauschens bei einem Ereignis Ebenenbericht kann durch eine Verringerung der oben genannten Parameter netto reduziert werden.

Neben der dynamischen Festlegung von Rauschpegeln basierend auf den haben wir einige Parameterlimits, um umfangreiche Berechnungen Kosten und Konfigurationen mit zu vielen Ausgabezuständen (bei denen das Rauschen zunimmt) erheblich). Hier ist ein Beispiel für eine Reihe von Einschränkungen. Wir freuen uns über Feedback zu [Designvorschlag][50]:

Maximal 20 Berichte insgesamt, global und pro trigger_data
Maximal 5 mögliche Berichtsfenster pro trigger_data
Maximal 32 Triggerdaten-Kardinalität (nicht zutreffend für Phase 1: Lite) Flexible Ereignisebene)

Da Anzeigentechnologie-Anbieter diese Funktion verwenden, kann die Verwendung von Extremwerten zu starkem Rauschen führen oder Fehler bei der Registrierung verursachen, wenn nicht erfüllt.

Aggregierbare Berichte

Bevor Sie aggregierte Berichte verwenden können, müssen Sie Ihr Cloud-Konto einrichten und aggregierte Berichte erhalten.

Aggregierte Berichte liefern detailliertere Triggerdaten vom Gerät über die Berichte auf Ereignisebene hinaus. Diese genaueren Daten können nur in der Aggregierung erlernt werden die mit einem bestimmten Trigger oder Nutzer verknüpft sind. Bis zu 128 Aggregationsschlüssel sind zulässig So lassen sich aggregierbare Berichte für Anwendungsfälle wie wie folgt:

Berichte für Triggerwerte wie „Umsatz“
Weitere Triggertypen verarbeiten

Außerdem wird in aggregierten Berichten die gleiche quellenpriorisierte Attribution verwendet. als Berichte auf Ereignisebene. Sie unterstützen jedoch mehr Conversions, klicken oder ansehen.

Das Gesamtkonzept für die Vorbereitung und den Versand von Daten aggregierte Berichte wie im Diagramm dargestellt:

Das Gerät sendet verschlüsselte aggregierte Berichte an den Anzeigentechnologie-Anbieter. In einer in einer Produktionsumgebung erstellt haben, können Anzeigentechnologie-Anbieter diese Berichte nicht direkt verwenden.
Die Anzeigentechnologie sendet einen Batch aggregierter Berichte an den Aggregationsdienst. für die Aggregation.
Der Aggregationsdienst liest einen Batch aggregierter Berichte, entschlüsselt und aggregiert sie.
Die endgültigen Daten werden in einem Zusammenfassungsbericht

Von der Attribution Reporting API verwendeter Prozess und zusammenfassende Berichte erstellen.

Aggregierte Berichte enthalten die folgenden Daten in Bezug auf Attributionsquellen:

Ziel:Der Paketname der App oder die eTLD+1-Web-URL, bei der der Trigger passiert ist.
Datum:Das Datum, an dem das Ereignis durch die Attributionsquelle dargestellt wird. aufgetreten.
Nutzlast:Triggerwerte, die als verschlüsselte Schlüssel/Wert-Paare erfasst werden, die wird im vertrauenswürdigen Aggregationsdienst verwendet, um Aggregationen zu berechnen.

Aggregationsdienste

Die folgenden Dienste bieten Aggregationsfunktionen und tragen dazu bei, Schutz vor unangemessenen Zugriffen auf aggregierte Daten.

Diese Dienste werden von verschiedenen Parteien verwaltet, die in mehr weiter unten auf dieser Seite:

Der Aggregationsdienst ist der einzige Dienst, den AdTech-Anzeigentechnologie bereitstellen.
Den Schlüsselverwaltungs- und den aggregierbaren Bericht Buchhaltungsdienste werden von vertrauenswürdigen die sogenannten Koordinatoren. Diese Koordinatoren bestätigen, dass der Code Der Aggregationsdienst wird als öffentlich verfügbarer Code und dass alle Nutzer des Aggregationsdienstes denselben Schlüssel und die auf sie angewendet werden.

Zusammenfassungsdienst

AdTech-Plattformen müssen vorab einen Aggregationsdienst bereitstellen, der auf auf von Google bereitgestellten Binärprogrammen.

Dieser Aggregationsdienst wird in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) ausgeführt die in der Cloud gehostet werden. Ein TEE bietet die folgenden Sicherheitsvorteile:

Er stellt sicher, dass der im TEE verwendete Code dem spezifischen Binärprogramm entspricht, das angeboten wird. von Google. Solange diese Bedingung nicht erfüllt ist, kann der Aggregationsdienst auf die für den Betrieb erforderlichen Entschlüsselungsschlüssel.
Es bietet Sicherheit für den laufenden Prozess und isoliert ihn von externen Quellen. zu überwachen oder zu manipulieren.

Diese Sicherheitsvorteile machen einen Aggregationsdienst sicherer sensible Vorgänge wie der Zugriff auf verschlüsselte Daten.

Weitere Informationen zu Design, Workflow und Sicherheitsaspekten der Aggregationsdienst, siehe Aggregation Service Dokument auf GitHub.

Key Management Service

Dieser Dienst prüft, ob ein Aggregationsdienst eine genehmigte Version ausführt des Binärprogramms und stellt dann den Aggregationsdienst in der Anzeigentechnologie richtigen Entschlüsselungsschlüssel für ihre Triggerdaten.

Aggregierbare Berichte

Dieser Dienst erfasst, wie oft der Aggregationsdienst einer Anzeigentechnologie auf einen Spezifischer Trigger, der mehrere Aggregationsschlüssel enthalten kann und den Zugriff beschränkt auf die angemessene Anzahl von Entschlüsselungen. Weitere Informationen finden Sie im Aggregationsdienst für Designvorschlag für die Attribution Reporting API.

Aggregierbare Berichte API

Die API zum Erstellen von Beiträgen zu aggregierten Berichten verwendet dieselbe Basis API wie beim Registrieren einer Attributionsquelle für Berichte auf Ereignisebene. In den folgenden Abschnitten werden die Erweiterungen der der API erstellen.

Aggregierbare Quelldaten registrieren

Wenn die API eine Anfrage an den URI der Attributionsquelle sendet, kann die Anzeigentechnologie eine Liste mit Aggregationsschlüsseln namens histogram_contributions registrieren, indem mit einem neuen Feld namens aggregation_keys im HTTP-Header antworten Attribution-Reporting-Register-Source mit dem Schlüssel key_name und dem Wert als key_piece:

(Schlüssel) Schlüsselname:Ein String für den Namen des Schlüssels. Wird als Join-Schlüssel verwendet, um mit Auslöser-Tasten kombinieren, um den letzten Schlüssel zu bilden.
(Wert) Schlüsselteil:Ein Bitstringwert für den Schlüssel.

Der endgültige Histogramm-Bucket-Schlüssel wird zum Zeitpunkt der Auslösung vollständig definiert, indem eine binäre OR-Operation auf diese Teile und die Teile auf Triggerseite.

Die endgültigen Schlüssel sind auf maximal 128 Bit beschränkt. Schlüssel sind länger als dieser Wert abgeschnitten. Das bedeutet, dass Hex-Strings in der JSON-Datei auf höchstens 32 Ziffern.

Weitere Informationen zur Strukturierung von Aggregationsschlüsseln können Sie Aggregationsschlüssel konfigurieren.

Im folgenden Beispiel erfasst ein Anzeigentechnologie-Anbieter über die API Folgendes:

Aggregierte Conversion-Anzahl auf Kampagnenebene
Kaufwerte auf geografischer Ebene aggregieren

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

Aggregierbaren Trigger registrieren

Die Triggerregistrierung enthält zwei zusätzliche Felder.

Mit dem ersten Feld wird eine Liste von aggregierten Schlüsseln beim Trigger registriert zu verstehen. Der Anzeigentechnologie-Anbieter sollte mit dem Feld aggregatable_trigger_data antworten im HTTP-Header Attribution-Reporting-Register-Trigger mit folgende Felder für jeden aggregierten Schlüssel in der Liste:

Schlüsselteil:Ein Bitstring-Wert für den Schlüssel.
Quellschlüssel:Eine Liste von Strings mit den Namen der Attributionsquellenseite Schlüssel, mit denen der Triggerschlüssel kombiniert werden soll, um die endgültigen Schlüssel zu bilden.

Das zweite Feld dient zur Registrierung einer Liste von Werten, für jeden Schlüssel. Der Anzeigentechnologie-Anbieter sollte mit dem Feld aggregatable_values antworten im HTTP-Header Attribution-Reporting-Register-Trigger. Das zweite Feld zum Registrieren einer Liste von Werten, die zu jedem Schlüssel beitragen sollen, ganze Zahlen im Bereich $ [1, 2^{16}] $ sein.

Jeder Trigger kann mehrere Beiträge zu den aggregierbaren Berichten leisten. Die Der Gesamtbetrag der Beiträge zu einem bestimmten Quellereignis ist an ein $ L1 $ gebunden. Parameter, der die maximale Summe der Beiträge (Werte) für alle für eine bestimmte Quelle aggregieren. $ L1 $ bezieht sich auf die L1-Empfindlichkeit oder Norm der Histogrammbeiträge pro Quellereignis. Das Überschreiten dieser Grenzwerte führt künftige Beiträge ohne Meldung verworfen. Der erste Vorschlag besteht darin, $ L1 $ auf 2^{16} $ (65536).

Das Rauschen im Aggregationsdienst wird proportional zu diesem Parameter skaliert. Daher empfiehlt es sich, die für eine bestimmte Anzahl von Conversions gemeldeten Werte basierend auf dem Anteil des $ L1 $-Budgets, der ihm zugewiesen ist. Dieses aggregierte Berichte so, dass die höchstmögliche Anzahl Rauschen zu entfernen. Dieser Mechanismus ist sehr flexibel und unterstützen viele Aggregationsstrategien.

Im folgenden Beispiel wird das Datenschutzbudget zu gleichen Teilen campaignCounts und geoValue durch Aufteilen des Beitrags von L1 $ auf die beiden:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

Das vorherige Beispiel generiert die folgenden Histogrammbeiträge:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

Die Skalierungsfaktoren können invertiert werden, um die richtigen Werte zu erhalten. angewandtes Modulo-Rauschen:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Differential Privacy

Ziel dieser API ist es, ein Framework zu schaffen, das differenzielle private aggregierte Analyse. Dies kann erreicht werden, indem das zu den $ L1 $-Budget hinzu, wie z. B. Rauschen mit der folgenden Verteilung:

\[ Laplace(\frac{L1}{ε}) \]

Integration der Protected Audience API und der Attribution Reporting API

API-übergreifende Integration der Protected Audience API und der Attributionsberichte APIs ermöglichen AdTechs, ihre Attributionsleistung über verschiedene Remarketing-Taktiken anwenden, um zu verstehen, welche Zielgruppen den höchsten ROI.

Durch diese API-übergreifende Integration können AdTechs:

Schlüssel/Wert-Zuordnung mit URIs erstellen, die für beides verwendet werden sollen 1) Interaktionsberichte und 2) Quellenregistrierung
CustomAudience in die quellseitige Schlüsselzuordnung für die Aggregation aufnehmen zusammenfassende Berichte (über die Attribution Reporting API) erstellt.

Wenn ein Nutzer eine Anzeige sieht oder darauf klickt:

Die URL, über die diese Interaktionen mit Protected Audience erfasst werden, wird auch verwendet werden, um eine Ansicht oder einen Klick als zulässige Quelle mit dem Attribution Reporting API
Die Anzeigentechnologie kann CustomAudience (oder andere relevante kontextbezogene wie Anzeigen-Placement oder Wiedergabedauer angezeigt. URL so, dass diese Metadaten in zusammenfassenden Berichten weitergegeben werden können, wenn die Anzeigentechnologie die zusammengefasste Kampagnenleistung.

Weitere Informationen dazu, wie diese Funktion in Protected Audience aktiviert wird, finden Sie in der im entsprechenden Abschnitt der Erläuterung zur Protected Audience API.

Beispiele für Registrierungspriorität, Attribution und Berichterstellung

In diesem Beispiel werden Nutzerinteraktionen und die Definition von Anzeigentechnologie veranschaulicht. Attributionsquelle und Triggerprioritäten können sich auf zugeordnete Berichte auswirken. In In diesem Beispiel nehmen wir Folgendes an:

Alle Attributionsquellen und Trigger werden von derselben Anzeigentechnologie registriert, über denselben Werbetreibenden.
Alle Attributionsquellen und Trigger finden während des ersten Ereignisses statt (innerhalb von 2 Tagen nach der ersten Schaltung der Anzeigen in einem Publisher-App).

Stellen Sie sich den Fall vor, bei dem Nutzende Folgendes tun:

Der Nutzer sieht eine Anzeige. AdTech registriert eine Attributionsquelle bei der API, mit der Priorität 0 (Ansicht 1).
Der Nutzer sieht eine Anzeige mit der Priorität 0 (Ansicht 2).
Der Nutzer klickt auf eine Anzeige mit der Priorität 1 (Klick 1).
Der Nutzer führt in der App eines Werbetreibenden eine Conversion aus (erreicht die Landingpage). Die Anzeigentechnologie registriert einen Trigger mit der Priorität 0 (Conversion 1) bei der API.
- Wenn Trigger registriert werden, führt die API zuerst eine Attribution vor, bevor Erstellen von Berichten.
- Es sind drei Attributionsquellen verfügbar: Ansicht 1, Ansicht 2 und klicken Sie auf 1. Die API weist diesen Trigger an, auf „#1“ zu klicken, da es sich um mit der höchsten und der neuesten Priorität.
- Datenansicht 1 und Ansicht 2 werden verworfen und können nicht mehr verwendet werden. Namensnennung.
Der Nutzer legt in der App des Werbetreibenden einen Artikel in den Einkaufswagen. Priorität von 1 (Conversion 2).
- Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute diesen Trigger, um auf Nummer 1 zu klicken.
Der Nutzer legt in der App des Werbetreibenden einen Artikel in den Einkaufswagen. Priorität von 1 (Conversion 3).
- Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute diesen Trigger, um auf Nummer 1 zu klicken.
Der Nutzer legt in der App des Werbetreibenden einen Artikel in den Einkaufswagen. Priorität von 1 (Conversion 4).
- Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute diesen Trigger, um auf Nummer 1 zu klicken.
Der Nutzer tätigt einen Kauf in der Werbetreibenden-App und ist mit einer Priorität registriert von 2 (Conversion 5).
- Klick 1 ist die einzige zulässige Attributionsquelle. Die API-Attribute diesen Trigger, um auf Nummer 1 zu klicken.

Berichte auf Ereignisebene haben folgende Merkmale:

Standardmäßig werden die ersten drei Trigger, die einem Klick zugeordnet sind, und der erste Trigger die einer Datenansicht zugeordnet sind, nach den entsprechenden Berichtsfenstern.
Wenn im Berichtsfenster Trigger mit einer höheren Priorität haben, haben diese Vorrang und ersetzen den neuesten Trigger.
Im Beispiel oben erhält die Anzeigentechnologie drei Ereignisberichte nach dem 2-tägiges Berichtsfenster für Conversion 2, Conversion 3 und Conversion 5.
- Alle fünf Trigger werden Klick 1 zugeordnet. Standardmäßig würde die API Berichte für die ersten drei Trigger senden: Conversion 1, Conversion 2, und Conversion Nr. 3.
- Die Priorität von Conversion 4 (1) ist jedoch höher als die Priorität von Conversion 1. Priorität (0) Der Ereignisbericht von Conversion 4 ersetzt Conversion 1 Ereignisbericht gesendet.
- Außerdem ist die Priorität von Conversion 5 (2) höher als alle anderen auslösen. Der Ereignisbericht von Conversion 5 ersetzt den Bericht von Conversion 4 durch gesendet werden.

Aggregierte Berichte haben folgende Eigenschaften:

Verschlüsselte, aggregierte Berichte werden an die Anzeigentechnologie gesendet, sobald sie einige Stunden nach der Registrierung der Trigger verarbeitet wird.

Als AdTech-Unternehmen erstellen Sie Batches basierend auf den Informationen, in Ihren aggregierten Berichten nicht verschlüsselt. Diese Informationen sind in das Feld shared_info in Ihrem aggregierten Bericht und enthält den Zeitstempel und die Quelle der Berichte. Sie können keine Batches basierend auf verschlüsselten Informationen in Ihrer Aggregations-Schlüssel/Wert-Paare. Einige einfache Strategien, die Sie anwenden können, sind: die tägliche oder wöchentliche Batch-Verarbeitung von Berichten. Idealerweise sollten Batches mindestens Jeweils 100 Berichte.
Die Anzeigentechnologie, wann und wie die aggregierbaren Berichte erstellt und an den Aggregationsdienst gesendet.
Im Vergleich zu Berichten auf Ereignisebene können verschlüsselte aggregierte Berichte einer Quelle weitere Trigger zuordnen.
Im vorherigen Beispiel werden fünf aggregierte Berichte gesendet, jeweils einer. registrierter Trigger.

Übergangsberichte zur Fehlerbehebung

Die Attribution Reporting API ist eine neue und ziemlich komplexe Methode zur Attribution. ohne App-übergreifende Kennungen. Daher unterstützen wir eine Übergangsmechanismus, um weitere Informationen zu Zuordnungsberichten zu erhalten, wenn Sie Die Werbe-ID ist verfügbar (der Nutzer hat die Personalisierung nicht deaktiviert) mithilfe der Werbe-ID und der Publisher- oder Werbetreibenden-App hat die Anzeigen-ID deklariert Berechtigungen) Dadurch wird sichergestellt, dass die API während Einführung, das Beseitigen von Fehlern und einen einfacheren Vergleich der Leistung mit Alternativen zu Werbe-IDs. Es gibt zwei Arten von Debugging-Berichten: Attribution-Erfolg und ausführliche Übung.

Details zur Fehlerbehebung finden Sie im Leitfaden zu Transitional-Debugging-Berichten. die Analyse von App-zu-Web- und Web-zu-App-Analysen.

Berichte zur Fehlerbehebung bei erfolgreicher Attribution

Für Quell- und Triggerregistrierungen kann jeweils ein neues 64-Bit-Feld debug_key verwendet werden (als String formatiert), den die Anzeigentechnologie ausfüllt. source_debug_key und trigger_debug_key werden sowohl auf Ereignisebene als auch auf aggregierten Daten unverändert übergeben. Berichte.

Wenn ein Bericht sowohl mit dem Quell- als auch mit dem Trigger-Schlüssel zur Fehlerbehebung erstellt wird, wird ein Duplikat Debug-Bericht mit begrenzter Verzögerung an einen Endpunkt .well-known/attribution-reporting/debug/report-event-attribution. Die Debug-Berichte sind identisch mit normalen Berichten, einschließlich der beiden Felder für Debugging-Schlüssel. Wenn diese Schlüssel in beiden enthalten sind, können normale Berichte mit dem separaten Stream verknüpft werden. von Debugging-Berichten.

Berichte auf Ereignisebene: <ph type="x-smartling-placeholder">
- Doppelte Debugging-Berichte werden mit begrenzter Verzögerung gesendet und sind daher durch Limits für verfügbare Trigger unterdrückt, wodurch AdTech- um die Auswirkungen dieser Grenzwerte auf Berichte auf Ereignisebene zu verstehen.
- Berichte auf Ereignisebene, die mit falschen Trigger-Ereignissen verknüpft sind, enthalten trigger_debug_key Sek. So kann die Anzeigentechnologie besser nachvollziehen, in der API angewendet wird.
Für aggregierte Berichte: <ph type="x-smartling-placeholder">
- Es wird ein neues debug_cleartext_payload-Feld unterstützt, das Folgendes enthält: entschlüsselte Nutzlast, wenn sowohl source_debug_key als auch trigger_debug_key sind festgelegt.

Ausführliche Debugging-Berichte

Mit ausführlichen Debugging-Berichten können Entwickler bestimmte Fehler im Attributionsquelle oder lösen Registrierungen aus. Diese Debugging-Berichte werden mit begrenzter Verzögerung nach der Attributionsquelle oder lösen Registrierungen für eine .Endpunkt well-known/attribution-reporting/debug/verbose.

Jeder ausführliche Bericht enthält die folgenden Felder:

Typ: Der Grund für die Erstellung des Berichts. Hier finden Sie eine vollständige Liste ausführliche Berichtstypen.
- Im Allgemeinen werden ausführliche quellenbasierte Berichte generiert, die ausführlichere Berichte auslösen.
- Bei ausführlichen Quellenberichten muss die Werbe-ID für den Publisher-App und das Auslösen ausführlicher Berichte erfordert, dass die Werbe-ID für die App des Werbetreibenden zur Verfügung.
- Ausführliche Berichte auslösen (mit Ausnahme von trigger-no-matching-source) kann optional den source_debug_key enthalten. Dies kann nur angegeben werden, wenn die Werbe-ID auch für den Publisher-App.
Text: Der Textkörper des Berichts, abhängig vom Typ.

Anzeigentechnologie-Anbieter müssen dem Erhalt ausführlicher Debugging-Berichte mit einem neuen Wörterbuchfeld debug_reporting im Attribution-Reporting-Register_Source und Attribution-Reporting-Register-Trigger-Header.

Ausführliche Quellenberichte erfordern eine Aktivierung nur im Header der Quellenregistrierung.
Für Trigger-Fehlerbehebungsberichte ist nur eine Aktivierung im Trigger-Registrierungsheader erforderlich.

Fehlerbehebungsberichte verwenden

Wenn (laut Ihrem vorhandenen Messsystem) eine Conversion stattfand und ein für diese Conversion empfangen wurde, bedeutet das, dass der Trigger erfolgreich registriert.

Prüfen Sie für jeden Attributionsbericht zur Fehlerbehebung, ob Sie einen regulären Attributionsbericht, der den beiden Fehlerbehebungsschlüsseln entspricht.

Wenn keine Übereinstimmung gefunden wird, kann das verschiedene Gründe haben.

Funktioniert wie vorgesehen:

Datenschutzfreundliche API-Verhaltensweisen: <ph type="x-smartling-placeholder">
- Ein Nutzer erreicht die Ratenbegrenzung für den Bericht, was dazu führt, dass bei allen nachfolgenden Berichten keine innerhalb des Zeitraums gesendet werden; oder eine Quelle wird aufgrund der ausstehenden Ziellimit.
- Bei Berichten auf Ereignisebene: Der Bericht unterliegt einer zufälligen Antwort. (Rauschen) und unterdrückt wird. Eventuell erhalten Sie auch einen zufälligen Bericht.
- Für Berichte auf Ereignisebene: das Limit von drei (für Klicks) oder eins (für Aufrufe) erreicht wurde und nachfolgende Berichte keine expliziten Priorität festgelegt oder eine Priorität haben, die niedriger ist als die der vorhandenen Berichte.
- Die Beitragslimits für aggregierte Berichte wurden überschritten.
Von AdTech definierte Geschäftslogik: <ph type="x-smartling-placeholder">
- Trigger werden über Filter oder Prioritätsregeln herausgefiltert.
Zeitverzögerungen oder Interaktionen mit der Netzwerkverfügbarkeit (z.B. wenn der Nutzer ihr Gerät für einen längeren Zeitraum aus.

Unbeabsichtigte Ursachen:

Probleme bei der Implementierung: <ph type="x-smartling-placeholder">
- Der Quellheader ist falsch konfiguriert.
- Der Trigger-Header ist falsch konfiguriert.
- Sonstige Konfigurationsprobleme.
Geräte- oder Netzwerkprobleme: <ph type="x-smartling-placeholder">
- Ausfälle aufgrund von Netzwerkbedingungen.
- Die Quell- oder Trigger-Registrierungsantwort erreicht den Client nicht.
- API-Fehler.

Zukünftige Überlegungen und offene Fragen

Die Attribution Reporting API ist noch in der Entwicklung. Wir schauen uns auch die Zukunft potenzielle Funktionen wie Attributionsmodelle für vorbereitende Klicks (nicht letzte Klicks) und geräteübergreifende Anwendungsfälle für die Messung.

Außerdem bitten wir die Community um Feedback zu einigen Problemen:

Gibt es Anwendungsfälle, in denen Sie möchten, dass die API Berichte für die die Installation überprüft? Diese Berichte werden für Anzeigentechnologie-Plattformen die entsprechenden Ratenbegrenzungen.
Vorausgesetzt, ob bei der Übergabe der InputEvent aus der App Probleme auftreten zur Registrierung von Quellen?
Gibt es Anwendungsfälle für vorab geladene Apps oder Apps neu installiert?