Einführung in die Attributionsberichterstattung (Conversion-Messung)

Einführung und Schlüsselkonzepte zum Verständnis des Attribution Reporting APIs.

Published on Updated on

Translated to: Español, Português, 한국어, 中文, Pусский, 日本語, Français


Dieses API hat den Status eines Vorschlags und wird im Laufe der Zeit erweitert werden. Dieser Blogbeitrag beschreibt den aktuellen Stand und wird im Zuge der Entwicklung des API aktualisiert.

Aktualisierungen:

  • Anfang 2021: aggregierte Berichte und View-through-Messungen wurden dem Vorschlag hinzugefügt.
  • Anfang 2021: Das API wurde in „Attribution Reporting API“ umbenannt.
Caution
  • Dieser Beitrag konzentriert sich auf Werbeanwendungsfälle, aber das Attribution Reporting API kann auch Anwendungsmöglichkeiten außerhalb des Werbebereichs haben.
  • Die Werbeanwendungsmöglichkeiten für dieses API konzentrieren sich auf die Verknüpfung von Anzeigenklicks oder -aufrufen mit Conversions (Conversion-Messung).

Einführung

Mit dem Attribution Reporting API lässt sich messen, wann ein Klick oder die Ansicht einer Werbeanzeige zu einer Conversion auf der Website eines Werbetreibenden führt, z. B. zu einem Verkauf oder einer Registrierung. Das API setzt dabei nicht auf Drittanbieter-Cookies oder Mechanismen, die verwendet werden können, um einzelne Benutzer über verschiedene Websites hin zu identifizieren.

Dieser Vorschlag wird in einem offenen Verfahren entwickelt. Der Vorschlag und die zugehörigen Diskussionen sind im WICG GitHub-Repository zu finden.


Dieses API ist Teil der Privacy Sandbox, einer Reihe von Vorschlägen mit dem Ziel Anwendungsmöglichkeiten für Drittanbieter zu schaffen, ohne Drittanbieter-Cookies oder andere websiteübergreifende Tracking-Mechanismen zu nutzen. Siehe Privacy-Sandbox-Vorschläge.

Warum wird dieses API benötigt?

Heutzutage basiert die Messung von auf Anzeigen zurückzuführender Conversions häufig auf Drittanbieter-Cookies. Browser schränken den Zugriff auf Drittanbieter-Cookies ein, da diese verwendet werden können, um Benutzer über Websites hinweg zu verfolgen und die Privatsphäre der Benutzer beeinträchtigen. Dieses API ermöglicht diese Messungen auf datenschutzwahrende Weise ohne Drittanbieter-Cookies.

Wer sollte über dieses API Bescheid wissen?

  • Adtech-Plattformen wie nachfrageseitige Plattformen (DSP) oder Datenverwaltungsplattformen (DMP) können dieses API verwenden, um Funktionen zu unterstützen, die derzeit auf Drittanbieter-Cookies angewiesen sind.
  • Werbetreibende und Betreiber, die auf benutzerdefinierten Code für Werbung oder Conversion-Messung angewiesen sind, können dieses API verwenden, um bestehende Techniken zu ersetzen.
  • Werbetreibende und Betreiber, die sich für die Conversion-Messung auf Adtech-Plattformen verlassen, müssen das API zwar nicht direkt nutzen, haben aber möglicherweise Interesse daran es zu verstehen, wenn sie mit Adtech-Plattformen zusammenarbeiten, die diese API-Integration nutzen.

Debuggen Sie die API-Fehler mit den Chrome-Entwicklertools

Erhältlich ab Chrome 93. Fehler des Attribution Reporting APIs werden jetzt in den DevTools unter der Registerkarte „Issues“ gemeldet.

Attribution-Reporting-API-Fehler unter der Registerkarte „Probleme“

Beteiligen Sie sich


