Datenschutz-Sandbox für das Web: Die sich ändernde Datenschutzlandschaft und Auswirkungen auf Ihre Websites

Chrome wird im Laufe des Jahres 2023 im Rahmen der Privacy Sandbox-Initiative Änderungen am Datenschutz vornehmen und gleichzeitig neue Technologien entwickeln, um Benutzerinformationen privat zu halten. Gleichzeitig ändern Web-Publisher und Marken ihre digitale Strategie, um Werbeeinnahmen und wertvolle Marketinganalysen zu erhalten, die auf Cookies von Drittanbietern beruhen.

Dieser Vorstoß in Richtung erweiterter Browser-Privatsphäre führt zu einer höheren Nachfrage nach Personalisierung von Websites.

In dieser Sitzung geht Google Developer Advocate Sam Dutton durch die bevorstehenden Änderungen, teilt die Ziele der Datenschutz-Sandbox-Initiative und hilft Ihnen dabei, besser zu verstehen, wie Sie umschwenken können, um sicherzustellen, dass Sie über die Daten verfügen, die Sie zum Erhalt Ihres Unternehmens und Ihrer Websites benötigen vorwärts bewegen.

Sitzungsfolien:

Transkript:

SAM DUTTON: Hallo, ich bin Sam Dutton. Ich bin Developer Advocate beim Chrome-Team hier in London. Vielen Dank, dass Sie sich mir heute angeschlossen haben. Also drei Dinge, die ich in den nächsten 25 Minuten tun werde. Ich gebe Ihnen einen Überblick über die Datenschutz-Sandbox-APIs. Ich erkläre Ihnen, was Sie jetzt tun müssen, und ich zeige Ihnen, wie Sie Tester werden, an Diskussionen über die APIs teilnehmen und Feedback geben können.

Lassen Sie mich also zunächst erklären, warum wir die Privacy Sandbox brauchen. Viele von Ihnen werden die Hintergrundgeschichte nur allzu gut kennen, aber es lohnt sich, schnell zu wiederholen, warum wir das brauchen und wie wir dahin gekommen sind, wo wir heute sind. Die Privacy Sandbox ist also eine Initiative zum Aufbau einer Reihe von APIs zum Schutz der Privatsphäre, um Geschäftsmodelle zu unterstützen, die das offene Web für eine Zukunft ohne Tracking-Mechanismen wie Cookies von Drittanbietern finanzieren.

Vielleicht haben Sie dieses Beispiel von Google I/O gesehen. Es ist eine typische Site mit Komponenten aus verschiedenen Quellen. Und natürlich ist die Zusammensetzbarkeit eine der Superkräfte des Webs. Sie haben eine Karte von einem Ursprung, ein Drehbuch von einem anderen und so weiter und natürlich Werbung, und ob es uns gefällt oder nicht und was auch immer die Zukunft bringt, Werbung ist zu einer entscheidenden Einnahmequelle und einem Treiber für das Geschäft auf der ganzen Welt geworden Netz.

An diesem Punkt in der Geschichte denke ich, dass Browser und CMS Werbeanwendungsfälle unterstützen müssen. Also, was ist das Problem? Nun, Anzeigenauswahl, Conversion-Messung, Betrugserkennung, Geräteanpassung und viele andere Anwendungsfälle haben sich auf die Cross-Site-Identität verlassen, indem Mechanismen verwendet wurden, die einfach nicht im Hinblick auf den Datenschutz entwickelt wurden.

Jetzt werden nicht nur Cookies von Drittanbietern, sondern Fingerabdrücke verwendet, um das Benutzerverhalten über Websites hinweg zu verfolgen, oder Websites fordern persönliche Informationen wie E-Mail-Adressen an, und außerdem sind Ökosysteme von Drittanbietern sehr komplex, insbesondere für Werbung. Nicht einmal Entwickler, Werbetreibende oder Publisher verstehen die Lieferkette für Dienste von Drittanbietern.

