Häufig gestellte Fragen zur Relevanz und Messung der Privacy Sandbox

Antworten auf häufig gestellte Fragen zu Relevance and Measurement APIs der Privacy Sandbox.

Was unterscheidet die Topics API von den Seller Defined Audiences (SDA)?

Topics und SDA bieten ergänzende Arten von Informationen und haben beide die Kontrolle des Publishers. Wir glauben nicht, dass sie miteinander in Konkurrenz stehen. Stattdessen arbeiten beide parallel oder in unterschiedlichen Kontexten, um die Kaufmöglichkeiten zu maximieren. Käufer berücksichtigen bei der programmatischen Bewertung von Impressionen viele Signale. Dazu gehören auch Topics. Verkäufer haben in der Vergangenheit keine Zielgruppensegmente in offenen Marktplatzauktionen berücksichtigt. Wahrscheinlich werden hier Topics genutzt. Stattdessen bieten Verkäufer ihre Zielgruppen in Deals mit Werbetreibenden, Agenturen oder DSPs für programmatische Käufe an. In diesen Fällen führen der Verkäufer und der Käufer absichtlich Transaktionen im Rahmen der SDA aus. Wenn in diesen Fällen Topics verwendet werden, kann es für eines oder mehrere der folgenden Elemente sein:

• Der Verkäufer ergänzt seine Zielgruppendefinition mit der Topics API.
• Der Käufer nutzt Topics als Signal dafür, wie viel er bieten soll.
• Der Käufer verwendet Topics, um zu prüfen, ob die SDA korrekt ist

Übernimmt Google die Kontrolle über die Zielgruppenerstellung?

Nein. Websites können weiterhin ihre eigenen Zielgruppen innerhalb und außerhalb der Privacy Sandbox aufbauen. Wenn Websites Zielgruppen innerhalb der Privacy Sandbox erstellen, bestimmt der Websiteinhaber oder der ausgewählte Proxy, wer die Zielgruppen erstellen kann, was diese sind, wie diese Zielgruppen aktualisiert werden, wie auf diese Zielgruppen geboten wird und ob Nutzer aus einer Zielgruppe entfernt werden.

Unterstützt Protected Audience von Publishern erstellte Interessengruppen?

Ja. Wir wissen, dass Publisher ihre Zielgruppen aus Angst vor Datenlecks scheuen, ihre Zielgruppen heute in OpenRTB-basierte Auktionen einzubeziehen. Publisher können heute Zielgruppen in Protected Audience erstellen, die dem Bieter keine websiteübergreifende Übersicht über den jeweiligen Publisher-Nutzer geben. Wir freuen uns darauf, weiterhin nach Möglichkeiten zu suchen, wie Publisher von der verringerten Umgebung von Datenlecks von Protected Audience profitieren können.

Wie werden die Regeln für die Anzeigenqualität in Protected Audience-Auktionen erzwungen?

Es gibt mehrere Möglichkeiten, Regeln für die Anzeigenqualität in Protected Audience-Auktionen zu erzwingen. Jedes dieser Schritte ähnelt der derzeitigen Durchsetzung der Regeln für die Anzeigenqualität durch SSPs. Eine Möglichkeit besteht darin, das Creative durch eine Auktion mit einem unbekannten Creative auslösen zu lassen, damit es zum Scannen in eine Warteschlange gestellt wird. Wir haben das Feedback erhalten, dass SSPs eine bessere Unterstützung für diesen Anwendungsfall wünschen, und entwickeln einen Mechanismus, mit dem ein Feed mit renderUrls erstellt werden kann, den die SSP Out-of-Band prüfen und dann Informationen in ihrem Schlüssel/Wert-Server speichern kann. Eine weitere Möglichkeit ist eine Vorregistrierung. Wie im vorherigen Fall können die Ergebnisse nach dem Scannen des Creatives an den Schlüssel/Wert-Server gebunden werden. Wenn dann ein Käufer ein Gebot für dieses Creative abgibt (wie durch eine Creative-ID angegeben, die wahrscheinlich demselben Format wie OpenRTB entspricht), kann die Bewertungslogik des Verkäufers eine Suche auf dem Schlüssel/Wert-Server durchführen und entscheidet, wie die Bewertung entsprechend bewertet wird.

