Feedbackbericht – Q1 2024

Vierteljährlicher Bericht für das 1. Quartal 2024 mit einer Zusammenfassung des Feedbacks zu den Privacy Sandbox-Vorschlägen und der Reaktion von Chrome.

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat Google zugestimmt, vierteljährlich Berichte über den Prozess der Einbeziehung der Stakeholder für seine Privacy Sandbox-Vorschläge zur Verfügung zu stellen (siehe Paragraf 12 und 17(c)(ii) der Zusicherungen). Diese zusammenfassenden Feedbackberichte zur Privacy Sandbox werden durch das Sammeln von Feedback generiert, das Chrome von den verschiedenen in der Feedbackübersicht aufgeführten Quellen erhalten hat. Dazu gehören unter anderem GitHub-Probleme, das Feedbackformular auf privacysandbox.com, Besprechungen mit Branchenvertretern und Webstandards-Foren. Chrome begrüßt das Feedback aus der Plattform und sucht aktiv nach Möglichkeiten, das Gelernte bei Designentscheidungen zu berücksichtigen.

Feedbackthemen sind nach der Häufigkeit pro API geordnet. Dazu wird das Feedback, das das Chrome-Team zu einem bestimmten Thema erhalten hat, aggregiert und in absteigender Reihenfolge nach Anzahl sortiert. Die gemeinsamen Feedbackthemen wurden durch Überprüfung der Diskussionsthemen aus öffentlichen Meetings (W3C, PatCG, IETF), direktem Feedback, GitHub und häufig gestellten Fragen identifiziert, die über interne Teams von Google und öffentliche Formulare von Google gestellt wurden.

Genauer gesagt wurden die Besprechungsprotokolle für Besprechungen von Webstandard-Gremien geprüft und für direktes Feedback wurden die Aufzeichnungen von Google zu persönlichen Meetings mit Stakeholdern, die von einzelnen Entwicklern eingegangenen E-Mails, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Google hat sich dann zwischen den Teams, die an diesen verschiedenen Kontaktaufnahmen beteiligt waren, koordiniert, um die relative Verbreitung der in den einzelnen APIs entstehenden Themen zu ermitteln.

Die Erklärungen zu den Reaktionen von Chrome auf das Feedback basieren auf veröffentlichten FAQs, auf tatsächlichen Antworten auf von Stakeholdern vorgebrachte Probleme und auf der Festlegung einer Position speziell für die Zwecke dieser öffentlichen Berichterstattung. Unter Berücksichtigung des aktuellen Schwerpunkts bei Entwicklung und Tests wurden insbesondere Fragen und Feedback zu den APIs Topics, Protected Audience und Attribution Reporting erhalten.

Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingeht, hat möglicherweise noch keine Antwort von Chrome als Antwort erhalten.

Glossar der Akronyme

ARA

Attribution Reporting API

CHIPS

Cookies mit unabhängig partitioniertem Status

DSP

Demand-Side-Plattform

FedCM

Federated Credential Management

fps

First-Party-Sets

IAB

Interactive Advertising Bureau

IdP

Identitätsanbieter

IETF

Internet Engineering Task Force

IP-Adresse

Internet Protocol-Adresse

openRTB

Echtzeitgebote

ÜS

Ursprungstest

PAT-API

Protected Audience API (früher FLEDGE)

PatCG

Private Community für Werbetechnologie-Gruppe

RP

Verlassende Partei

RWS

Sets ähnlicher Websites (früher First-Party-Sets)

SSP

Supply-Side-Plattform

TEE

Vertrauenswürdige Ausführungsumgebung

UA

User-Agent-String

UA-CH

User-Agent-Client-Hints

W3C

World Wide Web Consortium

In Arbeit

Willful IP Blindness

Allgemeines Feedback, keine bestimmte API oder Technologie

Feedback	Zusammenfassung	Chrome-Antwort
Governance	Interesse an einer Phase öffentlicher Kommentare zu Governance-Änderungen an der Privacy Sandbox.	Wir sind offen für angemessenes Feedback von Stakeholdern zu allen wichtigen Entwicklungen bei der Privacy Sandbox, einschließlich der zukünftigen Governance der Privacy Sandbox.
Testen	Zusätzliche Testphasen für 3PCD zusätzlich zu den aktuellen 1% von Chrome unterstützten Tests.	Wir beabsichtigen, ab Anfang Januar keine von Chrome unterstützten Tests über die aktuellen 1% des Chrome-Traffics hinaus anzubieten.
Web to App	3PCD auf Mobilgeräten sollte erst erfolgen, wenn die vollständige Interoperabilität zwischen Web und App erreicht ist.	Wir sind uns einig, dass es wünschenswert ist, die App- und Web-Interoperabilität zu unterstützen, und haben die App- und Web-Attributionsmessung eingeführt und arbeiten an Lösungen für Web-zu-App-Targeting. Wir planen jedoch nicht, 3PCD im mobilen Web zu verzögern. Wir haben kein Ziel von 100% Abdeckung am Ende der 3PCD. Stattdessen gehen wir davon aus, dass die App- und Web-Messung unter Android bei 3PCD relativ hoch sein wird und mit der Zeit zunimmt, wenn Nutzer ihr Smartphone aktualisieren.
Rolle des Browsers	Chrome übernimmt anscheinend die Rolle eines Ad-Servers oder einer SSP.	Chrome übernimmt nicht die Rolle eines Ad-Servers oder SSP. Mit der PA API stellt Chrome einen Container für Ad-Server, Sell-Side-Plattformen, DSPs und andere AdTech-Technologien bereit, in die sie ihre eigene Gebots- und Bewertungslogik nutzen können.
Anleitung für Anwendungsfälle	Klarere Erläuterungen dazu, welche Anwendungsfälle von den Privacy Sandbox-APIs unterstützt werden	Zu Beginn des Privacy Sandbox-Projekts konzentrierte sich die Entwicklerdokumentation in erster Linie darauf, Entwickler in die Diskussions- und Feedbackprozesse für alle Vorschläge einzubeziehen. Das bedeutete, dass der Inhalt im Allgemeinen darauf bestand, die Motivation und die Konzepte des Projekts zu verstehen, gefolgt von Details zu den frühen Entwicklungs- und Testdetails für die einzelnen Vorschläge. Dies war bei der Entwicklung der Angebote effektiv beim Aufbau einer echten Zusammenarbeit im Ökosystem. Mit der allgemeinen Verfügbarkeit der APIs gibt es jedoch eine neue Zielgruppe von Entwicklern, die hauptsächlich auf die APIs aufbauen, anstatt an der zugrunde liegenden Entwicklung zu arbeiten. Wir haben vor Kurzem die Navigation unter developer.google.com/privacy Sandbox für den Einsatz der Privacy Sandbox in der Privacy Sandbox geändert. Diesen anwendungsfallbasierten Ansatz der Dokumentation werden wir auch in Zukunft fortsetzen.
Lokale Entwicklungsumgebung	Wie entwickeln und testen wir unser Frontend weiter lokal auf http://localhost, wenn das Cookie SameSite=Secure ist und das Backend von einem CDN vorangeht?	Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback von der Community.
3PCD-Abwehr	Gibt es eine programmatische Möglichkeit zu erkennen, dass Drittanbieter-Websites blockiert sind oder wenn Heuristiken aktiv sind?	In Chrome können Entwickler sowohl mit der Funktionserkennung als auch mit document.hasStorageAccess in einem iFrame feststellen, ob der Ursprung im iFrame Zugriff auf Drittanbieterdaten hat.
Videotests	Derzeit können keine Videoanzeigen in der Privacy Sandbox getestet werden.	Chrome hat heute eine Diskussion und Demonstration verschiedener Möglichkeiten veröffentlicht, wie Videos mit der PA API erstellt werden können (siehe 242 und 254 in unserem Demo-Repository auf GitHub). Hinweis: Sie sind nicht als Beispielcode gedacht, den Anzeigentechnologie-Anbieter übernehmen würden, sondern als Proof of Concept und Demonstration der Techniken, die das VAST-Video-Rendering mit der PA API unterstützen können. Im Verlauf dieser Diskussion wurde auch klar, dass das Videorendering zwar bereits heute möglich ist, es aber Änderungen gibt, die Chrome vornehmen könnte, die die Implementierung mit der PA API vereinfachen würden. Bei den Aktualisierungen der Makroersetzung ( siehe hier), die wir aufgrund des Feedbacks zu Markensicherheitsanwendungsfällen bei der Anzeigenprüfung durch Drittanbieter bereits umsetzen wollten, berücksichtigen wir auch Feedback zum Video-Anwendungsfall, in dem der Käufer sucht, welche Verkäufermakros für das Rendering verwendet werden sollen. Bisher haben wir uns vor allem für das Rendern von VAST-Videoanzeigen beschäftigt. Beim Rendern nativer Anzeigen können die gleichen Ansätze verwendet werden, und es ist in vielerlei Hinsicht einfacher. Native Anzeigen scheinen derzeit weniger Beachtung zu erhalten als Videoanzeigen. Aber es geht hier nur um die Priorisierung der AdTech-Branche, nicht um technische Hürden bei der Implementierung.
Nicht werbebezogene Analyse	Die 3PCD kann sich auf nicht werbebezogene Lösungen zur Zielgruppenanalyse auswirken.	Für die APIs zur Messung muss der Anwendungsfall nicht auf Anzeigen bezogen sein. Während die ARA eher spezifischer für einen typischen Kaufprozess ist,dient die private Aggregation für allgemeine Zwecke. Mit diesen beiden Bausteinen können Sie eine Vielzahl von Messaktivitäten abdecken.
Videokünstler	Die Privacy Sandbox soll Creator ermutigen, mehr Inhalte für YouTube und weniger auf ihren eigenen Websites zu erstellen.	Die Privacy Sandbox-Initiative zielt darauf ab, die Aktivitäten von Nutzern in einem offenen und kostenlosen Internet privat zu halten. Wir wissen, dass sich Publisher auf Anzeigen verlassen, um Inhalte zu produzieren und so allgemein wie möglich verfügbar zu machen. Werbetreibende helfen Nutzern dabei, neue Produkte oder Angebote zu entdecken, die sie interessieren könnten. Mit den Privacy Sandbox-Funktionen können Websites aller Art – auch solchen, die mit Creatorn zusammenarbeiten – Nutzern nützliche Anzeigen präsentieren, die auf ihren Aktivitäten mit verschiedenen Parteien basieren, ohne dass die Identität des Nutzers gegenüber diesen Parteien offengelegt wird.
Klarere Zeitpläne	Klarere und detailliertere Veröffentlichungspläne für die Privacy Sandbox-Technologien.	Die Dokumentation zur Privacy Sandbox API enthält Informationen zum API-Status und zur Verfügbarkeit. Auf diesen Seiten finden Sie eine Liste der demnächst verfügbaren Funktionen und ihre Zeitpläne (z.B. PA API, ARA). Hier finden Sie eine zentrale Ansicht dieser Status.
Machine Learning	Anzeigentechnologie-Anbieter können Machine-Learning-Modelle erst dann richtig trainieren, wenn die 3PCD-Werte 1 % überschreiten.	Die Erweiterung von 3PCD auf weitere Browser für Tests würde nicht garantieren, dass die APIs mehr genutzt werden, was vermutlich das ist, wonach Anzeigentechnologie-Anbieter suchen, um Modelle für maschinelles Lernen weiter zu trainieren. Wenn die Nutzung eines breiteren Systems nicht das ist, was Anzeigentechnologien zum Trainieren von Modellen für maschinelles Lernen anstreben, dann gibt es keinen Grund, 3PCD zu erweitern, da eine Anzeigentechnologie, die Modelle für mehr Traffic trainieren möchte, dies heute ohne erhöhten 3PCD tun kann. Das ist möglich, ohne dass Chrome auf 3PCD vor dem Ende des Standstill-Modus vorankommt.
Nicht unterstützter Anwendungsfall	Self-Service-DSP-Anwendungsfälle werden derzeit nicht in Betracht gezogen.	Mehrere Self-Service-DSPs geben regelmäßig öffentliches Feedback zu den APIs ab. Einige dieser DSPs, die regelmäßig öffentliches Feedback geben, werden auch als Tester aufgeführt. Außerdem beschäftigt Chrome sich aktiv mit typischen Self-Service-DSP-Themen wie Videos und Ad-Servern von Drittanbietern. In den letzten wöchentlichen PA API-Aufrufen wurden diese Themen behandelt.
Ursprungstest	Anfrage für OT für Websites, die eine höhere Anlaufzeit und Testabdeckung für 3PCD wünschen.	Chrome entwickelt derzeit ein eigenes OT, das es Ursprüngen ermöglicht, der schrittweisen Einstellung von Drittanbieter-Cookies zuzustimmen. Bei Ursprüngen der obersten Ebene, die sich für diese Testversion registrieren und Tokens bereitstellen, werden 3PCs blockiert, als ob auf dem Nutzergerät der Tracking-Schutz aktiviert wäre. Dieses OT bietet Websites eine wertvolle Gelegenheit, umfassendere Tests langfristiger Alternativen zu 3PCs durchzuführen, bevor die 3PCs nach Rücksprache mit der CMA endgültig eingestellt werden. Wir arbeiten noch daran, den Zeitplan für die Einführung des OT zu finalisieren.
Bericht des IAB Tech Lab	Feedback zur Privacy Sandbox aus dem Bericht des IAB Tech Lab.	Wir haben hier ausführlich auf den Bericht des IAB Tech Lab geantwortet. Wir haben dort auch anerkannt, dass „der Bericht Fragen zu fragmentierten Dokumentationen, kommerziellen Anforderungen, Audits durch Dritte, Branchenakkreditierung, Skalierbarkeit, Transparenz und zukünftiger Governance aufwirft. Wir werden uns mit dem Ökosystem befassen und unsere öffentlichen FAQs entsprechend aktualisieren.“ Wir haben bereits fragmentierte Dokumentationen angegangen. Wir erfüllen die kommerziellen Anforderungen, die unter „Datengarantien“ aufgeführt sind, und über einige Werbeprodukte von Google. Audits durch Dritte sind im Rahmen der Integritätsgarantie des Algorithmus aufgeführt. Im Hinblick auf die Akkreditierung gehen wir davon aus, dass diese Organisationen weiterhin Produkte und nicht die Technologien selbst akkreditieren, einschließlich der Nutzung von Technologien. In Bezug auf die Skalierbarkeit sind wir weiterhin offen für Daten von Entwicklern, die Probleme aufzeigen. Im Hinblick auf Transparenz und Governance entwickeln wir weiterhin offen auf GitHub und in Foren wie W3C und arbeiten gleichzeitig mit der CMA im Rahmen der Selbstverpflichtungen zusammen.
Google Log-in	Google Log-ins würde für Google die Möglichkeit bieten, identifizierbare Anmeldedaten entgegen den Vereinbarungen zu verwenden.	Google Log-in ermöglicht Google nicht, Daten entgegen den Vereinbarungen zu nutzen.
Kompatibilität	Welche Unterstützung soll die Privacy Sandbox APIs bieten und wie sieht die Vor- und Abwärtskompatibilität aus?	Sobald eine Chrome-Funktion allgemein verfügbar ist, wird sie auch weiterhin unterstützt. Natürlich ist es nicht immer möglich, Abwärtskompatibilität zu gewährleisten. In solchen Fällen haben wir einen klaren Prozess zur Einstellung und Entfernung vorhandener Funktionen, wie hier beschrieben. Wir gehen davon aus, dass wir den Privacy Sandbox APIs im Laufe der Zeit weitere Funktionen hinzufügen werden, um auf Feedback aus der Community zu Anwendungsfällen zu reagieren, die von einem verbesserten Support profitieren würden. In solchen Fällen setzen wir eine Technik zur Funktionserkennung ein, damit ein Anzeigentechnologie-Anbieter, der mit einer neuen Funktion experimentieren möchte, direkt beim Browser nachfragen kann, ob die Funktion unterstützt wird. Das ist besser, als Entwickler zu bitten, nach einer bestimmten Chrome-Versionsnummer zu suchen, da einige Funktionen möglicherweise nicht für alle Chrome-Nutzer gleichzeitig eingeführt werden. Informationen zu unseren Funktionserkennungsarbeiten für die PA API findest du hier.
Serverimplementierung	Statt eine eigene Implementierung durchzuführen, sollte Chrome die Verhaltensweisen festlegen, die eine zufriedenstellende Implementierung eines vertrauenswürdigen Signals-Servers, eines Aggregationsservers und aller anderen erforderlichen Nicht-Browser-Komponenten erfüllen muss. Dies würde Innovationen innerhalb akzeptabler Datenschutzgrenzen ermöglichen.	Wir freuen uns über den Wunsch nach Innovationen durch externe Parteien. Unser Ziel ist es, bei allen APIs und Diensten Flexibilität bei der Implementierung ihrer Funktionen zu bieten. So dürfen Anzeigentechnologie-Anbieter beispielsweise beim Entwerfen der Gebotslogik für Auktionen vertrauliche Unternehmensinformationen verwenden. Darüber hinaus greifen wir kontinuierlich auf das Feedback von Anzeigentechnologie-Anbietern ein und integrieren es, wo es gerechtfertigt ist, in unsere Designs. Damit andere ihren eigenen Code in vertrauenswürdigen Ausführungsumgebungen ausführen können, muss die Privacy Sandbox den Code (und alle Änderungen) überprüfen, um sicherzustellen, dass er die Datenschutzgarantien erfüllt. Dies erfordert erhebliche Anstrengungen des Privacy Sandbox-Teams. Daher möchten wir verstehen, welche Vorteile der Stakeholder sich erhofft, die wir heute nicht erfüllen.
Heuristik	Was sind die langfristigen Pläne für Heuristiken?	Entsprechend den Angaben anderer Browser beabsichtigen wir, diese Heuristik zu entfernen, wenn alternative Lösungen weit verbreitet sind und einer weiteren Machbarkeitsanalyse unterliegen. Wir haben diese Informationen hier veröffentlicht.
Volume testen	Unterschiedliches Traffic-Volumen beim Vergleich verschiedener Dimensionen	Für den 1 %-Test gibt es Ausschlusskriterien, die zu unterschiedlichen Eignungsvoraussetzungen für den Test zwischen verschiedenen Gruppen von Chrome-Kunden führen. Zum Beispiel werden in dem Test Chrome Enterprise-Nutzer ausgeschlossen, sodass der Anteil der Zugriffe mit Testlabels an Wochenenden voraussichtlich höher ist. Es ist zu erwarten, dass unterschiedliche Prozentsätze des Traffics in verschiedenen Datensegmenten wie Geografie, Datum und Plattform angezeigt werden. Dies entspricht dem, was wir in Chrome-Daten sehen.
Drittanbieter manuell wieder aktivieren	Können die Websites erkennen, wie viele Nutzer (%) Cookies manuell wieder aktiviert haben, nachdem die 3PCD erzwungen wird?	Nutzer haben die Möglichkeit, den Drittanbieterzugriff auf Website-Ebene über die Nutzerumgehung wieder zu aktivieren, falls Probleme auftreten. Drittanbieter-Apps können auch durch andere Maßnahmen wie die Storage Access API wieder aktiviert werden. Es gibt technische Maßnahmen wie hasStorageAccess(), durch die Websites feststellen können, ob 3PCs aktiviert oder deaktiviert sind. Websites können in Chrome jedoch nicht die Gründe für die erneute Aktivierung ermitteln.
Schutz vor Tracking	Wie lange wird die Benutzeroberfläche zum Schutz vor Tracking-Schutz von Chrome verfügbar sein?	Die Benutzeroberfläche für den Schutz vor Tracking in der Adressleiste wird auch nach der Einstellung von Drittanbieter-Apps weiter verfügbar bleiben.
(Auch in vorherigen Quartalen gemeldet) Browserübergreifende Unterstützung	Andere Browseranbieter, die die Privacy Sandbox APIs verwenden	Andere Browser-Anbieter wie Apple, Mozilla und Microsoft sind aktive Teilnehmer in den öffentlichen Foren, in denen Datenschutzprinzipien und browserbasierte Ansätze diskutiert werden. Wir freuen uns über gemeinsame Diskussionen in Foren wie dem letzten jährlichen W3C-Treffen der TPAC und den laufenden W3C-PATCG-Foren, in denen wir Anzeichen für eine Konvergenz erkennen können. Microsoft Edge hat beispielsweise vor Kurzem seinen Plan angekündigt, „die syntaktische Kompatibilität mit der PA API und ARA zu maximieren und gleichzeitig zusätzliche Funktionen für Entwickler anzubieten.
Fallback-Option für inkompatible Einbettungen nach 3PCD	Stellen Sie API-Hooks bereit, um festzustellen, ob ein Drittanbieter-iFrame/-einbettung mit 3PCD konform ist.	Wir besprechen die Anfrage hier und freuen uns über zusätzliches Feedback von der Community.
Testen	Anfrage für zusätzliche Flags in verwalteten Instanzen von Chrome, durch die das benutzerdefinierte Verhalten vorübergehend deaktiviert wird.	Wir prüfen diese Anfrage für verwaltete Instanzen von Chrome und freuen uns über zusätzliche Informationen aus der Umgebung, wenn ein solches Flag nützlich wäre.