Wenn ich also eine Website besuche, bin ich mir sicherlich nicht aller beteiligten Dritten bewusst und was sie mit meinen Daten machen, und das bin nicht nur ich, Untersuchungen zeigen, dass es den Menschen wirklich wichtig ist, die Kontrolle über ihre Daten zu behalten. Datenschutzbedenken beeinflussen zunehmend die Entscheidungen darüber, was Menschen online tun, und Aufsichtsbehörden auf der ganzen Welt verschärfen die Datenschutzanforderungen, und dies geschieht sehr schnell.

Angesichts der Tatsache, wie viele Unternehmen auf effektive Online-Werbung angewiesen sind und wie viele Publisher auf Werbung angewiesen sind, um ihre Websites zu monetarisieren, und einer ganzen Reihe anderer Anwendungsfälle, ist dies ein Problem für das gesamte Web-Ökosystem und nicht nur für Technologieunternehmen und Werbeplattformen. Aber natürlich, weil das Web eine offene Plattform ist, brauchen Änderungsvorschläge Zustimmung und Feedback, und Browser wie Chrome können und wollen nicht einseitig handeln.

Browser sind keine Produkte, für die Browserhersteller isoliert Entscheidungen treffen können, und die Realität ist, dass das Web nicht für viele der Anforderungen konzipiert wurde, die heute für die Erkennung von Werbebetrug, das Identitätsmanagement und all diese anderen Anforderungen und Anwendungsfälle für die Plattform von zentraler Bedeutung sind bald. Was wir also brauchen, sind speziell entwickelte Technologien für dieses datenschutzorientierte Web, und hier kommt die Datenschutz-Sandbox ins Spiel.

Daher hat Chrome mit der Web-Community zusammen mit Branchenvertretern und Regulierungsbehörden zusammengearbeitet, um neue Technologien zum Schutz der Privatsphäre zu entwickeln, die ein gesundes, nachhaltiges Ökosystem unterstützen können. Sobald diese neuen, speziell entwickelten APIs verfügbar sind, müssen wir sicherstellen, dass Unternehmen Zeit haben, sie einzuführen, damit wir die Unterstützung für Cookies von Drittanbietern in Chrome sicher auslaufen lassen und unsere Arbeit fortsetzen können, um andere Arten von Tracking zu entschärfen.

Nun, das Kernprinzip dieser Initiative ist das potenzielle Datenschutzmodell für das Internet, das von Datenschutzexperten und Informatikern bei Google entwickelt wurde. Dieses Datenschutzmodell legt eine Reihe von Grundregeln für die Entwicklung von Technologien fest, die den Anwendungsfällen von Webplattformen entsprechen, über die ich gesprochen habe, und gleichzeitig unsere sich ändernden Datenschutzanforderungen einhalten.

Insbesondere behandelt der Vorschlag die schwierige Frage, wie man standortübergreifende Verbindungen ermöglichen kann, ohne die Privatsphäre zu gefährden. Nun, eine der wichtigsten Neuerungen der Privacy Sandbox APIs besteht darin, dem Browser zu ermöglichen, im Namen des Benutzers zu handeln, in gewissem Sinne zurück zu der Kernrolle des Browsers als dem, was wir Benutzeragenten nennen.

Mit aktuellen Technologien werden Daten von Dritten gesammelt, aggregiert und weitergegeben, um das Surfen von Benutzern auf Websites zu verfolgen. Datenschutz-Sandbox-APIs können ermöglichen, dass die Konversionsmessung von Anzeigenauktionen und diese anderen Aufgaben vom Browser des Benutzers auf dem Gerät des Benutzers ausgeführt werden.

Wir müssen also Anzeigenplattformen und das Web in Zusammenarbeit zwischen Browseranbietern, Plattformen, Werbetreibenden, Publishern, Adtech, Benutzern, Aufsichtsbehörden und der Datenschutzgemeinschaft und nicht zuletzt Entwicklern wie Ihnen, die mit CMS-Plattformen arbeiten, neu aufbauen.

In Anbetracht dessen möchte ich Ihnen nur eine kurze Tour durch die Privacy Sandbox-APIs selbst geben. Bei Google ist dies also eine gemeinsame Initiative für das Web und Android. Privacy Sandbox auf Android konzentriert sich auf die Einführung neuer, privaterer Werbelösungen ohne App-übergreifende Kennungen.