Unterstützt Protected Audience Videoanzeigen?

Ja. VAST-URLs können an Protected Audience und aus dieser weitergegeben werden. Wenn eine VAST-URL ausgegeben wird, kann der Vertriebsmitarbeiter koordinieren, wie die VAST-URL des Käufers umschlossen wird, bevor sie an den Player gesendet wird. Vor der Anforderung, spätestens im Jahr 2026 auf Fenced Frames umzustellen und den Datenschutz für Nutzer weiter zu stärken, gehen wir davon aus, dass wir Designdiskussionen entwickeln werden, die sicherlich auch Videos umfassen werden.

Unterstützt Protected Audience native Anzeigen?

Ja. JSON-URLs können an Protected Audience und aus dieser weitergegeben werden. Wenn eine JSON-URL ausgegeben wird, kann die Sell-Side-Technologie koordinieren, wie die gewünschten Ereignisse hinzugefügt werden, bevor die endgültige JSON-Datei an den Rendering-Code übergeben wird. Vor der Anforderung, bis spätestens 2026 auf Fenced Frames umzustellen, um den Datenschutz für Nutzer weiter zu stärken, gehen wir davon aus, dass wir Designdiskussionen entwickeln werden, die wahrscheinlich native Designs umfassen werden.

Hemmt das Rendern von Protected Audience-Anzeigen Innovationen?

Nein. Das Anzeigen-Rendering hing schon immer von Browsertechnologien ab. Daran ändert sich nichts. Vielleicht ist dieses Problem spezifisch für Pläne, in Zukunft die Verwendung von Fenced Frames in Verbindung mit Protected Audience erforderlich zu machen. Diese Pläne sind unter anderem deshalb „in Zukunft“, weil wir die Fenced Frames-Technologie möchten, um Innovationen und Differenzierung beim Anzeigen-Rendering zu unterstützen. Interessierten Entwicklern und Unternehmen bleibt es Zeit, sich über die Entwicklung von Fenced Frames zu äußern. Dazu gehört auch, wie die Ansätze für native Anzeigen unterstützt werden können.

Ermöglicht Protected Audience eine ausgefeilte Taktung und Gebotsbewertung, die heutzutage bei herkömmlichen Auktionen eingesetzt werden?

Protected Audience bietet Käufern eine Echtzeitoption, mit der sie sich einen Überblick über das Kampagnentempo und die Budgets verschaffen können. Aus Sicht des Inventars kann der Verkäufer dem Käufer Auktionssignale über den Kontext der Seite und alles andere zur Verfügung stellen. Wenn ein Verkäufer eine kontextbezogene Gebotsanfrage senden möchte, kann der Käufer über diesen Mechanismus ebenfalls mehr über das Inventar erfahren und sich selbst kontextbezogene Signale zur Verfügung stellen (über perBuyerSignals), die für seine Protected Audience-Gebote verwendet werden können. Die ersten Nutzer verknüpfen bereits Systeme für maschinelles Lernen mit Protected Audience. Uns ist bewusst, dass es einige Zeit dauern wird, diese Systeme auf Gebote in Protected Audience-Umgebungen abzustimmen. Beachten Sie jedoch, dass eine Abstimmung möglich ist und bereits durchgeführt wird.

Funktioniert der OpenRTB-Standard auch bei Protected Audience?

Ja. Diese Arbeit wird vom IAB Tech Lab in Zusammenarbeit mit einer gut besuchten Gruppe repräsentativer DSPs und SSPs durchgeführt. Offenbar werden wir in Zukunft Teile des OpenRTB-Protokolls als Kommunikationsstandard in Protected Audience-Auktionen verwenden, und wir wissen, dass die ersten Nutzer das OpenRTB-Protokoll bereits so entwickeln.