Ihre Teilnahme ist gefragt! Dieses API muss höchstwahrscheinlich Unterstützung für eine Vielzahl von Anwendungsmöglichkeiten zur Conversion-Messung und -optimierung bieten. Es ist entscheidend, dieses Ökosystem mit Ideen zu bereichern, um sicherzustellen, dass Lösungen zur Unterstützung aller dieser Anwendungsfälle offen diskutiert werden.

Beteiligen Sie sich an der Diskussion und testen Sie das API. Beides zu tun wäre optimal, aber Sie können sich gerne auch ohne eigener Erfahrung mit dem API an der Diskussion beteiligen.

Beteiligen Sie sich an der Diskussion

Probieren Sie das API aus

Caution

Wenn Sie mit dem API in Chrome experimentieren, haben Sie Zugriff auf alle derzeit implementierten Funktionen. Nicht alle im Repository und in der Sitzung besprochenen Funktionen sind in der Chrome-Origin-Trial implementiert. Informationen über den aktuellen Status einer Funktion finden Sie unter Status. Die für Experimente verfügbaren Funktionen sind eine Teilmenge dessen, was letztendlich von dem API unterstützt werden wird. Sie sind ständigen Änderungen unterworfen, während das API in diesem öffentlichen Verfahren entwickelt wird und Feedback aus dem Software-Ökosystem gesammelt wird.

Experimentieren Sie lokal oder mit einer Demo

  1. Um das API lokal in Ihrem Browser zu aktivieren, aktivieren Sie das Flag #enable-experimental-web-platform-features. Ein Chrome-Flag ist ein Schalter, der Ihrem Browser mitteilt, bestimmte experimentelle Funktionen zu aktivieren. Fügen Sie zur Aktivierung dieses Flags chrome://flags/#enable-experimental-web-platform-features in die Suchleiste von Chrome ein und klicken Sie auf Aktivieren.
  2. Führen Sie die Demo lokal aus (oder probieren Sie die Live-Demo aus).
  3. Erstellen Sie einen Fork des Democodes und passen Sie diesen an oder erstellen Sie von Grund auf Ihre eigene Demo.

Experimentieren Sie auf einer aufgesetzten Website mit Endbenutzern

  1. Aktivieren Sie das API für Endbenutzer, indem Sie sich für eine Origin-Trial registrieren, falls verfügbar. Eine Origin-Trial gibt Ihnen Zugriff auf eine experimentelle Funktion, um diese für eine begrenzte Zeit ausprobieren zu können. Beachten Sie, dass Drittanbieter-Origin-Trials es Dritten wie Werbeanbietern und Werbeanalysediensten ermöglichen, ein API über mehrere Websites zu testen. Um die derzeit verfügbaren Origin-Trials für dieses API anzuzeigen, navigieren Sie zu Status. Um über zukünftige Origin-Trials informiert zu werden, tragen Sie sich in die Attributionsberichterstellung-Mailingliste für Entwickler ein.

  2. Integrieren Sie das API in Ihre Websites und Systeme.


Wenn Sie Fragen zur Implementierung haben, tragen Sie sich in die Attributionsberichterstattung-Mailingliste für Entwickler ein und fragen Sie nach.

Wenn Sie allgemeine technische Fragen bezüglich Ihres Anwendungsfalls haben, sollten Sie eine Issue im Privacy-Sandbox-Entwicklersupport-Repository öffnen.

Demo

Es stehen Ihnen einige Demos zum Ausprobieren zur Verfügung.

Anwendungsfälle und Funktionen

Dieses API befindet sich in stetiger Weiterentwicklung und wird sich im Laufe der Zeit je nach Feedback und Einflüssen des Software-Ökosystems weiterentwickeln.

Alle von diesem API unterstützten Funktionen sind Vorschläge. Alle Vorschläge werden offen diskutiert und es kann Feedback für sie abgegeben werden, auch für diejenigen, für die schon eine erste Browserimplementierung vollzogen wurde.

Dieses API wird in einem offenen Verfahren entwickelt. Ziehe in Erwägung, dich an der Diskussion zu beteiligen.