Das Web und Android haben natürlich die gleichen Prinzipien und einige der Webvorschläge werden auch für Android entwickelt. Allerdings basieren die Web- und Android-Mobilplattformen natürlich auf grundlegend unterschiedlichen Technologien.

Dies ist also eine eigenständige Initiative für Android, aber diejenigen unter Ihnen, die sowohl Android-Apps erstellen als auch im Internet arbeiten, sollten dies im Auge behalten. Daher hat Google die neuen APIs in Zusammenarbeit mit einer Reihe von Partnern weltweit getestet.

Hunderte von Unternehmen nehmen an öffentlichen Foren teil, sei es das W3C, sie erklären die Probleme auf GitHub und so weiter, veröffentlichen Perspektiven und Analysen und nehmen an runden Tischen der Branche teil, teilen Feedback mit Chrome und Android und nehmen natürlich an Tests teil.

Täuschen Sie sich jetzt nicht, Privacy Sandbox hat eine Menge Anforderungen zu erfüllen, und es wird auf dem Weg dahin schwierig werden. Ich meine, ich denke, die gute Nachricht ist, dass es am Ende von all dem Plattformen geben wird, die sicherer und privater für Benutzer und besser für Werbetreibende, Publisher, Entwickler und natürlich für Plattformen wie WordPress sind.

Daher werde ich nicht alle Datenschutz-Sandbox-APIs beschreiben. Stattdessen möchte ich mich auf die drei wichtigsten Werbe-APIs in der Datenschutz-Sandbox konzentrieren. Das sind Themen, FLEDGE und Attributionsberichte. Unsere Topics und FLEDGE sind als Relevanz-APIs bekannt.

Now Topics bietet hochrangige Signale für das Interesse eines Benutzers auf der Grundlage seines jüngsten Browserverlaufs. Und Themen können mit Kontextsignalen und Erstanbieterdaten kombiniert werden, um relevante Anzeigen auszuwählen.

Und FLEDGE unterstützt granularere Anwendungsfälle für Remarketing und benutzerdefinierte Zielgruppen, bei denen Vermarkter Zielgruppen erreichen möchten, die Interesse an bestimmten Websites oder Produkten gezeigt haben, aber natürlich, um dies unter Wahrung der Privatsphäre zu ermöglichen.

Zu guter Letzt ist Attribution Reporting der Vorschlag von Chrome für die Messung von Kampagnen zum Schutz der Privatsphäre, der anonymisierte Leistungsberichte bereitstellt und anzeigt, wann Personen eine Anzeige ansehen oder darauf klicken und dann später einen Kauf oder eine andere Art von Conversion abschließen.

Diese APIs haben also eine Testphase in Android und in Chrome auf Desktops und Mobilgeräten durchlaufen. Wenn Sie mit Ad-Tech-Plattformen arbeiten, müssen Sie sicherstellen, dass Sie diese Plattformpläne verstehen, um diese Anwendungsfälle und die Anwendungsfälle zu adressieren, die von diesen APIs für diese Zukunft ohne Cookies von Drittanbietern oder andere Tracking-Mechanismen erfüllt werden.

Jetzt hatten wir also eine Zeit technischer Tests mit den APIs, die mithilfe von Chrome-Flags aktiviert wurden, und jetzt in der Origin-Testversion zunächst nur für einen kleinen Prozentsatz der Chrome-Benutzer aktiviert. Jetzt befinden wir uns also in dieser Phase des Utility-Tests. 50 % der Entwickler- und Beta-Nutzer von Chrome Canary haben die Test-APIs für Anzeigenursprung auf Seiten aktiviert, die ein gültiges Token bereitstellen, und 5 % der stabilen Nutzer.

Das ist natürlich ein kleiner Prozentsatz des gesamten Chrome-Verkehrs, aber es reicht aus, um die APIs in begrenztem Umfang mit echten Benutzern zu testen. Und wir bewegen uns jetzt auf den Start in Chrome Stable zu, wo die APIs standardmäßig für alle Benutzer verfügbar sein werden, und ich werde später auf die Zeitpläne dafür zurückkommen.