Müssen Unternehmen für Protected Audience zwei separate Architekturen für die Anzeigenbereitstellung unterhalten?

Nein. Für Protected Audience sind keine zwei separaten Architekturen erforderlich. Ihre Architekturentscheidungen entscheiden sich für Sie. So hat sich die Onlinewerbung im Laufe der Jahre weiterentwickelt und damit auch die Komplexität der Systeme, auf denen sie basiert. Wenn der Datenschutz für Nutzer erhöht wird, wird dies komplexer und erfordert mehr Arbeit. Unternehmen im Bereich Anzeigentechnologie können zwei separate Architekturen verwenden oder Protected Audience in eine kombinierte Architektur mit herkömmlichen Auktionen einbinden.

Was passiert mit herkömmlichen Auktionen, wenn noch mehr Unternehmen im Bereich Anzeigentechnologie Protected Audience unterstützen?

Wir gehen davon aus, dass kontextbezogene Auktionen aus vielen Gründen relevant bleiben, z. B. für Deals, Kampagnen, die nicht auf Zielgruppen mit selbst erhobenen Daten ausgerichtet sind, und viele andere kontextbezogene Szenarien. Sie sind auch dann wertvoll, wenn keine Interessengruppen vorhanden sind oder die Gebote in Protected Audience die Mindestpreise nicht erreichen oder die Anzeigenqualitätsregeln nicht einhalten.

Wird die Protected Audience-Auktion den Bemühungen zur Optimierung des Supply Path (SPO) des Systems entgegenwirken, um die Gesamtzahl der Mittler zwischen einem Werbetreibenden und einem Publisher und/oder die Duplizierung einer bestimmten Opportunity zu reduzieren?

Nein. Eine erfolgreiche Anzeige in Protected Audience durchläuft höchstens zwei Verkäuferentitäten (z. B. eine Supply Side Platform (SSP) und einen Publisher-Ad-Server) und nur wenige, wenn der Käufer eine direkte Integration mit dem Publisher herstellt.

Die Entscheidung des Publishers für die Vervielfältigung desselben Antrags über mehrere Vermittler bleibt die Entscheidung des Publishers. Die Protected Audience API sollte sich nicht auf die eine oder die andere Art und Weise auswirken.

Protected Audience-Auktionen finden außerhalb des heutigen Server-zu-Server-Echtzeitsystems statt, damit keine websiteübergreifenden Nutzerdaten offengelegt werden. Manche behaupten möglicherweise, dass dies eine Anzeigenanfrage dupliziert. Ein technisch nachweisbarer Datenschutz erfordert einige Kompromisse. Langfristig kann es jedoch vorkommen, dass Protected Audience verwendet wird, ohne auf herkömmliche serverseitige Auktionen zu verzichten. Dies könnte zu noch besser optimierten Quellpfaden führen.

Reduziert Protected Audience den Wert der vorhandenen Infrastruktur zur Anpassung an den Traffic?

Bei Abfragen pro Sekunde ändert sich also, dass viele SSPs websiteübergreifende IDs verwenden, um zu ermitteln, ob eine DSP eine Anfrage senden soll. Eine Reduzierung der websiteübergreifenden IDs wirkt sich daher auf vorhandene Techniken zur Anpassung der Zugriffe aus. Dies gilt unabhängig davon, ob der Publisher eine Protected Audience-Auktion durchführen möchte oder nicht.

Wir haben Trafficmuster mit vielen SSPs untersucht und Lösungen wie Caching und kontextbasierter Filterung gefunden. Wir gehen davon aus, dass Entwickler im Laufe der Zeit die private Aggregation nutzen werden, um die DSP-Gebotseinstellungen besser zu verstehen und entsprechend zu filtern.