Dieses API ermöglicht es Websites, Conversions in den folgenden Fällen zu messen:

  • Bei Anzeigenklicks und Anzeigenansichten.
  • Für Werbeanzeigen in einem **Drittanbieter-**iframe, z. B. bei Anzeigen eines Adtech-Drittanbieters auf einer Betreiberwebsite.
  • Für Anzeigen in einem Erstanbieter-Kontext, wie zum Beispiel Anzeigen in einem sozialen Netzwerk, auf der Ergebnisseite einer Suchmaschine oder aber von einem Betreiber selbst geschalteten Anzeigen.

Ein flexibles Attributionsmodell wird unterstützt. Siehe Details unter Status.

Dieses API ermöglicht den Zugang zu unterschiedlichen Erkenntnissen über zwei Typen von Berichten, die an einen Werbetreibenden oder einen Adtech-Drittanbieter gesendet werden können. Diese beiden Berichtstypen können gleichzeitig genutzt werden, da sie sich ergänzen.

Berichte auf Ereignisebene verknüpfen einen Anzeigenklick oder eine Anzeigenansicht mit groben Conversion-Daten.

Bericht auf Ereignisebene
Beispiel eines Berichts auf Ereignisebene: Klick-ID 200400600 auf news.example (angehängt an die Benutzer-ID „Bob_Doe“ auf news.example) hat zu einem Kauf auf shop.example geführt.

Berichte auf Ereignisebene eignen sich für:

  • Anwendungsfälle von Optimierung. Berichte auf Ereignisebene helfen bei der Beantwortung von Fragen wie „Wie kann ich meine Return on Investment verbessern?“. Sie können insbesondere zur Optimierung der Anzeigenplatzierung genutzt werden, da eindeutige IDs auf Anzeigenseite in den Berichten zur Verfügung gestellt werden können. Berichte auf Ereignisebene können Trainingsdaten für Machine-Learning-Modelle bereitstellen.
  • Anwendungsfälle grober Berichterstattung, bei denen nur sehr wenige Informationen über die Conversion benötigt werden. Die aktuelle Begrenzung für Klicks liegt bei Conversion-Daten mit 3 Bits – das heißt, einer Conversion kann eine von acht Kategorien zugeordnet werden. Für Anzeigenansichten liegt die Begrenzung bei 1 Bit. Die Kodierung detaillierter Conversion-Daten, wie z. B. eines bestimmten Kaufpreises oder einer Conversion-Zeit, wird daher in Berichten auf Ereignisebene nicht unterstützt.
  • Anwendungsfälle von Betrugserkennung. Die Daten in einigen Berichten können für die Erkennung und Analyse von Werbeanzeigenbetrug hilfreich sein, da Sie Muster erkennen, mit denen Spam oder ungültige Aktivitäten identifiziert werden können.

Aggregierte Berichte hingegen bieten detailliertere Conversion-Daten und mehr Flexibilität beim Zusammenführen von Klick-/Ansichtsdaten und Conversion-Daten.

aggregierter Bericht
Beispiel für Erkenntnisse aus aggregierten Berichten: Kampagne Nr. 1234567 auf news.example hat zu 518 Conversions auf shoes.example und zu Gesamtausgaben von 38174 $ geführt. Die Hälfte der Conversions stammte von Nutzern in NYC, USA.

Aggregierte Berichte eignen sich am besten für die Berichterstattung. Sie helfen bei der Beantwortung von Fragen wie „Wie hoch ist mein Return on Investment?“.
Die Nutzung aggregierter Berichte für Anwendungsfälle von Optimierung – beispielsweise zum Optimieren eines Einkaufswerts, die von Berichten auf Ereignisebene nicht unterstützt wird, weil die Conversion-Daten zu grob sind – ist ein Bereich aktiver Forschung. Siehe Offene Fragen.



Warum werden zwei Berichttypen benötigt?