Um es noch einmal zu wiederholen: Für einen einzelnen Benutzer können Sie die APIs mithilfe von Chrome-Flags aktivieren, aber zum Testen in großem Maßstab müssen Sie an der Privacy Sandbox Origin Trial teilnehmen, und ich werde später Links mit Anleitungen teilen, wie das alles geht .

Übrigens aktualisiert Chrome auch die Datenschutzeinstellungen der Benutzer, wie die Benutzeroberfläche, und die Datenschutz-Sandbox-Steuerelemente sind tatsächlich als Teil der Origin-Testversion der Anzeigen-APIs verfügbar. Die Benutzer können die mit ihrem Surfen verbundenen Interessen sehen und verwalten oder die APIs vollständig deaktivieren.

Es gibt also tatsächlich drei weitere Datenschutz-Sandbox-Technologien, die Sie meiner Meinung nach ebenfalls testen oder auf jeden Fall einem Ihrer Drittanbieter melden möchten. Erstens CHIPS. Das sind Cookies mit unabhängigem Partitionsstatus, die es Entwicklern ermöglichen, ein Cookie für die partitionierte Speicherung mit einer separaten Cookie-Jar pro Top-Level-Site zu aktivieren.

Erstanbieter-Sätze ermöglichen es verwandten Domänennamen, die derselben Entität gehören und von derselben betrieben werden, sich als zu derselben Erstpartei gehörend zu erklären, und Privatstatus-Tokens. Sie haben vielleicht von diesem anfänglichen Namen als Trust Tokens gehört. Dies ist eine API, um eine begrenzte Menge an Informationen von einem Browsing-Kontext zu einem anderen zu übertragen, beispielsweise über Websites hinweg, um Betrug zu bekämpfen, aber ohne passive Tracking-Techniken zu verwenden.

Lassen Sie uns zunächst einen genaueren Blick auf die Topics-API werfen. Die Themen-API bietet einen Mechanismus, um interessenbezogene Werbung zu aktivieren, ohne jedoch Dritten zu ermöglichen, die Surfaktivitäten der Benutzer zu verfolgen. Die API besteht also gewissermaßen aus drei Hauptkomponenten, und zunächst einmal benötigt interessenbasierte Werbung eine Taxonomie von Themen von Interesse.

Die Topics-API-Taxonomie sieht folgendermaßen aus. Es handelt sich um eine öffentlich gepflegte, für Menschen lesbare Themenliste, die sensible Themen vermeidet. Und jetzt wird sich dies wahrscheinlich im Laufe der Zeit in Absprache mit dem Web-Ökosystem ändern und weiterentwickeln, und das bedeutet, dass Leute wie Sie, wir brauchen Ihr Feedback dazu sowie zu allem anderen.

Die Topics-API muss also Interessen für einen Benutzer basierend auf seiner Browsing-Aktivität ableiten, aber wie gesagt, um dies auf eine Weise zu tun, die seine Privatsphäre schützt. So werden die Top-Interessensthemen für einen Benutzer in seinem Browser auf seinem Gerät auf der Grundlage seiner letzten Browsing-Aktivitäten erneut von seinem Browser auf seinem Gerät aufgezeichnet.

Derzeit tut Topics dies, indem es maschinelles Lernen verwendet, um die Hostnamen von Seiten, die der Benutzer besucht, auf Topics aus der Taxonomie abzubilden. Wie bei der Topics-Taxonomie selbst wird sich dieser Ansatz im Laufe der Zeit weiterentwickeln. Aber das Ableiten von Interessen aus der Browsing-Aktivität muss das richtige Gleichgewicht finden.

Wenn Sie zu viele Details über das Surfen von Benutzern haben, ist das schlecht für die Privatsphäre, aber zu wenig Granularität bedeutet, dass die API nicht nützlich ist. Ich denke, in gewisser Weise ist es hier wichtig zu verstehen, dass Themen von Interesse nur ein Signal sind, um zu finden, was für Benutzer relevant ist.