Letztendlich wird eine Legacy-Infrastruktur, die auf websiteübergreifenden Kennungen basiert, nicht mehr nützlich sein.

Belasten neue Anfragen, die aus einer Protected Audience-Auktion resultieren, die Kapazität der SSP?

Einige SSPs haben uns mitgeteilt, dass die Kapazität aus Integrationsperspektive kein Problem und kein wichtiger Bestandteil eines Nutzenversprechens für SSPs ist. Den SSPs, die neue Aufrufe im Auktionsprozess befürchten, kennen wir Unternehmen, die SSPs bereits bei Kapazitätsproblemen helfen und diese Dienste erweitern, um Protected Audience zu unterstützen. Teilen Sie uns mit, wenn wir Sie an eines dieser Unternehmen weiterleiten sollen.

Welche Priorität hat die Protected Audience API, wenn konkurrierende Ressourcen im Browser vorhanden sind?

Protected Audience folgt allgemein dem Standardmodell der Erstellung von Steuerelementen, mit denen Verkäufer entscheiden können, wie viel Zeit und Ressourcen Bieter benötigen, und Tools entwickeln, mit denen Käufer entscheiden können, wie sie die ihnen zur Verfügung stehenden Ressourcen am besten einsetzen. Diese Kontrollmechanismen und Tools sind bereits verfügbar, aber ihr Vorteil wird sich erst nach der Einführung durch Käufer und Verkäufer realisieren. Darüber hinaus arbeitet Chrome kontinuierlich an einer Reihe von Infrastrukturverbesserungen im Hinblick auf die Auktionsgeschwindigkeit, z. B. crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339 und crrev.com/119.

Wie geht Protected Audience bei Latenzproblemen um?

In der Vergangenheit, vor Protected Audience, wurden Verkäufer bei Echtzeitgeboten auf Servern strenge Zeitlimits für die Antworten der Käufer festgelegt, um die Latenz unter Kontrolle zu halten. Wir haben der Protected Audience API eine Reihe von sehr ähnlichen Steuerelementen für die Zeitüberschreitung hinzugefügt (siehe Dokumentation für perBuyerCumulativeTimeouts, perBuyerTimeouts und sellerTimeout), um dasselbe Ziel zu erreichen, die Latenz unter Kontrolle zu halten. Mit diesen Einstellungen werden Auktionsteilnehmer außerdem dazu ermuntert, ihre Logik zu optimieren, damit die Ressourcen so effizient wie möglich genutzt werden, um das AdTech-Ökosystem zu unterstützen und eine hohe Nutzerfreundlichkeit zu bieten.

Außerdem arbeitet Chrome kontinuierlich an einer Reihe von Infrastrukturverbesserungen im Hinblick auf die Auktionsgeschwindigkeit, z.B. crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339 und crrev.com/1197323. Wir bitten Sie um Feedback zu diesen beiden Aspekten dieser Latenz: zu zusätzlichen Tools, die für Käufer und Verkäufer nützlich sein könnten, und Berichte zu beobachteten Engpässen, die Chrome-Entwickler untersuchen sollten.

Ist die Erstellung von Protected Audience auf dem Gerät ein verschwendeter Aufwand, wenn Bidding und Auktionsdienste (B&A) bereits vorhanden sind?

Nein. „On-Device“ ist für AdTech-Anwendungsfälle ausreichend. Gebots- und Auktionsdienste sind eine optionale Lösung mit horizontaler Skalierung, wenn AdTech-Unternehmen mehr in Rechenressourcen für Gebote investieren möchten, als der Browser zulässt. Die On-Device-Entwicklung ist eine gute Investition, da die meisten Arbeiten wiederverwendet werden könnten, selbst wenn Entwickler sich später für eine Gebots- und Auktionsdienstumgebung entscheiden. Der Großteil der erstellten Pipes und der erstellten Infrastruktur würde weiterhin ähnlich funktionieren.