Registrierung und Bestätigung

Feedback	Zusammenfassung	Chrome-Antwort
Bestätigung der Attestierung	Wie gewährleistet Google die Echtheit von Bescheinigungen?	Alle Domaininhaber müssen die Bestätigungsdatei beibehalten, während sie die APIs verwenden. Google überprüft, ob die Datei vorhanden und die Syntax korrekt ist, aber Google validiert nicht das Verhalten der Anzeigentechnologie in Bezug auf die Attestierungssprache.
Registrierungsprozess für die Private Aggregation API	Gibt es eine Möglichkeit, den Status der Registrierung für die Private Aggregation API zu prüfen?	Alle genehmigten Personen werden per E-Mail vom Supportteam für Registrierungen benachrichtigt, sobald die Registrierung bestätigt wurde. Wenn der Domaininhaber Fragen während des Prozesses hat, kann er sich an das Supportteam wenden, das er beim Einreichen des Anmeldeformulars kontaktiert. Das Supportteam wird auf Ihre Fragen antworten und Sie bei Bedarf unterstützen.

Relevante Inhalte und Werbung präsentieren

Themen

Feedback	Zusammenfassung	Chrome-Antwort
(Auch in vorherigen Quartalen verfügbar) Zeitachse und Dokumentation des Klassifikators	Es sollte ein Mechanismus vorhanden sein, mit dem die Klassifizierung überprüft werden kann, oder zumindest mehr Transparenz dafür bieten, wie der Klassifizierungsmodus Kategorien bestimmt.	Unsere Antwort hat sich im Vergleich zu vorherigen Quartalen nicht geändert: „Durch die falsche Klassifizierung von Websites kann das Topics-Signal insgesamt etwas weniger nützlich sein. Die falsch klassifizierten Websites sind dadurch aber nicht mehr und genauso stark beeinträchtigt als andere Websites. Dies liegt daran, dass die Kontextinformationen einer Website für Auktionen auf der Website immer verfügbar sind. So erhalten Sie auch bei falscher Klassifizierung vergleichbare Informationen zum richtigen Thema. Wir freuen uns über Feedback zu diesem Thema.“
Google Ad Manager	Google Ad Manager ist bereits in die meisten Websites eingebettet und bietet wesentlich umfassendere Informationen zu Nutzerthemen als Mitbewerber, die sich auf weniger Websites befinden.	Die Beobachtungsanforderung besteht darin, sicherzustellen, dass die Topics API nicht dazu führt, dass Nutzerdaten an mehr Entitäten weitergegeben werden als die Technologien, die die API ersetzt (einschließlich 3PCs). Andere Branchenlösungen wie Prebid funktionieren mit Tausenden von Websites und ermöglichen Marktteilnehmern,die Topics API über ihre Technologie aufzurufen. Beachten Sie außerdem, dass die Beschränkung von bis zu fünf Topthemen pro Woche einen ausgleichenden Effekt haben kann, da Marktteilnehmer auf vielen Websites, die mit Drittanbieter-Tools mehr als fünf äquivalente Themen erlernen können, auf 5 begrenzt sind.
(Auch in vorherigen Quartalen berichtet) Nützlichkeit für verschiedene Arten von Stakeholdern	Bedenken hinsichtlich der Wertschaffung und Verteilung dieses Werts für Websites abhängig von der Anzahl der Zugriffe oder der Spezialisierung ihres Contents.	Uns ist bewusst, dass spezialisierte Websites eher detailliertere Themen beisteuern als Domains von allgemeinem Interesse. Allerdings bieten nicht alle spezialisierten Websites kommerziell wertvolle Themen. Diese Dynamik spiegelt außerdem den Status quo wider und ist völlig unabhängig vom Ende des Supports für Drittanbieter-PCs in Chrome. Außerdem sind in der aktuellen Umgebung manche Websites in 3PC-basierten Anzeigenrelevanzsystemen wertvoller als andere. Darüber hinaus können die Themen auf spezialisierten Websites füreinander von Vorteil sein, da Werbetreibende mit unterschiedlichen Themen Kampagnen für verschiedene Themen schalten können und die Gebotslogik bei einer Vielzahl von Themen Werte beobachten kann.
Hostnamen vs. vollständige URLs	Ist die Klassifizierung, die auf den Hostnamen von Websites basiert, ausreichend effektiv und verringert sich dadurch das Datenschutzrisiko im Vergleich zu vollständigen URLs?	Wir haben in Betracht gezogen, zusätzlich zu Hostnamen auch Informations-URLs oder Seitentitel zu verwenden. Dabei sind wir zu dem Schluss gekommen, dass die potenziellen Vorteile durch die Risiken für Datenschutz und Sicherheit für Nutzer überwiegt werden. Ein Beispiel für Datenschutzrisiken für Nutzer ist die Einordnung vertraulicher Informationen in der URL oder dem Seitentitel in die Themen des Nutzers.
Themen als Signal	Bitten Sie um Unterstützung, wie Sie Topics mit anderen Signalen kombinieren können und welche anderen Signale nützlich sein könnten.	Mit AdTech-Lösungen lassen sich die besten Ergebnisse erzielen, indem alle verfügbaren Tools wie maschinelles Lernen und datenschutzkonforme Signale von datenschutzfreundlichen APIs mit Kontext-, Creative- und selbst erhobenen Daten kombiniert werden. Weitere Informationen dazu finden Sie hier.

Protected Audience API (früher FLEDGE)