Berichte auf Ereignisebene bieten nur grobe Conversion-Daten, um die Privatsphäre der Benutzer zu wahren.

Diese groben Daten reichen jedoch möglicherweise nicht aus, um die Effektivität von Kampagnen zu messen. Marketingspezialisten müssen möglicherweise weitere Details zu Conversions in Erfahrung bringen, z. B. den Einkaufswert, die vom Werbetreibenden aggregierten demografischen Daten konvertierter Benutzer, Kategorien gekaufter Produkte, Informationen zum Kundenstatus (Erstkunde oder wiederkehrender Kunde), Einkaufswageninhalte etc.

Aus diesem Grund wurden aggregierte Berichte entwickelt.

Andere in diesem API vorgeschlagene Funktionen sind App-to-Web-Attribution (Ansehen oder Klicken einer Anzeige in einer App und konvertieren im Web) und geräteübergreifende Attribution (Ansehen oder Klicken einer Anzeige auf einem Mobilgerät und konvertieren auf dem Desktop-Computer).


In einer Zukunft ohne Drittanbieter-Cookies würde dieses API mit anderen datenschutzwahrenden Werbe-APIs kombiniert werden, um Ende-zu-Ende-Anwendungsfälle abdecken zu können:

  • Remarketing: siehe FLEDGE
  • Interessenbasierte Anzeigenauswahl: siehe FLoC

Status

🕙 Letzte Aktualisierung: August 2021

Status:

  • 🤿 Wird ergründet: Diese Idee befindet sich in einer frühen Diskussionsphase.
  • 🥚 Vorschlag: Ein erster Entwurf ist fertig und wird in einem öffentlichen Verfahren weiterentwickelt.
  • 🏗️ In der Entwicklung (BROWSER_NAME): Die Funktion wird in BROWSER_NAME implementiert.
  • 🧪 Experiment (BROWSER_NAME): Ein Experiment ist in BROWSER_NAME verfügbar. In Chrome wird ein Experiment als Origin-Trial bezeichnet.
  • 🚀 Stable (BROWSER_NAME) : Die Funktion wird standardmäßig in BROWSER_NAME ausgeliefert.


Aktuelle Origin-Trial (Chrome-Experiment 🧪)

Caution


Es werden mehrere Origin-Trials (Experimente) durchgeführt. Jede Entwicklungsrunde wird verwendet, um das API basierend auf dem Feedback aus dem Software-Ökosystem zu verbessern und anzupassen.

VorschlagStatus
Berichte auf Ereignisebene für Klicks
Erläuterung
🧪 Experiment (Chrome)
Berichte auf Ereignisebene für Klicks
Erläuterung
🏗️ In Entwicklung (Chrome)
Aggregierte Berichte für Klicks und Ansichten
Erläuterungen
🥚 Vorschlag
Conversion Journey: geräteübergreifend
Erläuterung
🥚 Vorschlag
Conversion Journey: App-to-Web
Erläuterung
🥚 Vorschlag
Attributionsmodell: letzter Klick
Erläuterung
🧪 Experiment (Chrome)
Attributionsmodell: prioritätsbasiert
Erläuterung
🏗️ In Entwicklung (Chrome)
Attributionsmodell: flexibel🤿 Wird ergründet

Über Attributionsmodelle

Beim prioritätsbasierten Modell kann der Browser jeder Attributionsquelle eine Priorität zuordnen. Dies kann genutzt werden, um:

  • Zu entscheiden, ob ein Klick oder eine Ansicht die wahrscheinlichste Ursache für die Conversion war (ein Klick wird normalerweise als klareres Signal des Nutzerinteresses angesehen).
  • Ein First-Touch-Attributionsmodell festzulegen, indem Sie attributionsourcepriority relativ zur Zeit einstellen.
  • Legen Sie ein (pro­ba­bi­lis­tisches) lineares Attributionsmodell fest, indem Sie die Priorität einheitlich als zufällig einstellen.