Sobald also vom Browser für einen Benutzer interessante Themen abgeleitet wurden, muss Topics API-Aufrufern Zugriff auf die interessanten Themen gewähren, die sie für den Benutzer beobachtet haben.

Wenn der Benutzer also durch das Web navigiert, gibt es zwei Stufen der API. Ein API-Aufrufer, beispielsweise eine Adtech-Plattform, ruft die API auf einer Seite auf, um zu signalisieren, dass er Themen für die aktuelle Seite und den aktuellen Benutzer beobachten möchte.

Jetzt später kann der API-Aufrufer auf die Themen zugreifen, die er für den Benutzer beobachtet hat. All dies muss nun geschehen, ohne dass mehr über die Browsing-Aktivität des Benutzers preisgegeben wird als die beobachteten Interessensgebiete.

Die Themen-API bietet also zwei Möglichkeiten, für einen Benutzer interessante Themen zu beobachten und dann Zugriff auf die beobachteten Themen zu erhalten, zuerst mit einer JavaScript-API oder durch Verwendung der Anforderungs- und Antwort-Header einer Abrufanforderung.

Die erste Möglichkeit, wie ein Topics-API-Aufrufer dem Browser signalisieren kann, dass er Themen für einen Benutzer beobachtet hat, besteht darin, document.browsingTopics von einem Iframe aufzurufen, das in Websites eingebettet ist, die der Benutzer besucht.

Jetzt kann der API-Aufrufer später dieselbe document.browsingTopics-Methode aufrufen, um auf Themen zuzugreifen, die er für den aktuellen Benutzer beobachtet hat. Und der Grund, warum diese Methode übrigens einen Iframe benötigt, ist, dass der Kontext für das Beobachten von Topics derselbe sein muss wie der Kontext für den Zugriff auf Topics.

Die andere Möglichkeit, Themen zu beobachten und darauf zuzugreifen, ist die Verwendung von Fetch-, Request- und Response-Headern. Zuerst muss der API-Aufrufer eine Abrufanforderung an eine URL an seinem Ursprung stellen, einschließlich des wahren Objekts zum Durchsuchen von Themen im Optionsparameter.

Und wenn die Antwort auf die Abrufanforderung einen Observe-Browsing-Topics ?1-Header enthält, signalisiert das dem Browser, dass der Aufrufer möchte, dass der Browser aufzeichnet, dass der Aufrufer die für den aktuellen Benutzer interessanten Themen für den aktuellen beobachtet hat Buchseite. Ich hoffe das ergibt Sinn.

Jetzt können für einen Benutzer beobachtete Themen aus der Abrufanforderung eines Anrufers abgerufen werden, indem auf den Anforderungsheader sec-browsing-topics zugegriffen wird. Hier ist also der gesamte Prozess von Anfang bis Ende. Ich bin mir der Zeit bewusst, also werde ich es jetzt nicht durchgehen, aber wir werden dies später teilen, damit Sie sehen können, wie das funktioniert, den gesamten Prozess und wir werden das für jede der APIs haben.

Und Sie können die Topics-Demo ausprobieren, die die JavaScript-Iframe-Methode verwendet, um Themen zu beobachten und darauf zuzugreifen, oder Sie können unsere Demo ausprobieren, die den Ansatz zum Abrufen von Anforderungsheadern verwendet. chrome://topics-internals zeigt Themen für den aktuellen Benutzer, für Hostnamen vergebene Themen und technische Informationen über die API-Implementierung an.

Sie können auch das Co-Labor für Themen ausführen, um die Themeninferenz mithilfe des Topics-Klassifikatormodells zu testen. Nun drei wichtige offene Fragen an Sie, bevor ich Topics verlasse: Wie können wir besser auf interessante Themen für einen Benutzer basierend auf seiner Browsing-Aktivität schließen? Wie können wir den Inhalt und die Struktur der Taxonomie verbessern, um sie nützlicher zu machen und gleichzeitig die Privatsphäre der Benutzer zu wahren? Und wie können wir die Gesamtarchitektur der API verbessern?