Feedback	Zusammenfassung	Chrome-Antwort
Traffic-Volumen testen	Die Tester melden ein geringes Volumen an Gebotsantworten für die PA API-Auktion.	1. Die Gebotsdichte korreliert mit der Beteiligung des Systems an der PA API, die unserer Einschätzung nach im Laufe des Jahres 2024 und darüber hinaus weiter zunehmen wird. Letztendlich liegt es bei den Werbetreibenden, ihren Agenturen und Technologieanbietern, wie die Kampagnenbudgets zugewiesen werden. Wir gehen davon aus, dass einige Teilnehmer ihre Investition in verschiedene Lösungen ohne Cookies, einschließlich der PA API, erst nach der Einführung der 3PCD verzögern. Wir gehen dann davon aus, dass das Unternehmen die Budgetzuweisung für diese Lösungen entsprechend erhöhen wird. 2. (1) Das Volumen der Gebotsanfragen in PA API-Auktionen kann dadurch beeinflusst werden, dass Publisher und ihre AdTech-Anbieter möglicherweise keine PA API-Auktionen starten, wenn sie der Meinung sind, dass die Nachfrage gering ist. Die Publisher legen die Priorität der Aktualisierung ihrer Seiten und der Teilnahme fest. Wir gehen davon aus, dass sich Publisher aus diesen Gründen möglicherweise etwas Zeit nehmen, den Traffic zu testen und den Traffic schrittweise zu steigern. Dieser Bericht enthält auch eine Antwort von Google Ad Manager zu den Publisher-Steuerelementen für die Teilnahme an der PA API.
(Auch in früheren Quartalen gemeldet) Betrug / Missbrauch	Wie kann das System die Risiken reduzieren und verhindern, dass sich böswillige Akteure oder Käufer als gewünschte Zielgruppe positionieren?	Die Meldemechanismen von PA API-Anzeigen enthalten die Informationen, die derzeit zur Unterscheidung zwischen Menschen und Bot-Traffic verwendet werden. Darüber hinaus können aktuelle domainbasierte Techniken zum Ein- oder Ausschließen von Domains in der PA API verwendet werden. Weitere Informationen hierzu finden Sie in unserer Antwort auf den Bericht zur Privacy Sandbox des IAB Tech Lab.
Gleiche Ursprungsbeschränkung für Inhaber von IG und URL der Gebotslogik	Bei Same-Origin-Anforderungen müssen Endpunkte eines IG-Inhabers denselben Load-Balancer durchlaufen. Das kann dazu führen, dass Weiterleitungen abgelehnt werden.	Die Anforderung am selben Ursprung beim Laden von Skripts ist ein wichtiger Sicherheitsschutz. Hier finden Sie Details zu einem Lösungsvorschlag, bei dem das Feedback der Plattform und andere Aspekte berücksichtigt werden.
Private Auktion mit mehreren Slots	Durch den Einsatz von Rauschen und einer engeren Integration in die aktuellen Anzeigenpraktiken ist viel Spielraum für private Multi-Slot-Auktionen im Rahmen des Datenschutzes vorhanden.	Wir berücksichtigen dieses Feedback und prüfen die Anfrage für Auktionen mit mehreren Tags im Hinblick auf die höhere Komplexität und die mit dieser Funktion verbundenen Datenschutzrisiken. Wir haben dieses Problem in einem Anruf der PA API Web Incubator Community Group (WICG) weiter besprochen.
Top-Level-Verkäufer	Die aktuelle Struktur der PA API bietet allen Top-Level-Verkäufern deutlich mehr Daten und Informationen zum relativen Wert von Impressionen als Publisher oder Komponentenverkäufer.	Bei einer Auktion mit mehreren Verkäufern gibt jeder Verkäufer das beste Gebot ab. Außerdem haben wir herausgefunden, dass Publisher die direkt verkaufte Nachfrage neben den besten Geboten der einzelnen Verkäufer, mit denen sie zusammenarbeiten, möglicherweise berücksichtigen sollten. Es ist wichtig, all diese potenziellen Monetarisierungsmöglichkeiten zu prüfen, um zu entscheiden, welche Anzeige ausgeliefert werden soll. Diese Situation, in der es für einen Nutzer erforderlich ist, um alle Optionen zu sehen, um eine Anzeige für die Auslieferung auszuwählen, ist die Zeit vor der PA API. Die PA API soll Auktionen mit mehreren Verkäufern unterstützen und der Wunsch der Publisher, das beste Gebot der einzelnen Verkäufer neben direkt verkauften Werbekampagnen zu berücksichtigen, sofern Letzteres anwendbar ist. Es muss also ein Mechanismus vorhanden sein, um aus den Monetarisierungsmöglichkeiten wie heute wählen zu können. Wir waren der Meinung, dass der Browser bei der Auswahl der zu schaltenden Anzeige nicht die Rolle des Browsers hätte. Daher ist das Konzept eines Top-Level-Verkäufers erforderlich, um aus vielen Möglichkeiten eine erfolgreiche Anzeige auszuwählen. Die Logik dieses übergeordneten Verkäufers muss in der Lage sein, die besten Gebote der einzelnen Verkäufer zu berücksichtigen, mit denen der Publisher zusammenarbeitet. Außerdem stellt die Logik dieses Verkäufers möglicherweise Informationen zu den direkt verkauften Kampagnen des Publishers bereit, sofern diese Informationen verfügbar sind. All diese Informationen können in der Anzeigenauswahllogik der obersten Ebene berücksichtigt werden. Das bedeutet, dass die übergeordnete Logik die besten Gebote aus der PA API-Auktion und gegebenenfalls allen direkt verkauften Anzeigenoptionen des Publishers berücksichtigt, um den Gewinner zu ermitteln. Google Ad Manager beschreibt in diesem Bericht unter dem Thema „Zugriff auf Informationen“ die Implementierung der PA API als Top-Level-Verkäufer.
Trennung von Anzeigen von Mitbewerbern	Sie haben die Möglichkeit, eine Trennung von Anzeigen von Mitbewerbern anzufordern, z. B. dass verhindert werden soll, dass Anzeigen konkurrierender Marken nebeneinander ausgeliefert werden.	Uns ist noch nicht bekannt, wie eine Wettbewerbstrennung in der heutigen programmatischen, gebotsfähigen Multi-seller-Plattform für digitale Werbung sichergestellt werden kann. Die PA API ermöglicht Verkäufern jedoch, zusätzliche Echtzeitsignale anhand einer Kombination aus render-URL und Hostnamen (die die Domain des Publishers darstellen) abzurufen. Diese Signale können während der ScoreAd() beim Bewerten von Creatives verwendet werden. Verkäufer können damit verhindern, dass Anzeigen konkurrierender Marken nebeneinander ausgeliefert werden, sofern der Publisher diese Regel erzwingen möchte.
Eingeschränkte Informationen	Die PA API reduziert die für Publisher verfügbaren Informationen wie den Anzeigenwert, den Namen des Käufers der Komponente, den Namen des Werbetreibenden, die Landingpage-URL, die Creative-Größe, die Antwortzeit und die Gebotsrate sowie unterlegene Gebote.	Wir haben hier einige mögliche Lösungen vorgeschlagen und würden uns über zusätzliches Feedback vonseiten der Community freuen.
Berichte auf Ereignisebene	Publisher erhalten nach der Einstellung der API für Berichte auf Ereignisebene nicht genügend Informationen zur ausgelieferten Anzeige.	Wir sind uns der verschiedenen Anwendungsfälle für die Berichterstellung bewusst, die wir nach der Einstellung von Berichten auf Ereignisebene weiterhin unterstützen müssen. Aus diesem Grund haben wir die Berichterstellung auf Ereignisebene so eingestellt, dass sie frühestens 2026 liegt. In der Zwischenzeit möchten wir Sie zur aktiven Beteiligung ermutigen, während wir uns für nachhaltige Entwicklungen einsetzen, zum Beispiel neue Ideen für den Erhalt von Informationen auf datenschutzfreundliche Weise.
Mehrere Sell-Side-Plattformen	Der Nutzen mehrerer Sell-Side-Plattformen ist für Publisher zu gering.	Wir sind der Meinung, dass dies nicht korrekt ist, und bitten daher um zusätzliches Feedback aus der Community, um die Begründung für diese Behauptung zu verstehen.
Kuratationsaktivitäten	Auswahlaktivitäten sind mit der PA API nicht möglich.	Wir haben Feedback dazu erhalten, dass Verkäufer die PA API verwenden können, um ihre Zielgruppeninformationen für Käufer im Web bereitzustellen (auch als Zielgruppenerweiterung bezeichnet). Wir glauben, dass dies heute möglich ist, indem wir die Delegationsfunktion von PA für personalisierte Anzeigen zusammen mit Geschäftsvereinbarungen verwenden. Gleichzeitig prüfen wir aktiv, ob und wie wir diese Art von Anwendungsfällen besser berücksichtigen können.
Käufer-Opt-out	Die standardmäßige Deaktivierung durch den Käufer führt bei Komponentenauktionen wahrscheinlich zu geringeren Ergebnissen.	Unabhängig davon, ob der Verkäufer einen Einzel- oder mehrere Verkäufer-PA-Auktion definiert, muss der Verkäufer die Käufer im Feld „interestGroupBuyers“ der Auktionskonfiguration explizit auflisten. Das basiert auf Feedback aus dem System, dass Verkäufer mit einigen Käufern vertragliche Vereinbarungen getroffen haben und daher die ausdrückliche Kontrolle darüber benötigen, welche Käufer an der Auktion teilnehmen. Wir würden uns über weitere Diskussionen auf GitHub freuen.
Anzeigen	Vorfilterung nach Anzeigengröße und adSlotSize ist nicht möglich.	Wir arbeiten daran, diese Funktion hinzuzufügen. Weitere Informationen finden Sie hier.
Unterstützung für auszuschließende Ausrichtung auf IG	Eine API zur Unterstützung des negativen Targetings auf IG: Anzeigen werden nur dann ausgeliefert, wenn ein Nutzer nicht zu einem IG gehört.	Mit diesem GitHub-Problem wurde eine alternative Möglichkeit zur Implementierung des negativen Targetings vorgeschlagen, bei der der Browser dem Ad-Server direkt mitteilt, welche Regeln für das ausschließende Targeting für eine bestimmte Anzeigenanfrage gelten sollen. Dieser Ansatz scheint auf den ersten Blick attraktiv zu sein, doch alle Versionen dieser Idee, die wir untersucht haben, ermöglichen es dem Server, den Nutzer eindeutig zu identifizieren.
Digital Services Act	Wie kann ein Publisher Fenced Frames verwenden und gleichzeitig verhindern, dass Antworten mit Informationen, die dem Gesetz über digitale Dienste unterliegen, gerendert werden?	Wie bei jeder neuen Technologie ist jedes Unternehmen dafür verantwortlich, dass die Privacy Sandbox gesetzeskonform verwendet wird. Google kann anderen keine Rechtsberatung anbieten. Wir haben für jede API umfangreiche technische Dokumentation veröffentlicht, die die Grundlage für die notwendigen rechtlichen Überprüfungen bilden sollte. Fenced Frames sind vor 2026 nicht für die Verwendung in der PA API erforderlich. So haben die Beteiligten mehr Zeit, um sicherzustellen, dass ihre Nutzung dieser Technologie allen relevanten Gesetzen entspricht.
Dokumentation	Ist „updateAdInterestGroups()“ temporär?	Wir haben keine Pläne zur Einstellung von "updateAdInterestGroup" bekannt gegeben. In Zukunft werden wir möglicherweise ähnliche Datenschutzmaßnahmen wie für andere Update-Mechanismen von Google Analytics anwenden, über die wir bereits gesprochen haben, z.B. die Nutzung einer IP-Adresse als Proxy und eine gewisse Verzögerung vor dem Update.
Unterstützung von Käufermetadaten und logischen Eigentumsrechten für Nicht-DSPs	Anfrage für eine Möglichkeit, als Proxy für DSPs zu fungieren.	Uns ist das Feedback von Nicht-DSP-Segmenten bekannt und wir prüfen diese Anfrage. Wir freuen uns immer über zusätzliches Feedback.
Berichterstellung	Anfrage zum Hinzufügen einer benutzerdefinierten Handler-Funktion für den Signal-Bucket / Wert in Berichten zur privaten Aggregation.	Uns ist bekannt, dass wir diese Funktionsanfrage zur weiteren Untersuchung in die Warteschlange stellen. Wir freuen uns immer über zusätzliches Feedback aus der Plattform hier.
Dokumentation	Gibt es einen Link, über den Sie alle Antwortheader sehen können, die vom Werbetreibenden und der (delegierten) Inhaberdomain festgelegt werden müssen?	Wir arbeiten an Aktualisierungen der Dokumentation, um dies zu verdeutlichen, und freuen uns über zusätzliches Feedback von der Community.
Multi-Tower-Gebote	Bitten Sie um eine Erläuterung des Workflows (Training und Inferenz) über ein Architektur-/Blockdiagramm, um zu zeigen, wie ein Multi-Tower-Ansatz im PA API-Kontext vorgesehen ist.	Vielen Dank für dein Feedback. Wir haben einige Präsentationen zu diesem Thema, für die wir voraussichtlich zusätzliche Dokumentation erstellen werden.
Ausschließende Ausrichtung	Möglichkeit der Privacy Sandbox, sensible Zielgruppen und Minderjährige vor unangemessener Werbung, z. B. Glücksspielen, zu schützen.	Die PA API berücksichtigt nicht die Inhalte der ausgelieferten Anzeigen. Die Kontrolle über die AdTech-Entwickler, die PA verwenden. Im Allgemeinen können der Publisher und seine AdTech-Anbieter Anzeigen-Creatives in Protected Audience-Auktionen blockieren, indem sie Kontextinformationen von der Seite sowie Regelsätze des Publishers verwenden. Dies spiegelt unser Verständnis davon wider, wie das Ökosystem heute an diese Herausforderungen herangegangen ist. Für Käufer kann die ausschließende Ausrichtungsfunktion für IG auch für einige Compliance-Anwendungsfälle nützlich sein.
API-Design	Google lehnt das ab und möchte, dass Anzeigentechnologie-Anbieter eine Funktion für universelle Gebote verwenden, um die Latenz zu erhöhen, anstatt unterschiedliche biddingLogicURLs in verschiedenen Google-Plattformen zu verwenden.	Bei unseren Gesprächen zur Latenz bei Auktionen haben wir festgestellt, dass die Verwendung desselben Scripts in allen Google-Produkten eines Käufers die Gebote dieses Käufers beschleunigen würde. Weitere Informationen dazu finden Sie hier, zusammen mit unseren anderen Empfehlungen zur Verbesserung der Latenz von PA API-Auktionen.
Kontobasiertes Marketing	Die PA API ist keine saubere API für Anwendungsfälle des kontobasierten Marketings.	Wir freuen uns über Feedback zu bestimmten Anwendungsfällen, die ihrer Meinung nach nicht möglich sind, und empfehlen den Teilnehmern, diese Diskussion über unser öffentliches GitHub-Repository oder wöchentliche Anrufe fortzusetzen.
A/B-Test	Wenn die PA API in GAM für einen Publisher konfiguriert ist, muss sie derzeit entweder für das gesamte Inventar oder für kein Inventar aktiviert werden. Dies schränkt die Möglichkeiten der Publisher ein, einen realistischen A/B-Test durchzuführen.	Antwort von Google Ad Manager: Die PA API-Einstellungen in Google Ad Manager (GAM) wirken sich darauf aus, ob die API in GAM verwendet werden kann, sofern die API verfügbar ist. Publisher können daher A/B-Tests durchführen, indem sie die Funktion für Berechtigungsrichtlinien von Chrome nutzen, um die Verwendung der API für einen Teil des Traffics zu deaktivieren und sie als Kontrollgruppe für A/B-Tests zu verwenden.
Machine Learning	Publisher benötigen mehr Kontrolle über den von GAM vorgeschlagenen Einsatz von maschinellem Lernen.	Antwort von Google Ad Manager: Im Januar 2024 haben wir eine Einstellung eingeführt, mit der Publisher unseren Drosselung für maschinelles Lernen deaktivieren und PA API-Auktionen mit Verkäufern außerhalb von Google für ihren gesamten Traffic aktivieren können. Weitere Informationen zu diesem Steuerelement finden Sie in der Hilfe.
(Auch in vorherigen Quartalen aufgeführt) Auktionen der obersten Ebene	Die Möglichkeit, den Ad-Server für Publisher von Google zu verwenden, ohne gleichzeitig GAM die Kontrolle über die PA-API-Auktion der obersten Ebene zu geben.	Antwort von Google Ad Manager: Aus den im Bericht vom 3. Quartal 2023 erläuterten Gründen ist bei GAM für die Integration der PA API keine Unterstützung für Publisher geplant, die GAM als Publisher-Ad-Server verwenden, ohne Kontrolle über die Auktion der obersten Ebene zu haben.
Zugriff auf Informationen	GAM hat Zugriff auf wertvolle Informationen von Mitbewerbern, darunter kontextbezogene Auktionspreise, Signale, die Käufer den SSPs für die PA API-Auktion zur Verfügung stellen, und Konfigurationsparameter der SSPs.	Antwort von Google Ad Manager: Wir legen seit Jahren großen Wert auf Fairness bei Auktionen. Unter anderem wird versichert, dass keine Preise aus nicht garantierten Werbequellen eines Publishers (einschließlich nicht garantierter Werbebuchungen) an einen anderen Käufer weitergegeben werden, bevor dieser ein Gebot für die Auktion abgibt. Dies haben wir später im Rahmen unserer Verpflichtungen gegenüber der französischen Wettbewerbsbehörde bekräftigt. Bei PA API-Auktionen beabsichtigen wir, unser Versprechen zu halten und das Gebot eines Auktionsteilnehmers vor Abschluss der Auktion nicht an andere Auktionsteilnehmer weiterzugeben. Wie in diesem Update erläutert, geben wir den Preis der kontextbezogenen Auktion nicht für andere Auktionen weiter, auch nicht für unsere eigene. Außerdem nutzen wir im Rahmen unserer eigenen Auktionen keine Informationen zu Auktionskonfigurationen wie etwa Signalen, die Käufer an SSPs senden. Wir würden uns sogar über Änderungen an der PA API freuen, die es Verkäufern von Komponenten ermöglichen, ihre Auktionskonfigurationen für Komponenten so anzugeben, dass sie vor dem Top-Verkäufer verschleiert werden können.
Auktionen für Komponenten	Als übergeordnete Auktion wird in GAM gesteuert, welche SSPs Komponentenauktionen für die einzelnen Werbechancen durchführen.	Antwort von Google Ad Manager: Als Ad-Server für Publisher bietet GAM eine einfache API für Sell-Side-Plattformen (SSP), mit denen Publisher möglicherweise ihre Komponenten-Auktionskonfigurationen über die Google Publisher Tag (GPT) API festlegen. Weitere Informationen Wenn eine Sell-Side-Plattform (SSP) über diese API eine Auktionskonfiguration für Komponenten bereitstellt, wird sie in die Liste der Komponentenauktionen für diese Werbechance aufgenommen. In GAM gelten keine Einschränkungen für die Komponentenauktionen. Alle Sell-Side-Plattformen, die eine Komponentenauktion durchführen möchten, können dies tun, sofern der Publisher ihnen erlaubt hat, den erforderlichen Code auf der Seite des Publishers auszuführen.
Auktionen für Komponenten	GAM könnte für jede Komponente, die die Auktion gewinnt, einen bestimmten und nicht angegebenen Mindestpreis festlegen.	Antwort von Google Ad Manager: GAM legt seit Jahren großen Wert auf Fairness bei Auktionen. Im Rahmen unserer fairen und transparenten Auktion werden keine Mindestpreise unterstützt, die nur für bestimmte Nachfragesegmente gelten. Dies ist ein einheitliches Prinzip in unserem Produkt und wird auch für PA API-Auktionen so bleiben.
Ad-Server eines Drittanbieters	Ad-Server von Drittanbietern hätten keinen Zugriff auf die Teilnahme von Google an der übergeordneten Auktion, was ihre Möglichkeiten einschränken, von der Google SSP-Nachfrage im Zusammenhang mit der PA API zu profitieren.	Antwort von Google Ad Manager: Derzeit unterstützt GAM das Testen der PA API bei mehreren Verkäufern in GAM über die hier beschriebene API. Die Teilnahme an GAM als Komponentenauktion in anderen Auktionen der obersten Ebene wird derzeit nicht unterstützt.
(Auch in vorherigen Quartalen aufgeführt) Leistung von PA API-Auktionen	Bericht von Testern, dass PA API-Auktionen eine hohe Latenz haben.	Wir haben Bedenken bezüglich der Latenz gehört. Dies ist einer der Gründe, aus dem wir im Rahmen der PA API eine Reihe von Funktionen entwickelt haben, mit denen SSPs sowohl die DSP-Latenz begrenzen als auch Verbesserungen vornehmen können, die die Latenz verringern können. Vor Kurzem haben wir unseren Leitfaden mit Best Practices zur Latenz aktualisiert. Er enthält weitere Informationen dazu, wie Sie diese Funktionen nutzen können. Außerdem entwickeln wir ständig neue Latenzverbesserungen. Einige davon findest du hier.
(Auch in früheren Quartalen gemeldet) Video-Rendering	Unterstützung für Videorendering mit der PA API und Fenced Frames.	Im Januar haben wir eine Demo dazu veröffentlicht, wie In-Stream-Videos in einer Auktion für private Anzeigen funktionieren können und zusätzliche Informationen zu alternativen Vorgehensweisen. Wir sehen auch einige Akteure im Ökosystem, die anfangen, Vorschläge zur Funktionsweise des Video-Renderings für Partner zu machen, die in das System integriert sind, z. B. die Vorschläge von GAM zur Erstellung von videokompatiblen Rendering-URLs oder den vollständigen E2E-Prozess. Darüber hinaus berücksichtigen wir Feedback zu Änderungen, die wir ergreifen können, um die Akzeptanz zu erhöhen. Eine solche Änderung wird in GitHub aufgeführt. Wir arbeiten weiterhin aktiv mit der Plattform zusammen, um eventuelle weitere Hindernisse bei der Einführung zeitnah zu erkennen und zu beseitigen.
(Auch in vorherigen Quartalen gemeldet) Richtlinie zur Datenverarbeitung	Wie lauten die Datenverarbeitungsrichtlinien für IGs / PA API?	Im PA API-Design bleiben alle in Google Analytics 4 gespeicherten Daten bzw. Informationen darüber, was Personen in diesen Google-Diensten enthalten, entweder (i) auf dem Gerät oder (ii) werden in den Gebots- und Auktionsdiensten (B&A) verarbeitet, die in einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) ausgeführt werden. In beiden Fällen können die Daten weder von Dritten gelesen noch verwendet werden, um Gebote in der Auktion zu erstellen. Einige Datenschutzverbesserungen, die Chrome derzeit prüft, beziehen sich auf die Interaktion mit einem von Google verwalteten k-Anonymitätsserver. Diese Interaktion ist sorgfältig so konzipiert, dass keine Informationen über Nutzer weitergegeben und in einem TEE verwendet werden, um die Gleichheit der Informationen im gesamten Werbesystem sicherzustellen. Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht durch das eigene Unternehmen verzerrt wird und dass die Auswirkungen auf den Wettbewerb bei digitaler Werbung sowie auf Publisher und Werbetreibende berücksichtigt werden. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass wir diesen Verpflichtungen nachkommen.
(Auch in vorherigen Quartalen gemeldet) Lifetime Lifetime von IG	Anfrage zur Verlängerung der Laufzeit von IGs von 30 auf 90 Tage.	Eine solche Änderung erfordert eine sorgfältige Abwägung der Vorteile für die Branche gegen die Auswirkungen auf Chrome-Nutzer und andere Beteiligte. Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback hier.
(Auch in vorherigen Quartalen erfasst) ModellierungSignale	Fordern Sie zusätzlich zu „modelSignals“ ein neues Feld an, das nur Display- und Klickinformationen codieren kann.	Wir haben auf dieses Feedback hier einen Gegenvorschlag eingereicht. Wir arbeiten aktiv mit der Branche zusammen, um deren Meinung zu unserem Vorschlag zu erfahren, und wägen derzeit die Vorteile für die Branche gegen die Auswirkungen auf Chrome-Nutzer und andere Interessengruppen ab.
Zusätzliche Bits in reportWin()	Geben Sie in „reportWin()“ zusätzliche Bits der aktuellen Beschränkung von 12 vor der 3PCD an.	Wir arbeiten derzeit an Ansätzen, um diesen Anwendungsfall zu unterstützen. Es dauert einige Zeit, da wir auch nach Ansätzen suchen, die uns helfen können, einen langfristigen Datenschutzplan zu haben.
Auktionsdesign	Anfragen für eine einzelne Auktion, bei der Rendering-URLs mit der entsprechenden Punktzahl zurückgegeben werden.	Wir haben in Betracht gezogen, mehrere Rendering-URLs und deren jeweilige Bewertung aus einer einzigen PA-Auktion zu verwenden. Aus Datenschutzgründen haben wir sie aber nicht implementiert. Wir verstehen, dass dieselbe Anzeige einem Nutzer nicht mehrmals auf einer Seite präsentiert werden soll, und begrüßen weitere Diskussionen auf GitHub.
reportWin	Beliebige Felder in der Funktion reportWin() protokollieren.	Dies geschieht bereits heute während der Testphase. Sobald Chrome die Unterstützung für Drittanbieter beendet, wird die forDebuggingOnly-Version der API migriert, um das Downsampling-Debugging zu ermöglichen. Weitere Informationen dazu finden Sie hier.
Komponentenverkäufer	Sie haben einen unabhängigen Mechanismus zur Zählung der eigenen Impressionen und anderer Ereignisse und müssen sich nicht ausschließlich auf die Berichte von Anzeigentechnologie-Anbietern verlassen können.	Diese Funktionsanfrage wird derzeit noch geprüft. Während der von Chrome unterstützten Testphase ist nicht geplant, dieses Problem zu beheben.
Cost-per-Click-Abrechnung	Implementieren Sie die Cost-per-Click-Abrechnung in der PA API.	Wir prüfen diese Anfrage hier und sehen derzeit Vorschläge zur Implementierung auf der aktuellen API-Oberfläche.
browserSignals	Fügen Sie „sendBidInSellerCurrency“ zur browserSignals-Spezifikation für die Berichterstellung für Verkäufer hinzu.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback hier.
Unterstützung von Metadaten und logischer Inhaberschaft auf Käuferseite für Nicht-DSPs	Das aktuelle Design der API könnte zu einer deutlichen Verschiebung bei Retargeting-Kampagnen auf Produktebene führen, bei denen Kampagnen unter Umständen auf Plattformen migriert werden müssen, die sowohl als DSPs als auch als DCO-Anbieter dienen.	Wir besprechen dieses Problem derzeit und freuen uns über zusätzliches Feedback hier .
Unterstützung von Metadaten und logischer Inhaberschaft auf Käuferseite für Nicht-DSPs	Geben Sie Beispiele an, bei denen die DSP nicht der Inhaber von IG ist.	Uns ist bewusst, dass Nicht-Bieter einige Funktionen von IGs nutzen möchten, andere aber nicht. Wir prüfen derzeit aktiv Optionen für diese Anwendungsfälle und freuen uns über Feedback zu diesem Thema.
Zeitüberschreitungseinstellungen	Publisher sollten in der Lage sein, die Anzahl der IGs, die teilnehmen können, und das Top-Level-Zeitlimit bzw. das globale Timeout vorzugeben.	Uns ist bewusst, dass der Wunsch nach verbesserten Zeitüberschreitungskontrollen und einer besseren Transparenz zwischen der obersten Ebene und dem Komponentenverkäufer besteht, und wir prüfen diese Anfrage.
Mehrere Anzeigengrößen	PA API-Unterstützung für Anwendungsfälle mit mehreren Anzeigengrößen	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback von der Community.
Dokumentation	Gibt es eine Liste von IG-Attributen, die K-anon unterliegen?	Wir haben diese Frage hier beantwortet.
Debugging	Verbesserte Debugging-Funktionen für die PA API.	Wir wissen, wie wichtig zuverlässige Debugging-Tools für Entwickler sind, die mit der PA API arbeiten. Wir möchten die Nutzerfreundlichkeit für Entwickler verbessern, indem wir nach Möglichkeiten suchen, .well-known-Dateiabrufe besser in Entwicklertools zu integrieren. Unser Ziel ist es, in der Entwicklungsumgebung mehr Transparenz sowie Funktionen zur Fehlerbehebung zu bieten. Wir sehen uns dieses Problem hier genauer an und würden uns über zusätzliches Feedback freuen.
Labels	Haben alle Nutzer mit Behandlungslabels für Modus B die Privacy Sandbox APIs aktiviert?	Die Zuweisungen von Chrome-Testgruppen werden zufällig und unabhängig von den vom Nutzer konfigurierten Chrome-Einstellungen bestimmt. Diese APIs sind zwar möglicherweise für Nutzer in bestimmten Testgruppen verfügbar (z.B. treatment_1.*), aber ihre Funktionalität kann in den Chrome-Einstellungen geändert oder deaktiviert werden. Gruppe von Modus B „control_2“: Durch die Aufnahme in diese Gruppe werden die Privacy Sandbox-APIs für Relevanz und Messung grundsätzlich deaktiviert. Diese Einstellung kann vom Nutzer in den Chrome-Einstellungen nicht überschrieben werden.
API-Verwendung	Erfolgen der Aufruf von „reportWin()“ und das Anzeigen-Rendering parallel oder nacheinander?	reportWin() wird direkt nach Abschluss von runAdAuction() aufgerufen. Gleichzeitig kann das Anzeigen-Rendering gestartet werden, wenn das Auktionsergebnis in einem iFrame oder Fenced Frame platziert wird. Nachdem sowohl „reportWin()“ die Ausführung abgeschlossen hat und die Anzeige mit dem Rendern begonnen hat, werden die für „sendReportTo()“ bereitgestellten URLs abgerufen.
(Auch in vorherigen Quartalen angegeben) A/B Testing-Support	Fordern Sie Support für A/B-Tests an die PA API an.	Wir besprechen diese Anfrage hier und freuen uns über zusätzliches Feedback.
Anpassung an den Traffic	Ein Vorschlag von Google, die erforderliche Entscheidungsfindung über den KV-Server zu verwalten, ist nicht hilfreich, da Verkäufer nicht mit ihrem Backend interagieren können, was die Anpassung der Zugriffe erschwert.	Wie im GitHub-Problem erläutert, kann es Probleme mit dem Fingerprinting haben, wenn die Informationen darüber offengelegt werden, ob einzelne DSPs IGs haben. Wir haben andere Alternativen für das Problem vorgeschlagen und sind offen für weitere Vorschläge.
Anpassung an den Traffic	Caching-Mechanismen erhöhen die Komplexität und verhindern, dass DSPs die tatsächliche Form des Traffics erkennen, auf die sie bieten würden.	Der Caching-Mechanismus wurde lediglich als Vorschlag angeboten. AdTechs können die Vorschläge nutzen, die zu ihrem Anwendungsfall passen. Wir freuen uns über ein zusätzliches Gespräch.
Labels	Chrome sollte das Label als Parameter in Anfragen an vertrauenswürdige Server von Käufern und Verkäufern weitergeben.	Diese Anfrage scheint angemessen zu sein, da sie offenbar weitgehend auf das Ziel einer verantwortungsvollen Nutzung von IG-Daten ausgerichtet ist. Wir prüfen den Antrag jedoch derzeit und werden intern geprüft und werden im Laufe der Diskussion zu diesem Thema öffentliche Updates dazu veröffentlichen.
API-Verwendung	Die explizite Definition der Gruppe „control_1“ im Dokument „Zusätzliche CMA-Richtlinien für Dritte zu Tests“ wurde näher erläutert. Es besteht insbesondere die Befürchtung, dass eine Änderung der Formulierungen so fälschlicherweise so interpretiert werden könnte, dass alle Privacy Sandbox APIs aus „control_1“ ausgeschlossen werden müssen.	Wir haben in diesem GitHub-Thread unsere Meinung dazu geäußert. Wir können jedoch nicht für die CMA sprechen. Wir empfehlen Ihnen, Fragen in Bezug auf die Auslegung ihrer Testrichtlinien direkt an die CMA zu richten.
API-Verwendung	Lässt Chrome das Aufrufen von „joinAdInterestGroup()“ auf einer leeren Seite bei der Weiterleitung zu einer anderen Ressource zu?	Wenn ein Nutzer eine Website besucht, kann der Websiteinhaber die Möglichkeit zum Aufrufen von „joinAdInterestGroup“ an einen Dritten delegieren. Diese Delegierung ermöglicht es einem Drittanbieter, IGs zu erstellen, ohne eine Art von Weiterleitung über eine leere Seite hinzufügen zu müssen. Wir freuen uns über Feedback zu bestimmten Gründen, IGs mitten in einer Weiterleitung zu erstellen, anstatt den vorgesehenen Delegationsmechanismus zu verwenden.
API-Verwendung	Anzeigenplattformen sollten in der Lage sein, IGs auf die Seiten der Publisher zu schreiben, mit denen sie zusammenarbeiten, und dass sie dann die Berechtigung zum Bieten auf diese IG an einen bestimmten Käufer oder eine bestimmte DSP delegieren können.	Wir haben das Feedback erhalten und prüfen derzeit, ob eine solche Anfrage unterstützt werden kann. Wir freuen uns immer über zusätzliches Feedback.
API-Verwendung	Es gibt keine Benachrichtigung bei Verlust der Fehlerbehebung, wenn niemand eine PA API-Auktion gewinnt.	Die Funktionen „reportWin“ und „reportResult“ von Chrome sind für Berichte zu Erfolgen auf Ereignisebene im Privacy Auktionssystem (PA-System) vorgesehen. Werden alle Gebote während einer PA-Auktion abgelehnt, wird erwartet, dass diese Funktionen nicht aufgerufen werden, da kein Gewinner ermittelt wird. Ein kürzlich veröffentlichtes Update für Chrome kann Abweichungen erklären, bei denen an fürDebuggingOnly.reportAdAuctionLoss() übergebene URLs nicht im Bereich „Werbenetzwerk“ der Entwicklertools angezeigt werden. Wir empfehlen, diese Funktion mit einem Canary- oder Entwicklerkanal-Build von Chrome zu prüfen.
API-Verwendung	Kann die von „generateBid“ zurückgegebene „adCost“ negativ sein (sie ist bereits auf 2 Byte gerundet)?	„AdCost“ gibt die Klick- oder Conversion-Kosten des Werbetreibenden an, die von „generateBid()“ an „reportWin()“ übergeben werden. Dieser Wert kann null oder ein doppelter Wert sein. Negative Werte werden ignoriert und nicht übergeben. Der Wert wird beim Übergeben stochastisch gerundet.
API-Verbesserung	Können vertrauenswürdige Server und verschlüsselte Ausführungsserver statt Chrome für das Targeting / die Kohorten / die Attribution und Auktionen verwendet werden?	Sehen Sie sich am besten die TEE-basierten Komponenten und Optionen der PA API (z.B. KV-Server und B&A-Dienste) sowie die TEE-basierten Komponenten von Attribution Reporting und privaten Aggregationen (z.B. Aggregation Service) an, die diese Frage beantworten.
API-Verbesserung	Kann die Privacy Sandbox-Auktionsantwort eine Gebotsantwort (wie Header Bidding) und keine Anzeigenantwort (wie Anzeigen-Tags) sein?	Durch diese Art der Änderung werden die Datenschutzeigenschaften der PA API grundlegend verändert, weshalb wir dies nicht in Betracht ziehen.
Steuerelemente für Publisher	Können Publisher PA API-Creatives auf ihren Seiten blockieren?	Chrome bietet einen Vorschlag für das Scannen von Creatives in Echtzeit, der noch nicht für Tests verfügbar ist. Diese Funktion ist zwar noch nicht verfügbar, aber die meisten Sell-Side-Plattformen (SSP) haben dafür bereits entsprechende Lösungen entwickelt.
API-Verwendung	Welche Größenbeschränkung gilt für proKäuferSignale?	In der klassischen Form gibt es für „perBuyerSignals“ keine grundsätzlichen Größenbeschränkungen in Chrome. Die Haupteinschränkungen bestehen darin, dass die Daten JSON-serialisierbar sind und nicht zu einem übermäßigen Arbeitsspeicherverbrauch führen. Dabei ist zu beachten, dass sich sehr große und komplexe „perKäufersignal“-Signale negativ auf die Leistung auswirken können. Es gibt eine alternative Methode, um „perBuyerSignals“ über den „directFromSellerSignalsHeaderAdSlot“ zu übergeben. Bei diesem Ansatz werden perBuyerSignals-Daten innerhalb eines Headers übertragen. Für die gesamte Headerantwort gilt eine Größenbeschränkung von 10 KB. Darüber hinaus können einzelne Server ihre eigenen Einschränkungen für die maximale Headergröße auferlegen.
Dokumentation	Die Dokumentation zu „registerAdBeacon“ für Anrufe innerhalb von „generateBid“ muss geändert werden.	Wir haben diese Dokumentation am 17. Februar aktualisiert.
API-Verwendung	Wie wählt reportEvent die richtige Beacon-URL aus mehreren registrierten Optionen aus?	Jede Auktion führt zu einer separaten Konfiguration, die wiederum zu einer separaten Berichtsübersicht führt. Einzelne Auktionen und die daraus resultierenden Frames sind völlig voneinander getrennt und teilen keine Daten. Weitere Informationen finden Sie in der Erläuterung zu Berichten zu Fenced Frames-Anzeigen.
Chrome-UI	Fügen Sie in den Chrome-Entwicklertools auf dem Tab „Anwendung“ -> „Interessengruppen“ einen Filter hinzu, um nach dem Inhaber von IG (oder dem IG-Namen) zu filtern.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback von der Community.
monitorlose Chrome-Version	PA API-Unterstützung in Headless Chrome.	Einige Komponenten der PA API sind an Chrome gebunden, z. B. die K-anon-Aufrufe an die Google-Server, die im „alten“ monitorlosen Chrome möglicherweise nicht funktionieren. Wir gehen davon aus, dass dies durch die „neue“ Version von Headless Chrome in Chrome 112 behoben werden könnte.
API-Verwendung	Im Fall von Verlustberichten mit „reportAdAuctionLoss“ sehen wir in vielen Fällen „topLevelWinningBid=0“. Wie ist das zu verstehen?	Der Wert „topLevelWinningBid“ stammt aus der Funktion „scoreAd()“ innerhalb der Top-Level-Verkäuferkomponente. Dieser Wert spielt eine Rolle bei der Auktion der obersten Ebene. Wie in der Erläuterung zu sehen, bedeutet ein Wert von null oder eine negative Zahl für „topLevelWinningBid“, dass die entsprechende Anzeige die Auktion nicht gewinnen kann. Dieser Mechanismus kann beispielsweise eingesetzt werden, um Anzeigen herauszufiltern, die auf eine Interessengruppe ausgerichtet sind, die eine Anzeigen mit Kontext-Targeting nicht übertreffen. Obwohl ein topLevelWinningBid mit einem Wert von null ein Hinweis darauf sein kann, dass eine kontextbezogene Auktion erfolgreich war, berücksichtigt die Spezifikation der PA API, dass andere Faktoren zu diesem Ergebnis beitragen könnten.
Modus-A/B-Tests	Erläuterungen zur Verkehrsauswahl und Deaktivierungsaufforderungen.	Die Aufnahmekriterien für Modus A und Modus B sind identisch. Ziel ist es, Gruppen zu haben, die für den normalen Chrome-Traffic repräsentativ sind, solange sie die Privacy Sandbox APIs und die Labeling-Methode unterstützen, da einige Clientkonfigurationen nicht kompatibel sind. Für den Test ist es wichtig, nur mit Labels versehene Zugriffe mit anderen Zugriffen mit Labels zu vergleichen. Nutzer in Modus B haben den Schutz vor Tracking aktiviert und erhalten daher eine Benachrichtigung zu dieser Funktion.
API-Verbesserung	Kann „lifetimeMs“ als direkte Property in den „joinAdInterestGroup“-Aufruf aufgenommen oder als separates Argument verwaltet werden?	Wir berücksichtigen das Feedback der Webentwicklungs-Community zur Funktion "joinAdInterestGroup" im Rahmen des PA-API-Vorschlags sorgfältig. Ein wichtiger Diskussionspunkt konzentriert sich auf die optimale Methode für das Management der Lebensdauer von IG. Wir evaluieren derzeit die Vorteile eines separaten Arguments für den Parameter „lifetimeMs“, da er die Flexibilität und Anpassungsfähigkeit für mögliche zukünftige Verbesserungen der Spezifikation fördert. Wir werden dieses Problem hier besprechen und würden uns über zusätzliches Feedback freuen .
API-Verwendung	Potenzieller Anstieg falsch negativer Raten im PA API-Framework aufgrund von Konflikten mit Browser-IDs mit niedriger Entropie.	Das Chrome-Team arbeitet aktiv an der fortlaufenden Optimierung des PA API-Frameworks. Wir freuen uns über die Diskussion über fälschlich-negative Raten, die sich aus Browser-ID-Kollisionen ergeben. Wir werten dieses Feedback sorgfältig aus und arbeiten daran, dass aktualisierte Analysen alle relevanten Faktoren umfassend berücksichtigen. Unser Ziel ist eine Lösung, mit der die gewünschten datenschutzbezogenen Ergebnisse erzielt werden, während gleichzeitig Genauigkeit und Zuverlässigkeit aufrechterhalten werden. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Verwendung	Ist eine Browser-ID mit niedriger Entropie erforderlich, um zu verhindern, dass Clients wiederholt Join-Anfragen für dasselbe Objekt in einem k-Anonymitätssystem senden?	Wir wissen die laufende Diskussion über die Verwendung von Browserkennungen bei der Implementierung von k-Anonymitätssystemen zu schätzen. Uns ist bewusst, dass Sie im Hinblick auf die möglichen Auswirkungen dieser Kennungen auf den Datenschutz geäußert wurden. Bei der anfänglichen Implementierung wurde eine Kennung mit niedriger Entropie als Mechanismus zum Schutz vor Missbrauch verwendet. Wir erforschen aktiv alternative Techniken wie anonyme Zähltokens, bei denen der Datenschutz für Nutzer im Vordergrund steht und gleichzeitig die Integrität des Systems aufrechterhalten wird. Unser Ziel ist es, Lösungen zu finden, die ein Gleichgewicht zwischen einer verantwortungsbewussten Datennutzung und einem robusten Datenschutz bieten, und freuen uns über einen kontinuierlichen Austausch mit der Forschungscommunity. Wir diskutieren hier über dieses Thema und freuen uns über zusätzliches Feedback .
API-Verwendung	Unterstützt AMP (Accelerated Mobile Pages) die PA API?	Die PA API wird von AMP derzeit nicht nativ unterstützt. Sollte der Support durch AMP eine hohe Priorität haben, freuen wir uns über zusätzliches Feedback.
API-Verbesserung	Sie sollten den Typ aus den k-Anonymitätsprüfungen entfernen.	Wir prüfen das Feedback zur Optimierung von Anträgen auf k-Anonymität sorgfältig. Wir verstehen den Vorschlag, Parameter zu konsolidieren und Typen zu vereinheitlichen, um den Prozess zu optimieren. Unser Ziel ist es, Effizienz und Verwaltbarkeit zu gewährleisten. Wir evaluieren derzeit alle Optionen, während wir unsere Datenschutzlösungen weiterentwickeln. Wir werden dieses Problem hier besprechen und würden uns über zusätzliches Feedback freuen .
Chrome-UI	Fordern Sie ein Verfahren für weniger technisch orientierte Nutzer*innen an, mit dem sie die Google-Produkte, denen sie angehören, einfach aufrufen und verwalten können, einschließlich potenzieller Einstellungen für die Deaktivierung auf Websiteebene.	Wir sind uns bewusst, wie wichtig es ist, nutzerfreundliche Tools bereitzustellen, um Google-Mitarbeiter zu verstehen und zu verwalten. Wir haben verschiedene Methoden sorgfältig überlegt und sind zu dem Ergebnis gekommen, dass die Identifizierung von IGs anhand der Website, auf der sie hinzugefügt wurden, die beste Balance zwischen Klarheit und Datenschutz bietet. Die globale Verwaltung von Google-Diensten erfolgt derzeit in den Chrome-Einstellungen. Wir suchen ständig nach Möglichkeiten, die Nutzererfahrung in diesem Bereich weiter zu verbessern. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Sicherheit	Ist die PA API anfällig für Datenschutzlecks durch Anzeigeninteraktionen, selbst im Kontext von Fenced Frames?	Uns ist bewusst, dass durch ausgefeilte Anzeigeninteraktionen Datenlecks auftreten können. Wir untersuchen aktiv das Zusammenspiel zwischen Fenced Frames, der PA API und potenziellen Angriffsvektoren. Die Minderung von Datenschutzrisiken hat höchste Priorität. Wir sind bestrebt, solide Lösungen zu entwickeln, bei denen Innovation und Nutzerschutz gleichermaßen berücksichtigt werden. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
Latenz	Ist das Zeitlimit von 50 ms für die Gebotslogik des Käufers ein realistischer Wert?	Wir verstehen die Bedenken hinsichtlich möglicher Inkonsistenzen zwischen der Spezifikation und dem Zeitplan von Netzwerkanfragen für die Gebotslogik. Wir überprüfen aktiv die Spezifikationen, um ihre Genauigkeit sicherzustellen und die optimalen Standard-Zeitüberschreitungseinstellungen zu untersuchen, um Leistung und Machbarkeit in Einklang zu bringen. Wir werden dieses Problem hier besprechen und würden uns über zusätzliches Feedback freuen .
Dokumentation	Potenzielles Zeitleck in der Spezifikation, bei dem eine Website Rückschlüsse darauf ziehen könnte, ob eine Anzeige den k-Anonymitätsschwellenwert nicht erreicht hat, und mögliche Auswirkungen auf das websiteübergreifende Tracking.	Das Problem bezüglich eines potenziellen Zeitlecks ist uns bekannt. Wir haben eine Abweichung der Spezifikation bestätigt und ergreifen Maßnahmen, um den k-Anonymitätsstatus von Anzeigen vor der Auktion zu ermitteln, um solche Datenlecks zu verhindern. Wir nehmen diese Bedenken ernst und werden die Spezifikation entsprechend aktualisieren. Wir werden dieses Problem hier besprechen und würden uns über zusätzliches Feedback freuen .
API-Verwendung	Möglichkeiten zum Implementieren einer SSP-Sperrliste in der PA API	Uns ist bewusst, dass SSPs Mechanismen zur Verwaltung von Anzeigeneinschränkungen benötigen. Wir empfehlen Lösungen, bei denen die Bewertung direkt auf dem Gerät priorisiert und vorhandene Anzeigenmetadaten verwendet werden, um die Privatsphäre der Nutzer zu schützen und gleichzeitig Flexibilität zu ermöglichen. Wir sind bestrebt, mit Entwicklern zusammenzuarbeiten, um optimale Ansätze für die PA API zu finden. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Verwendung	Kann jemand seinen Browser anweisen, eine PA API auf eine Weise vorzutäuschen, die von Websites nicht erkannt wird?	Wir sind uns bewusst, dass die Deaktivierung der PA API in ihrer derzeitigen Form von Websites erkannt werden könnte. Wir arbeiten aktiv an Funktionen wie zusätzlichen Geboten und ausschließender Ausrichtung sowie an Fenced Frames-Renderings, um den Datenschutz zu verbessern und nicht erkennbare Deaktivierungsoptionen anbieten zu können. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
Modus-A/B-Tests	Traffic in Rechenzentren, der als Bericht dient 1.1.	Das Chrome-Team hat mit dem GAM-Team bestätigt, dass dieser Traffic jetzt aus dem Test herausgefiltert wird. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Verwendung	Effizienz und Fairness der interessenbezogenen Gruppenkäufer-Implementierung in der PA API	Wir sind uns der laufenden Diskussion über die Effizienz und Fairness des Felds „interestGroup Buyer“ in API-Auktionen für private Anzeigen bewusst. Wir sind uns der Vor- und Nachteile von Effizienz, Datenschutz und Marktgerechtigkeit bewusst. Verkäufer müssen zwar die Geschäftsbeziehungen mit Käufern verwalten, wir arbeiten jedoch an Möglichkeiten, den Zuordnungsprozess zu optimieren. Dazu können dynamische Anpassungen auf Basis von Echtzeitdaten und Hybridmodellen gehören. Wir arbeiten weiter daran, Lösungen zu finden, bei denen der Datenschutz für Nutzer im Vordergrund steht und die ein wettbewerbsfähiges Werbesystem unterstützen. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
Chrome-UI	Mögliche Speicherprobleme und eine klare Benutzeroberfläche in Bezug auf IG in Chrome.	Wir verstehen, dass Sie Bedenken bezüglich der Anzeige von IGs in den Entwicklertools geäußert haben. Während die aktuelle Ansicht alle IG-Ereignisse für die Nachverfolgung in der Vergangenheit abbildet, wissen wir, wie wichtig es ist, einen besseren Einblick in den aktuellen Status gespeicherter IGs zu bieten. Wir werden uns mit Optimierungen und möglichen Verbesserungen der Benutzeroberfläche befassen, um Entwicklerstatistiken zu verbessern. In Bezug auf die Speicherverwaltung soll die IG-Implementierung Speicherlecks verhindern, aber wir überwachen und optimieren die Ressourcennutzung kontinuierlich. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
Dokumentation	Beim ursprünglichen Poster tritt ein Fehler auf, wenn er versucht, benannte Anzeigengrößen direkt im Feld „sizeGroup“ der Funktion „joinAdInterestGroup“ zu verwenden. Er möchte wissen, ob dies beabsichtigt ist.	Wir wissen, wie wichtig die Optimierung der Anzeigenkonfiguration innerhalb der Funktion „joinAdInterestGroup“ ist. Wir arbeiten aktiv daran, diese Einschränkung zu beheben, und planen, diese Funktion in zukünftigen Updates zu aktivieren. Mit dieser Verbesserung möchten wir Entwicklern flexible und effiziente Tools für die Anzeigenverwaltung zur Verfügung stellen. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
Label für von Chrome unterstützte Tests	Fordern Sie direkte Daten zu Modus A im Vergleich zu Modus B und genaue Labels in sendReportTo an, damit wir den Test konsistent verfolgen können.	Wir besprechen diese Anfrage hier und würden uns über zusätzliches Feedback freuen.
Dokumentation	Ist der Domainname des Verkäufers zu Validierungszwecken in Anfragen enthalten, die an den vertrauenswürdigen Server eines Verkäufers gesendet werden?	Wir bestätigen, dass der Hostname-Parameter ursprünglich aus der Dokumentation zur Protected Audience KV Server API ausgelassen wurde. Wir möchten den Entwicklern versichern, dass der Domainname des Verkäufers automatisch in Anfragen an den vertrauenswürdigen Server des Verkäufers enthalten ist. Diese Funktion ist für zuverlässige Anzeigenvalidierungsprozesse unerlässlich. Wir haben die Dokumentation aktualisiert, um dieses Versäumnis zu beheben. Klarheit und Transparenz für die Entwickler-Community werden dabei weiterhin an erster Stelle stehen. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Verwendung	Mögliche Methoden, um den Namen „IG“ zu Berichtszwecken in Anzeigenimpressionen-Tracking-Aufrufe aufzunehmen.	Wir möchten eine Balance zwischen der Notwendigkeit zuverlässiger Meldemechanismen und dem Grundprinzip des Datenschutzes für Nutzer finden. Die Einbeziehung von IG-Namen in das Tracking von Anzeigenimpressionen unterliegt den Absicherungen der k-Anonymität, die verhindern sollen, dass einzelne Personen identifiziert werden. Wir werden weiterhin an innovativen Berichtslösungen arbeiten, wenn wir diese datenschutzbezogenen Einschränkungen einhalten. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Funktion	Anfrage für den vertrauenswürdigen Server des Käufers zum Empfang von HTTP-Headern für Kundenhinweise	Wir verfolgen diese Funktionsanfrage hier.
API-Verwendung	Ob für die Delegationsdatei das Laden des Headers „Access-Control-Allow-Origin“ erforderlich sein soll, da dadurch das Verhalten der IG-Mitgliedschaft für den Browser vorgegeben wird?	Wir sind bestrebt, uns an den Best Practices für die Websicherheit zu orientieren. Durch die Anforderung des Headers „Access-Control-Allow-Origin“ für Delegierungsdateien wird die Übereinstimmung mit den CORS-Prinzipien sichergestellt und die unbeabsichtigte Offenlegung vertraulicher Informationen verhindert. Wir arbeiten an Möglichkeiten, diesen Prozess zu optimieren und gleichzeitig einen hohen Sicherheitsgrad zu gewährleisten. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Verwendung	Ermöglichen Sie Ad-Servern, Creatives innerhalb des PA API-Frameworks zu personalisieren.	Wir wissen, welche Rolle Ad-Server bei der Creative-Personalisierung spielen können. Wir arbeiten aktiv an Lösungen zur Unterstützung von Ad-Servern innerhalb der PA API, z. B. das „gemeinsame IG“-Modell, bei dem Gebots- und Anzeigenlogik zur Auswahl der Anzeigen kombiniert werden kann. Unser Ziel ist es, ein Gleichgewicht zwischen der Bereitstellung zuverlässiger Anzeigen-Creative-Funktionen und dem Schutz der Privatsphäre der Nutzer zu finden. Wir freuen uns über eine weitere Zusammenarbeit und Feedback zur Weiterentwicklung der API, um den Anforderungen aller Beteiligten gerecht zu werden. Hier finden Sie weitere Informationen.
Bedenken im Hinblick auf Datenschutz	Verfügbarkeit alternativer Kennzeichnungen (z.B. RampID, ID5) in kontextbezogenen Gebotsanfragen untergraben, um die Datenschutzziele der PA API zu untergraben, da die websiteübergreifende Datenerhebung vereinfacht wird.	Uns ist bewusst, dass ein Zusammenhang zwischen websiteübergreifenden Kennungen und den Datenschutzzielen der PA API besteht. Publisher können diese Kennungen zwar gemeinsam nutzen, aber das Design der PA API zielt grundsätzlich darauf ab, die Anzeigenauswahl von der Notwendigkeit eines websiteübergreifenden Trackings zu entkoppeln. Wir setzen uns dafür ein, ein datenschutzkonformes Werbesystem zu schaffen, und empfehlen Entwicklern, den PA API-Ansatz zu priorisieren. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
Caching	Lässt sich verhindern, dass Gebots-Skripts in mehreren Auktionen wiederverwendet werden?	Wir erkennen das beobachtete Caching-Verhalten von Bidding-Skripts im PA API-Framework an. Zwar werden Standard-HTTP-Caching-Mechanismen unterstützt, das Risiko einer Wiederverwendung von Skripts in Auktionen besteht jedoch durch das Verhalten der Gerätesperrung und das Design von Gebots-Executors. Das Team untersucht Lösungen, um Käufern mehr Kontrolle über das Skript-Caching zu bieten und so ihre Gebotsstrategien effektiv zu verwalten. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Verwendung	Zentralisierte Berichte zu Gebotsaktivitäten für alle IGs für eine DSP unter Wahrung des Datenschutzes für Nutzer	Beim Entwerfen der PA API legen wir großen Wert auf den Datenschutz für Nutzer. Die direkte Meldung einzelner Gebotsereignisse ist aufgrund von Risiken beim websiteübergreifenden Tracking nicht möglich. Wir bieten jedoch Mechanismen wie freigegebener Speicher und private Aggregation. So erhalten DSPs zusammengefasste Informationen zur Gebotsaktivität, und zwar unter Einhaltung des Datenschutzes.
API-Verwendung	Der Abruf von sendReportTo() in reportResult() erfolgt nur in 94% der Zeit im Vergleich zu einem Abruf, der mit forDebuggingOnly.reportAdAuctionWin() registriert wurde.	Auch wenn sie nicht dasselbe Timing haben, ist es möglich, dass beide URLs gleichzeitig abgerufen werden. In einigen Fällen wurde das Worklet des Komponentenverkäufers verworfen und muss neu geladen werden, um dann die Funktion reportResult() auszuführen. Das Zeitlimit von 50 ms für „reportResult()“ wird jedoch weder durch die Zeit, die zum Abrufen der Bewertungslogik benötigt, noch von der Zeit, die das Worklet zum Aktualisieren benötigt, beeinflusst. Beachten Sie, dass Chrome Caching-Header verwendet, um das Abrufverhalten für den Fall zu definieren, dass das Worklet neu geladen werden muss. Weitere Informationen zu den Phasen einer PA-Auktion finden Sie hier.
k-Anonymität	Anfrage zur Bestätigung, dass der Name der interessenbezogenen Gruppe sich nicht auf die k-Anonymität der Anzeigenbereitstellung auswirkt	Damit ein Creative als k-anonym gilt, muss das Tupel aus IG-Inhaber-URL, Gebotsskript-URL, Creative-URL und Anzeigengröße im vergangenen Zeitraum (w) den angegebenen Grenzwert (k) erreichen. Der Status der k-Anonymität wird regelmäßig aktualisiert (p).
Chrome-UI	Vorschlag, die Art der „internen Sichtbarkeit“ zu bieten, die viele Frameworks für MVC, ORM usw. bieten. Beginnen Sie z. B. mit der einfachen Protokollierung ausgewählter interner Ereignisse in einem neuen Bereich unter „Entwicklertools“ > „Anwendung“ > „Anwendung“.	Wir besprechen den Vorschlag hier und freuen uns über zusätzliches Feedback.
Chrome-UI	Bei der Verknüpfung mit IG in den Entwicklertools werden keine priorisierten Elemente angezeigt.	Hier finden Sie Informationen zur Behebung dieses Problems.
API-Verbesserung	Es wäre besser, wenn der Creative-Ad-Server seine eigenen Ereignisse erfassen kann. Lässt sich eine Liste der zulässigen Tracking-Domains konfigurieren?	Hier haben wir Ihnen einen Vorschlag unterbreitet und würden uns über zusätzliches Feedback aus der Community freuen.
API-Funktionsanfrage	Kann die PA API erweitert werden, um Medientransaktionen ohne Echtzeitgebote zu unterstützen und kritische Anwendungsfälle wie Ad Serving und das Optimierungstool für Display-Kampagnen aufrechtzuerhalten?	Wir besprechen das hier und freuen uns über zusätzliches Feedback.
Zeitüberschreitung bei Auktionen für Publisher	Publisher müssen die Auktionsdauer steuern, um entgangene Impressionen zu verhindern, insbesondere bei Header Bidding-Konfigurationen, bei denen Anzeigen sequenziell ausgewählt werden.	Uns ist bewusst, wie wichtig es ist, Publishern eine detaillierte Kontrolle über Zeitüberschreitungen bei Anzeigenauktionen zu geben. Wir prüfen aktiv, wie ein globales Zeitlimit für Auktionen implementiert werden kann, möglicherweise innerhalb des „auctionConfig“-Objekts. Dabei berücksichtigen wir sorgfältig die Grenzfälle. Diese Funktion zielt darauf ab, die Ausführungsrate von Impressionen für Publisher zu optimieren. Wir arbeiten weiterhin mit der Community zusammen, um die beste Lösung zu finden. Wir besprechen das hier und freuen uns über zusätzliches Feedback.
API-Verbesserung	Beim aktuellen Design der erweiterten Conversions in der PA API sind die Metadaten aufgrund der langen Rendering-URLs sehr groß. Die Tester würden diese URLs gerne komprimieren, um die Effizienz zu steigern.	Wir wissen, wie wichtig es ist, die Größe von IG-Metadaten zu optimieren, insbesondere bei Anzeigenauktionen, bei denen die Effizienz besonders wichtig ist. Wir sind der Meinung, dass eine vorlagenbasierte Lösung zum Komprimieren von Rendering-URLs viel Potenzial bietet. Wir werden die vorgeschlagenen Vorlagendesigns sorgfältig evaluieren und sicherstellen, dass jede implementierte Lösung robuste Mechanismen zur Vermeidung von Missbrauch umfasst, um die Stabilität des Browsers aufrechtzuerhalten. Wir arbeiten weiterhin mit der Community für Webstandards zusammen, um unter Berücksichtigung dieser Aspekte einen optimalen Ansatz zu entwickeln. Wir besprechen das hier und freuen uns über zusätzliches Feedback.
API-Verwendung	Tester, die native Anzeigenformate verarbeiten, möchten den Privacy Sandbox-Auktionsprozess optimieren, indem sie mehrere Anzeigenergebnisse in einem einzigen Aufruf abrufen, um die Netzwerklast zu verringern und das Anzeigen-Rendering zu beschleunigen.	Uns ist bewusst, dass es im Hinblick auf das Rendering nativer Anzeigen in der Privacy Sandbox Leistungseinbußen gibt. Wir möchten ein Gleichgewicht zwischen Effizienz und einem starken Schutz der Nutzerdaten finden. Die Rückgabe mehrerer Anzeigen mit vollständigen Bewertungen beeinträchtigt den Datenschutz. Wir arbeiten jedoch aktiv an Möglichkeiten, den Auktionsprozess zu optimieren. Wir möchten die Unterstützung der PA API für native Anzeigenformate verbessern und nach alternativen Mechanismen suchen, um im Rahmen der strengen Datenschutzvorgaben der Privacy Sandbox die Effizienz zu verbessern. Wir besprechen das hier und freuen uns über zusätzliches Feedback.
API-Verwendung	Flexibilität bei der Bewertung und Sortierung von Anzeigengeboten in der Privacy Sandbox, insbesondere zur Darstellung von Prioritätsebenen oder privaten Marktplatzregeln	Wir wissen, wie wichtig es ist, die Bewertung und Sortierung von Anzeigen in der Privacy Sandbox genau zu steuern, insbesondere bei komplexen Gebotsszenarien. Wir kennen die Lösungsvorschläge, bei denen Tupel und mathematische Funktionen verwendet werden, um eine mehrdimensionale Bewertung zu erzielen, ohne den Datenschutz für Nutzer zu beeinträchtigen. Diese Ansätze können für Entwickler zwar komplizierter sein, bieten aber die notwendige Aussagekraft. Wir arbeiten an Möglichkeiten, diese Prozesse zu optimieren, zum Beispiel mithilfe von Hilfsfunktionen oder Richtlinien, um die Privacy Sandbox-Funktionen für die erweiterte Auktionslogik optimal zu nutzen. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
reportEvent()	Fügen Sie ein neues reserviertes Ereignis (z. B. ein automatisches Beacon) hinzu, das vom Browser ausgelöst wird, sobald ein Frame mit einem Anzeigen-Creative initialisiert wurde.	Wir besprechen diese Anfrage hier und freuen uns über zusätzliches Feedback.
adCost	Aufschlüsselung der Werbekosten zulassen.	Bei jedem Kostenwert wird eine begrenzte Anzahl von Informationen aus der Auktion ausgeschlossen. Es reicht aus, eine ganze Liste von N dieser Kosten zuzulassen, um eine gesamte Nutzerkennung zu senden und websiteübergreifendes Tracking zu ermöglichen. Wir sprechen über dieses Thema hier und würden uns über zusätzliches Feedback freuen.
resolveToConfig	Soll „ResolveToConfig“ von der obersten Ebene übernommen und in „browserSignals“ verfügbar gemacht werden?	Wir besprechen diese Anfrage hier und freuen uns über zusätzliches Feedback.
Bessere Tools	Gibt es so etwas wie chrome://topics-internals, aber für die PA API?	Nichts ist genau das Gleiche. Es gibt jedoch umfassende Entwicklertools für die PA API.
Labels	Kann Chrome mithilfe von Labels die 20% der K-Anon-Population identifizieren?	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback von der Community.
Dokumentation	Werden Privacy Sandbox-Auktions-Worklets zu Standard-Worklet-Typen?	Aufgrund der besonderen Datenschutz- und Sicherheitsanforderungen unterscheiden sich diese Worklets erheblich von den standardmäßigen Browser-Worklet-Typen. Daher gehen wir nicht davon aus, dass sie bald zu Standard-Worklet-Typen in der HTML-Spezifikation werden werden. Wir sind bestrebt, unsere Entwicklerressourcen mit klaren Erklärungen zur Implementierung und Ausführungsumgebung von Auktions-Worklets zu erweitern, damit diese Informationen für Privacy Sandbox-Teilnehmer besser zugänglich sind. Hierauf gehen wir näher ein.
BYOS-Schlüssel-Wert-Server (Bring-Your-Own-Server)	Parteien können möglicherweise mehrere IGs (vom selben Inhaber) abrufen, die von einem Nutzer über Abfragen von KV-Diensten in einer BYOS-KV-Service-Einrichtung verknüpft wurden.	Dies wird nicht mehr möglich sein, wenn KV-Server in TEEs ausgeführt werden, und wir können dafür sorgen, dass sie das veröffentlichte Vertrauensmodell einhalten.
userBiddingSignals	einen Teil von „userBiddingSignals“ aktualisieren und andere beibehalten.	Dies ist bereits möglich, ohne dass Änderungen an der API erforderlich sind.
API-Verwendung	Implementieren Sie Frequency Capping für mehrere Google-Konten innerhalb der Privacy Sandbox und verwenden Sie dabei gegebenenfalls den KV-Server oder geänderte „prevWinsMs“-Daten.	Wir wissen den Wunsch nach erweiterten Frequency Capping-Funktionen im Rahmen der Privacy Sandbox zu schätzen. Wir sind uns bewusst, dass die derzeitigen Einschränkungen beim Datenaustausch zwischen verschiedenen Google-Produkten Probleme bei der Umsetzung dieser Strategien mit sich bringen können. Der KV-Server bietet zwar einen möglichen Mechanismus mit geeigneten Datenschutzvorkehrungen, wir empfehlen Entwicklern jedoch, Lösungen innerhalb eines einzigen IG-Modells zu untersuchen. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.
API-Verwendung	Komponentenverkäufer (die an verschachtelten Auktionen in der Privacy Sandbox teilnehmen) benötigen Einblick in die Zeitüberschreitungen bei Auktionen auf oberster Ebene, um ihre eigenen Konfigurationen zu optimieren und unnötige Verzögerungen zu vermeiden.	Uns ist bewusst, dass es erforderlich ist, das Zeitlimit zwischen Top-Level-Verkäufern und Komponentenverkäufern innerhalb der Privacy Sandbox besser zu koordinieren. Wir prüfen derzeit die Einführung neuer Zeitüberschreitungsmechanismen, einschließlich eines potenziellen Zeitlimits für die gesamte Auktion, und suchen nach Möglichkeiten, Zeitüberschreitungen auf oberster Ebene auf Komponentenauktionen anzuwenden. Unser Ziel ist es, die Effizienz und Vorhersehbarkeit für alle Teilnehmer des Privacy Sandbox-Auktionsprozesses zu verbessern. Wir sprechen hier über dieses Problem und freuen uns über zusätzliches Feedback.