In Zukunft könnten auch andere Attributionsmodelle unterstützt werden. In aggregierten Berichten würde das Worklet-basierte Schema möglicherweise flexiblere Attributionsoptionen ermöglichen (einschließlich der Angabe zur teilweisen Anerkennung mehrerer vorheriger Attributionsquellen).

Browser-Unterstützung

Obwohl sich die beiden APIs unterscheiden, arbeiten Chrome und WebKit in einem offen Verfahren zusammen, um die Entwicklungserfahrung zu vereinfachen, indem sie beispielsweise die Attributnamen und die JSON-Struktur von Berichten aneinander anpassen.



Unterschiede zwischen dem von Chrome vorgeschlagenen API und dem von WebKit vorgeschlagenen API


Der Funktionsumfang des von Chrome vorgeschlagenen Attribution Reporting APIs unterscheidet sich von dem des Private Click Measurement APIs von Safari/WebKit.
Besonders nennenswert ist, dass mit dem Attribution Reporting API von Chrome:

  • View-through-Messung unterstützt wird.
  • Berichte auf Ereignisebene bereitgestellt werden können.
  • Sowohl Werbelinks in einem Erstanbieterkontext (wie Anzeigen in einem sozialen Netzwerk, auf einer Suchergebnisseite, oder aber von einem Betreiber selbst geschaltete Anzeigen) als auch Werbelinks in einem Drittanbieter-iframe (wie Anzeigen auf einer Betreiberwebsite, die Dienste von Adtech-Drittanbietern nutzt) unterstützt werden.
  • Dritte wie Adtech-Plattformen Berichte im Namen von Betreibern und Werbetreibenden erhalten können.

Wie es funktioniert

Berichte auf Ereignisebene

Bericht auf Ereignisebene
Berichte auf Ereignisebene werden wie folgt erstellt: Der Browser gleicht Klicks oder Anzeigenansichten („Attributionsquellereignisse“) mit Conversion-Daten („Attributionsauslöserdaten“) ab, die von einem Adtech-Anbieter definiert wurden. Später sendet der Browser die resultierenden Berichte mit etwas Verzögerung und beigefügtem Rauschen an einen vordefinierten Endpunkt.



So funktioniert es im Detail: Berichte auf Ereignisebene


Werbelinks können mit Attributen konfiguriert werden, die spezifisch für auf Anzeigen zurückzuführende Conversions sind:

Hinweis: Es ist auch möglich, eine Attributionsquelle für Navigationsaktionen zu registrieren, die durch window.open() oder (Anzeigenansichten betreffend) über ein JavaScript-API initiiert werden.

Wenn der Nutzer auf eine speziell konfigurierte Anzeige klickt oder sie ansieht, protokolliert der Browser auf dem lokalen Gerät des Nutzers dieses Ereignis zusammen mit den angegebenen Attributionskonfigurationsdaten.

Später besucht der Benutzer die Website des Werbetreibenden und führt eine Aktion aus, die der Werbetreibende oder sein Adtech-Anbieter als Conversion einordnet, z. B. einen Kauf. In diesem Fall löst der Werbetreibende oder Adtech-Anbieter eine Attribution aus: Er fordert den Browser auf, eine Conversion mit einem bestimmten trigger-data-Wert zu protokollieren, woraufhin der Anzeigenklick (oder die Anzeigenansicht) sowie das Conversion-Ereignis vom Browser des Nutzers verknüpft werden.

Der Browser plant schließlich, dass ein Bericht an den auf der Anzeigenseite angegebenen Endpunkt gesendet wird. Dieser Bericht enthält:

Wenn für einen bestimmten Anzeigenklick (oder eine bestimmte Anzeigenansicht) mehrere Conversions registriert werden, wird eine entsprechende Anzahl von Berichten zum Versand vorbereitet. Für Aneigenansichten kann nur ein Bericht gesendet werden und für Klicks bis zu drei Berichte.