Werden Unternehmen aufgrund der Anforderungen an cloudbasierte vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEE) für Protected Audience zur Nutzung von Google Cloud motiviert?

Die APIs der Privacy Sandbox bieten zuverlässige Datenschutz- und Sicherheitsfunktionen. Wir haben keine Designentscheidungen getroffen, die Google Cloud zugutekommen sollten. Unsere Unterstützung für Cloud-Anbieter begann mit AWS, weil wir wissen, wie viele AdTech-Anbieter sich für Amazon entscheiden. Wir gehen davon aus, dass wir in Zukunft neben AWS und Google Cloud auch andere Cloud-Anbieter unterstützen werden, und wir sind offen für Vorschläge für andere Cloud-Anbieter. Wenn Latenz ein Problem ist, bieten Cloud Kunden Standortoptionen, mit denen die Entfernungen zu anderen Cloud-Anbietern verkürzt werden.

Können vertrauenswürdige Ausführungsumgebungen (TEEs) mit der Privacy Sandbox auch in nicht öffentlichen Cloud-Rechenzentren ausgeführt werden?

Überprüfbare vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEEs) sind Teil unseres Datenschutz- und Sicherheitsmodells. Aufgrund strenger Sicherheitsmaßnahmen begannen wir mit TEEs, die von Anbietern öffentlicher Clouds angeboten werden. Zur Klarstellung: Die einzigen APIs, für die in naher Zukunft die Verwendung von vertrauenswürdigen Ausführungsumgebungen erforderlich ist, sind die Attribution Reporting API und die Private Aggregation API. Außerdem wird bei keiner der APIs in Echtzeit in einer Auktionseinstellung das TEE aufgerufen. Wir suchen weiterhin nach Optionen, die über öffentliche cloudbasierte Lösungen hinausgehen.

Wird es nicht teurer, vertrauenswürdige Ausführungsumgebung in öffentlichen Clouds auszuführen, als lokale AdTech-Rechenzentren?

Unser aktuelles TEE-Datenschutzmodell profitiert von den Sicherheitspraktiken von öffentlichen Cloud-Implementierungen. Wir stellen die Annahme infrage, dass es kostengünstiger ist, eine vertrauenswürdige Ausführungsumgebung lokal zu betreiben. Im Folgenden finden Sie einige Kostenüberlegungen für diese Praktiken:

Anbieter öffentlicher Clouds müssen sehr hohe Sicherheitsstandards haben. AWS ist beispielsweise ein seriöser Cloud-Anbieter mit etablierten Sicherheitspraktiken. AWS Nitro verfügt insbesondere über ein dokumentiertes Sicherheitsmodell, mit dem sichergestellt wird, dass Nitro Enclaves Operatoren daran hindern, auf Daten zuzugreifen, die in der Enklave verarbeitet werden. Geschützte Ressourcen (z. B. Entschlüsselungsschlüssel) sind nur für autorisierten Code verfügbar, der in der Enclave ausgeführt wird. Der physische Zugang zu berücksichtigen ist auch. AWS hat Maßnahmen zur Minderung von physischen Zugriffsrisiken entwickelt und implementiert, auch von Amazon-Mitarbeitern. Bestehende hardwarebasierte TEEs schützen sich möglicherweise nicht vor allen physischen Angriffen, für die öffentliche Clouds ausgelegt sind. Darüber hinaus hat Amazon kürzlich die NCC Group, ein unabhängiges Forschungsunternehmen, beauftragt, seine Nitro-Designs zu überprüfen, deren Schwerpunkt auf Sicherheitsanforderungen in Bezug auf den Zugriff durch interne Mitarbeiter liegt. Aus dem öffentlichen Bericht geht hervor, dass die AWS-Designs ihren Ansprüchen entsprechen.

Die Implementierung, Unterstützung und Verbesserung dieser Praktiken kosten Geld. Bei global verteilten und weit verfügbaren öffentlichen Clouds verteilen sich diese Kosten auf eine breite Kundenbasis.