Protected Audience-Dienste

Feedback	Zusammenfassung	Chrome-Antwort
Vertrauenswürdige Ausführungsumgebungen	Ist die Ausführung von TEEs in öffentlichen Clouds kostspieliger als in lokalen AdTech-Rechenzentren?	Unsere Reaktion ist mit vorherigen Quartalen vergleichbar: Unser aktuelles TEE-Sicherheitsmodell profitiert von Implementierungen in öffentlichen Clouds. Insbesondere schützen die aktuellen hardwarebasierten TEEs nicht vor allen physischen Angriffen. Unsere bestehenden unterstützten Anbieter öffentlicher Clouds, AWS und GCP, haben Maßnahmen zur Minderung von physischen Zugriffsrisiken entwickelt und implementiert, auch durch Mitarbeiter. Weitere Informationen zum lokalen Support finden Sie unten. Nach Angaben von Anzeigentechnologie-Anbietern sind Cloud-Dienste teurer als lokale Rechenzentren für Anzeigentechnologie. Obwohl wir diese Aussagen nicht bewerten können, freuen wir uns über zusätzliches Feedback zu den Kosten und prüfen weiterhin, wie wir unseren TEE-Support erweitern können.
TEE	Unterstützung für TEEs in nicht öffentlichen Cloud-Umgebungen	Unsere Reaktion ist ähnlich wie in den vorherigen Quartalen: Wir suchen weiterhin nach Optionen, die über öffentliche cloudbasierte Lösungen hinausgehen, aber derzeit haben wir keine Pläne, lokale TEEs zu unterstützen. Derzeit sind wir angesichts der Sicherheitsanforderungen der Privacy Sandbox und der großen Herausforderungen, die lokale Bereitstellungen mit sich bringen, der Meinung, dass die weitere Erweiterung und Verbesserung cloudbasierter Bereitstellungen (z. B. die Unterstützung von Google Cloud zusätzlich zu AWS) für das System am vorteilhaftesten ist. Wir freuen uns jedoch über zusätzliches Feedback dazu, warum eine solche Anforderung angesichts der Datenschutz- und Sicherheitseinschränkungen notwendig und durchführbar ist.
Andere Cloud-Anbieter	Support für andere Cloud-Anbieter	Wir sind immer offen für Vorschläge für andere Cloud-Anbieter, planen aber zumindest, die GCP und AWS auch dann zu unterstützen, wenn 3PCD erzwungen wird. Weitere Informationen finden Sie in dieser Erläuterung.
API für B&A-Dienste	Wie sieht die Strategie von Google für die B&A Services API aus? Wird sie bei Geräteauktionen über oder unter der Protected Audience API im Chrome-Browser priorisiert?	Unsere Reaktion ist ähnlich wie in den vorherigen Quartalen: Wir arbeiten weiterhin an der aktuellen Entwicklung der Protected Audience-Gebote auf Geräten. Die B&A-Dienste wurden vorgeschlagen, um mögliche Lösungen für bestimmte Anwendungsfälle zu finden, bei denen die Rechenleistung oder die Netzwerkgeschwindigkeit des Geräts begrenzt sein kann.
Standardisierung	Die B&A-Services haben keinen Standardisierungsprozess durchlaufen.	Der Vorschlag für B&A-Dienste befindet sich in einer Phase des Standardisierungsprozesses und wir freuen uns über zusätzliches Engagement zur Unterstützung dieses Ziels. Er begann mit einem Vorschlag (basierend auf früheren Vorschlägen), wird im Rahmen einer umfassenden offenen Diskussion bei W3C öffentlich ausgearbeitet und interessierte Entwickler können damit beginnen, damit zu experimentieren und Feedback zu geben. Dies ist das übliche Muster bei der Entwicklung von Webfunktionen, wie es zum Beispiel in unserem Blogpost beschrieben wird.
KV-Server	Vollständige URL für das Content-, das Kontext- und das Website-Targeting dem Schlüsselwert-Server des Käufers bereitstellen.	Wir besprechen diese Anfrage hier und freuen uns über zusätzliches Feedback von der Community.
Dokumentation	Die Dokumentation zu „Vertrauenswürdige/erzwungene Komponenten vs. optional“ auf GitHub verursacht Verwirrung bei einigen Anzeigentechnologie-Anbietern, die über eigene Bereitstellungs-Images und -Infrastrukturen verfügen.	Wir arbeiten daran, die Dokumentation für „Vertrauenswürdige/erzwungene Komponenten im Vergleich zu optional“ zu verbessern, und würden gern Feedback von der Branche erhalten, wenn solche Arbeiten priorisiert werden müssen.
API-Verbesserung	Der HTTP-Statuscode eines KV-Serveraufrufs sollte auch für die Funktion „scoreAd()“ als Parameter verfügbar sein.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback von der Community.
Dokumentation	Geben Sie weitere Informationen dazu an, wie JS- und WASM-Arbeitslasten bei der UDF-Ausführung genau gehandhabt werden.	Wir arbeiten daran, diese Informationen zur Verfügung zu stellen, und freuen uns über zusätzliches Feedback.
Dokumentation	Anfrage zum Aktualisieren des Repository-Namens.	Wir haben das Repository in „protection-auction-key-value-service“ umbenannt. Dies entspricht dem Begriff für die Sammlung von Diensten, zu der dieses Feature gehört, die auch weitere Repositories wie die Protected Audience Services-Diskussion und die Protected Auktion Services-Dokumentation enthält.
Dokumentation	Verweis auf die Cloud Debugger API in bidding_auction_services_gcp_guide.md entfernen.	Wir haben die Dokumentation aktualisiert und die Referenz entfernt.
API-Verwendung	Die durch die KV-Suche erzeugte Latenz dauert mehr als 50 ms. Das dauert fast 100 ms. Haben Sie vielleicht einen Anhaltspunkt dafür, was bei anderen Verkäufern gut funktioniert hat? Haben Sie irgendwelche Vorschläge, wie sich die Zeitüberschreitungen und das Timing messen lassen?	Der Aufruf des KV-Servers erfolgt im Kontext der Script-Runner, also der speziellen geschützten Umgebung innerhalb des Chrome-Browsers. Die Informationen in diesen Skript-Runnern sollen vor nicht API-Zugriffen geschützt werden. Eine ausführliche Erläuterung finden Sie hier.
API-Verwendung	Gibt es ein Zeitlimit für eine Antwort des KV-Servers in einer bestimmten Zeit?	Verkäufer können das Feld „perBuyerCumulativeTimeouts“ in der Auktionskonfiguration angeben. Bei dieser Zeitüberschreitung wird die Zeit berücksichtigt, die zum Abrufen vertrauenswürdiger Gebotssignale benötigt wird.
Latenz	Wie geht das Privacy Sandbox-Team mit Latenzen um?	Strategien, mit denen wir die Latenz innerhalb akzeptabler Grenzen halten können, finden Sie hier.