Berichte werden vom Browser mit Verzögerung gesendet. Dies kann manchmal Tage oder erst Wochen nach einer Conversion sein.

Aggregierte Berichte

ALT_TEXT_HERE
Aggregierte Berichte werden wie folgt generiert: Der Browser gleicht detaillierte Klicks oder Anzeigenansichten („Attributionsquellereignisse“) mit detaillierten Conversion-Daten („Attributionsauslöserdaten“) ab, die von einem Adtech-Unternehmen definiert wurden. Vom Adtech-Unternehmen bereitgestellter Code wird in einem Worklet ausgeführt, um Daten zu definieren, die vom Browser zum Berechnen aggregierter Berichte verwendet werden. Für die private Erstellung von aggregierten Berichten für die Adtech-Anbieter sind Aggregationsdienste verantwortlich.

So funktioniert es im Detail: aggregierte Berichte

Werbelinks können mit speziellen Attributen für auf Anzeigen zurückzuführende Conversions konfiguriert werden.

Wenn der Nutzer auf eine speziell konfigurierte Anzeige klickt oder sie ansieht, protokolliert der Browser auf dem lokalen Gerät des Nutzers dieses Ereignis zusammen mit den angegebenen Attributionskonfigurationsdaten.

Anschließend wird von Adtech-Unternehmen bereitgestellter Code innerhalb eines Worklets ausgeführt, um die bereitgestellten Informationen zu bestimmen, bei denen sich um eine Mischung von anzeigenseitigen und konvertierungsseitigen Daten handelt.

Diese Beiträge (Rohberichte) werden verschlüsselt an einen Adtech-Server gesendet und dann an Aggregationsdienste weitergegeben, die anschließend auf private Weise aggregierte Berichte berechnen.

Beachten Sie, dass aggregierte Berichte nicht im gleichen Ausmaß verzögert werden wie Berichte auf Ereignisebene.

Datenschutz

Überblick

Stellen wir uns eine Person namens Bob vor. Bob sieht während er die Nachrichten auf news.com liest eine Anzeige. Eine Woche später kauft Bob Schuhe auf shoes.example.

Heute würde diese Conversion von einem als Cross-Site-Identifier agierenden Drittanbieter-Cookie verfolgt werden. Mit Drittanbieter-Cookies kann ein Adtech-Unternehmen auf diverse Details zu Bobs Aktivitäten auf news.example und shoes.example zugreifen und diese Informationen zusammenführen, um ein detailliertes Profil von Bob zu erstellen. Ein Adtech-Unternehmen kann am Ende Bobs Standort, Surfgewohnheiten und Lieblingsinhalte auf news.comsowie Einkäufe, Aktivitäten und Kreditkarteninformationen auf shoes.com kennen. Diese websiteübergreifende Verknüpfung ist nützlich, um mit Werbung in Zusammenhang stehende Conversions zu messen. Es stellt jedoch einen Einschnitt in die Privatsphäre der Benutzer dar: Bobs Aktivitäten werden auf allen Websites mit einem hohen Detailgrad nachverfolgt.

Auf der anderen Seite ermöglicht das Attribution Reporting API es Werbeunternehmen jedoch, Einblicke in Konversionen zu gewinnen, ohne die Aktivitäten einer Person über Websites hinweg zu verfolgen. Eine kleine Menge an Informationen wird auf allen Websites zusammengeführt – genug, um Konversionen zu messen, aber nicht genug, um Bobs Aktivitäten über alle Sites hinweg im Detail zu verfolgen. Informationen zu Bobs Aktivitäten auf news.example und shoes.example bleiben voneinander getrennt.

Diagramm: Seite-an-Seite-Darstellung des heutigen Webs (verbundene Identität) und des zukünftigen Webs (partitionierte Identität)

Im Detail