Ich denke, eine Sache, die man hier im Auge behalten sollte, ist, ob wir Themen oder etwas anderes haben, wir müssen immer noch die Anwendungsfälle erfüllen. Als nächstes FLEDGE. Dies ist also eine API für Anzeigenoptionen auf dem Gerät, um Anwendungsfälle für Remarketing und benutzerdefinierte Zielgruppen bereitzustellen, ohne dass ein standortübergreifendes Drittanbieter-Tracking erforderlich ist.

Ich denke, das ist ein bisschen mehr Code-Detail mit FLEDGE, weil es eine kompliziertere Aufgabe zu erledigen hat als Topics. Der FLEDGE-Prozess besteht also aus drei Teilen. Zunächst fügt der Anzeigenkäufer Nutzer bzw. einzelne Browser wirklich zu sogenannten Interessengruppen hinzu. Diese sind wie benutzerdefinierte Zielgruppen, aber die Mitgliedschaft in Interessengruppen wird im Browser auf dem Gerät des Benutzers gespeichert.

Wenn nun ein Benutzer eine Website besucht, auf der Anzeigen angezeigt werden, wie z. B. eine Publisher-Website, kann ein Anzeigenverkäufer eine Anzeigenauktion initiieren, um eine Anzeige für ihn auszuwählen, und mit FLEDGE kann diese Auktion auf dem Gerät des Benutzers ausgeführt werden.

Um eine Anzeige auszuwählen, führt der Auktionscode die Gebotslogik der Käufer und die Auktionslogik des Verkäufers aus. Und schließlich sendet der Browser Auktionsberichte an Endpunkte, die von den Verkäufern und Käufern bereitgestellt werden.

Also gehe ich FLEDGE ganz kurz Schritt für Schritt durch. Stellen Sie sich zunächst vor, ein Benutzer besucht ein Online-Schuhgeschäft und stöbert ein wenig. Eine Adtech-Plattform oder vielleicht ein Werbetreibender selbst macht einen JavaScript-Aufruf, um den Browser anzuweisen, einer Interessengruppe beizutreten. Und diese Gruppe könnte so etwas wie Trailrunning-Schuhe heißen.

Das Konfigurationsobjekt für eine Interessengruppe könnte so aussehen. In diesem Beispiel hat der Anzeigentechniker des Schuhgeschäfts möglicherweise eine Interessengruppe für Remarketing, zu der er den Nutzer hinzufügen möchte, und er hat diese Gruppe gut „Trail Running Shoes“ genannt. Und die Adtech-Plattform des Schuhgeschäfts ruft Join Ad Interest Group auf, um den Browser des Benutzers aufzufordern, seiner Interessengruppe Trailrunning-Schuhe beizutreten, indem er die Konfiguration verwendet, die ich Ihnen gerade gezeigt habe.

Und der zweite Parameter gibt die Dauer der Interessengruppe an, die auf 30 Tage begrenzt ist. Jetzt besucht der Benutzer eine Website, die Anzeigen veröffentlicht. In diesem Beispiel eine Nachrichten-Website. Eine Auktion zur Auswahl einer Anzeige, die dem Benutzer angezeigt werden soll, wird in JavaScript auf dem Gerät des Benutzers durch den Verkäufer unter Verwendung von Run Ad Auction ausgeführt, und der Verkäufer ist wahrscheinlich eine Ad-Tech-Plattform, aber möglicherweise der Herausgeber selbst, in diesem Fall die Nachrichtenseite.

Nun wählt diese Auktion die am besten geeigneten Anzeigengebote für jede der Interessengruppen aus, zu denen der Browser des Benutzers gehört, zusammen mit anderen Faktoren des Verkäufers und des Browsers selbst.

Wenn Sie sich nun den Code ansehen, erstellt der Publisher oder eine Plattform, die Werbeflächen auf der Publisher-Website verkauft, Konfigurationsdaten für die Anzeigenauktion. Der Verkäufer fordert dann den Browser auf, eine Anzeigenauktion durchzuführen, um eine Anzeige im Browser auszuwählen, und der von der Ausführung der Anzeigenauktion zurückgegebene Wert wird an ein Element namens „Fenced Frame“ übergeben, damit die Website die Gewinneranzeige anzeigen kann.