Analyse digitaler Anzeigen

Attribution Reporting (und andere APIs)

Feedback	Zusammenfassung	Chrome-Antwort
Manuelle Kampagnenoptimierung	ARA unterstützt keine manuelle Kampagnenoptimierung.	Wir haben dieses Szenario mit dem AdTech-Team besprochen und Möglichkeiten aufgezeigt, wie ARA zur manuellen Kampagnenoptimierung verwendet werden kann. ARA wurde so konzipiert, dass es eine flexible Anpassung der Anzeigentechnologie und eine Vielzahl von Anwendungsfällen für AdTech-Lösungen ermöglicht. Einige Vorschläge wurden durch die Verwendung verschiedener flexibler Konfigurationen auf Ereignisebene und die Verwendung von Berichten auf Ereignisebene mit Zusammenfassungsberichten verwendet, um die Auswirkungen von Störfaktoren zu reduzieren und die Anforderungen an die manuelle und automatische Optimierung zu erfüllen. Wir freuen uns über zusätzliches Feedback zur Anpassbarkeit und Flexibilität von ARA-Konfigurationen.
Conversion-Art	Google lässt nur acht Conversion-Typen zu, was eingeschränkt ist.	Wir haben die meisten flexiblen Berichte auf Ereignisebene implementiert, die Anzeigentechnologien zusätzliche Flexibilität in Bezug auf die Anzahl der Berichtszeiträume, die Anzahl der Attributionsberichte und die Anzahl der verwendeten Triggerdaten bieten. AdTech-Unternehmen können eine Konfiguration auswählen, mit der bis zu 32 verschiedene Conversion-Typen erfasst werden können.
Limit für aggregierbare Berichtsereignisse	Die Mindestanzahl von 20 Conversion-Ereignissen pro Bericht mit Zusammenfassung ist nicht für kleinere Werbetreibende mit begrenztem Budget geeignet.	Es ist keine Mindestanzahl von Conversion-Ereignissen pro aggregierten Bericht erforderlich. Darüber hinaus gibt es eine Reihe von Designentscheidungen, um aggregierte Berichte für kleinere Werbetreibende zu optimieren. Dazu gehören das Ändern der Schlüsselstruktur / der erfassten Dimensionen, das Testen verschiedener Epsilon-Ebenen, das Testen längerer Batch-Häufigkeiten und das Testen verschiedener Beitragsbudget-Zuweisungen zwischen Analysezielen. Kleinere AdTech-Berichte können auch mit der Kombination von zusammenfassenden Berichten auf Ereignisebene experimentieren.
Echtzeitdaten	Da den DSPs keine Echtzeitdaten (z.B. zu Klicks, Sitzungen und Conversions) zur Verfügung gestellt werden, die sie verwenden, um ihre Gebotsstrategie anzupassen und eine bessere Kampagneneffektivität zu erzielen, ist das gegen die Verpflichtung zur Aufrechterhaltung bestehender Funktionen.	Auch bei Verwendung von ARA bleiben Klicks und Sitzungen in Echtzeit und Conversions werden immer nachträglich erfasst, auch bei Drittanbieter-Websites.
Fehlende Felder	Fehlende Anforderungen im Abschnitt zur vollständigen flexiblen Einführung von Ereignissen: i) das Feld „Währung“ und ii) das Feld „orderID“/„TransactionID“.	Derzeit werden die Felder „Währung“ und „Auftrags-ID / Transaktions-ID“ nicht als Teil der vollständigen flexiblen Ereignisebene unterstützt, da dies bei aktuellen Berichten auf Ereignisebene bereits möglich ist. Wir sind offen für zusätzliches Feedback zu diesen Bereichen und werden es noch einmal prüfen, ob es weitere Anwendungsfälle gibt, in denen diese Informationen erforderlich sind. Möglichkeiten zur Nutzung des aktuellen ARA-Designs zur Messung von Währungs- und Bestell-ID-Informationen: 1. Basierend auf dem Feedback wird die Währung durch den Standort des Nutzers bestimmt, der als Teil von „source_event_id“ hinzugefügt werden kann. So lässt sich feststellen, welche Währung verwendet wurde. 2. Basierend auf dem Feedback wird das Feld für die Bestell-ID benötigt, um sicherzustellen, dass Conversions und Werte nicht versehentlich doppelt gezählt werden, was mit Deduplizierungsschlüsseln möglich ist.
Datenschutzbudget	ARA Privacy Budget schränkt die Möglichkeit ein, Messungen über mehrere Dimensionen hinweg zu messen	ARA wurde so entwickelt, dass Anzeigentechnologie-Anbieter ihre eigenen ARA-Konfigurationen anpassen können, um eine Vielzahl von Attributionsszenarien abzudecken. Beim aktuellen ARA-Design müssen Anzeigentechnologien einen Kompromiss zwischen den für sie wichtigsten Dimensionen und den Auswirkungen von Datenrauschen auf ihre Daten abwägen. Für den Datenschutz ist es von entscheidender Bedeutung, die Daten je nach Detaillierungsgrad der zu erfassenden Dimensionen mit Rauschen zu ergänzen. Wir sind offen für zusätzliches Feedback aus dem System, wenn es darum geht, Analysen über verschiedene Dimensionen hinweg durchzuführen.
Spezifikation aktualisieren	Obwohl Google angekündigt hat, dass es von festen zu flexiblen Zeitfenstern für Ereignisberichte gewechselt ist, wurde dies nicht in den technischen Spezifikationen von Google berücksichtigt, die derzeit noch ein Mindestfenster von einer Stunde haben.	Dank flexibler Berichte auf Ereignisebene können Anzeigentechnologie-Anbieter die Anzahl der Attributionsberichte pro Quellereignis, die Anzahl der Triggerdaten und die Anzahl bzw. Länge von Berichtszeiträumen ändern. ARA hat nach wie vor ein Mindest-Meldefenster von einer Stunde für Berichte auf Ereignisebene. Dies ist aus Datenschutzgründen und zur Vermeidung bestimmter Arten von Angriffen auf die Wiederherstellung des Verlaufs unerlässlich. Da zusammenfassende Berichte aggregierte Informationen enthalten, können Anzeigentechnologie-Anbieter bei Bedarf sofort und ohne Verzögerung zusammenfassende Berichte erhalten.
API-Design	Bedenken, dass die Reduzierung von Informationen in Conversion-Berichten und das Hinzufügen von Rauschen die Werbeplattform stärker beeinträchtigen könnten als von Google.	Google hat sich der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu gestalten und umzusetzen, dass der Wettbewerb nicht dadurch verfälscht wird, dass das eigene Unternehmen von Google bevorzugt wird. Außerdem müssen die Auswirkungen auf den Wettbewerb bei digitaler Werbung sowie auf Publisher und Werbetreibende aller Größen berücksichtigt werden.
Korrektur der Namensnennung	Mit ARA ist es dem Technologieanbieter nicht möglich, die korrekte Zuordnung zu kontrollieren und zu überprüfen.	Für ARA gibt es viele Möglichkeiten zur Überprüfung: 1. Anzeigentechnologie-Anbieter können prüfen, ob das ARA-Verhalten ihren Erwartungen entspricht: – Clientseitiger ARA-Code ist Open-Source. – Serverseitiger ARA-Code ist ebenfalls Open-Source-Code und Koordinatoren sorgen dafür, dass nur zulässige Versionen von Aggregation Service aggregierbare Berichte entschlüsseln und verarbeiten können. 2. Chrome stellt Anzeigentechnologie-Anbietern eine Simulationsbibliothek zur Verfügung, mit der das Attributionsverhalten überprüft werden kann. Dort kann getestet werden, wie die ARA die Attribution in einer simulierten Umgebung durchführt. 3. ARA unterstützt eine Reihe von Debug-Signalen, mit denen Sie prüfen können, ob und warum die erwartete Verarbeitung nicht stattgefunden hat.
(Auch in früheren Quartalen gemeldet) Rauschen	Feedback, dass das Rauschen zu hoch ist und den Nutzen der Berichterstellung beeinträchtigt	Wir haben mit demselben Feedback auch mit Anzeigentechnologie-Anbietern gesprochen und konnten herausfinden, wie ARA selbst bei verrauschten Anwendungsfällen besser auf ihre Anwendungsfälle abgestimmt werden kann. Die Entwicklerdokumentation enthält die meisten Designentscheidungen und Anpassungen, die wir mit den Anzeigentechnologie-Anbietern besprochen haben. ARA wurde so konzipiert, dass Anzeigentechnologie-Anbieter ihre eigenen ARA-Konfigurationen für eine Vielzahl von Attributionsszenarien anpassen können. Aber Anzeigentechnologie-Anbieter müssen überlegen, welche Dimensionen für sie am wichtigsten sind, und die Auswirkungen des Rauschens auf ihre Daten. Wir sind offen für zusätzliches Feedback aus dem System zu den Auswirkungen des Rauschens und können Ihnen zusätzliche Tipps zu ARA-Maßnahmen geben, mit denen die Auswirkungen des Rauschens verändert werden können.
Domainübergreifende Attribution	Wie erfasse ich domainübergreifende Attributionen?	Bei diesem Anwendungsfall können Anzeigentechnologie-Anbieter zu verschiedenen Berichts-URLs weiterleiten. Wir freuen uns über zusätzliches Feedback aus dem System zu diesem Designaspekt von ARA.
API-Verbesserung	Ändern Sie regelmäßig den Skalierungsfaktor, der beim Registrieren der Attribution für ARA-Zusammenfassungsberichte verwendet wird.	Aus der Diskussion auf GitHub geht hervor, dass die Verarbeitung mehrerer Skalierungsfaktoren im Aggregation Service höchstwahrscheinlich zu einer höheren Menge an Rauschen in den Zusammenfassungsberichten führen wird als bei der aktuellen Funktion. Wir sind offen für zusätzliches Feedback bezüglich der Notwendigkeit von Skalierungsfaktoren im Rahmen von aggregierten Berichten, möchten aber auf den potenziellen Kompromiss bei einem erhöhten Rauschen hinweisen. Wir prüfen auch, ob dieser Anwendungsfall auch mit anderen zukünftigen ARA-Funktionen behoben werden könnte.
API-Verwendung	Möglichkeit, die Art und Weise zu vereinheitlichen, wie Attributionsereignisse mit allen Teilnehmern geteilt werden, was für SSP, DSP usw. von Vorteil ist.	Wir planen, mit den Anzeigentechnologie-Anbietern zusammenzuarbeiten, um ihr Feedback besser zu verstehen und etwaige Einschränkungen zu verstehen, denen sie begegnen.
Traffic-Volumen testen	Ist der Testtraffic für Modus B für alle Chrome-Versionen stabil?	Die Aufnahme in eine Testgruppe ist unabhängig von den Chrome-Einstellungen nicht betroffen.
Dokumentation	Unterstützen Sie ARA für Pixel.	Wir haben Informationen dazu veröffentlicht, wie dieser Anwendungsfall unterstützt werden kann, und freuen uns über zusätzliches Feedback.
API-Verwendung	ARA wird für Drittanbieter auf E-Commerce-Plattformen möglicherweise nicht der richtigen Quelle zugeordnet, wenn die Conversion nicht durch die letzte Berührung erfolgt.	Unternehmen können Filter verwenden, um eine falsche Zuordnung zu verhindern, da kein Conversion-Bericht erstellt wird. Wir arbeiten auch an einem Vorschlag für eine Vor-Attributionsfilterung, um diesen Anwendungsfall zu vereinfachen.
Unterstützte Browser	Wird ARA in verschiedenen Browsern unterstützt?	Wir begrüßen auch andere Browser, die die Privacy Sandbox APIs verwenden, und nehmen sich auch weiterhin Zeit, unseren Ansatz auf W3C zu diskutieren. Wir haben ausdrücklich erklärt, dass Interoperabilität als Ziel für die Bereitstellung von ARA und das Design von ARA mit flexiblen, anbieterspezifischen Werten für Anbieter mit unterschiedlichen Datenschutzansätzen geeignet ist. Andere Browser entscheiden selbst, ob sie die Website-übergreifenden Alternativen unterstützen. Wir freuen uns, dass Microsoft Edge angegeben hat, dass es ARA unterstützt.
API-Verwendung	Welche Quellart wird für ARA-Quellenregistrierungen für RegisterAdBeacon/reportEvent (und automatische Beacons für navigation_start/commit) erwartet?	Das hängt davon ab, ob diese Beacons automatisch oder manuell sind: - reserviert.* (d.h. automatische) Ereignisse vom Typ „Navigationsquelle“. – Manuell ausgelöste Ereignisse vom Typ „Ereignisquelle“.
API-Verwendung	Bedeutet die Höchstzahl von 20 aggregierbaren Berichten pro Quelle für jedes Quellereignis? Gilt das Limit global oder täglich? Ist eine Erhöhung des Limits geplant?	Das Limit von 20 aggregierbaren Berichten pro Quelle ist ein globales Limit, bei dem 20 aggregierbare Berichte pro Quelle erstellt werden können. Das Limit wird vom Browser festgelegt und ist nicht konfigurierbar. Mit dieser Begrenzung soll ein Missbrauch des Schutzes von echten Attributionsberichten mit Null-Berichten vermieden werden. Hierauf gehen wir näher ein.
API-Verwendung	Unterstützung für E-Mail-Marketing mit ARA	Derzeit gibt es keine direkte Unterstützung für diesen Anwendungsfall innerhalb von ARA, wenn Sie die E-Mail-Hosting-Website nicht verwalten. Wir sprechen über dieses Thema hier und würden uns über zusätzliches Feedback freuen.
Epsilon	Wann wird der Wert von Epsilon für die Aggregate API ermittelt?	Der aktuelle Epsilon-Wert kann von Anzeigentechnologie-Anbietern bis zu einem in der Privacy Sandbox festgelegten Grenzwert konfiguriert werden (derzeit 64). Wir empfehlen, verschiedene Epsilon-Werte zu testen, Wendepunkte für Ihre eigenen Anwendungsfälle zu ermitteln und Feedback zu geben. Wir werden die Anzeigentechnologie-Anbieter vorab informieren, bevor wir den Bereich der Epsilon-Werte ändern.
API-Verbesserung	Verwenden Sie einen Anwendungsfall, bei dem Werbetreibende eine Kennung in das Feld „trigger_data“ einfügen können, um den Abgleich mit externen CRM-Daten durchzuführen, damit Werbetreibende die Qualität der Conversions prüfen können.	Wir besprechen die Anfrage derzeit und freuen uns über zusätzliches Feedback hier.
API-Verwendung	Weiterleitungs-URLs als Ziel-URLs verarbeiten	AdTech-Unternehmen haben folgende Möglichkeiten: 1. Geben Sie die finale Ziel-URL in das Feld „Ziel“ ein. 2. Im Feld „Ziel“ sind bis zu drei URLs zulässig, sodass Sie mehrere URLs eingeben können. Bei beiden Optionen ist die Angabe der endgültigen Ziel-URL erforderlich. Wir haben hier weiter darauf eingegangen .