ALT_TEXT_HERE
Im Gegensatz zu Drittanbieter-Cookies kann das Attribution Reporting API auch ohne der Nutzung von Cross-Site-Identifiern Erkenntnisse liefern, um die Identitätspartitionierung zwischen Websites zu bewahren.
Berichte auf Ereignisebene verknüpfen anzeigenseitige Kennungen lediglich mit einer kleinen Menge Conversion-seitiger Daten. Sie stellen also websiteübergreifende Informationen zu einer Conversion bereit, die Conversion-seitigen Informationen sind jedoch zu grob, um die Nutzeridentität über Websites hinweg verknüpfen zu können.
Aggregierte Berichte bieten detaillierte Einblicke, allerdings nur auf aggregierter Ebene. Dank Techniken der differentiellen Privatsphäre, privater Berechnungen und Kryptografie können aggregierte Berichte nicht genutzt werden, um die Aktivitäten eines einzelnen Benutzers über Websites hinweg zu verfolgen.
Sowohl für die Berichte auf Ereignisebene als auch für die aggregierten Berichte gelten zusätzliche Datenschutzmaßnahmen wie z. B. Ratenbeschränkungen.

Im Detail: Berichte auf Ereignisebene und Datenschutz

Berichte auf Ereignisebene bieten Einblicke in Conversions, ohne Benutzer dabei über Websites hinweg zu verfolgen, indem sie die folgenden Datenschutzmechanismen befolgen:

  • Es werden keine Cross-Site-Identifier verwendet und keine detaillierten Informationen zur Cross-Site-Browsing-Aktivität verlassen das Gerät. Berichte auf Ereignisebene verknüpfen 64-Bit-Informationen auf der Anzeigenseite (news.example) mit lediglich 1 oder 3 Bit auf der Conversion-Seite (shop.example). 64 Bit bieten genug Platz, um eine individuelle Benutzerkennung abbilden zu können, diese 64 Bit können jedoch lediglich mit einer geringen Anzahl an Cross-Site-Informationen verknüpft werden: nämlich 1 oder 3 Bit, die nicht ausreichen, um eine Kennung zu enthalten. Hinweis: Bei 64 Bit auf Anzeigenseite handelt es sich um keine Neuerung. Auf der Anzeigenseite kann bereits heute eine Benutzer-ID vorhanden sein. news.example oder adtech.example wissen bereits über die Aktivität eines bestimmten Benutzers auf news.example Bescheid.

  • Es werden zusätzliche Schutzmaßnahmen angewendet, um Missbrauch und Cross-Site-Tracking zu verhindern:

    • Die Berichte werden mit Verzögerung gesendet.
    • Die Conversion-Daten sind verrauscht: In einer bestimmten Anzahl der Fälle (5 % der Fälle in Chrome) werden die echten Conversion-Daten durch einen zufälligen Wert ersetzt.
    • Die Anzahl der zugeordneten Conversion-Berichte ist pro Klick oder Ansicht begrenzt.


Es ist möglich, die tatsächliche Conversion-Anzahl auf datenschutzfreundliche Weise wiederherzustellen. Siehe Beispielskript.

Im Detail: aggregierte Berichte und Datenschutz