Jetzt kann ein eingezäunter Rahmen verwendet werden, um eine Anzeige anzuzeigen, aber er kann nicht mit der Seite um ihn herum interagieren. Und dann haben der Verkäufer und der siegreiche Käufer jeweils die Möglichkeit, eine Protokollierung und Berichterstellung durchzuführen, und das geschieht durch Aufrufen von navigator.reportresult.

Wenn alles gut geht, tippt oder klickt der Nutzer schließlich auf die Anzeige, und jetzt übernimmt die Attribution Reporting API. Und wieder haben wir ein Diagramm, das den gesamten Prozess von Anfang bis Ende zeigt, das wir Ihnen nach der Keynote mitteilen werden.

Abschließend möchte ich Ihnen etwas über die Datenschutz-Sandbox-API für die Anzeigenmessung erzählen, bei der es sich um Attributionsberichte handelt. Attributionsberichte werden verwendet, um zu messen, wann ein Anzeigenklick oder eine Anzeigenimpression zu einer Conversion führt. Zum Beispiel, wenn der Aufruf einer Anzeige auf einer Nachrichtenseite zu einem Kauf in einem Online-Schuhgeschäft führt.

Wie bei Topics und FLEDGE wurde diese API entwickelt, um Cross-Site-Tracking zu vermeiden. Die API ermöglicht also zwei Arten von Messergebnissen, Berichte auf Ereignisebene und zusammenfassende Berichte. Lassen Sie mich kurz beschreiben, wie das funktioniert.

Werfen wir zunächst einen Blick auf die Berichte auf Ereignisebene. So können Anzeigenlinks mit Attributen konfiguriert werden, die für die Attribution Reporting API spezifisch sind, und dies ermöglicht es, Aufrufe und Klicks mit einer Anfrage auf der Conversion-Seite zu zählen.

Wenn ein Benutzer nun auf eine Anzeige klickt oder eine Anzeige sieht und dann konvertiert, generiert der Browser einen Bericht, und in diesem Bericht enthält das Werbeunternehmen oder der Anzeigentechniker zwei Datenelemente. Erstens alle Daten, die sie über den Anzeigenklick oder die Impression haben möchten, und dies kann sehr detailliert sein, z. B. eine Creative-ID, Informationen über den Publisher, den Zeitstempel und so weiter. Und zweitens ein kleines Stück Daten über die Anzeigenkonvertierung.

Nun, um die Privatsphäre der Benutzer zu schützen, kann dies nicht zu detailliert sein. Später sendet der Browser diesen Bericht über – Nun, diesen Bericht mit den Daten, die ich gerade dem Anzeigentechniker oder dem Werbetreibenden erklärt habe, und der eine Verzögerung enthält, um ein Benutzer-Tracking zu vermeiden.

Der Bericht enthält zwei Datenelemente, detaillierte Daten über den Anzeigenklick oder die Impression, das Ereignis und allgemeine Daten über die Konversion. Dies ist also ein Bericht auf Ereignisebene. Werfen wir nun einen Blick auf zusammenfassende Berichte.

Jetzt ist die Browser-API zum Generieren eines zusammenfassenden Berichts ähnlich, aber die Ergebnisse und der Mechanismus sind etwas anders. Wenn also ein Benutzer auf eine Anzeige klickt oder eine Anzeige sieht und dann später konvertiert, generiert der Browser einen Bericht, und in diesem Bericht kann das Werbeunternehmen oder der Anzeigentechniker alle gewünschten Daten über den Anzeigenklick oder die Impression und alle Daten, die er möchte, aufnehmen über die Anzeigenkonvertierung möchten, aber dieser Bericht ist verschlüsselt.

Und dies ist ein Datenschutz, da dieser Bericht detaillierte Daten über die Conversion und die Impression enthält. Der Bericht könnte also für das Cross-Site-Tracking verwendet werden, wenn er nicht verschlüsselt wäre. Später sendet der Browser diesen verschlüsselten Bericht mit einer kleinen Verzögerung erneut.