Zusammenfassungsdienst

Feedback	Zusammenfassung	Chrome-Antwort
Wichtigster Erkennungsmechanismus	Anfrage für einen Schlüsselerkennungsmechanismus	Wir haben einen Vorschlag für die Schlüsselanalyse und freuen uns über Feedback aus der Branche zu diesem Vorschlag.
API-Verwendung	Roadmap für die Beobachtbarkeit im Aggregation Service	Wir prüfen derzeit Möglichkeiten, die Beobachtbarkeit zu verbessern. Hier können Sie uns Feedback geben.
API-Verbesserung	Anfrage zur erneuten Abfrage von Berichten	Der Aggregation Service arbeitet an einem Vorschlag für eine erneute Abfrage, bei dem AdTech-Unternehmen ihr Epsilon für jeden Bericht aufteilen können. Dies kann zu mehr Datenrauschen pro Abfrage führen, ermöglicht aber Anzeigentechnologie-Anbietern, Abfragen neu durchzuführen und den Datenschutz zu wahren.
API-Verbesserung	möchte in der Lage sein, mehrere Ursprünge mit derselben AWS-ID zu verknüpfen.	Mit dem Aggregation Service können jetzt mehrere Standorte über dasselbe Cloud-Konto (GCP oder AWS) eingerichtet werden. So können Anzeigentechnologie-Anbieter dieselbe Aggregation Service-Enklave verwenden, um Berichte von mehreren Websites und mehreren Ursprüngen von denselben Websites zu verarbeiten.
API-Verwendung	Wenn aggregierbare Batches fehlschlagen, wissen Sie nicht, ob das Budget aufgebraucht ist und ob der Batch noch einmal verarbeitet werden kann. Wenn bei einem Aggregationsdienst ein Budgetfehler für doppelte Berichte auftritt, gehen die restlichen Berichte verloren. Wie kann ich diesen Verlust minimieren?	In einem typischen Szenario wird das Budget nicht verbraucht, wenn der gesamte Job fehlschlägt. Sollte es selten zu Fehlern kommen, bei denen das Budget aufgebraucht wird, können AdTech-Mitarbeiter eine Wiederherstellung des Budgets anfordern. Sollten AdTech-Teams häufig Fehler aufgrund des erschöpften Budgets finden, sollten sie ihre Batch-Strategie überprüfen. Hier finden Sie eine Anleitung dazu, wie Sie Berichte korrekt im Batch erstellen und Fehler vermeiden. Wir freuen uns über Ihr Feedback zur Budgetausgleichung.
API-Verwendung	Wenn Sie die Private Aggregation API mit dem hier beschriebenen Trigger verwenden, wird ein zusammenfassender Bericht für jede Auktion erstellt. Welche Skalierungsfunktionen bietet Aggregation Service?	Der Aggregationsdienst selbst legt keine Obergrenze für die Anzahl der Schlüssel oder Berichte in einem Batch fest, aber eine Skalierung von 10^14 Berichten und 10^12 Schlüsseln wird derzeit aufgrund des erforderlichen Arbeitsspeichers nicht unterstützt. In unseren Größenempfehlungen finden Sie die Bereiche, die wir für eine optimale Leistung bei der erwarteten Last und den unterstützten Cloud-VM-Instanztypen getestet und empfohlen haben.
Datenverarbeitung	Wie sieht die rechtliche Vereinbarung zur Bereitstellung verschlüsselter Daten für den Aggregationsdienst aus, wenn verschlüsselte Daten personenbezogene Daten enthalten? Können Sie garantieren, dass der Koordinator nicht auf verschlüsselte Daten zugreifen wird?	Der Aggregationsdienst gibt keine verschlüsselten Daten bzw. Nutzerdaten an den Koordinator weiter. Der Aggregationsdienst verwendet den Koordinator für die Schlüsselverwaltung und Buchhaltung. Einige Details zum Koordinator finden Sie hier. Für die Buchhaltung gibt der Aggregationsdienst für die Budgetnutzung nur die gemeinsame ID und den Ursprung des Berichts an das PBS weiter. Sobald wir eine Website mit mehreren Websites einführen, ersetzen wir den Ursprung durch die Website. Hinweis: Der Aggregationsdienst wird in einem TEE ausgeführt. Dies ist der einzige Ort, an dem Berichte von Clients entschlüsselt werden können. Der im TEE ausgeführte Code ist Open Source und wird von externen Parteien geprüft, wie hier beschrieben.