Aggregierte Berichte verknüpfen ein detailliertes Klick- oder Ansichtereignis mit detaillierten Conversion-Daten. Diese Einblicke in Conversions können sie allerdings erhalten, ohne Benutzer über Websites hinweg zu verfolgen, indem sie die folgenden Datenschutzmechanismen nutzen:

  • Es werden keine Cross-Site-Identifier verwendet.

  • Jede Attribution kann mehrere Beiträge zu einem resultierenden aggregierten Bericht leisten und ein bestimmter Nutzer kann mehrere Attributionen für einen bestimmten Klick (oder eine bestimmte Anzeigenansicht) und eine bestimmte Conversion auslösen. Die Beiträge, die jeder Benutzer in einem bestimmten Zeitfenster leisten kann, sind jedoch begrenzt.

  • Die Daten werden auf eine Ebene vieler Ereignisse (viele Benutzer) aggregiert und es können keine einzelnen Ereignisse genau beobachtet werden. Differentielle Privatsphäre wird hergestellt, um zu verhindern, dass mit den Ausgabedaten die Benutzeridentität über Websites hinweg verknüpft werden kann, denn beim Analysieren der aggregierten Daten nimmt mit zunehmender Detailstufe auch das relative Rauschen dieser Daten zu. Dies führt zu einem größeren relativen Fehler und stellt sicher, dass keine einzelnen Ereignisse (oder Benutzer) genau beobachtet werden können. Außerdem sind Datenausschnitte, die viele Ereignisse und Benutzer zusammenfassen, genauer, und bewahren die Nützlichkeit.

  • Die Rohberichte, die ein detailliertes Klick- oder Ansichtsereignis mit detaillierten Conversion-Daten verknüpfen, sind verschlüsselt und können vom Adtech-Unternehmen nicht gelesen werden. Über einen vertrauenswürdigen Server werden aus diesen Berichten dann auf private Weise aggregierte Daten berechnet. Es werden verschiedene Berechnungsmöglichkeiten für diese Aufgabe in Betracht gezogen:

    • Sichere Mehrparteienberechnung (MPC). Vertrauen wird auf mehrere Server verteilt. Jeder Server erhält ein Stück der Daten, das für sich allein genommen bedeutungslos ist. Nachdem jeder Helfer seine Berechnungen durchgeführt hat, werden die von diesem Helfer ausgegebenen Daten zu einem sinnvollen Ganzen kombiniert.
    • Einzelserver-Berechnung. Ein Hilfsserver berechnet die Ausgabedaten. Diese Option ist weniger sicher und weniger privat. Sie ist jedoch einfacher zu realisieren, was bedeutet, dass es mehr verschiedenen Akteuren des Software-Ökosystems ermöglichen kann, mit diesem API zu experimentieren und Feedback zu geben. Diese Option ist nicht als langfristige Lösung gedacht. Sie wird mit ausreichender Vorankündigung und Migrationszeit zugunsten sicherer Alternativen wie MPC oder sicherer Einzelserver ausgemustert, sobald das Feedback der Entwicklergemeinschaft berücksichtigt und integriert wurde und dieses API reif genug ist.
    • Sichere Einzelserver-Berechnung. Ein einzelner Server, der jedoch vertrauliche Berechnungseigenschaften bietet, die MPC ähnlich (aber nicht gleichwertig) sind.
    • Langfristig sollten Server Daten ausschließlich unter Nutzung sicherer Mehrparteienberechnung verarbeiten (sicherer Einzelserver oder sicherer Mehrparteienbetrieb).
  • Es werden zusätzliche Schutzmaßnahmen angewendet, um Missbrauch und Cross-Site-Tracking zu verhindern:

    • Berichte werden mit zufällig gewählten Verzögerungen gesendet.
    • Die Datenrate für Anfragen zu verschiedenen Datenausschnitten ist begrenzt.

Sites und Benutzerkontrolle

Offene Fragen

Eine Reihe von Fragen sind weiterhin offen und werden in dem transparenten Entwicklungsverfahren des APIs angegangen. Sie werden ermutigt, an diesen Diskussionen teilzunehmen. Insbesondere zu den Fragestellungen:


Dieses API kombiniert mehrere Datenschutztechniken, um Datenschutz und Nützlichkeit zu bieten. Dies bedeutet, dass die Datenbeschränkung von 3 Bit (bzw. 1 Bit für Ansichten) und andere von dem API verwendete Datenschutzmechanismen, beabsichtigt und ein Mittel zum Zweck sind. Sie sind regelmäßigen Änderungen unterworfen. Sobald sich für Adtech-Unternehmen neue Möglichkeiten aufzeigen, nützlichere Daten für ihre Anwendungsfälle zu erhalten und gleichzeitig starke Datenschutzgarantien erreichen zu können, wird sich dieses API entsprechend weiterentwickeln.

Last updated: Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.