Und auf diese Weise sammelt eine Adtech-Plattform viele Berichte von vielen Benutzern und sendet dann alle Berichte an einen so genannten Aggregationsdienst, und dieser Dienst sammelt alle diese Berichte, entschlüsselt sie, fügt etwas Rauschen hinzu, um die Privatsphäre der Benutzer zu schützen, und dann das Endergebnis zurückgeben und das Endergebnis wird als zusammenfassender Bericht bezeichnet. Es enthält Messdaten für viele Benutzer.

Das ist also Attributionsmessung. Ich hoffe das ergibt Sinn. Ich verlinke auf viele weitere Ressourcen, damit Sie die Datenschutz-Sandbox-APIs genauer verstehen und testen können. Aber eine letzte Sache möchte ich erwähnen, Privacy Sandcastle.

Dies ist eine Demo, die alle wichtigen Datenschutz-Sandbox-APIs kombiniert. Es wurde von unserem Team in Tokio gebaut. Es ist noch sehr neu. Aber Sie können den Code von GitHub abrufen und lokal ausführen, und er soll Ihnen helfen zu verstehen, wie all diese APIs zusammenpassen.

Bevor ich zum Schluss komme, möchte ich noch einmal kurz zusammenfassen und mir die Zeitachse für Privacy Sandbox ansehen. Wie Sie sehen können, nähern wir uns dem Quartal, in dem wir mit der Auslieferung der APIs beginnen, was bedeutet, dass sie standardmäßig in Chrome Stable verfügbar und für Tests im Produktionsmaßstab bereit sind. Das ist nur eine kurze Zeit im Kalender, und ich kann mich selbst sehen. Ich bin hier kurz vor der Zeit.

Also ein paar Dinge, die Sie meiner Meinung nach jetzt tun müssen. Verstehen Sie zunächst die Zeitleisten für Web und Android. Stellen Sie sicher, dass Sie und Ihre Drittanbieter auf die jetzt bevorstehenden Änderungen vorbereitet sind. Zweitens: Prüfen Sie Ihre Websites, um zu verstehen, wo sie auf Cookies von Drittanbietern und andere veraltete Mechanismen angewiesen sind. Wir werden heute nach der Veranstaltung Links zu Tools und Anleitungen dafür teilen.

Fragen Sie als Nächstes Ihre Drittanbieter wie Adtech-Plattformen usw., wie sie sich darauf vorbereiten, ihre Kernanwendungsfälle ohne Cookies von Drittanbietern oder andere Cross-Site-Tracking-Mechanismen zu erfüllen, und testen Sie schließlich die Datenschutz-Sandbox-APIs und geben Sie Feedback und bitten Sie Ihre Drittanbieter, dasselbe zu tun.

Und wenn es ihnen nicht gut geht, fragen Sie sie, warum nicht, und teilen Sie uns die Antwort auf diese Frage mit. So bietet privacysandbox.com Zeitleisten, FAQs und weitere Informationen zu plattformübergreifenden Bemühungen. Ich werde die URLs nach diesem Ereignis weitergeben, aber viele der Inhalte, auf die ich hier verwiesen habe, finden Sie im Abschnitt „Datenschutz-Sandbox“ auf developer.chrome.com.

Hier finden Sie insbesondere Ressourcen, die erklären, wie Sie Fragen an uns stellen und Feedback geben können, und Sie können mehr über Origin-Testversionen auf developer.chrome.com erfahren. Wir haben auch eine Reihe von kurzen Videos und Artikeln erstellt, um Chrome-Konzepte wie Origin-Tests, Chrome-Flags, Blink-Inhalte und all diese Dinge zu erklären.

Also danke fürs Zuhören. Das ist es von mir. Wie ich schon sagte, wenn Sie Unterstützung benötigen, gehen Sie bitte zu diesen Ressourcen oder senden Sie mir einfach eine direkte Nachricht an SW12 auf Twitter. Vielen Dank.