Private Aggregation API

Feedback	Zusammenfassung	Chrome-Antwort
API-Verwendung	Möglichkeit von Komponentenverkäufern, Berichte an mehrere Aggregationsserver innerhalb eines TEE zu senden.	Der aktuelle Status der Private Aggregation API unterstützt dieses Feature nicht. Weitere Informationen zu diesem Problem finden Sie hier.
Dokumentation	Welcher Epsilon-Wert wird in den Tests von Google verwendet?	Für die Private Aggregation API entspricht der in einer Aggregationsdienstabfrage angegebene e-Wert dem L1-Beitragsbudget von 2^16, das auf einer rollierenden 10-Minuten-Basis erzwungen wird. Es gibt auch ein „Backstop“-Budget für L1-Beiträge von 2^20, das über einen rollierenden Zeitraum von 24 Stunden erzwungen wird. Der Datenschutzparameter hat also einen rollierenden Wert von 10 Minuten und ist 16 e pro rollierender 24-Stunden-Basis (statt 144 e). Der Aggregationsdienst unterstützt derzeit eine Reihe von e für Tests (bis zu 64), um Tests mit verschiedenen Aggregationsstrategien zu ermöglichen und Feedback zum Nutzen des Systems mit verschiedenen Datenschutzparametern für Private Aggregation und andere APIs zu geben. Wir planen, den maximal zulässigen Epsilon-Wert im Laufe der Zeit zu überprüfen, wenn wir Feedback von Testern erhalten und Funktionen hinzufügen, die eine effizientere Nutzung des Datenschutzbudgets ermöglichen.