Ändert die Privacy Sandbox die Abrechnung?

Nein. Anzeigentechnologie-Unternehmen und andere API-Aufrufer können weiterhin sehen, ob und zu welchem Preis etwas auf einer Seite gerendert wird.

Ist Frequency Capping in der Privacy Sandbox möglich?

Protected Audience unterstützt über das Objekt prevWinsMs websiteübergreifendes Frequency Capping innerhalb derselben Interessengruppe. Mit der Funktion generateBid() eines Käufers in der Protected Audience-Auktion kann eine Logik erstellt werden, mit der die Gebotsstrategie anhand des Ergebnisses früherer Anzeigenpräsenzen für denselben Browser angepasst werden kann.

Es gibt einige Lösungen, die für das Frequency Capping außerhalb von Protected Audience verwendet werden können. Diese stimmen jedoch nicht vollständig mit den websiteübergreifenden Verfahren von Anzeigentechnologien in Verbindung mit Drittanbieter-Cookies überein.

• Eigene Cookies: Anzeigentechnologie-Anbieter können ihre eigenen Daten für das Frequency Capping auf der eigenen Website verwenden.
• CHIPs: Anzeigentechnologie-Anbieter können Frequency Capping auf Website-Ebene mithilfe eines partitionierten Cookies verwalten.
• Gemeinsam genutzter Speicher SelectURL(): Nachdem ein Anzeigentechnologie-Anbieter eine Auktion gewonnen hat und bevor er das Creative rendert, kann er den freigegebenen Speicher aufrufen, um auf websiteübergreifende Daten zuzugreifen und das richtige Creative basierend auf der Häufigkeit über das Ausgabe-Gatter zum Auswählen der URL auszuwählen.

Ein datenschutzorientiertes Frequency Capping ohne Protected Audience, das einen sinnvollen Nutzen für die Anzeigentechnologie bietet, ist aus folgenden Gründen schwierig:

• Aufgrund des Feedbacks von AdTech konnte derzeit nicht festgestellt werden, ob ein Frequenzsignal Rauschen toleriert.
• Wir haben immer wieder das Feedback erhalten, dass während der Auktion ein websiteübergreifendes Frequenzsignal verfügbar sein muss. Daher müssen nicht verrauschte websiteübergreifende Signale für die Verwendung in jeder Anzeigenauktion verfügbar sein. Dadurch könnten viele Informationen über die Aktivitäten eines Nutzers auf Websites offengelegt werden, was die Datenschutzziele der Privacy Sandbox untergraben.
• Wir achten empfindlich auf Latenzzeiten. Eine geräteinterne Lösung, die dieses Signal bereitstellt, könnte zu Latenz führen und die Auktionsumgebung stören.
• Eine Lösung müsste wahrscheinlich eine neue API sein, die den W3C-Vorschlagsprozess durchlaufen muss.

Daher steht die Entwicklung einer Frequency Capping-Lösung außerhalb der Protected Audience API nicht in unserer unmittelbaren Roadmap. Wir sind jedoch offen für Feedback zu möglichen Möglichkeiten zur Lösung dieses Anwendungsfalls.

Was ist mit Anwendungsfällen, die nicht von der Privacy Sandbox abgedeckt sind?

Privacy Sandbox APIs bieten wichtige Bausteine für datenschutzfreundliche Werbung, bei denen Entwickler flexibel entscheiden können, wie sie zusammengestellt werden. Mit dem Baustein-Ansatz können Unternehmen innovativ sein und Lösungen entwickeln, die ihren Kunden einen Mehrwert bieten. Die Privacy Sandbox soll nicht als End-to-End-Lösung für alle Anwendungsfälle dienen. Wir glauben, dass das ein schlechtes Ergebnis wäre. Stattdessen setzen Entwickler und Unternehmen ihre Ideen mithilfe einer Vielzahl von Technologien ein, darunter Privacy Sandbox APIs, die sie in ihre Lösungen einbinden.