Verdecktes Tracking einschränken

Reduzierung des User-Agents/Client-Hints beim User-Agent

In diesem Quartal gab es kein Feedback.

IP Protection (früher Gnatcatcher)

Feedback	Zusammenfassung	Chrome-Antwort
Lösungs-ID	Die Privacy Sandbox muss deutlicher formuliert werden, um zu betonen, dass Lösungs-IDs, die oft auf geistigem Eigentum basieren, für Werbetreibende nicht tragfähig sind.	Privacy Sandbox hat deutlich gemacht, dass wir das websiteübergreifende Tracking reduzieren wollen. Unsere öffentlichen Initiativen, die über Cookies hinausgehen, werden sowohl auf privacysandbox.com als auch auf GitHub veröffentlicht. Wir bemühen uns, das websiteübergreifende Tracking zu reduzieren, auch das auf Grundlage von IP-Adressen. Letztlich müssen jedoch die einzelnen Websites selbst entscheiden, ob websiteübergreifendes Tracking aktiviert wird. In einer Zeit, in der die Einhaltung gesetzlicher Vorschriften immer genauer unter die Lupe genommen wird, ist es für einzelne Unternehmen umstritten, die Praktiken ihrer Dienstleister zu verstehen.
Chromecast	Wirkt sich der IP-Schutz auf Chromecast oder andere Chrome-Geräte aus?	Derzeit gibt es keine Pläne für die Anwendung des IP-Schutzes auf Chromecast-Geräte.
IP-Schutzliste	Wird die Liste der Drittanbieter, die möglicherweise IP-Adressen für websiteübergreifendes Tracking verwenden, veröffentlicht?	Die Liste wird veröffentlicht, sobald sie fertiggestellt ist, wie hier beschrieben.

Eindämmung von Bounce-Tracking

Feedback	Zusammenfassung	Chrome-Antwort
Ausnahme für die Einmalanmeldung (SSO)	Wie wird die Bounce Tracking Mitigation (BTM) SSO-Anwendungsfälle für eine Ausnahme verifizieren?	BTM wird durch Chrome-Heuristiken deaktiviert. Weitere Informationen finden Sie hier.
Testzeitraum zur Einstellung	Ist BTM für Websites während des Einstellungstests von 3PC aktiviert?	Nein, BTM berücksichtigt die Cookie-Ausnahmen, die beim Einstellungstest erstellt wurden, wie hier beschrieben.

Datenschutzbudget

Wie in der Erklärung auf GitHub und der Entwicklerwebsite erwähnt,wird Privacy Budget nicht mehr aktiv als Teil der Privacy Sandbox-Vorschläge berücksichtigt.

Websiteübergreifende Datenschutzgrenzen stärken

Sets ähnlicher Websites (früher First-Party-Sets)

Feedback	Zusammenfassung	Chrome-Antwort
Feature Request (Funktionsanfrage)	Auf CHIPs und / oder die Speicherpartitionierung kann automatisch innerhalb der RWS zugegriffen werden, ohne dass die Storage Access API oder Nutzerinteraktion erforderlich ist.	Wir prüfen den Nutzen und die Durchführbarkeit einer Funktion, mit der diese Funktion ausgeführt werden kann. Eine mögliche Lücke bei der browserübergreifenden Interoperabilität, die durch RWS durch die Nutzung der Storage Access API beseitigt wird. Derzeit gibt es keine Entsprechung dieser angeforderten Funktion, die in anderen Browsern unterstützt wird. Wir empfehlen Entwicklern, hier ihre Anwendungsfälle zu diesem Thema einzureichen, um Diskussionen zu ermöglichen.
Nicht konforme Sätze entfernen	Wie werden nicht konforme Sets aus dem Repository entfernt?	Wir arbeiten an der Definition eines entsprechenden Verfahrens und informieren Sie, sobald diese verfügbar sind.
Durchsetzungsprozess	Es herrscht Unklarheit darüber, welche Rolle Google bei der Durchsetzung der RWS spielt.	Da RWS ein fortlaufendes Projekt ist und wir immer wieder neue Einreichungen erhalten, sind einige Aspekte des Verfahrens und unsere Kriterien noch nicht ausgereift. Wir stimmen zu, dass es wichtig ist, dass unsere Einreichungsrichtlinien vollständig umreißen, welche Anforderungen für die Einreichung gelten. Wir werden unsere Einreichungsrichtlinien in Zukunft noch genauer ergänzen, um weitere Unklarheiten und Unklarheiten zu vermeiden. Wir möchten das Einreichungsverfahren so technisch wie möglich gestalten, damit wir nicht mehr manuell in die Überprüfung einfließen und uns vollständig auf automatisierte Prüfungen verlassen können. PRs wie diese erfordern mehr menschliche Interaktion, da sie Verhaltensweisen umfassen, die wir nicht erwartet haben. Sie ermöglichen uns jedoch, weitere Bereiche für die Automatisierung zu identifizieren und Möglichkeiten zu finden, wie wir unsere Richtlinien korrigieren können, um diese Probleme in Zukunft zu vermeiden.
Daten hochladen	Anfrage für eine Funktion, mit der Domaininhaber mit der Einwilligung des Nutzers angeben können, dass ein Dritter RWS-Daten ebenfalls weitergeben soll.	Die angeforderte Funktion ist bereits über APIs wie FedCM und Storage Access APIs verfügbar, die den Zugriff auf die authentifizierte Identität ermöglichen, nachdem der Nutzer eine Berechtigungsaufforderung akzeptiert hat. Wir freuen uns über Feedback zu bestimmten Anwendungsfällen, die ihrer Meinung nach nicht möglich sind.
Andere Speichermethoden	Werden Informationen, die im lokalen oder Sitzungsspeicher gespeichert sind, ebenfalls als Drittanbieterdaten interpretiert?	Lokaler Speicher, Sitzungsspeicher und andere Formen von Nicht-Cookie-Speicherung, die in Drittanbieterkontexten verwendet werden, wurden seit Version 115 in Chrome partitioniert. Weitere Informationen finden Sie in diesem Blogpost.
Limit für verknüpfte Sätze	Was passiert mit Organisationen, die mehr als fünf Domains einreichen, obwohl dies auf fünf verknüpfte Websites beschränkt ist?	Diese Gruppen werden über den GitHub-Prozess akzeptiert, aber der Browser (Chrome) wendet die Regeln für die automatische Zuweisung der Storage Access API nur auf die ersten fünf Domains an. Die verbleibenden Domains werden wie hier beschrieben ignoriert.
find_robots_txt	Die Überprüfung „find_robots_txt“ funktioniert nicht bei Weiterleitungen.	Wir haben eine Korrektur gesendet, um das Problem zu beheben.
Nutzergeste	Die Anforderung an Nutzergesten für accessStorage() wurde entfernt.	Diese Anforderung basiert auf einem ähnlichen Design, das für alle gängigen Browser für die requestStorageAccess API gilt. Wir bitten Sie um zusätzliches Feedback und Anwendungsfälle zu diesem GitHub-Problem, damit wir diese Anfrage priorisieren und browserübergreifende Diskussionen ermöglichen können.
Nutzergeste	Ist eine Touch-Geste des Nutzers erforderlich, um nach einem Chrome- oder OS-Neustart die Berechtigung für den Zugriff auf Drittanbieterspeicher zu erteilen?	Ja, aber wir freuen uns über zusätzliches Feedback von der Community dazu, ob wir dieses Verhalten hier ändern können.

Fenced Frames-API

Feedback	Zusammenfassung	Chrome-Antwort
adComponent	Fehlende Dokumentation und Flexibilität bei der Verwendung von AdComponents mit Fenced Frames	Wir sind dabei, Ihnen weitere Informationen zu diesem Anwendungsfall zur Verfügung zu stellen. Außerdem werden Anzeigenkomponenten in Fenced Frames mithilfe von „getNestedConfigs()“ unterstützt, das in der Spezifikation dokumentiert ist.
(Auch in vorherigen Quartalen aufgeführt) „adComponent“ rendern	Anfrage nach Beispielcodes zum Rendern von adComponents in Fenced Frame	Wir arbeiten daran, einige Beispielcodes bereitzustellen.
Überprüfung von Drittanbieteranzeigen	Die Rolle der Anzeigenüberprüfung durch Drittanbieter im Zusammenhang mit Fenced Frames erfordert mehr Details, insbesondere im Hinblick auf die Kontext- und Markensicherheit.	Mit den Berichten zu Anzeigen mit Fenced Frames können DSPs Daten auf Impressions- und Auktionsereignisebene an Anzeigenprüfer von Drittanbietern senden, um die Markensicherheit nach dem Rendering und die Abrechnung zu überprüfen.
Erweiterbare Anzeigen	Anfrage zur Unterstützung von Expandable-Anzeigen	Wenn die Anzeige zwischen zwei Größen mit demselben Seitenverhältnis wechseln muss und es keinen funktionellen Unterschied zwischen den beiden gibt (nur die Größe), könnte der Einbettunger die Größe des Fenced Frame mit der zweiten Anzeigengröße ändern und der Browser das Fenced Frame-Element entsprechend skaliert.
(Auch in vorherigen Quartalen erfasst) Unterstützung für Video- und natives Inventar	Unterstützen Fenced Frames auch Videoinventar und natives Inventar?	Unsere Antwort ähnelt den vorherigen: Die PA API unterstützt das Video-Rendering mit einem Mechanismus, der auf iFrames basiert. Wir haben jedoch noch keine Lösung für das Rendering von Videos und nativen Anzeigen entwickelt, die mit Fenced Frames kompatibel ist. Dies ist einer der Gründe, warum wir uns entschlossen haben, die Durchsetzung von Fenced Frames bis 2026 zurückzuziehen. Das bedeutet, wenn ein Partner sich jetzt für die Durchsetzung von Fenced Frames entscheidet, kann dieser Partner keine Unterstützung für Video- und native Anzeigen bieten.
Beirat	Fordert die Einrichtung eines Beirats aus Anbietern von nativen Anzeigen auf, um sicherzustellen, dass die Implementierungen von Fenced Frames den Branchenstandards entsprechen.	Fenced Frames sind ab 2026 nicht zur Verwendung in der PA API erforderlich. Durch diese zusätzliche Zeit können wir in Zusammenarbeit mit der Branche weiter an der Entwicklung und Implementierung eines Supports für eine breitere Palette kritischer Anwendungsfälle arbeiten. Wie bereits angekündigt, werden wir Fenced Frames weiterentwickeln, bevor die Unterstützung für Video- und native Anzeigen mit der PA API auch weiterhin erforderlich ist. Gemäß unseren Verpflichtungen werden wir uns über solche Änderungen informieren und die CMA darüber informieren. Wir werden auch weiterhin auf Feedback aus dem Ökosystem eingehen, bevor wir Fenced Frames einführen. Unser Engagement-Modell beim W3C und Organisationen für Anzeigenstandards wie IAB Tech Lab ermöglicht es Branchenexperten aller Art, die Designs zu entwickeln, bevor sie benötigt werden.
(Auch in vorherigen Quartalen angegeben) Größenunterschied zwischen Plattformen	Gibt an, dass die Größe des im Fenced Frame angezeigten Contents auf Computern und Smartphones unterschiedlich aussieht.	Dies ist ein bekanntes Problem in Chromium, das wir untersuchen. Wir freuen uns über weiteres Feedback.
API-Verbesserung	Wurde die Anforderung für Fenced Frames ins Jahr 2025 verschoben, sodass native Anzeigen jetzt im Rahmen der Privacy Sandbox unterstützt werden?	Wie wir bereits in unserer öffentlichen Bekanntmachung zur Durchsetzung von Fenced Frames Anfang 2026 erwähnt haben, hatten wir von erheblichen Anstrengungen zur Unterstützung von Fenced Frames erfahren. Eine davon war zwar nativ, aber nicht der einzige Faktor. Ziel war es, mehr Zeit für die Unterstützung wichtiger Anwendungsfälle zur Verfügung zu stellen, einschließlich, aber nicht beschränkt auf native Anzeigen.

Shared Storage API

Feedback	Zusammenfassung	Chrome-Antwort
Leistung	Rückgabezeiten außerhalb des Worklets scheinen von der Aktivität im Worklet abhängig zu sein.	Hier besprechen wir das Testergebnis.
Stärkere Akzeptanz	Shared Storage sollte ein branchenweiter Standard sein, der in allen Browsern verfügbar ist.	Wir freuen uns über dieses Feedback und freuen uns immer über Feedback. Chrome nimmt weiterhin aktiv an W3C-Foren teil, einschließlich der WICG, um den Vorschlag zu fördern, Feedback einzuholen und die Akzeptanz voranzutreiben.
Gebots-Worklets	Ist es möglich, Daten aus dem freigegebenen Speicher innerhalb des GenerateBid, das bereits in einem Worklet ausgeführt wird, zu lesen, um die Anzeigenentscheidung bzw. Geschäftslogik (z. B. Frequency Capping) basierend auf websiteübergreifenden Informationen anzuwenden und eine Untergruppe von Anzeigen auszuwählen?	Nein, es ist nicht möglich, Daten aus dem freigegebenen Speicher innerhalb von Bidding-Worklets zu lesen.

CHIPS

Feedback	Zusammenfassung	Chrome-Antwort
Partitionskapazität	Es wurde das Verhalten bei Überschreitung der Partitionskapazität verdeutlicht.	Sobald die Kapazitätsgrenze erreicht ist, werden die ältesten Cookies von den Cookies, auf die zuletzt zugegriffen wurde, so lange ausgestoßen, dass diese so lange kostenlos werden, bis das Limit nicht mehr überschritten wird. Entwickler sehen den aktualisierten Cookie-Header in nachfolgenden Anfragen.
Zugriff auf Drittanbieter-iFrames	Eingebettete Inhalte von Drittanbieter-iFrames, die einen neuen Tab oder ein neues Fenster auf derselben Drittanbieter-Website öffnen, sollten auf dieselben partitionierten Cookies zugreifen können wie der Öffnende.	Wir diskutieren diesen Anwendungsfall und freuen uns über zusätzliches Feedback aus der Plattform.
Doppelte Cookies	Welchen Schlüsselwert sendet der Browser, wenn es ein partitioniertes und ein nicht partitioniertes Cookie mit demselben Namen gibt?	Wenn zwei Cookies mit demselben Namen vorhanden sind (eines partitioniert ist und eines nicht), erhalten Sie beide Cookies. Leider lässt sich das nicht unterscheiden. Die entsprechende RFC-Spezifikation finden Sie hier. Entsprechend der Reihenfolge, in der Cookies gesendet werden, sollte nicht vertraut werden.
Feature Request (Funktionsanfrage)	Aktivieren Sie nach Ursprung partitionierte Cookies.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback aus unserer Community.

FedCM

In diesem Quartal gab es kein Feedback.

So bekämpfen Sie Spam und Betrug

Private State Token API (und andere APIs)

Feedback	Zusammenfassung	Chrome-Antwort
Webansicht	Werden Private State Tokens (PSTs) für mehrere WebViews auf demselben Mobilgerät (Profil) beibehalten?	Jede App, die WebView verwendet, hat einen anderen lokalen Speicher. Das bedeutet, dass PST-Aussteller keine Tokens in der WebView einer App ausstellen und später in einer separaten App das Einlösen von Tokens zulassen können. Dies gilt auch für andere Arten von Daten, die lokal in WebViews gespeichert werden, wie etwa Cookies. PSTs sind in WebView noch nicht vollständig verfügbar. Wir werden voraussichtlich bis Ende des zweiten Quartals weitere Informationen dazu bekannt geben.
Neuer Tokentyp	Vorschlag für einen neuen Tokentyp.	Wir sind dankbar für diesen Vorschlag und für die kontinuierliche Prüfung der Anwendung und Anpassung von PSTs. Wir freuen uns darauf, mehr über diesen Vorschlag bei den bevorstehenden Treffen der Gruppe zum Schutz vor Betrug im 2. Quartal 2024 zu erfahren.
Nutzeridentifikation	Wie wird verhindert, dass Nutzer anhand der bestimmten PST-Dateien eines Nutzers identifiziert werden?	Dies wird derzeit abgemildert, indem die Einlösungsversuche auf einer Website auf zwei Aussteller beschränkt werden, unabhängig davon, ob Tokens von diesem Aussteller verfügbar sind. Sie müssen einen Aussteller auf das Limit zählen, auch wenn keine Tokens verfügbar sind, da die Website sonst alle Aussteller durchlaufen könnte, bis eine positive Übereinstimmung gefunden wird.
Anmeldung	Wie lange dauert die Registrierung für PSTs?	Eine Registrierung ist auf absehbare Zeit weiterhin erforderlich, wie hier genauer erläutert.
Unterstützung für andere Chromium-Browser	Wird die PST-Ausstellerregistrierung für andere Chromium-basierte Browser über das Registrierungs-Repository für den Chrome-Aussteller unterstützt?	Chrome ruft die Schlüsselzusicherungen ab und verteilt sie über einen Mechanismus namens „Component Updater“ an Chrome-Clients. Da andere Browser die API umfassender unterstützen, müssen sie einen Prozess zum Empfang der wichtigsten Zusicherungen an den Client definieren, entweder über eine Methode im Stil eines Komponenten-Updates oder eine andere Methode. Hier erfährst du mehr dazu.