Feedbackbericht – Q1 2024

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Quartalsbericht für das 1. Quartal 2024 mit einer Zusammenfassung des Feedbacks zum Privacy Sandbox-Vorschlag und zur Antwort von Chrome.

Im Rahmen seiner Verpflichtungen gegenüber der CMA hat sich Google verpflichtet, vierteljährlich öffentliche Berichte zum Prozess der Stakeholder-Beteiligung an seinen Privacy Sandbox-Vorschlägen zu veröffentlichen (siehe Paragraf 12 und Paragraf 17(c)(ii) der Verpflichtungen). Für die Feedbackberichte werden die Rückmeldungen aggregiert, die das Chrome-Team aus den verschiedenen Quellen erhält, die in der Feedbackübersicht aufgeführt sind, darunter: GitHub-Probleme, das Feedbackformular, das unter privacysandbox.com verfügbar ist, Besprechungen mit Branchenvertretern und Foren für Webstandards. Wir freuen uns über das Feedback, das wir aus der Community erhalten haben, und suchen aktiv nach Möglichkeiten, die Erkenntnisse in Designentscheidungen einfließen zu lassen.

Feedbackthemen werden nach Häufigkeit pro API sortiert. Dazu wird die Menge des Feedbacks, das das Chrome-Team zu einem bestimmten Thema erhalten hat, zusammengefasst und in absteigender Reihenfolge nach Menge sortiert. Die häufigsten Feedbackthemen wurden anhand von Diskussionsthemen aus öffentlichen Treffen (W3C, PatCG, IETF), direktem Feedback, GitHub und häufig gestellten Fragen identifiziert, die über die internen Teams von Google und öffentliche Formulare aufkamen.

Insbesondere wurden die Protokolle der Sitzungen von Webstandards-Organisationen überprüft. Für direktes Feedback wurden die Aufzeichnungen von persönlichen Stakeholder-Sitzungen von Google, E-Mails, die von einzelnen Entwicklern empfangen wurden, die API-Mailingliste und das öffentliche Feedbackformular berücksichtigt. Google koordinierte dann die an diesen verschiedenen Outreach-Aktivitäten beteiligten Teams, um die relative Verbreitung der Themen in Bezug auf die einzelnen APIs zu ermitteln.

Die Erläuterungen zu den Antworten von Chrome auf Feedback wurden anhand veröffentlichter FAQs, tatsächlicher Antworten auf von Stakeholdern angesprochene Probleme und einer speziell für diese öffentliche Berichterstattung festgelegten Position entwickelt. Entsprechend dem aktuellen Schwerpunkt der Entwicklung und Tests haben wir vor allem Fragen und Feedback zu den APIs Topics, Protected Audience und Attribution Reporting erhalten.

Für Feedback, das nach dem Ende des aktuellen Berichtszeitraums eingegangen ist, wurde möglicherweise noch keine Chrome-Antwort berücksichtigt.

Glossar mit Akronymen

ARA

Attribution Reporting API

CHIPS

Cookies mit unabhängigem partitionierten 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

NSZ

Origin-Testversion

PAT API

Protected Audience API (früher FLEDGE)

PatCG

Private Advertising Technology Community Group

RP

Vertrauende Partei

RWS

Gruppen ä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

WIPB

Willful IP Blindness

Allgemeines Feedback, keine bestimmte API oder Technologie

Feedbackthema	Zusammenfassung	Chrome-Antwort
Governance	Interesse an einer öffentlichen Kommentarphase für alle Governance-Änderungen an der Privacy Sandbox.	Wir sind offen für angemessenes Feedback von Stakeholdern zu allen wichtigen Entwicklungen im Zusammenhang mit der Privacy Sandbox, einschließlich der zukünftigen Governance der Privacy Sandbox.
Test	Zusätzliche Testphasen für 3PCD zusätzlich zu den aktuellen 1% von Chrome unterstützten Tests.	Wir haben nicht vor, Chrome-gestützte Tests über die aktuellen 1% der Chrome-Zugriffe hinaus anzubieten, die seit Anfang Januar aktiviert sind.
Web to App	3PCD auf Mobilgeräten sollte erst erfolgen, wenn die vollständige Interoperabilität zwischen Web und App erreicht ist.	Wir sind der Meinung, dass die Interoperabilität zwischen Apps und dem Web unterstützt werden sollte. Deshalb haben wir die App- und Web-Attribution eingeführt und arbeiten an Lösungen für das Web-zu-App-Targeting. Die Einführung von 3PCD im mobilen Web wird jedoch nicht verschoben. Wir haben kein Ziel, am Ende des 3PCD eine Abdeckung von 100% zu erreichen. Wir gehen davon aus, dass die Kompatibilität bei Android für die App- und Web-Messung bei 3PCD relativ hoch ist und mit der Zeit zunimmt, wenn Nutzer ihre Smartphones aktualisieren.
Rolle des Browsers	Chrome übernimmt offenbar die Rolle eines Ad-Servers oder SSP.	Chrome übernimmt nicht die Rolle eines Anzeigenservers oder einer SSP. Mit der PA API bietet Chrome einen Container für Ad-Server, Sell-Side-Plattformen, Demand-Side-Plattformen und andere Anzeigentechnologien, um ihre eigene Gebots- und Bewertungslogik einzubringen.
Anleitung für Anwendungsfälle	Deutlichere Hinweise dazu, welche Anwendungsfälle von Privacy Sandbox APIs unterstützt werden.	Zu Beginn des Privacy Sandbox-Projekts lag der Schwerpunkt der Entwicklerdokumentation vor allem darauf, Entwickler in die Diskussion und den Feedbackprozess für alle Vorschläge einzubinden. Das bedeutete, dass die Inhalte im Allgemeinen auf die Motivation und die Konzepte hinter dem Projekt ausgerichtet waren, gefolgt von Details zur frühen Entwicklung und zu den Tests für jedes Angebot. Das war effektiv, um eine echte Zusammenarbeit im Ökosystem bei der Entwicklung der Vorschläge zu ermöglichen. Da die APIs jedoch zur allgemeinen Verfügbarkeit übergegangen sind, gibt es eine neue Zielgruppe von Entwicklern, die die APIs in erster Linie nutzen, anstatt zur zugrunde liegenden Entwicklung beizutragen. Wir haben vor Kurzem die Navigation der Privacy Sandbox-Entwicklerwebsite auf den Anwendungsfall ausgerichtet und dabei ähnliche Kategorien wie das IAB Tech Lab in seinem aktuellen Bericht der Privacy Sandbox Task Force verwendet. Dieser anwendungsfallbasierte Ansatz für die Dokumentation wird auch in Zukunft beibehalten.
Lokale Entwicklungsumgebung	Wie können wir unser Frontend lokal unter http://localhost weiter entwickeln und testen, wenn das Cookie „SameSite=Secure“ ist und das Back-End von einem CDN verwaltet wird?	Hier diskutieren wir dieses Problem und freuen uns über zusätzliches Feedback aus der Community.
Abhilfe bei der Einstellung von Drittanbieter-Cookies	Gibt es eine programmatische Möglichkeit, festzustellen, ob Drittanbieter-Cookies blockiert sind oder Heuristiken aktiv sind?	In Chrome können Entwickler sowohl über die Funktionserkennung als auch über document.hasStorageAccess, das in einem IFrame aufgerufen wird, feststellen, ob der Ursprung im IFrame Zugriff auf Drittanbieter-Cookies hat.
Videotests	Videoanzeigen können derzeit nicht in der Privacy Sandbox getestet werden.	Chrome hat eine Diskussion und eine Demonstration verschiedener Möglichkeiten veröffentlicht, wie Videoinhalte mit der PA API erstellt werden können (siehe 242 und 254 in unserem Demo-Repository auf GitHub). Hinweis: Dieser Code ist nicht als Beispielcode gedacht, der von Anzeigentechnologien in großem Umfang übernommen werden soll, sondern als Proof-of-Concept und Demonstration der Techniken, die das VAST-Video-Rendering mit der PA API unterstützen könnten. Im Laufe dieser Diskussion wurde auch klar, dass das Video-Rendering zwar bereits heute möglich ist, es aber Änderungen an Chrome geben könnte, die die Implementierung mit der PA API vereinfachen würden. Beispielsweise werden wir auf Grundlage des Feedbacks zu Anwendungsfällen für die Markensicherheit von Drittanbieter-Anzeigenprüfern Änderungen an der Makrosubstitution vornehmen, die wir bereits geplant hatten ( weitere Informationen). Dadurch wird auch das Feedback im Anwendungsfall für Videoanzeigen berücksichtigt, bei dem der Käufer wissen möchte, welche Verkäufermakros beim Rendern verwendet werden sollen. Bisher haben sich die meisten Diskussionen vor allem auf das Rendern von VAST-Videoanzeigen konzentriert. Beim Rendern nativer Anzeigen könnten dieselben Ansätze verwendet werden. Das ist in vielerlei Hinsicht einfacher. Native Anzeigen erhalten derzeit weniger Aufmerksamkeit als Videoanzeigen. Das liegt jedoch nur an der Priorisierung der Anzeigentechnologiebranche und nicht an technischen Hürden bei der Implementierung.
Nicht werbebezogene Messung	Die 3PCD-Technologie kann sich auf nicht werbebezogene Lösungen zur Zielgruppenanalyse auswirken.	Die Mess-APIs erfordern nicht, dass der Anwendungsfall werbebezogen ist. Während ARA auf einen typischen Werbekaufprozess ausgerichtet ist,ist Private Aggregation allgemeiner einsetzbar. Mit diesen beiden Bausteinen lassen sich eine Vielzahl von Analyseaktivitäten abdecken.
Videokünstler	Die Privacy Sandbox soll Creator dazu anregen, mehr Inhalte für YouTube und weniger auf ihren eigenen Websites zu erstellen.	Ziel der Privacy Sandbox-Initiative von Google ist es, die Aktivitäten von Nutzerinnen und Nutzern in einem offenen und kostenlosen Internet privat zu halten. Wir wissen, dass Publisher auf Anzeigen angewiesen sind, um Inhalte zu erstellen und möglichst vielen Nutzern zugänglich zu machen. Werbetreibende helfen Nutzern, neue Produkte oder Angebote zu entdecken, die sie interessieren könnten. Mit den Privacy Sandbox-Funktionen können Websites aller Art, einschließlich solcher, die mit Creatorn zusammenarbeiten, Nutzern nützliche Anzeigen präsentieren, die auf ihren Aktivitäten bei verschiedenen Anbietern basieren, ohne dass die Identität des Nutzers für diese Anbieter offengelegt wird.
Deutlichere Zeitachsen	Klarere und detailliertere Zeitpläne für die Einführung der Privacy Sandbox-Technologien.	Die Dokumentation der Privacy Sandbox API enthält Seiten zum API-Status und zur Verfügbarkeit. Auf diesen Seiten werden anstehende Funktionen und deren Zeitpläne aufgeführt (z.B. PA API, ARA). Eine zentrale Übersicht dieser Status finden Sie hier.
Maschinelles Lernen	AdTech-Unternehmen können Modelle für maschinelles Lernen erst dann richtig trainieren, wenn der Wert für „3 Tage nach dem Kauf“ über 1 % liegt.	Die Ausweitung von 3PCD auf weitere Browser für Tests ist keine Garantie dafür, dass die APIs häufiger verwendet werden. Das ist aber vermutlich das, was Anbieter von Anzeigentechnologien suchen, um Modelle für maschinelles Lernen weiter zu trainieren. Wenn Anbieter von Anzeigentechnologien keine breitere Nutzung des Werbesystems zum weiteren Trainieren von Modellen für maschinelles Lernen anstreben, gibt es keinen Grund, die 3PCD zu erweitern. Anbieter von Anzeigentechnologien, die Modelle anhand von mehr Traffic trainieren möchten, können dies auch heute schon ohne erhöhte 3PCD tun. Dies kann geschehen, ohne dass Chrome vor dem Ende des Stillstands in 3PCD fortschreitet.
Nicht unterstützter Anwendungsfall	Self-Service-DSP-Anwendungsfälle werden derzeit nicht berücksichtigt.	Es gibt mehrere Self-Service-DSPs, die regelmäßig öffentliches Feedback zu den APIs geben. Einige dieser DSPs, die regelmäßig öffentliches Feedback geben, haben sich auch als Tester registriert. Außerdem befasst sich Chrome aktiv mit typischen Themen für Selfservice-DSPs wie Video und Ad-Server von Drittanbietern. Diese Themen wurden in den letzten wöchentlichen PA API-Anrufen behandelt.
Ursprungstest	OT-Anfrage für Websites, die eine schnellere Einführung und Testabdeckung für 3PCD wünschen.	In Chrome wird derzeit eine eigene OT entwickelt, mit der Ursprünge das Einstellungsverhalten für Drittanbieter-Cookies aktivieren können. Bei Ursprüngen der obersten Ebene, die sich für diesen Test registrieren und Tokens bereitstellen, werden 3PCs so blockiert, als wäre der Tracking-Schutz auf dem Nutzergerät aktiviert. Dieser Testzeitraum bietet Websites eine wertvolle Gelegenheit, langfristige Alternativen zu Drittanbieter-Cookies vor der endgültigen Einstellung von Drittanbieter-Cookies zu testen, die nach Rücksprache mit der CMA erfolgen soll. Wir arbeiten noch daran, den Zeitplan für die Einführung des Testzeitraums fertigzustellen.
IAB Tech Lab Report	Feedback zur Privacy Sandbox aus dem Bericht des IAB Tech Lab	Hier finden Sie unsere ausführliche Antwort auf den Bericht des IAB Tech Lab. Außerdem haben wir dort zugegeben, dass „der Bericht Fragen zu fragmentierter Dokumentation, kommerziellen Anforderungen, Prüfungen durch Dritte, Branchenakkreditierung, Skalierbarkeit, Transparenz und zukünftiger Governance aufwirft, zu denen wir uns mit der Branche austauschen und unsere öffentlichen FAQs entsprechend aktualisieren werden“. Wir haben bereits auf die unvollständige Dokumentation hingewiesen. Informationen zu kommerziellen Anforderungen finden Sie unter „Datengarantien“. Einige Google Ads-Produkte haben ihre Ansätze geteilt. Weitere Informationen zu externen Prüfungen finden Sie unter „Garantie für die Integrität von Algorithmen“. Bei der Akkreditierung gehen wir davon aus, dass diese Stellen weiterhin Produkte akkreditieren, einschließlich der Verwendung von Technologien, anstatt die Technologien selbst. In Bezug auf die Skalierbarkeit sind wir weiterhin offen für Daten von Entwicklern, die Probleme aufzeigen. In Bezug auf Transparenz und Governance arbeiten wir weiterhin offen auf GitHub und in Foren wie dem W3C, während wir uns im Rahmen der Verpflichtungen mit der CMA austauschen.
Google Log-in	Google-Anmeldungen würden es Google ermöglichen, Anmeldedaten zur geräteübergreifenden Identifizierung zu verwenden, was gegen die Verpflichtungen verstößt.	Google kann mit Google Sign-in keine Daten entgegen den Verpflichtungen verwenden.
Kompatibilität	Wie sieht es mit der Unterstützung von Privacy Sandbox-APIs und der Vorwärts-/Abwärtskompatibilität aus?	Sobald eine Chrome-Funktion allgemein verfügbar ist, möchten wir sie auch weiterhin unterstützen. Natürlich ist es nicht immer möglich, die Abwärtskompatibilität beizubehalten. In solchen Fällen haben wir einen klaren Prozess für die Einstellung und Entfernung bestehender Funktionen, der hier beschrieben ist. Wir werden die Privacy Sandbox APIs im Laufe der Zeit voraussichtlich um weitere Funktionen ergänzen, als Reaktion auf Feedback aus dem Ökosystem zu Anwendungsfällen, die von einer verbesserten Unterstützung profitieren würden. In solchen Fällen verwenden wir in der Regel eine Art Funktionserkennung, damit Anbieter von Anzeigentechnologien, die eine neue Funktion ausprobieren möchten, den Browser direkt fragen können, 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 gleichzeitig für alle Chrome-Nutzer eingeführt werden. Unsere Arbeit zur Feature-Erkennung für die PA API finden Sie hier.
Serverimplementierung	Anstatt eine eigene Implementierung zu verwenden, sollte Chrome die Verhaltensweisen angeben, die eine zufriedenstellende Implementierung eines Trusted Signals-Servers, eines Aggregationsservers und aller anderen erforderlichen nicht browserbasierten Komponenten erfüllen muss. Dies würde Innovationen innerhalb akzeptabler Datenschutzgrenzen ermöglichen.	Wir begrüßen den Wunsch nach Innovationen von externen Parteien. Wir möchten Werbetechnologieanbietern bei allen APIs und Diensten Flexibilität bei der Implementierung ihrer Funktionen bieten. So ist es beispielsweise zulässig, vertrauliche Geschäftsinformationen für die Entwicklung der Gebotslogik für Auktionen zu verwenden. Außerdem berücksichtigen wir kontinuierlich das Feedback von Anbietern von Anzeigentechnologien und binden es gegebenenfalls in unsere Designs ein. Damit andere ihren eigenen Code in Trusted Execution Environments ausführen können, muss der Code (und alle Änderungen) von der Privacy Sandbox geprüft werden, um sicherzustellen, dass die Datenschutzgarantien eingehalten werden. Das erfordert erhebliche Anstrengungen des Privacy Sandbox-Teams. Daher möchten wir wissen, welche Vorteile die Stakeholder erreichen möchten, die wir derzeit nicht bieten.
Heuristik	Was sind die langfristigen Pläne für Heuristiken?	Wie andere Browser auch, möchten wir diese Heuristiken nach und nach einstellen, sobald alternative Lösungen weithin verwendet werden. Dies ist jedoch abhängig von einer weiteren Machbarkeitsanalyse. Weitere Informationen dazu findest du hier.
Testvolumen	Unterschiedliches Traffic-Volumen beim Vergleichen verschiedener Dimensionen.	Der Test mit 1% hat Ausschlusskriterien, die zu Unterschieden bei der Teilnahmeberechtigung für verschiedene Gruppen von Chrome-Clients führen. Wenn der Test beispielsweise Chrome Enterprise-Nutzer ausschließt, ist an Wochenenden mit höherer Wahrscheinlichkeit ein größerer Anteil der Zugriffe mit Testlabels versehen. Es ist zu erwarten, dass der Traffic-Prozentsatz in verschiedenen Datenschnitten (z. B. nach Standort, Datum und Plattform) variiert. Das entspricht den Ergebnissen in den Chrome-Daten.
3PCs manuell wieder aktivieren	Können Websites sehen, wie viele Nutzer (%) Cookies nach der Einführung der 3PCD-Richtlinie manuell wieder aktiviert haben?	Nutzer können den Zugriff von Drittanbietern auf Websiteebene über die Nutzerumgehung wieder aktivieren, wenn Probleme auftreten. Drittanbieter-Cookies können auch durch andere Maßnahmen wie die Storage Access API wieder aktiviert werden. Es gibt technische Maßnahmen wie „hasStorageAccess()“, mit denen Websites erkennen können, ob 3PCs aktiviert oder deaktiviert sind. Chrome bietet jedoch keine Möglichkeit, den Grund für die Reaktivierung zu erfahren.
Schutz vor Tracking	Wie lange wird die UI-Funktion „Schutz vor Tracking“ in Chrome verfügbar sein?	Die Benutzeroberfläche für den Schutz vor Tracking in der Adressleiste wird voraussichtlich auch nach der Einstellung von Drittanbieter-Cookies verfügbar bleiben.
(wurde auch in früheren Quartalen gemeldet) Browserübergreifender Support	Andere Browseranbieter, die die Privacy Sandbox APIs verwenden	Andere Browseranbieter wie Apple, Mozilla und Microsoft nehmen aktiv an öffentlichen Foren teil, in denen Datenschutzgrundsätze und browserbasierte Ansätze diskutiert werden. Wir sind ermutigt von den gemeinsamen Diskussionen in Foren wie der letzten jährlichen W3C-TPAC-Veranstaltung und den laufenden W3C-PATCG-Foren, in denen wir Anzeichen für eine Annäherung sehen. Microsoft Edge hat beispielsweise vor Kurzem einen Plan angekündigt, der darauf abzielt, die syntaktische Kompatibilität mit der PA API und ARA zu maximieren, und bietet gleichzeitig zusätzliche Funktionen für Entwickler.
Fallback-Option für inkompatible Einbettungen nach dem 3. November 2020	API-Hooks bereitstellen, um zu erkennen, ob ein iFrame / Eingebettetes Element eines Drittanbieters den Anforderungen für Drittanbieter-Kampagnen entspricht.	Wir diskutieren die Anfrage hier und freuen uns über zusätzliches Feedback aus der Community.
Test	Sie können zusätzliche Flags in verwalteten Chrome-Instanzen anfordern, mit denen die benutzerdefinierten Verhaltensweisen vorübergehend deaktiviert werden.	Wir prüfen diese Anfrage für verwaltete Chrome-Instanzen und freuen uns über weitere Informationen aus der Community, ob eine solche Markierung hilfreich wäre.

Registrierung und Attestierung

Feedbackthema	Zusammenfassung	Chrome-Antwort
Attestierungsprüfung	Wie sorgt Google dafür, dass die Echtheit von Attestationen gewährleistet ist?	Alle registrierten Nutzer müssen die Attestationsdatei während der Verwendung der APIs beibehalten. Google prüft, ob die Datei vorhanden und die Syntax korrekt ist. Das Verhalten der Anzeigentechnologie im Hinblick auf die Attestierungssprache wird jedoch nicht geprüft.
Registrierungsprozess für die Private Aggregation API	Kann ich den Status der Registrierung für die Private Aggregation API prüfen?	Alle genehmigten Teilnehmer werden vom Registrierungssupportteam per E-Mail benachrichtigt, sobald die Registrierung bestätigt wurde. Sollten während des Vorgangs Fragen auftauchen, kann sich der Domaininhaber an das Supportteam wenden, das er nach dem Einreichen des Registrierungsformulars kontaktiert. Das Supportteam antwortet und beantwortet Fragen und gibt gegebenenfalls weitere Hinweise.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema	Zusammenfassung	Chrome-Antwort
(Auch in früheren Quartalen gemeldet) Zeitleiste und Dokumentation des Klassifikators	Es sollte eine Möglichkeit geben, die Klassifizierung überprüfen zu lassen, oder zumindest zusätzliche Transparenz darüber, wie Kategorien im Klassifizierungsmodus ermittelt werden.	Unsere Antwort bleibt unverändert: „Eine falsche Klassifizierung von Websites kann das Topics-Signal insgesamt etwas weniger nützlich machen. Die fälschlicherweise klassifizierten Websites sind davon aber nicht mehr oder weniger betroffen als andere Websites. Das liegt daran, dass die Kontextinformationen einer Website immer für Auktionen auf der Website verfügbar sind. So können auch bei einer Falschklassifizierung vergleichbare Informationen zum richtigen Thema bereitgestellt werden. Hier können Sie uns Feedback zu diesem Thema geben.“
Google Ad Manager	Google Ad Manager ist bereits auf den meisten Websites eingebettet und verfügt über viel umfassendere Informationen zu Nutzerthemen als Mitbewerber, die auf weniger Websites vertreten sind.	Die Beobachtungsanforderung soll dafür sorgen, dass durch die Topics API keine mehr Nutzerdaten an mehr Entitäten weitergegeben werden als durch die Technologien, die durch die API ersetzt werden (einschließlich Drittanbieter-Cookies). Andere Branchenlösungen wie Prebid werden auf Zehntausenden von Websites eingesetzt und ermöglichen Marktteilnehmern,die Topics API über ihre Technologie aufzurufen. Außerdem kann das Limit von bis zu fünf Top-Themen pro Woche einen ausgleichenden Effekt haben, da Marktteilnehmer, die auf vielen Websites vertreten sind und mithilfe von 3 PCs mehr als fünf Themen-Äquivalente lernen könnten, auf fünf beschränkt werden.
(Auch in früheren Quartalen erfasst) Nützlichkeit für verschiedene Arten von Stakeholdern	Bedenken hinsichtlich des generierten Werts und der Verteilung dieses Werts für Websites, je nach Besucherzahlen oder Spezialisierung der Inhalte.	Wir sind uns bewusst, dass auf spezialisierten Websites eher detailliertere Themen behandelt werden als auf Websites mit allgemeinen Inhalten. Allerdings enthalten nicht alle Fachwebsites kommerziell wertvolle Themen. Außerdem spiegelt diese Dynamik den Status quo wider und ist völlig unabhängig von der Einstellung der Unterstützung für 3rd-Party-Cookies in Chrome. Auch in der aktuellen Umgebung bieten einige Websites in 3PC-basierten Systemen zur Anzeigenrelevanz mehr Mehrwert als andere. Außerdem können Themen auf spezialisierten Websites für beide Seiten von Vorteil sein, da verschiedene Werbetreibende Kampagnen für verschiedene Themen ausführen und die Gebotslogik den Wert für eine breite Palette von Themen berücksichtigen kann.
Hostnamen und vollständige URLs im Vergleich	Ist die Klassifizierung anhand der Hostnamen von Websites ausreichend effektiv und reduziert dies das Datenschutzrisiko im Vergleich zu vollständigen URLs?	Wir haben erwogen, zusätzlich zu den Hostnamen auch Informations-URLs oder Seitentitel zu verwenden. Wir sind jedoch zu dem Schluss gekommen, dass die potenziellen Vorteile durch die Risiken für den Datenschutz und die Sicherheit der Nutzer überwiegen würden. Ein Beispiel für Risiken für den Datenschutz von Nutzern ist die Klassifizierung vertraulicher Informationen in der URL oder im Seitentitel in den Themen eines Nutzers.
Themen als Signal	Sie möchten wissen, wie Sie Topics mit anderen Signalen kombinieren können und welche anderen Signale nützlich sein könnten.	AdTech-Lösungen liefern die besten Ergebnisse, indem alle verfügbaren Tools kombiniert werden, etwa maschinelles Lernen und datenschutzkonforme Signale aus datenschutzfreundlichen APIs, zusammen mit Kontext-, Anzeigen- und selbst erhobenen Daten. Weitere Informationen

Protected Audience API (früher FLEDGE)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Testvolumen	Tester berichten von einem geringen Volumen von Gebotsantworten für PA API-Auktionen.	1. Die Gebotsdichte hängt mit der Teilnahme am PA API-System zusammen, die wir auch 2024 und darüber hinaus weiter steigern werden. Werbetreibende, ihre Agenturen und Technologieanbieter müssen letztendlich entscheiden, wie Kampagnenbudgets verteilt werden. Wir gehen davon aus, dass einige Teilnehmer des Werbesystems ihre Investitionen in verschiedene „ohne Cookies“-Lösungen, einschließlich der PA API, bis nach dem 3. März 2021 verschieben. Wir gehen davon aus, dass sie dann die Zuweisung des Kampagnenbudgets für solche Lösungen erhöhen werden. 2. Das Volumen der Gebotsanfragen in PA API-Auktionen kann sich aufgrund von (1) auswirken, da Publisher und ihre Anbieter von Anzeigentechnologien entscheiden können, keine PA API-Auktionen zu starten, wenn sie der Meinung sind, dass die Nachfrage gering ist. Die Verlage und Webpublisher entscheiden selbst, welche Priorität sie der Aktualisierung ihrer Seiten und der Teilnahme an der Initiative einräumen. Wir gehen davon aus, dass Publisher sich Zeit nehmen werden, um die Funktion zu testen und die Zugriffe nach und nach zu steigern. Dieser Bericht enthält auch eine Antwort von Google Ad Manager zu den Publisher-Einstellungen für die Teilnahme an der PA API.
(Auch in vorherigen Quartalen gemeldet) Betrug / Missbrauch	Wie kann das System die Risiken verringern und verhindern, dass sich böswillige Akteure oder Käufer als erwünschte Zielgruppe präsentieren?	Die Berichtsmechanismen der PA API-Anzeigen behalten die Informationen bei, die derzeit verwendet werden, um zwischen menschlichen Nutzern und Bot-Traffic zu unterscheiden. Außerdem können aktuelle domainbasierte Verfahren zum Ein- oder Ausschließen von Domains in der PA API verwendet werden. Weitere Informationen dazu finden Sie in unserer Antwort auf den Bericht des IAB Tech Lab zur Privacy Sandbox.
Einschränkung derselben Quelle für die URL des IG-Inhabers und der Gebotslogik	Aufgrund der Anforderung für denselben Ursprung müssen Endpunkte für einen IG-Inhaber denselben Load Balancer durchlaufen, was dazu führen kann, dass Weiterleitungen abgelehnt werden.	Die Same-Origin-Anforderung für das Laden von Scripts ist ein wichtiger Sicherheitsmechanismus. Hier finden Sie einige Details zu einer vorgeschlagenen Lösung, die Feedback zum Ökosystem und andere Überlegungen in Einklang bringt.
Private Auktion mit mehreren Slots	Es gibt viele Möglichkeiten, private Auktionen mit mehreren Slots im Rahmen des Datenschutzes zuzulassen, indem Rauschen verwendet und die Integration in aktuelle Werbepraktiken verbessert wird.	Wir berücksichtigen dieses Feedback und prüfen die Anfrage für Multi-Tag-Auktionen im Hinblick auf die mit dieser Funktion verbundenen erhöhten Komplexität und Datenschutzrisiken. Wir haben dieses Problem in einem Anruf der PA API Web Incubator Community Group (WICG) weiter besprochen.
Verkäufer auf oberster Ebene	Die aktuelle Struktur der PA API bietet allen Verkäufern der obersten Ebene deutlich mehr Daten und Informationen zum relativen Wert von Impressionen als Publishern oder Komponentenverkäufern.	Bei einer Mehrfachkunden-Auktion hat jeder Verkäufer ein Bestgebot. Außerdem haben wir festgestellt, dass Publisher neben den besten Geboten der einzelnen Verkäufer, mit denen sie zusammenarbeiten, auch die Nachfrage nach direkt verkauften Anzeigen berücksichtigen sollten. Du musst alle diese potenziellen Monetarisierungsmöglichkeiten berücksichtigen, um zu entscheiden, welche Anzeige ausgeliefert werden soll. Diese Situation, in der ein Akteur die gesamte Palette an Optionen sehen muss, um eine Anzeige auszuwählen, die ausgeliefert werden soll, ist älter als die PA API. Die PA API soll Auktionen mit mehreren Verkäufern unterstützen und es Publishern ermöglichen, neben direkt verkauften Werbekampagnen auch das beste Gebot jedes Verkäufers zu berücksichtigen, sofern dies zutrifft. Das bedeutet, dass es einen Mechanismus geben muss, mit dem Creator aus den verschiedenen Monetarisierungsmöglichkeiten auswählen können, wie es heute der Fall ist. Wir sind der Meinung, dass es nicht Aufgabe des Browsers sein sollte, auszuwählen, welche Anzeige ausgeliefert werden soll. Daher ist das Konzept eines Verkäufers auf oberster Ebene erforderlich, um aus vielen Möglichkeiten eine Anzeigenauslieferung auszuwählen. Die Logik dieses Verkäufers der obersten Ebene muss die besten Gebote von jedem Verkäufer berücksichtigen können, mit dem der Publisher zusammenarbeiten möchte. Die Logik dieses Verkäufers kann auch Informationen zu den direkt verkauften Kampagnen des Publishers bereitstellen, sofern diese Informationen verfügbar sind. Alle diese Informationen können in die Logik der Anzeigenauswahl auf oberster Ebene einfließen. Das bedeutet, dass die Logik der obersten Ebene die besten Gebote aus der PA API-Auktion und gegebenenfalls alle direkt verkauften Anzeigenoptionen des Publishers sieht, um einen Gewinner zu ermitteln. In diesem Bericht wird die Implementierung der PA API als Verkäufer auf oberster Ebene in Google Ad Manager unter dem Thema Zugriff auf Informationen beschrieben.
Trennung von Konkurrenzanzeigen	Sie können die Auslieferung konkurrierender Anzeigen voneinander trennen lassen, z. B. verhindern, dass Anzeigen konkurrierender Marken nebeneinander ausgeliefert werden.	Wir kennen keine Möglichkeit, in der heutigen programmatischen, mehrverkäuferischen digitalen Werbebranche mit Geboten eine Wettbewerbsabgrenzung zu gewährleisten. Mit der PA API können Verkäufer jedoch zusätzliche Echtzeitsignale basierend auf einer Kombination aus renderURL und Hostnamen (für die Domain des Publishers) abrufen, die bei der Bewertung von Creatives während „scoreAd()“ verwendet werden können. Verkäufer können diese Funktion verwenden, um zu verhindern, dass Anzeigen konkurrierender Marken nebeneinander ausgeliefert werden, sofern der Publisher diese Regel erzwingen möchte.
Begrenzte Informationen	Mit der PA API werden die für Publisher verfügbaren Informationen wie Anzeigenwert, Name des Komponentenkäufers, Name des Werbetreibenden, Landingpage-URL, Creative-Größe, Antwortzeit und Gebotsrate sowie verlorene Gebote reduziert.	Hier haben wir einige mögliche Lösungen vorgeschlagen und freuen uns über zusätzliches Feedback aus der Branche.
Berichte auf Ereignisebene	Nach der Einstellung der PA API für Berichte auf Ereignisebene erhalten Publisher nicht mehr genügend Informationen zur ausgelieferten Anzeige.	Uns ist bewusst, dass wir auch nach der Einstellung der Berichte auf Ereignisebene weiterhin verschiedene Anwendungsfälle unterstützen müssen. Aus diesem Grund werden Berichte auf Ereignisebene frühestens 2026 eingestellt. Bis dahin möchten wir Sie aktiv einladen, sich mit uns über nachhaltige Lösungen auszutauschen. Dabei könnten auch neue Ideen für die datenschutzfreundliche Erhebung von Informationen entwickelt werden.
Mehrere SSPs	Der Mehrwert durch mehrere SSPs ist für Publisher zu gering.	Wir sind der Meinung, dass dies nicht der Fall ist, und würden uns über zusätzliches Feedback aus der Branche freuen, um die Begründung für diese Behauptung besser nachvollziehen zu können.
Kuratierungsaktivitäten	Mit der PA API sind keine Kuratierungsaktivitäten möglich.	Wir haben Feedback dazu erhalten, dass Verkäufer ihre Zielgruppeninformationen über die PA API für Käufer im Web freigeben können (auch als Zielgruppenerweiterung bezeichnet). Wir sind der Meinung, dass dies heute mithilfe der Delegierungsfunktion von PA und Geschäftsvereinbarungen möglich ist. Gleichzeitig überlegen wir aktiv, ob und wie wir diese Anwendungsfälle besser berücksichtigen können.
Deaktivierung durch Käufer	Wenn Käufer die Standardeinstellung deaktivieren, führt dies wahrscheinlich zu schlechteren Ergebnissen bei Komponentenauktionen.	Unabhängig davon, ob eine PA-Auktion für einen einzelnen Verkäufer oder für mehrere Verkäufer definiert wird, müssen Käufer im Feld „interestGroupBuyers“ der „AuctionConfig“ explizit aufgeführt werden. Diese Änderung basiert auf Feedback aus dem Werbesystem, dass Verkäufer vertragliche Vereinbarungen mit einigen Käufern, aber nicht mit anderen haben. Daher benötigen sie eine explizite Kontrolle darüber, welche Käufer in die Auktion aufgenommen werden sollen. Wir freuen uns über weitere Diskussionen auf GitHub.
Anzeigengröße	Es ist nicht möglich, eine Vorabfilterung basierend auf „adsize“ und „adSlotSize“ durchzuführen.	Wir arbeiten daran, diese Funktion hinzuzufügen. Weitere Informationen finden Sie in diesem Artikel.
Unterstützung für auszuschließendes IG-Targeting	Eine API zur Unterstützung des ausschließenden Targetings auf Interessengruppen: Anzeigen werden nur ausgeliefert, wenn ein Nutzer keiner Interessengruppe angehört.	In diesem GitHub-Problem wird eine alternative Methode zur Implementierung des ausschließenden 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. Das mag zwar ein ansprechender Ansatz sein, aber alle von uns untersuchten Versionen dieser Idee ermöglichen es dem Server, den Nutzer eindeutig zu identifizieren.
Digital Services Act	Wie kann ein Publisher abgegrenzte Frames verwenden, aber 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 Nutzung der Privacy Sandbox gesetzeskonform ist. Google kann anderen keine Rechtsberatung anbieten. Für jede API haben wir umfangreiche technische Dokumentationen veröffentlicht, die die Grundlage für die erforderlichen rechtlichen Bewertungen bilden sollten. Eingeschränkte Frames sind für die Verwendung in der PA API frühestens ab 2026 erforderlich. So haben die Stakeholder mehr Zeit, dafür zu sorgen, dass ihre Nutzung dieser Technologie allen relevanten Gesetzen entspricht.
Dokumentation	Ist updateAdInterestGroups() temporär?	Wir haben keine Pläne angekündigt, updateAdInterestGroup einzustellen. In Zukunft werden wir möglicherweise ähnliche Datenschutzmaßnahmen anwenden, wie wir sie für andere IG-Updatemechanismen öffentlich angekündigt haben, z.B. die Verwendung einer IP-Adresse als Proxy und eine gewisse Verzögerung vor dem Update.
Unterstützung der Inhaberschaft von Buy-Side-Metadaten und -Logik für nicht DSPs	Bitten Sie um eine Möglichkeit, als Proxy für DSPs zu fungieren.	Wir sind uns dieses Feedbacks von Segmenten außerhalb von DSPs bewusst und prüfen diese Anfrage. Wir freuen uns über zusätzliches Feedback aus der Community.
Berichte	Hinzufügen einer benutzerdefinierten Handler-Funktion für Signale (Bucket / Wert) in Berichten zur privaten Aggregation	Wir sind uns des Problems bewusst und prüfen diese Funktion derzeit. Wir freuen uns über zusätzliches Feedback von der Community. Hier können Sie es uns senden.
Dokumentation	Gibt es einen Link, unter dem alle Antwortheader angezeigt werden, die vom Werbetreibenden und der (delegierten) Inhaberdomain festgelegt werden müssen?	Wir planen Aktualisierungen der Dokumentation, um dies zu verdeutlichen, und freuen uns über zusätzliches Feedback aus der Community.
Gebote für mehrere Anzeigenplattformen	Erläuterung des Workflows (Training und Inferenz) anhand eines Architektur-/Blockdiagramms dazu, wie ein Multi-Tower-Ansatz im Kontext der PA API gedacht ist.	Vielen Dank für dein Feedback. Wir haben einige Präsentationen zu diesem Thema, aus denen wir zusätzliche Dokumentationen erstellen werden.
Ausschließendes Targeting	Die Möglichkeit der Privacy Sandbox, sensible Zielgruppen und Minderjährige vor unangemessenen Anzeigen zu schützen, z. B. vor Werbung für Glücksspiele.	Bei der PA API wird der Inhalt der angezeigten Anzeigen nicht berücksichtigt. Das liegt in der Verantwortung der Entwickler von Anzeigentechnologien, die PA verwenden. Im Allgemeinen können der Publisher und seine Anzeigentechnologieanbieter Creatives in Protected Audience-Auktionen mithilfe von Kontextinformationen von der Seite sowie Publisher-Regelnblöcken blockieren. Das spiegelt unsere Auffassung des Ansatzes des Ökosystems für diese Herausforderungen wider. Für Käufer kann die Funktion für das negative Targeting auf Interessengruppen auch für einige Compliance-Anwendungsfälle nützlich sein.
API-Design	Google lehnt dies ab und möchte, dass Anbieter von Anzeigentechnologien eine Universal Bidding-Funktion verwenden, was die Latenz erhöht, anstatt verschiedene biddingLogicURLs in verschiedenen IGs, was zulässig ist.	Bei unseren Gesprächen zur Auktionslatenz haben wir darauf hingewiesen, dass die Wiederverwendung desselben Scripts für alle IGs eines Käufers die Gebote dieses Käufers beschleunigen würde. Weitere Informationen dazu sowie unsere anderen Empfehlungen zur Verbesserung der Auktionslatenz der PA API finden Sie hier.
Kontobasiertes Marketing	Die PA API ist keine saubere API für Anwendungsfälle im accountbasierten Marketing.	Wir freuen uns über Feedback von der Community zu bestimmten Anwendungsfällen, die ihrer Meinung nach nicht möglich sind. Wir empfehlen den Community-Mitgliedern, diese Diskussion über unser öffentliches GitHub-Repository oder über die wöchentlichen 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 sein. Das schränkt die Möglichkeiten von Publishern ein, einen sinnvollen A/B-Test durchzuführen.	Antwort von Google Ad Manager: Die Einstellungen für die PA API in Google Ad Manager (GAM) wirken sich darauf aus, ob GAM die API verwenden kann, sofern die API verfügbar ist. Publisher können daher A/B-Tests durchführen, indem sie die Funktionen der Berechtigungsrichtlinie von Chrome verwenden, um die Verwendung der API für einen Teil des Traffics zu deaktivieren, der als Kontrollverzweigung für einen A/B-Test verwendet werden soll.
Maschinelles Lernen	Publisher benötigen mehr Kontrolle über die vorgeschlagene Verwendung von maschinellem Lernen in GAM.	Antwort von Google Ad Manager: Im Januar 2024 haben wir ein Steuerelement eingeführt, mit dem Publisher den Drosselmechanismus 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 YouTube-Hilfe.
(wurde auch in früheren Quartalen erfasst) Auktionen der obersten Ebene	Publisher-Ad-Server von Google verwenden, ohne GAM die Kontrolle über die PA API-Auktion auf oberster Ebene zu geben	Antwort von Google Ad Manager: Aus den im Bericht zu Google Ad Manager für das 3. Quartal 2023 genannten Gründen ist in den Plänen für die PA API-Integration in GAM keine Unterstützung für Publisher vorgesehen, die GAM als Publisher-Anzeigenserver verwenden, ohne die Auktion auf oberster Ebene zu steuern.
Zugriff auf Informationen	GAM hat Zugriff auf wertvolle Informationen von Mitbewerbern, darunter Kontextauktionspreise, Signale, die Käufer an SSPs für die PA API-Auktion senden, und Konfigurationsparameter von SSPs.	Antwort von Google Ad Manager: Wir legen seit Jahren großen Wert auf Fairness bei Auktionen. Dazu gehört auch unser Versprechen, dass kein Preis aus den nicht garantierten Anzeigenquellen eines Publishers, einschließlich der Preise für nicht garantierte Werbebuchungen, vor der Abgabe eines Gebots in der Auktion an einen anderen Käufer weitergegeben wird. Dieses Versprechen haben wir später in unseren Verpflichtungen gegenüber der französischen Wettbewerbsbehörde bekräftigt. Bei PA API-Auktionen möchten wir unser Versprechen halten und das Gebot eines Auktionsteilnehmers vor Abschluss der Auktion in Auktionen mit mehreren Verkäufern nicht mit anderen Auktionsteilnehmern teilen. Zur Klarstellung: Wir geben den Preis der kontextbezogenen Auktion nicht an andere Komponentenauktionen weiter, auch nicht an unsere eigenen, wie in diesem Update erläutert. Außerdem verwenden wir keine Informationen zu Auktionskonfigurationen für Komponenten, einschließlich Signalen, die Käufer an SSPs senden, in unseren eigenen Auktionen. Wir würden Änderungen an der PA API begrüßen, die es Komponentenverkäufern ermöglichen, ihre Auktionskonfigurationen so anzugeben, dass sie für den Verkäufer der obersten Ebene unkenntlich sind.
Komponentenauktionen	Als Auktion der obersten Ebene steuert GAM, welche SSPs Komponentenauktionen für jede Anzeigenbereitstellung durchführen.	Antwort von Google Ad Manager: Als Publisher-Anzeigenserver bietet GAM eine schlanke API für SSPs, mit denen ein Publisher seine Komponentenauktionskonfigurationen über die GPT API (Google Publisher Tag) angeben kann. Weitere Informationen Wenn eine SSP über diese API eine Auktionskonfiguration für Komponenten bereitstellt, wird sie in die Liste der Auktionen für Komponenten für diese Werbechance aufgenommen. Für die enthaltenen Komponentenauktionen gelten in GAM keine Einschränkungen. Jede SSP, die eine Komponentenauktion durchführen möchte, kann dies tun, sofern der Publisher ihr erlaubt hat, den erforderlichen Code auf der Seite des Publishers auszuführen.
Komponentenauktionen	GAM kann für jedes Gebot, das in einer Auktion für eine Komponente den Zuschlag erhalten hat, einen bestimmten und nicht offengelegten Mindestpreis anwenden.	Antwort von Google Ad Manager: Bei Google Ad Manager liegt seit Jahren ein starker Fokus auf der Fairness von Auktionen. Um eine faire und transparente Auktion zu ermöglichen, unterstützen wir keine Mindestpreise, die nur für bestimmte Nachfragesegmente gelten. Das ist ein Grundsatz unseres Produkts und wird auch für PA API-Auktionen gelten.
Ad-Server von Drittanbietern	Ad-Server von Drittanbietern hätten keinen Zugriff auf die Teilnahme von Google an der Auktion auf höherer Ebene. Sie könnten daher nur eingeschränkt von der Nachfrage nach Google SSP im Rahmen der PA API profitieren.	Antwort von Google Ad Manager: Derzeit unterstützt GAM den Test der PA API mit mehreren Verkäufern in GAM über die hier beschriebene API. Die Teilnahme von GAM als Komponentenauktion an anderen Auktionen der obersten Ebene wird derzeit nicht unterstützt.
(wurde auch in früheren Quartalen erfasst) Leistung von PA API-Auktionen	Tester haben gemeldet, dass Auktionen der PA API eine hohe Latenz haben.	Wir haben Bedenken hinsichtlich der Latenz gehört. Das ist einer der Gründe, warum wir im Rahmen der PA API eine Reihe von Funktionen entwickelt haben, mit denen SSPs sowohl Limits für die DSP-Latenz festlegen als auch Verbesserungen vornehmen können, um die Latenz zu verringern. Wir haben vor Kurzem unseren Leitfaden zu Best Practices für die Latenz aktualisiert. Dort finden Sie weitere Informationen dazu, wie Sie diese Funktionen optimal nutzen können. Außerdem arbeiten wir kontinuierlich an neuen Latenzverbesserungen, von denen einige hier zu sehen sind.
(wurde auch in früheren Quartalen erfasst) Video-Rendering	Unterstützung für das Video-Rendering mit der PA API und eingegrenzten Frames	Im Januar haben wir eine Demo veröffentlicht, in der gezeigt wird, wie In-Stream-Videos in einer PA-Auktion funktionieren könnten. Außerdem haben wir weitere Details zu alternativen Ansätzen geteilt. Außerdem sehen wir, dass Akteure im Ökosystem damit beginnen, Vorschläge zur Funktionsweise des Video-Renderings für Partner zu machen, die sie einbinden. Beispiele hierfür sind die Vorschläge von GAM zur Erstellung einer videokompatiblen Render-URL oder der vollständige E2E-Prozess. Außerdem hören wir uns Feedback aus dem Ökosystem zu Änderungen an, mit denen wir die Akzeptanz steigern können. Eine solche Änderung wird auf GitHub beschrieben. Wir bleiben aktiv im Austausch mit dem Ökosystem, um mögliche andere Hindernisse für die Akzeptanz zu identifizieren und zeitnah zu beheben.
(wurde auch in früheren Quartalen gemeldet) Richtlinie zum Umgang mit Daten	Wie lauten die Richtlinien zur Datenverarbeitung für die IGs / PA API?	Bei der PA API werden alle in sozialen Netzwerken gespeicherten Daten oder Daten dazu, welche Nutzer in welchen sozialen Netzwerken sind, entweder (i) auf dem Gerät gespeichert oder (ii) in den Bidding and Auction (B&A)-Diensten verarbeitet, die in einer Trusted Execution Environment (TEE) ausgeführt werden. In beiden Fällen können die Daten von anderen Parteien nicht gelesen oder für andere Zwecke als die Abgabe von Geboten in der Auktion verwendet werden. Einige Datenschutzverbesserungen, die in Chrome untersucht werden, beinhalten die Interaktion mit einem von Google betriebenen K‑Anonymitätsserver. Diese Interaktion wird sorgfältig konzipiert, um die Weitergabe von Informationen über Nutzer zu vermeiden und in einer TEE auszuführen, um für Datenparität im gesamten Werbesystem zu sorgen. Google hat sich gegenüber der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu entwerfen und umzusetzen, dass der Wettbewerb nicht durch Bevorzugung des eigenen Geschäfts von Google verzerrt wird, und die Auswirkungen auf den Wettbewerb in der digitalen Werbung sowie auf Publisher und Werbetreibende zu berücksichtigen. Wir arbeiten weiterhin eng mit der CMA zusammen, um sicherzustellen, dass unsere Arbeit diesen Verpflichtungen entspricht.
(wurde auch in vorherigen Quartalen erfasst) IG-Lifetime	Verlängerung der Gültigkeitsdauer von IGs von 30 auf 90 Tage beantragen	Eine solche Änderung erfordert eine sorgfältige Bewertung, bei der die Vorteile für die Branche gegen die Auswirkungen auf Chrome-Nutzer und andere Stakeholder abgewogen werden. Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback in diesem Formular.
(Auch in vorherigen Quartalen erfasst) modelingSignals	Fordern Sie zusätzlich zu den Modellierungssignalen, die nur Display- und Klickinformationen codieren können, ein neues Feld an.	Wir haben auf dieses Feedback mit einem Gegenvorschlag hier reagiert. Wir sind in engem Austausch mit der Branche, um ihre Meinung zu unserem Vorschlag zu erfahren. Derzeit wägen wir die Vorteile für die Branche gegen die Auswirkungen auf Chrome-Nutzer und andere Stakeholder ab.
Zusätzliche Bits in reportWin()	Geben Sie in reportWin() zusätzliche Bits an, die über das aktuelle Limit von 12 vor 3PCD hinausgehen.	Wir arbeiten derzeit an Lösungen, um diesen Anwendungsfall zu unterstützen. Das dauert etwas, da wir auch nach Ansätzen suchen, die uns dabei helfen können, einen langfristigen Datenschutzplan zu entwickeln.
Auktionsdesign	Anfragen für eine einzelne Auktion, bei denen Rendering-URLs mit der entsprechenden Bewertung zurückgegeben werden.	Wir haben zwar erwogen, mehrere Render-URLs und die jeweilige Bewertung aus einer einzelnen PA-Auktion zu teilen, dies aber aus Datenschutzgründen nicht implementiert. Wir können nachvollziehen, dass Sie vermeiden möchten, dass einem Nutzer auf einer einzelnen Seite dieselbe Anzeige mehrmals präsentiert wird. Wir freuen uns auf weitere Diskussionen auf GitHub.
reportWin	beliebige Felder in der Funktion „reportWin()“ protokollieren.	Das geschieht bereits während des gesamten Testzeitraums. Sobald Chrome die Unterstützung für 3PCs eingestellt hat, wird die Version „forDebuggingOnly“ der API migriert, um das herunterskalierte Debuggen zu ermöglichen, das hier beschrieben wird.
Komponentenverkäufer	Sie müssen einen unabhängigen Mechanismus haben, um eigene Impressionen und andere Ereignisse zu erfassen, und nicht nur auf Berichte von Anzeigentechnologien angewiesen sein.	Diese Funktionsanfrage wird derzeit geprüft. Wir gehen davon aus, dass wir dieses Problem während der von Chrome unterstützten Testphase nicht beheben können.
Abrechnung nach Cost-per-Click	Implementieren Sie die Abrechnung nach Cost-per-Click in der PA API.	Wir prüfen diese Anfrage hier und betrachten sie derzeit als Vorschlag für die Implementierung mit der aktuellen API-Oberfläche.
browserSignals	Fügen Sie der Berichtsspezifikation für Browsersignale für Verkäufer die Spalte „incomingBidInSellerCurrency“ hinzu.	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback hier.
Unterstützung der Inhaberschaft von Metadaten und Logik auf der Buy-Side für Drittanbieter von Demand-Side-Plattformen	Die aktuelle Version der API könnte zu einer erheblichen Umstellung bei Kampagnen mit Retargeting auf Produktebene führen. Kampagnen müssen dann möglicherweise auf Plattformen migriert werden, die sowohl als DSPs als auch als DCO-Anbieter dienen.	Wir besprechen dieses Problem und freuen uns über zusätzliches Feedback in diesem Forum .
Unterstützung der Inhaberschaft von Metadaten und Logik auf der Buy-Side für Drittanbieter von Demand-Side-Plattformen	Geben Sie Beispiele an, in denen die DSP nicht der Inhaber der Anzeigenplattform ist.	Uns ist bewusst, dass Nutzer, die keine Gebote abgeben, einige Funktionen von Anzeigengruppen nutzen möchten, andere aber nicht. Wir prüfen derzeit aktiv Optionen zur Lösung dieser Anwendungsfälle und freuen uns über zusätzliches Feedback hier.
Einstellungen für Zeitlimits	Publisher sollten die Anzahl der teilnehmenden IGs und die Zeitüberschreitung auf oberster Ebene / globale Zeitüberschreitung festlegen können.	Wir sind uns bewusst, dass es den Wunsch nach erweiterten Zeitüberschreitungseinstellungen und mehr Transparenz zwischen Verkäufern auf oberster Ebene und Komponentenverkäufern gibt. Wir prüfen diese Anforderung derzeit.
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 aus der Community.
Dokumentation	Gibt es eine Liste der IG-Attribute, die der K-Anonymisierung unterliegen?	Hier finden Sie eine Antwort auf diese Frage.
Debugging	Verbesserte Funktionen zum Beheben von Fehlern für die PA API.	Wir sind uns bewusst, wie wichtig zuverlässige Debugging-Tools für Entwickler sind, die mit der PA API arbeiten. Wir arbeiten daran, die Entwicklerfreundlichkeit zu verbessern, indem wir nach Möglichkeiten suchen, .well-known-Dateiabrufe besser in Entwicklertools zu integrieren. Unser Ziel ist es, die Transparenz und Fehlerbehebung in der Entwicklungsumgebung zu verbessern. Hier gehen wir näher auf dieses Problem ein und freuen uns über zusätzliches Feedback.
Labels	Sind die Privacy Sandbox APIs für alle Nutzer in den Behandlungslabels für Modus B aktiviert?	Die Zuweisung zu Chrome-Testgruppen erfolgt zufällig und unabhängig von den vom Nutzer konfigurierten Chrome-Einstellungen. Diese APIs sind zwar möglicherweise für Nutzer in bestimmten Behandlungsgruppen (z.B. treatment_1.*) verfügbar, ihre Funktionalität kann jedoch über die Chrome-Einstellungen geändert oder deaktiviert werden. Modus B: Gruppe „control_2“: Wenn Sie zu dieser Gruppe gehören, werden die Relevanz- und Mess-APIs der Privacy Sandbox automatisch deaktiviert. Diese Einstellung kann vom Nutzer nicht in den Chrome-Einstellungen ü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 beginnen, wenn das Auktionsergebnis in einen Iframe oder einen abgegrenzten Frame platziert wird. Nachdem die Ausführung von reportWin() abgeschlossen ist und die Anzeige gerendert wird, werden die URLs abgerufen, die für sendReportTo() angegeben wurden.
(wurde auch in früheren Quartalen gemeldet) A/B-Test-Support	Unterstützung für A/B-Tests mit der PA API anfordern	Wir besprechen diese Anfrage hier und freuen uns über zusätzliches Feedback.
Anpassung an Traffic	Der Vorschlag von Google, die erforderlichen Entscheidungen über den KV-Server zu verwalten, ist nicht hilfreich, da Verkäufer nicht mit ihrem Backend interagieren können, was die Verkehrssteuerung erschwert.	Wie im GitHub-Problem erläutert, kann die Offenlegung, ob bei einzelnen DSPs IDs vorhanden sind, zu Problemen mit dem Nutzer-Fingerprinting führen. Wir haben in der Anfrage andere Alternativen vorgeschlagen und sind offen für weitere Vorschläge.
Anpassung an Traffic	Caching-Mechanismen erhöhen die Komplexität erheblich und verhindern, dass DSPs die tatsächliche Form des Traffics kennen, auf den sie bieten würden.	Der Caching-Mechanismus wurde lediglich als Vorschlag angeboten. Anbieter von Anzeigentechnologien können die Vorschläge verwenden, die für ihren Anwendungsfall geeignet sind. Weitere Informationen dazu finden Sie hier.
Labels	Chrome sollte das Label als Parameter in Anfragen an vertrauenswürdige Server von Käufern und Verkäufern senden.	Dies scheint eine angemessene Anfrage zu sein, da sie weitgehend mit dem Ziel der verantwortungsbewussten Nutzung von Instagram-Daten übereinstimmt. Wir prüfen den Antrag jedoch intern und werden die Öffentlichkeit über den Fortschritt der Angelegenheit auf dem Laufenden halten.
API-Verwendung	Die explizite Definition der Gruppe „control_1“ im Dokument „Zusätzliche CMA-Leitfäden für Drittanbieter zum Testen“ wurde verdeutlicht. Insbesondere besteht die Befürchtung, dass eine Änderung der Formulierung so interpretiert werden könnte, dass alle Privacy Sandbox-APIs aus control_1 ausgeschlossen werden müssen.	Unsere Ansichten dazu haben wir in diesem GitHub-Thread dargelegt. Wir können jedoch nicht für die CMA sprechen und empfehlen Ihnen, alle Fragen zur Auslegung der Testrichtlinien direkt an die CMA zu richten.
API-Verwendung	Lässt Chrome das Aufrufen von „joinAdInterestGroup()“ auf einer leeren Seite zu, während eine Weiterleitung zu einer anderen Ressource erfolgt?	Wenn ein Nutzer eine Website besucht, kann der Websiteinhaber die Möglichkeit, joinAdInterestGroup aufzurufen, an einen Drittanbieter delegieren. Durch diese Deaktivierung können Drittanbieter IGs erstellen, ohne eine Weiterleitung über eine leere Seite hinzufügen zu müssen. Wir freuen uns über Feedback zu konkreten Gründen, warum IGs in der Mitte einer Weiterleitung erstellt werden, anstatt den vorgesehenen Deaktivierungsmechanismus zu verwenden.
API-Verwendung	Anzeigenplattformen sollten in der Lage sein, IGs auf den Seiten der Publisher zu schreiben, mit denen sie zusammenarbeiten, und die Berechtigung zum Bieten auf diese IG an einen bestimmten Käufer oder eine bestimmte DSP delegieren zu können.	Wir haben das Feedback erhalten und prüfen derzeit, ob ein solcher Antrag unterstützt werden kann. Wir freuen uns über zusätzliches Feedback aus der Community.
API-Verwendung	Wenn niemand eine PA API-Auktion gewinnt, wird keine Benachrichtigung zum Beheben von Fehlern gesendet.	Die Funktionen „reportWin“ und „reportResult“ von Chrome sind für Berichte zu Geboten auf Ereignisebene im Privacy Auction-System (PA) vorgesehen. Wenn bei einer PA-Auktion alle Gebote abgelehnt werden, werden diese Funktionen voraussichtlich nicht aufgerufen, da kein Gewinner ermittelt wird. Ein aktuelles Update für Chrome kann Abweichungen erklären, bei denen URLs, die an forDebuggingOnly.reportAdAuctionLoss() übergeben werden, nicht im DevTools-Netzwerkbereich angezeigt werden. Wir empfehlen, diese Funktion mit einer Build-Version von Chrome aus dem Canary- oder Dev-Kanal zu testen.
API-Verwendung	Kann der von „generateBid“ zurückgegebene Wert für „adCost“ negativ sein? Er wird bereits stochastisch auf 2 Byte gerundet.	„AdCost“ ist der Klick- oder Conversion-Kostenbetrag des Werbetreibenden, der von „generateBid()“ an „reportWin()“ übergeben wird. Dieser Wert kann „Null“ oder ein Double-Wert sein. Negative Werte werden ignoriert und nicht übergeben. Der Wert wird beim Übergeben stochastisch gerundet.
API-Verbesserung	Können vertrauenswürdige und verschlüsselte Ausführungsserver anstelle des Chrome-Browsers für das Targeting, die Kohorten, die Attribution und Auktionen verwendet werden?	Wir empfehlen, die TEE-basierten Komponenten und Optionen in der PA API (z.B. KV-Server und B&A-Dienste) sowie die TEE-basierten Komponenten der Attributionsberichte und der privaten Aggregation (z.B. Aggregationsservice) zu untersuchen, die diese Frage beantworten.
API-Verbesserung	Kann die Auktionsantwort der Privacy Sandbox eine Gebotsantwort (z. B. Header Bidding) anstelle einer Anzeigenantwort (z. B. Anzeigen-Tags) sein?	Diese Art von Änderung würde die Datenschutzeigenschaften der PA API grundlegend verändern und wird daher nicht in Betracht gezogen.
Steuerelemente für Publisher	Können Publisher PA API-Creatives auf ihren Seiten blockieren?	Chrome hat einen Vorschlag für das Echtzeit-Scannen von Creatives, der noch nicht zum Testen verfügbar ist. Diese Funktion ist noch nicht verfügbar. Wir haben jedoch festgestellt, dass die meisten SSPs Lösungen entwickelt haben, um dies zu ermöglichen.
API-Verwendung	Wie groß darf perBuyerSignals sein?	In seiner klassischen Form hat perBuyerSignals keine inhärenten Größenbeschränkungen in Chrome. Die wichtigsten Einschränkungen sind, dass die Daten JSON-serialisierbar bleiben und keinen übermäßigen Arbeitsspeicherverbrauch verursachen. Sehr große und komplexe perBuyerSignals können sich jedoch negativ auf die Leistung auswirken. Es gibt eine alternative Methode, perBuyerSignals über den directFromSellerSignalsHeaderAdSlot zu übergeben. Bei diesem Ansatz werden perBuyerSignals in einem Header übertragen, wobei die gesamte Headerantwort eine maximale Größe von 10 KB haben darf. Außerdem können einzelne Server eigene Einschränkungen für die maximale Headergröße festlegen.
Dokumentation	Die Dokumentation zum Aufruf von „registerAdBeacon“ aus „generateBid“ muss geändert werden.	Wir haben diese Dokumentation am 17. Februar aktualisiert.
API-Verwendung	Wie wird bei „reportEvent“ die richtige Beacon-URL aus mehreren registrierten Optionen ausgewählt?	Jede Auktion führt zu einer separaten Konfiguration, die wiederum zu einer separaten Berichtszuordnung führt. Einzelne Auktionen (und die daraus resultierenden Frames) sind völlig unabhängig voneinander und es werden keine Daten gemeinsam genutzt. In der Erläuterung Berichte zu Anzeigen in abgegrenzten Frames finden Sie weitere Informationen zu diesem Thema.
Chrome-Benutzeroberfläche	In Chrome DevTools auf dem Tab „Anwendung“ -> „Interessengruppen“ einen Filter hinzufügen, mit dem nach IG-Inhaber (oder möglicherweise auch nach IG-Namen) gefiltert werden kann.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus der Community.
monitorlose Chrome-Version	Unterstützung der PA API in der headless Chrome-Version	Einige Komponenten der PA API sind an Chrome gebunden, z. B. die k-anon-Aufrufe an die Google-Server. Diese funktionieren möglicherweise nicht im „alten“ Headless Chrome. Wir gehen davon aus, dass dieses Problem mit der neuen Version von Headless Chrome behoben wird, die in Chrome 112 veröffentlicht wurde.
API-Verwendung	Bei Verlustmeldungen mit reportAdAuctionLoss wird in vielen Fällen „topLevelWinningBid=0“ angezeigt. Wie ist das zu interpretieren?	Der Wert „topLevelWinningBid“ stammt aus der Funktion „scoreAd()“ in der Verkäuferkomponente der obersten Ebene. Dieser Wert spielt eine Rolle bei der Bestimmung des Ergebnisses der Auktion auf oberster Ebene. Wie in der Erläuterung erläutert, bedeutet ein Wert von „topLevelWinningBid“ von null oder einer negativen Zahl, dass die entsprechende Anzeige die Auktion nicht gewinnen kann. Mit diesem Mechanismus können beispielsweise Anzeigen herausgefiltert werden, die auf Interessengruppen ausgerichtet sind und nicht die Leistung einer kontextbezogenen Ausrichtung übertreffen. Ein topLevelWinningBid mit dem Wert „0“ kann zwar darauf hinweisen, dass eine kontextbezogene Auktion den Zuschlag erhalten hat, in der PA API-Spezifikation wird jedoch darauf hingewiesen, dass auch andere Faktoren zu diesem Ergebnis beitragen können.
A/B-Testmodus	Erläuterung der Trafficauswahl und der Aufforderungen zum Deaktivieren für Modus B und Modus A.	Die Einschlusskriterien für Modus A und Modus B sind identisch. Ziel ist es, Gruppen zu haben, die für normalen Chrome-Traffic repräsentativ sind, sofern sie die Privacy Sandbox APIs und die Labels unterstützen. Daher sind einige Clientkonfigurationen nicht kompatibel. Für den Test ist es wichtig, nur getaggten Traffic mit anderen getaggten Zugriffen zu vergleichen. Nutzer im Modus B haben die Funktion zum Schutz vor Tracking aktiviert und erhalten daher eine Benachrichtigung zu dieser Funktion.
API-Verbesserung	Kann „lifetimeMs“ als direkte Property im joinAdInterestGroup-Aufruf enthalten sein oder als separates Argument verwaltet werden?	Wir prüfen das Feedback der Webentwicklungs-Community zur Funktion „joinAdInterestGroup“ im PA API-Vorschlag sorgfältig. Ein wichtiger Diskussionspunkt konzentriert sich auf die optimale Methode zur Verwaltung der Lebensdauer von Anzeigenaufträgen. Wir prüfen die Vorteile eines separaten Arguments für den Parameter „lifetimeMs“, da dies für potenzielle zukünftige Verbesserungen der Spezifikation mehr Flexibilität und Anpassungsfähigkeit bietet. Hier finden Sie weitere Informationen zu diesem Problem. Wir freuen uns auch über zusätzliches Feedback.
API-Verwendung	Es besteht die Gefahr erhöhter Falsch-Negativ-Raten im PA API-Framework aufgrund von Kollisionen mit Browser-IDs mit niedriger Entropie.	Das Chrome-Team arbeitet aktiv an der kontinuierlichen Optimierung des PA API-Frameworks. Vielen Dank für die Diskussion zu möglichen Falsch-Negativ-Raten, die durch Kollisionen von Browser-IDs entstehen. Wir prüfen dieses Feedback sorgfältig und werden dafür sorgen, dass alle relevanten Faktoren in den aktualisierten Analysen berücksichtigt werden. Wir sind bestrebt, eine Lösung zu entwickeln, die die gewünschten Datenschutzergebnisse erzielt und gleichzeitig für Genauigkeit und Zuverlässigkeit sorgt. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Verwendung	Ist eine Browser-ID mit niedriger Entropie erforderlich, um zu verhindern, dass Clients in einem K-Anonymitätssystem wiederholt „Join“-Anfragen für dasselbe Objekt senden?	Wir sind uns der laufenden Diskussion über die Verwendung von Browser-IDs bei der Implementierung von K-Anonymitätssystemen bewusst und begrüßen sie. Uns sind die Bedenken hinsichtlich der potenziellen Auswirkungen solcher IDs auf den Datenschutz bewusst. Bei unserer ursprünglichen Implementierung wurde eine Kennung mit niedriger Entropie als Missbrauchspräventionsmechanismus verwendet. Wir prüfen jedoch aktiv alternative Verfahren wie anonyme Zähl-Tokens, die den Datenschutz der Nutzer priorisieren und gleichzeitig die Integrität des Systems aufrechterhalten. Wir sind bestrebt, Lösungen zu finden, die eine verantwortungsvolle Datennutzung mit einem robusten Datenschutz vereinen. Wir freuen uns auf einen kontinuierlichen Dialog mit der Forschungsgemeinschaft. Hier finden Sie weitere Informationen dazu.
API-Verwendung	Wird die PA API von AMP (Accelerated Mobile Pages) unterstützt?	Die PA API wird derzeit nicht nativ von AMP unterstützt. Wir freuen uns über zusätzliches Feedback aus der Community, wenn die Unterstützung durch AMP für Sie eine hohe Priorität hat.
API-Verbesserung	Sie sollten den Typ aus den k-Anonymitätsüberprüfungen entfernen.	Wir prüfen das Feedback zur Optimierung der Strukturen von Anträgen auf K-Anonymität sorgfältig. Wir verstehen den Vorschlag, Parameter zu konsolidieren und Typen möglicherweise zu vereinheitlichen, um den Prozess zu optimieren. Unser Ziel ist es, für Effizienz und Wartbarkeit zu sorgen. Wir prüfen alle Optionen, während wir unsere Datenschutzlösungen weiter entwickeln. Hier finden Sie weitere Informationen zu diesem Problem. Wir freuen uns auch über zusätzliches Feedback.
Chrome-Benutzeroberfläche	Nutzer ohne technische Vorkenntnisse sollen die Möglichkeit haben, die Gruppen, zu denen sie gehören, einfach aufzurufen und zu verwalten. Dazu gehören auch Optionen zur Deaktivierung auf Websiteebene.	Uns ist bewusst, wie wichtig es ist, nutzerfreundliche Tools zum Verstehen und Verwalten von IGs bereitzustellen. Wir haben verschiedene Methoden sorgfältig geprüft und festgestellt, dass die Identifizierung von IGs anhand der Website, über die sie registriert wurden, das beste Gleichgewicht zwischen Klarheit und Datenschutz bietet. Derzeit erfolgt die globale Verwaltung von Identitätsgruppen in den Chrome-Einstellungen. Wir arbeiten kontinuierlich daran, die Nutzerfreundlichkeit in diesem Bereich weiter zu verbessern. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Sicherheit	Ist die PA API anfällig für Datenschutzverletzungen durch Creative-Anzeigeninteraktionen, auch im Kontext von abgegrenzten Frames?	Wir sind uns bewusst, dass durch ausgefeilte Anzeigeninteraktionen Datenlecks möglich sind. Wir untersuchen derzeit aktiv das Zusammenspiel zwischen abgegrenzten Frames, der PA API und potenziellen Angriffsvektoren. Das Risiko von Datenschutzverstößen zu minimieren, hat für uns oberste Priorität. Wir sind bestrebt, robuste Lösungen zu entwickeln, die Innovation und den Schutz der Nutzer in Einklang bringen. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
Latenz	Ist das Standardzeitlimit von 50 ms für die Logik von Käufergeboten ein realistischer Wert?	Wir nehmen die Bedenken hinsichtlich potenzieller Inkonsistenzen zwischen der Spezifikation und dem Timing von Netzwerkanfragen für die Gebotslogik zur Kenntnis. Wir überprüfen die Spezifikationen aktiv auf ihre Richtigkeit und prüfen die optimalen Standardzeitüberschreitungseinstellungen, um Leistung und Machbarkeit in Einklang zu bringen. Hier finden Sie weitere Informationen zu diesem Problem. Wir freuen uns auch über zusätzliches Feedback.
Dokumentation	Potenzielles Timing-Leak in der Spezifikation, bei dem eine Website ableiten könnte, ob eine Anzeige den Grenzwert für die k-Anonymität nicht erreicht hat, und potenzielle Auswirkungen auf websiteübergreifendes Tracking.	Uns ist das Problem mit einem möglichen Zeitleck bekannt. Wir haben eine Abweichung in der Spezifikation festgestellt und ergreifen Maßnahmen, damit der K-Anonymitätsstatus von Anzeigen vor der Auktion ermittelt wird, um solche Datenlecks zu verhindern. Wir nehmen diese Bedenken ernst und werden die Spezifikation entsprechend aktualisieren. Hier finden Sie weitere Informationen zu diesem Problem. Wir freuen uns auch über zusätzliches Feedback.
API-Verwendung	Möglichkeiten zur Implementierung einer SSP-Sperrliste in der PA API	Wir sind uns bewusst, dass es Mechanismen zur Verwaltung von Anzeigeneinschränkungen durch SSPs braucht. Wir empfehlen Ihnen, Lösungen zu prüfen, bei denen die On-Device-Analyse priorisiert und vorhandene Anzeigenmetadaten genutzt werden, um die Privatsphäre der Nutzer zu schützen und gleichzeitig Flexibilität zu ermöglichen. Wir arbeiten mit Entwicklern zusammen, um die optimalen Ansätze für die PA API zu ermitteln. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Verwendung	Kann jemand seinem Browser vorgeben, die PA API so zu verwenden, dass Websites dies nicht erkennen können?	Uns ist bewusst, dass die Deaktivierung der PA API in ihrer aktuellen Form von Websites erkannt werden kann. Wir arbeiten aktiv an Funktionen wie zusätzlichen Geboten, ausschließendem Targeting und dem Rendern von eingezäunten Frames, um den Datenschutz zu verbessern und nicht erkennbare Deaktivierungsoptionen anzubieten. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
A/B-Testmodus	Rechenzentrums-Traffic, der als Maßnahme 1.1 gekennzeichnet ist.	Das Chrome-Team hat mit dem GAM-Team bestätigt, dass diese Zugriffe jetzt aus dem Test herausgefiltert werden. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Verwendung	Effizienz und Fairness der Implementierung von „interestGroupBuyers“ in der PA API.	Uns ist bewusst, dass es derzeit Diskussionen über die Effizienz und Fairness des Felds „interestGroupBuyers“ in PA API-Auktionen gibt. Wir sind uns der Kompromisse zwischen Effizienz, Datenschutz und Marktfairness bewusst. Verkäufer müssen Geschäftsbeziehungen mit Käufern verwalten. Wir arbeiten jedoch daran, den Abgleich zu optimieren. Dazu gehören unter Umständen dynamische Anpassungen auf der Grundlage von Echtzeitdaten und Hybridmodellen. Wir sind weiterhin bestrebt, Lösungen zu finden, bei denen der Datenschutz für Nutzer an erster Stelle steht und die ein wettbewerbsfähiges Werbesystem unterstützen. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
Chrome-Benutzeroberfläche	Potenzielle Speicherprobleme und Unklarheiten bei der Benutzeroberfläche im Zusammenhang mit IG in Chrome.	Uns sind die Bedenken hinsichtlich der Darstellung von IGs in den DevTools bekannt. Die aktuelle Ansicht enthält zwar alle IG-Ereignisse für das bisherige Tracking, wir sind uns aber bewusst, dass es hilfreich ist, den aktuellen Status der gespeicherten IGs besser nachvollziehen zu können. Wir werden Optimierungen und mögliche Verbesserungen der Benutzeroberfläche untersuchen, um die Informationen für Entwickler zu verbessern. Bei der Arbeitsspeicherverwaltung ist die IG-Implementierung so konzipiert, dass Speicherlecks verhindert werden. Wir überwachen und optimieren die Ressourcennutzung jedoch kontinuierlich. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
Dokumentation	Der Verfasser des ursprünglichen Beitrags erhält einen Fehler, wenn er benannte Anzeigengrößen direkt im Feld „sizeGroup“ der Funktion „joinAdInterestGroup“ verwendet. Er möchte wissen, ob das beabsichtigt ist.	Wir sind uns bewusst, dass es sinnvoll ist, die Anzeigenkonfiguration in der Funktion „joinAdInterestGroup“ zu optimieren. Wir arbeiten daran, diese Einschränkung zu beheben, und planen, diese Funktion in zukünftigen Updates zu aktivieren. Diese Verbesserung steht im Einklang mit unserem Bestreben, Entwicklern flexible und effiziente Tools für die Anzeigenverwaltung zur Verfügung zu stellen. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
Label für von Chrome unterstützte Tests	Bitten Sie um direkte Daten zu Modus A und Modus B sowie um genaue Labels in „sendReportTo“, damit wir den Test konsistent verfolgen können.	Wir besprechen diese Anfrage in diesem Artikel und freuen uns über zusätzliches Feedback.
Dokumentation	Ist der Domainname des Verkäufers in Anfragen enthalten, die zu Validierungszwecken an den vertrauenswürdigen Server des Verkäufers gesendet werden?	Wir bestätigen, dass der Parameter „hostname“ ursprünglich aus der Dokumentation der Protected Audience KV Server API fehlte. Wir möchten Entwicklern versichern, dass der Domainname des Verkäufers automatisch in Anfragen an den vertrauenswürdigen Server des Verkäufers aufgenommen wird. Diese Funktion ist für robuste Prozesse zur Anzeigenüberprüfung unerlässlich. Wir haben die Dokumentation aktualisiert, um diesen Fehler zu korrigieren. Wir legen weiterhin großen Wert auf Klarheit und Transparenz für die Entwickler. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Verwendung	Mögliche Methoden, den Anzeigenimpressions-Tracking-Aufruf in Berichten in den Anzeigengruppennamen einzubinden	Wir sind bestrebt, die Notwendigkeit robuster Meldemechanismen mit dem Grundsatz des Datenschutzes für Nutzer in Einklang zu bringen. Die Einbeziehung von IG-Namen in das Tracking von Anzeigenimpressionen unterliegt Sicherheitsmaßnahmen zur k-Anonymität, die die Identifizierung von Einzelpersonen verhindern sollen. Wir werden weiterhin innovative Lösungen für die Berichterstellung innerhalb dieser Datenschutzeinschränkungen entwickeln. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Funktion	Fordern Sie den vertrauenswürdigen Server des Käufers auf, HTTP-Header für Clienthinweise zu empfangen.	Wir verfolgen diesen Funktionswunsch hier.
API-Verwendung	Muss für das Laden der Delegierungsdatei der Header „Access-Control-Allow-Origin“ erforderlich sein, da er das Verhalten der IG-Mitgliedschaft für den Browser vorschreibt?	Wir verpflichten uns, Best Practices für die Websicherheit einzuhalten. Die Anforderung des Headers „Access-Control-Allow-Origin“ für Delegierungsdateien sorgt für Übereinstimmung mit den CORS-Prinzipien und verhindert die unbeabsichtigte Offenlegung vertraulicher Informationen. Wir arbeiten daran, diesen Prozess zu optimieren und gleichzeitig eine hohe Sicherheit zu gewährleisten. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Verwendung	Anzeigenservern die Personalisierung von Creatives im Rahmen der PA API ermöglichen.	Wir sind uns der Rolle bewusst, die Ad-Server bei der Personalisierung von Creatives spielen können. Wir arbeiten aktiv an Lösungen, um Anzeigenserver in der PA API zu unterstützen, z. B. das Modell „Joint IG“, bei dem Gebots- und Creative-Auswahllogik kombiniert werden können. Unser Ziel ist es, eine gute Balance zwischen robusten Funktionen für Creatives und dem Schutz des Datenschutzes für Nutzer zu finden. Wir freuen uns über weitere Zusammenarbeit und Feedback zur Weiterentwicklung der API, um die Anforderungen aller Stakeholder zu erfüllen. Hier können Sie uns Ihr Feedback mitteilen.
Datenschutz	Verfügbarkeit alternativer IDs (z.B. RampID, ID5) in Kontextgebotenanfragen könnten die Datenschutzziele der PA API untergraben, da sie die websiteübergreifende Datenerhebung erleichtern.	Wir sind uns der potenziellen Spannungen zwischen websiteübergreifenden Kennungen und den Datenschutzzielen der PA API bewusst. Publisher können solche IDs freigeben. Die PA API wurde jedoch entwickelt, um die Anzeigenauswahl von der Notwendigkeit eines websiteübergreifenden Trackings zu entkoppeln. Wir möchten ein datenschutzfreundliches Werbesystem schaffen und empfehlen Entwicklern, den Ansatz der PA API zu priorisieren. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
Caching	Gibt es eine Möglichkeit, die Wiederverwendung von Gebotsscripts für mehrere Auktionen zu verhindern?	Wir sind uns des beobachteten Caching-Verhaltens von Gebotsscripts im Rahmen der PA API bewusst. Standard-HTTP-Caching-Mechanismen werden zwar unterstützt, aber aufgrund des Suspend-Verhaltens von Geräten und der Ausgestaltung von Gebotsausführern besteht die Möglichkeit, Scripts für mehrere Auktionen wiederzuverwenden. Das Team untersucht Lösungen, mit denen Käufer mehr Kontrolle über das Script-Caching haben, um ihre Gebotsstrategien effektiv zu verwalten. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Verwendung	Zentrale Berichterstellung zu Gebotsaktivitäten für alle IGs einer DSP unter Wahrung des Datenschutzes der Nutzer.	Bei der Entwicklung der PA API legen wir großen Wert auf den Datenschutz der Nutzer. Die direkte Berichterstellung zu einzelnen Gebotsereignissen ist aufgrund von Risiken beim websiteübergreifenden Tracking nicht möglich. Wir bieten jedoch Mechanismen wie den gemeinsamen Speicher und die private Aggregation an. So erhalten DSPs aggregierte Informationen zu Gebotsaktivitäten, die den Datenschutz der Nutzer wahren.
API-Verwendung	Die Abfrage von „sendReportTo()“ in „reportResult()“ erfolgt nur in 94% der Fälle, verglichen mit einer Abfrage, die mit „forDebuggingOnly.reportAdAuctionWin()“ registriert wurde.	Auch wenn sie nicht unbedingt gleichzeitig abgerufen werden, ist es möglich, dass beide URLs gleichzeitig abgerufen werden. In einigen Fällen wurde das Worklet des Komponentenanbieters entfernt und muss neu geladen werden, damit die Funktion „reportResult()“ ausgeführt werden kann. Weder die Zeit, die zum Abrufen der Bewertungslogik benötigt wird, noch die Zeit, die zum Neuladen des Worklets benötigt wird, wirken sich auf das Zeitlimit von 50 Millisekunden für reportResult() aus. Hinweis: Chrome verwendet Caching-Header, um das Abrufverhalten zu definieren, wenn das Worklet neu geladen werden muss. Weitere Informationen zu den Phasen einer PA-Auktion
K-Anonymität	Bestätigung anfordern, dass der Name der Interessengruppe die k-Anonymität der Anzeigenbereitstellung nicht beeinträchtigt.	Damit ein Creative als k-anonym eingestuft werden kann, muss das Tupel aus der URL des IG-Inhabers, der URL des Gebotsscripts, der Creative-URL und der Anzeigengröße über einen bestimmten Zeitraum (w) den angegebenen Grenzwert (k) erreichen. Der k-Anonymitätsstatus wird regelmäßig aktualisiert (p).
Chrome-Benutzeroberfläche	Vorschlag, die Art der „internen Sichtbarkeit“ bereitzustellen, die viele MVC-, ORM- und andere Frameworks bieten. Beginnen Sie z. B. mit der einfachen Protokollierung ausgewählter interner Ereignisse in einem neuen Bereich in den Dev-Tools -> „Anwendung“ -> „Anwendung“.	Wir diskutieren den Vorschlag in diesem Artikel und freuen uns über zusätzliches Feedback.
Chrome-Benutzeroberfläche	In der DevTools-Ansicht für die Gruppenarbeit werden keine Elemente mit Priorität angezeigt.	Hier finden Sie weitere Informationen zu diesem Problem.
API-Verbesserung	Es ist besser, dem Creative-Ad-Server zu erlauben, seine eigenen Ereignisse zu erfassen. Könnte eine Liste der zulässigen Tracking-Domains konfiguriert werden?	Hier finden Sie unseren Vorschlag. Wir freuen uns über zusätzliches Feedback aus der Community.
API-Funktionsanfrage	Kann die PA API erweitert werden, um nicht RTB-Medientransaktionen zu unterstützen und wichtige Anwendungsfälle wie Anzeigenbereitstellung und DCO beizubehalten?	Wir diskutieren das Problem in diesem Artikel und freuen uns über zusätzliches Feedback.
Zeitüberschreitung bei Publisher-Auktionen	Publisher müssen die Auktionsdauer steuern können, um entgangene Impressionen zu vermeiden. Das gilt insbesondere für Header-Gebotskonfigurationen, bei denen Anzeigen nacheinander ausgewählt werden.	Wir sind uns bewusst, wie wichtig es ist, Publishern eine detaillierte Kontrolle über die Zeitüberschreitungen bei Anzeigenauktionen zu geben. Wir prüfen derzeit, wie ein globaler Auktions-Timeout-Mechanismus implementiert werden kann, möglicherweise im Objekt „auctionConfig“. Dabei berücksichtigen wir auch Grenzfälle. Mit dieser Funktion möchten wir die Impressionsauslieferungsraten für Publisher optimieren. Wir arbeiten weiterhin mit der Community zusammen, um die beste Lösung zu finden. Wir diskutieren das Problem in diesem Artikel und freuen uns über zusätzliches Feedback.
API-Verbesserung	Das aktuelle Design von IGs in der PA API führt aufgrund langer Render-URLs zu großen Metadatengrößen. Die Tester wünschen sich eine Möglichkeit, diese URLs zu komprimieren, um die Effizienz zu steigern.	Wir sind uns bewusst, wie wichtig es ist, die Größe von IG-Metadaten zu optimieren, insbesondere bei effizienten Anzeigenauktionen. Wir sind der Meinung, dass eine stempelbasierte Lösung zum Komprimieren von Render-URLs großes Potenzial bietet. Wir prüfen die vorgeschlagenen Vorlagendesigns sorgfältig und achten darauf, dass jede implementierte Lösung robuste Mechanismen zur Missbrauchsprävention enthält, um die Browserstabilität zu gewährleisten. Die Zusammenarbeit mit der Webstandards-Community zur Entwicklung des optimalen Ansatzes unter Berücksichtigung dieser Überlegungen hat weiterhin Priorität. Wir diskutieren das Problem in diesem Artikel und freuen uns über zusätzliches Feedback.
API-Verwendung	Tester, die mit nativen Anzeigenformaten arbeiten, möchten den Auktionsprozess der Privacy Sandbox optimieren, indem sie mehrere Anzeigenergebnisse in einem einzigen Aufruf abrufen, um die Netzwerklast zu reduzieren und die Anzeigen-Rendering-Geschwindigkeit zu verbessern.	Wir sind uns der Leistungsbedenken bewusst, die beim Rendern von nativen Anzeigen in der Privacy Sandbox geäußert wurden. Wir sind bestrebt, ein Gleichgewicht zwischen Effizienz und einem strengen Datenschutz für Nutzer zu finden. Die Auslieferung mehrerer Anzeigen mit der vollen Punktzahl beeinträchtigt den Datenschutz. Wir arbeiten jedoch aktiv daran, den Auktionsprozess zu optimieren. Wir arbeiten daran, die PA API-Unterstützung für native Anzeigenformate zu verbessern und alternative Mechanismen zu untersuchen, um die Effizienz innerhalb der strengen Datenschutzanforderungen der Privacy Sandbox zu verbessern. Wir diskutieren das Problem in diesem Artikel 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ätsstufen oder Regeln für private Marktplätze.	Wir verstehen, dass eine detaillierte Kontrolle der Anzeigenbewertung und ‑sortierung in der Privacy Sandbox erforderlich ist, insbesondere bei komplexen Gebotsszenarien. Wir erkennen an, dass die vorgeschlagenen Lösungen Tupel und mathematische Funktionen verwenden, um eine mehrdimensionale Bewertung zu erreichen, ohne den Datenschutz der Nutzer zu gefährden. Diese Ansätze können zwar die Komplexität für Entwickler erhöhen, bieten aber die erforderliche Ausdruckskraft. Wir arbeiten daran, diese Prozesse zu optimieren, möglicherweise durch Hilfsfunktionen oder Richtlinien, um die Privacy Sandbox-Funktionen für eine erweiterte Auktionslogik optimal zu nutzen. Hier findest du weitere Informationen zu diesem Problem. Wir 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 wird.	Wir besprechen diese Anfrage in diesem Artikel und freuen uns über zusätzliches Feedback.
adCost	Aufschlüsselung von „adCost“ zulassen	Mit jedem Kostenwert können Sie eine begrenzte Menge an Informationen aus der Auktion senden. Wenn eine ganze Liste von N dieser Kosten zulässig wäre, würde das ausreichen, um eine vollständige Nutzer-ID zu senden, was websiteübergreifendes Tracking ermöglichen würde. Hier findest du weitere Informationen dazu. Wir freuen uns über zusätzliches Feedback.
resolveToConfig	Sollte „resolveToConfig“ von der obersten Ebene übernommen und in „browserSignals“ freigegeben werden?	Wir besprechen diese Anfrage in diesem Artikel und freuen uns über zusätzliches Feedback.
Bessere Tools	Gibt es etwas Ähnliches wie chrome://topics-internals, aber für die PA API?	Es gibt nichts, das genau dasselbe ist. Es gibt jedoch umfangreiche Entwicklertools für die PA API .
Labels	Kann Chrome Labels verwenden, um die 20% der k-anon-Population zu identifizieren?	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback aus der Community.
Dokumentation	Werden Worklets für Privacy Sandbox-Auktionen zu Standard-Worklet-Typen?	Aufgrund der besonderen Datenschutz- und Sicherheitsanforderungen unterscheiden sich diese Worklets erheblich von den Standardtypen von Browser-Worklets. Wir gehen daher nicht davon aus, dass sie bald zu Standardtypen von Worklets in der HTML-Spezifikation werden. Wir arbeiten daran, unsere Entwicklerressourcen um klare Erläuterungen zur Implementierung und Ausführungsumgebung von Auktions-Worklets zu ergänzen, damit diese Informationen für Privacy Sandbox-Teilnehmer leichter zugänglich sind. Weitere Informationen dazu finden Sie hier.
BYOS-KV-Server (Bring-Your-Own-Server, eigener Server)	Bei einer BYOS-KV-Dienstkonfiguration können Dritte möglicherweise mehrere Gruppen (vom selben Inhaber) ermitteln, denen ein Nutzer über KV-Dienstabfragen beigetreten ist.	Das ist nicht mehr möglich, wenn KV-Server in TEEs ausgeführt werden. So können wir dafür sorgen, dass sie das veröffentlichte Vertrauensmodell einhalten.
userBiddingSignals	einen Teil der „userBiddingSignals“ aktualisieren und andere beibehalten.	Das ist bereits möglich, ohne dass Änderungen an der API erforderlich sind.
API-Verwendung	Implementieren Sie ein Anzeigenhäufigkeitslimit für mehrere IGs in der Privacy Sandbox, möglicherweise mit dem KV-Server oder den geänderten „prevWinsMs“-Daten.	Wir wissen, dass es Bedarf an erweiterten Möglichkeiten zur Häufigkeitsbeschränkung in der Privacy Sandbox gibt. Uns ist bewusst, dass die aktuellen Einschränkungen bei der Datenweitergabe zwischen Werbetreibendengruppen bei der Implementierung dieser Strategien zu Herausforderungen führen können. Der KV-Server bietet zwar einen potenziellen Mechanismus mit geeigneten Datenschutzmaßnahmen, wir empfehlen Entwicklern jedoch, Lösungen innerhalb eines einzigen IG-Modells zu prüfen. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.
API-Verwendung	Anbieter von Komponenten, die an verschachtelten Auktionen in der Privacy Sandbox teilnehmen, benötigen Informationen zu den Zeitüberschreitungen auf Auktionsebene, um ihre eigenen Konfigurationen zu optimieren und unnötige Verzögerungen zu vermeiden.	Wir sind uns bewusst, dass die Zeitüberschreitung für Verkäufer auf oberster Ebene und Komponentenverkäufer in der Privacy Sandbox besser koordiniert werden muss. Wir prüfen derzeit die Einführung neuer Zeitüberschreitungsmechanismen, einschließlich einer potenziellen Zeitüberschreitung für die gesamte Auktion. Außerdem untersuchen wir Möglichkeiten, Zeitüberschreitungen der obersten Ebene auf Komponentenauktionen anzuwenden. Unser Ziel ist es, die Effizienz und Vorhersagbarkeit für alle Teilnehmer am Privacy Sandbox-Auktionsprozess zu verbessern. Hier findest du weitere Informationen zu diesem Problem. Wir freuen uns über zusätzliches Feedback.

Protected Audience-Dienste

Feedbackthema	Zusammenfassung	Chrome-Antwort
Vertrauenswürdige Ausführungsumgebungen (TEEs)	Ist es teurer, TEEs in öffentlichen Clouds als in lokalen Rechenzentren für Anzeigentechnologien auszuführen?	Unsere Antwort ähnelt der aus den vorherigen Quartalen: Unser aktuelles TEE-Sicherheitsmodell profitiert von den Praktiken der öffentlichen Cloud-Implementierungen. Insbesondere bieten aktuelle hardwarebasierte TEEs keinen Schutz vor allen physischen Angriffen. Unsere unterstützten öffentlichen Cloud-Anbieter AWS und Google Cloud haben Maßnahmen zur Risikominimierung bei physischem Zugriff entwickelt und implementiert, einschließlich Zugriffen durch Mitarbeiter. Weitere Informationen zum On-Premise-Support finden Sie unten. Werbetechnologieanbieter haben uns mitgeteilt, dass der Betrieb von Cloud-Diensten teurer ist als der Betrieb von On-Premise-Werbetechnologie-Rechenzentren. Wir sind zwar nicht in der Lage, diese Aussagen zu bewerten, freuen uns aber über zusätzliches Feedback zu den Kosten und prüfen weiterhin Optionen zur Erweiterung unserer TEE-Unterstützung.
TEEs	Unterstützung von TEEs in nicht öffentlichen Cloud-Umgebungen	Unsere Antwort ähnelt der aus den vorherigen Quartalen: Wir prüfen zwar weiterhin, ob wir Optionen jenseits von öffentlich zugänglichen Cloud-basierten Lösungen unterstützen, haben aber derzeit keine Pläne, On-Premise-TEEs zu unterstützen. Angesichts der Sicherheitsanforderungen der Privacy Sandbox und der erheblichen Herausforderungen, die On-Premise-Bereitstellungen mit sich bringen, sind wir der Ansicht, dass es für das gesamte System am vorteilhaftesten ist, cloudbasierte Bereitstellungen weiter auszubauen und zu verbessern, z. B. durch die Unterstützung von Google Cloud zusätzlich zu AWS. Wir würden uns aber über zusätzliches Feedback freuen, warum eine solche Anforderung angesichts der Datenschutz- und Sicherheitsanforderungen notwendig und umsetzbar ist.
Andere Cloud-Anbieter	Support für andere Cloud-Anbieter	Wir sind immer offen für Vorschläge zu anderen Cloud-Anbietern. Wir planen jedoch, mindestens Google Cloud und AWS zu unterstützen, wenn die 3PCD-Pflicht eingeführt wird. Weitere Informationen finden Siein diesem Hilfeartikel.
B&A Services API	Wie geht es mit der B&A Services API weiter? Wird die Funktion bei Geräteauktionen über oder unter der Protected Audience API des Chrome-Browsers priorisiert?	Unsere Antwort ähnelt der aus den vorherigen Quartalen: Wir bleiben dem aktuellen Design für On-Device-Gebote für Protected Audience treu. Die B&A-Dienste wurden vorgeschlagen, um mögliche Lösungen für eine Reihe von Anwendungsfällen zu untersuchen, bei denen die Rechenleistung oder Netzwerkgeschwindigkeit des Geräts möglicherweise eingeschränkt ist.
Standardisierung	B&A-Dienste wurden nicht standardisiert.	Der Vorschlag für B&A-Dienste befindet sich in der Mitte einer Phase des Standardisierungsprozesses. Wir freuen uns über weitere Beiträge zur Unterstützung dieses Ziels. Der Vorschlag basiert auf früheren Vorschlägen und wird durch umfangreiche offene Diskussionen im W3C öffentlich entwickelt. Interessierte Entwickler können damit beginnen, damit zu experimentieren und Feedback zu geben. Das ist das übliche Muster für die Entwicklung von Webfunktionen, wie es in unserem Blogpost beschrieben wird.
KV-Server	Stellen Sie die vollständige URL für das Content-, Kontext- und Website-Targeting für den KV-Server des Käufers bereit.	Wir diskutieren diese Anfrage in diesem Artikel und freuen uns über zusätzliches Feedback aus der Community.
Dokumentation	Die Dokumentation zu „Vertrauenswürdige/erzwungene Komponenten im Vergleich zu optionalen“ auf GitHub verwirrt einige Anbieter von Anzeigentechnologien, die eigene Bereitstellungs-Images und -Infrastrukturen haben.	Wir möchten die Dokumentation für „Vertrauenswürdige/erzwungene Komponenten im Vergleich zu optionalen Komponenten“ verbessern. Ich würde gerne von Ihnen wissen, ob diese Arbeit priorisiert werden sollte.
API-Verbesserung	Der HTTP-Statuscode eines KV-Serveraufrufs sollte der Funktion „scoreAd()“ auch als Parameter zur Verfügung stehen.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback aus der Community.
Dokumentation	Geben Sie weitere Informationen dazu an, wie JS- und WASM-Arbeitslasten bei der UDF-Ausführung genau behandelt werden.	Wir arbeiten daran, diese Informationen bereitzustellen. Hier können Sie uns zusätzliches Feedback geben.
Dokumentation	Aktualisierung des Repository-Namens beantragen	Wir haben das Repository in „protected-auction-key-value-service“ umbenannt. Dieser Name entspricht dem Begriff für die Gruppe von Diensten, zu der es gehört. Zu dieser Gruppe gehören auch andere Repositories wie die Diskussion zu Protected Audience Services und die Dokumentation zu Protected Auction Services.
Dokumentation	Entfernen Sie den Verweis auf die Cloud Debugger API in bidding_auction_services_gcp_guide.md.	Wir haben die Dokumentation aktualisiert und die Referenz entfernt.
API-Verwendung	Die Latenz durch die KV-Suche dauert mehr als 50 ms. Das dauert fast 100 Millisekunden. Haben Sie Tipps, was bei anderen Verkäufern gut funktioniert hat? Haben Sie Vorschläge, wie ich die Zeitüberschreitungen und das Timing messen kann?	Der KV-Serveraufruf erfolgt im Kontext der Script Runners, also der speziellen geschützten Umgebung im Chrome-Browser. Damit sollen Informationen in diesen Script-Runnern vor nicht API-basiertem Zugriff geschützt werden. Hier finden Sie eine ausführliche Erklärung.
API-Verwendung	Gibt es ein Zeitlimit, innerhalb dessen der KV-Server antworten muss?	Verkäufer können das Feld „perBuyerCumulativeTimeouts“ in der Auktionskonfiguration angeben. Diese Zeitüberschreitung umfasst auch die Zeit, die zum Abrufen vertrauenswürdiger Gebotssignale erforderlich ist.
Latenz	Wie arbeitet das Privacy Sandbox-Team daran, die Latenz zu verringern?	Informationen zu den Strategien, mit denen wir die Latenz innerhalb akzeptabler Grenzen halten möchten, finden Sie hier.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Manuelle Kampagnenoptimierung	Die manuelle Kampagnenoptimierung wird von ARA nicht unterstützt.	Wir haben dieses Szenario mit dem Ad Tech-Team besprochen und Möglichkeiten aufgezeigt, wie ARA die manuelle Kampagnenoptimierung unterstützen kann. ARA wurde so konzipiert, dass AdTech-Anwendungen angepasst und flexibel eingesetzt werden können, um eine Vielzahl von Anwendungsfällen zu lösen. Unter anderem wurden flexible Konfigurationen auf Ereignisebene und die Verwendung von Berichten auf Ereignisebene mit Zusammenfassungsberichten vorgeschlagen, um die Auswirkungen von Störfaktoren zu verringern und die Anforderungen an die manuelle und automatische Optimierung zu erfüllen. Wir freuen uns über weiteres Feedback zum Thema Anpassungsmöglichkeiten und Flexibilität von ARA-Konfigurationen.
Conversion-Typ	Google erlaubt nur acht Conversion-Typen, was sehr einschränkend ist.	Wir haben den Großteil der flexiblen Berichte auf Ereignisebene implementiert. Das bietet Werbetreibenden mehr Flexibilität bei der Anzahl der Berichtszeitraume, der Attributionsberichte und der Triggerdaten, die sie verwenden können. Sie können eine Konfiguration auswählen, mit der bis zu 32 verschiedene Conversion-Typen gemessen werden können.
Maximal zulässige Anzahl von Ereignissen in Berichten, die zusammengefasst werden können	Die Mindestanzahl von 20 Conversion-Ereignissen pro Bericht, der zusammengefasst werden kann, ist für kleinere Werbetreibende mit begrenztem Budget nicht praktikabel.	Es gibt keine Mindestanzahl von Conversion-Ereignissen pro Bericht, der zusammengefasst werden kann. Außerdem gibt es eine Reihe von Designentscheidungen, die getroffen werden können, um Berichte, die zusammengefasst werden können, für kleinere Werbetreibende zu optimieren. Dazu gehören die Änderung der erfassten Schlüsselstruktur / Dimensionen, das Testen verschiedener Epsilon-Werte, das Testen längerer Batch-Frequenzen und das Testen verschiedener Beitragsbudgetzuweisungen zwischen Analysezielen. Kleinere Anbieter von Anzeigentechnologien können auch Berichte auf Ereignisebene und Zusammenfassungsberichte kombinieren, um die Auswirkungen von Störfaktoren zu verringern.
Echtzeitdaten	Wenn DSPs keine Echtzeitdaten (z.B. zu Klicks, Sitzungen und Conversions) zur Verfügung gestellt werden, mit denen sie ihre Gebotsstrategie anpassen und die Kampagneneffektivität verbessern können, verstößt das gegen die Verpflichtung, bestehende Funktionen beizubehalten.	Auch bei der ARA werden Klicks und Sitzungen in Echtzeit erfasst. Conversions werden auch bei 3 PCs immer nachträglich erfasst.
Fehlende Felder	Fehlende Anforderungen beim Roll-out des flexiblen Ereignisses vom Typ „Vollständig“: i) Währungsfeld und ii) Feld „orderID“/„TransactionID“.	Wir planen derzeit nicht, ein Feld für die Währung oder die Bestell-/Transaktions-ID im Rahmen der flexiblen Ereignisebene zu unterstützen, da es bereits Möglichkeiten dafür gibt. Wir sind für weiteres Feedback zu diesen Feldern offen und werden die Entscheidung noch einmal überdenken, falls es weitere Anwendungsfälle gibt, in denen diese erforderlich sind. So können Sie mit dem aktuellen ARA-Design Informationen zum Währungs- und Bestell-ID-Typ erfassen: 1. Laut Feedback wird die Währung anhand des Standorts eines Nutzers bestimmt. Dieser kann als Teil der „source_event_id“ hinzugefügt werden, um zu ermitteln, welche Währung verwendet wurde. 2. Das Feld „Bestell-ID“ ist laut Feedback erforderlich, damit Conversions und Werte nicht versehentlich doppelt gezählt werden. Dazu können Deduplizierungsschlüssel verwendet werden.
Datenschutzbudget	Privacy Budget für datengetriebene Attribution schränkt die Möglichkeit ein, Analysen über mehrere Dimensionen hinweg durchzuführen	ARA wurde so konzipiert, dass Anbieter von Anzeigentechnologien ihre eigenen ARA-Konfigurationen anpassen können, um eine Vielzahl von Attributionsszenarien abzudecken. Bei der aktuellen ARA-Version müssen Anbieter von Anzeigentechnologien abwägen, welche Dimensionen für sie am wichtigsten sind und welche Auswirkungen Rauschen auf ihre Daten hat. Je nach Detaillierungsgrad der gemessenen Dimensionen ist es für den Datenschutz unerlässlich, den Daten Rauschen hinzuzufügen. Wir sind offen für weiteres Feedback zum Analysesystem hinsichtlich der Möglichkeit, Analysen über verschiedene Dimensionen hinweg durchzuführen. Wir müssen jedoch die spezifischen Anwendungsfälle kennen, für die dies erforderlich ist.
Spezifikation aktualisieren	Google hat zwar angegeben, dass es von festen zu flexiblen Zeitfenstern für Ereignisberichte übergegangen ist, dies ist jedoch nicht in den technischen Spezifikationen von Google berücksichtigt. Dort ist weiterhin ein Mindestzeitraum von einer Stunde angegeben.	Mit flexiblen Berichten auf Ereignisebene können Anbieter von Anzeigentechnologien derzeit die Anzahl der Attributionsberichte pro Quellereignis, die Triggerdaten und die Anzahl/Länge der Berichtsfenster ändern. Für Berichte auf Ereignisebene gilt weiterhin ein Mindestzeitraum von einer Stunde. Dies ist wichtig, um den Datenschutz zu wahren und bestimmte Arten von Angriffen auf den Verlauf zu verhindern. Da Zusammenfassungsberichte aggregierte Informationen enthalten, können Anbieter von Anzeigentechnologien sich dafür entscheiden, aggregierbare Berichte sofort und ohne Verzögerung zu erhalten, wenn dies für ihre Anwendungsfälle erforderlich ist.
API-Design	Bedenken, dass die Reduzierung von Informationen in Conversion-Berichten und die Hinzunahme von Rauschen das System stärker als Google beeinträchtigen könnte	Google hat sich gegenüber der CMA verpflichtet, die Privacy Sandbox-Vorschläge so zu entwerfen und umzusetzen, dass der Wettbewerb nicht durch Bevorzugung des eigenen Geschäfts von Google verzerrt wird, und die Auswirkungen auf den Wettbewerb in der digitalen Werbung sowie auf Publisher und Werbetreibende aller Größen zu berücksichtigen.
Attributionskorrektur	ARA ermöglicht es dem Technologieanbieter nicht, die korrekte Attribution zu prüfen und zu bestätigen.	Es gibt viele Lösungen in ARA, die Überprüfungsfunktionen bieten: 1. Anbieter von Anzeigentechnologien können prüfen, ob das Verhalten von ARA ihren Erwartungen entspricht: – Der clientseitige Code von ARA ist Open Source. – Der serverseitige Code von ARA ist ebenfalls Open Source. Koordinatoren sorgen dafür, dass nur zulässige Versionen des Aggregationsdiensts aggregierbare Berichte entschlüsseln und verarbeiten können. 2. Chrome bietet Anbietern von Anzeigentechnologien eine Simulationsbibliothek, mit der sie das Attributionsverhalten überprüfen können. Dort können sie testen, wie die Attribution durch ARA in einer simulierten Umgebung funktioniert. 3. ARA unterstützt eine Reihe von Debug-Signalen, mit denen Sie prüfen können, ob und warum die erwartete Verarbeitung möglicherweise nicht stattgefunden hat.
(wurde auch in früheren Quartalen gemeldet) Rauschen	Feedback, dass der Geräuschpegel zu hoch ist und die Nützlichkeit der Berichte beeinträchtigt.	Wir haben mit Werbetechnologieexperten gesprochen, die uns dieses Feedback gegeben haben. Dabei haben wir Möglichkeiten gefunden, wie ARA angepasst werden kann, um auch bei Rauschen besser zu ihren Anwendungsfällen zu passen. In unserer Entwicklerleitfaden finden Sie die meisten Designentscheidungen und Anpassungen, die wir mit den Anbietern von Anzeigentechnologien besprochen haben. ARA wurde so konzipiert, dass Anbieter von Anzeigentechnologien ihre eigenen ARA-Konfigurationen anpassen können, um eine Vielzahl von Attributionsszenarien abzudecken. Sie müssen jedoch abwägen, welche Dimensionen für sie am wichtigsten sind und welche Auswirkungen die Datenrauschen auf ihre Daten haben. Wir sind offen für weiteres Feedback zum Thema Datenrauschen und können Ihnen weitere Informationen zu ARA-Steuerungselementen geben, mit denen sich die Auswirkungen von Datenrauschen ändern lassen.
Domainübergreifende Attribution	Wie werden domainübergreifende Attributionen erfasst?	Anbieter von Anzeigentechnologien können Nutzer zu verschiedenen Berichts-URLs weiterleiten, um diesen Anwendungsfall zu lösen. Wir freuen uns über weiteres Feedback zum Ökosystem in Bezug auf diesen Designaspekt von ARA.
API-Verbesserung	Ändern Sie regelmäßig den Skalierungsfaktor, der bei der Registrierung der Attribution für ARA-Zusammenfassungsberichte verwendet wird.	Wie aus der Diskussion auf GitHub hervorgeht, führt die Verwendung mehrerer Skalierungsfaktoren im Aggregationsdienst höchstwahrscheinlich zu mehr Rauschen in den Zusammenfassungsberichten als bei der aktuellen Funktion. Wir sind offen für weiteres Feedback zur Notwendigkeit von Skalierungsfaktoren in aggregierten Berichten, möchten aber auf den potenziellen Trade-off mit mehr Rauschen hinweisen. Wir prüfen auch, ob andere zukünftige ARA-Funktionen zur Lösung dieses Anwendungsfalls beitragen können.
API-Verwendung	Es besteht die Möglichkeit, die Freigabe von Attributionsereignissen für alle Teilnehmer zu vereinheitlichen. Das ist für SSPs, DSPs usw. von Vorteil.	Wir planen, uns mit Anbietern von Anzeigentechnologien auszutauschen, um ihr Feedback und etwaige Einschränkungen besser nachvollziehen zu können.
Testvolumen	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.
Dokumentation	Support für die Reparatur durch den Kunden selbst für Google Pixel	Wir haben Informationen zur Unterstützung dieses Anwendungsfalls veröffentlicht und freuen uns über zusätzliches Feedback aus der Community.
API-Verwendung	Die ARA wird Drittanbietern auf E-Commerce-Plattformen möglicherweise nicht der richtigen Quelle zugeordnet, wenn die Conversion nicht über den letzten Touch erfolgt.	Unternehmen können Filter verwenden, um eine falsche Attribution zu verhindern, da dann kein Conversion-Bericht generiert wird. Wir arbeiten auch an einem Vorschlag für die Filterung vor der Attribution, um diesen Anwendungsfall zu unterstützen.
Unterstützte Browser	Wird ARA in verschiedenen Browsern unterstützt?	Wir begrüßen es, wenn andere Browser die Privacy Sandbox APIs übernehmen, und nehmen uns weiterhin Zeit, unseren Ansatz offen im W3C zu diskutieren. Wir haben ausdrücklich die Interoperabilität als Ziel für die Einführung von ARA angegeben. Das Design von ARA soll browserunabhängig sein und flexible, vom Anbieter festgelegte Werte für Anbieter mit unterschiedlichen Datenschutzeinstellungen bieten. Andere Browser entscheiden selbst, ob sie praktikable Alternativen zu websiteübergreifenden IDs anbieten, die das digitale Ökosystem von Inhalten und Diensten unterstützen können. Wir freuen uns, dass Microsoft Edge angegeben hat, dass es ARA unterstützen wird.
API-Verwendung	Welche Art von Quelle wird für ARA-Quellregistrierungen für registerAdBeacon/reportEvent (und navigation_start/commit automatic beacons) 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 müssen vom Typ „Ereignisquelle“ sein.
API-Verwendung	Gilt die maximale Anzahl von 20 aggregierbaren Berichten pro Quelle für jedes Quellereignis? Gilt das Limit global oder pro Tag? Ist geplant, das Limit zu erhöhen?	Die Obergrenze von 20 aggregierbaren Berichten pro Quelle ist eine globale Obergrenze, bei der für jede Quelle 20 aggregierbare Berichte erstellt werden können. Das Limit wird vom Browser festgelegt und kann nicht konfiguriert werden. Mit diesem Limit soll verhindert werden, dass der Schutz echter Attributionsberichte durch Nullberichte missbraucht wird. Weitere Informationen dazu finden Sie hier.
API-Verwendung	Unterstützung für E-Mail-Marketing mit ARA	Derzeit gibt es in ARA keine direkte Unterstützung für diesen Anwendungsfall, wenn Sie nicht die Website des E-Mail-Hosts verwalten. Hier findest du weitere Informationen dazu. Wir freuen uns über zusätzliches Feedback.
Epsilon	Wann wird der Wert von Epsilon für die Aggregate API ermittelt?	Der aktuelle Epsilonwert kann von Anbietern von Anzeigentechnologien bis zu einem von der Privacy Sandbox festgelegten Grenzwert konfiguriert werden (derzeit 64). Wir empfehlen, verschiedene Epsilonwerte zu testen, Wendepunkte für Ihre eigenen Anwendungsfälle zu ermitteln und Feedback zu geben. Wir informieren die Werbetechnologieanbieter im Voraus, bevor Änderungen am Bereich der Epsilon-Werte vorgenommen werden.
API-Verbesserung	Es wird ein Anwendungsfall unterstützt, bei dem der Werbetreibende eine Kennung in das Feld „trigger_data“ einfügen kann, um sie mit externen CRM-Daten abzugleichen. So können Werbetreibende die Qualität von Conversions überprüfen.	Wir prüfen die Anfrage und freuen uns über zusätzliches Feedback hier.
API-Verwendung	Umgang mit Weiterleitungs-URLs als Ziel-URLs	Sie haben folgende Möglichkeiten: 1. Geben Sie die finale Ziel-URL in das Zielfeld ein: 2. Das Zielfeld kann bis zu drei URLs enthalten. Bei beiden Optionen muss die finale Ziel-URL bekannt sein. Weitere Informationen dazu finden Sie hier.

Zusammenfassungsdienst

Feedbackthema	Zusammenfassung	Chrome-Antwort
Schlüsselermittlungsmechanismus	Schlüsselermittlungsmechanismus anfordern	Wir haben einen Vorschlag für die Schlüsselerkennung und freuen uns über Feedback aus der Community.
API-Verwendung	Roadmap für die Sichtbarkeit des Aggregationsdiensts	Wir prüfen derzeit Optionen, um die Beobachtbarkeit zu verbessern. Hier können Sie uns Feedback geben.
API-Verbesserung	Ich möchte die Möglichkeit haben, Berichte noch einmal abzufragen.	Der Aggregationsdienst arbeitet an einem Vorschlag für neue Anforderungen, mit dem Anbieter von Anzeigentechnologien ihren Epsilonwert für jeden Bericht aufteilen können. Dies kann zu mehr Rauschen pro Abfrage führen, ermöglicht es aber Werbetechnologien, noch einmal abzufragen und den Datenschutz zu wahren.
API-Verbesserung	Ich möchte derselben AWS-ID mehrere Ursprünge zuordnen können.	Mit dem Aggregation Service können jetzt mehrere Websites in dasselbe Cloud-Konto (Google Cloud oder AWS) aufgenommen werden. So können Anbieter von Anzeigentechnologien dieselbe Aggregationsservice-Enklave für die Verarbeitung von Berichten von mehreren Websites und mehreren Ursprüngen derselben Websites verwenden.
API-Verwendung	Wenn aggregierbare Batches fehlschlagen, ist nicht klar, ob das Budget aufgebraucht ist oder nicht 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 lässt sich dieser Verlust minimieren?	Wenn der gesamte Job fehlschlägt, wird das Budget in der Regel nicht aufgebraucht. Bei seltenen Fehlern, bei denen das Budget aufgebraucht wird, können Anbieter von Anzeigentechnologien eine Budgetwiederherstellung beantragen. Wenn die Anzeigentechnologie häufige Jobfehler mit dem Fehler „Budget aufgebraucht“ verursacht, sollte die Batch-Strategie überprüft werden. Eine Anleitung zum Erstellen korrekter Batches und zum Vermeiden von Berichtsduplikaten und Fehlern finden Sie hier. Feedback zur Budgetwiederherstellung geben Sie bitte hier ein.
API-Verwendung	Wenn Sie die Private Aggregation API mit dem hier beschriebenen Trigger verwenden, wird für jede Auktion ein aggregierbarer Bericht erstellt. Welche Skalierungsfunktionen bietet der Aggregationsdienst?	Der Aggregations-Dienst selbst setzt keine Obergrenze für die Anzahl der Schlüssel oder Berichte in einem Batch. Eine Skalierung von 10 14 Berichten und 10 12 Schlüsseln wird jedoch aufgrund des erforderlichen Arbeitsspeichers derzeit nicht unterstützt. In unseren Größenrichtlinien finden Sie die von uns getesteten Bereiche, die wir für eine optimale Leistung bei der erwarteten Auslastung und den unterstützten Cloud-VM-Instanztypen empfehlen.
Datenverarbeitung	Wenn verschlüsselte Daten personenbezogene Daten enthalten, welche rechtlichen Regelungen gelten für die Bereitstellung verschlüsselter Daten für den Aggregationsdienst? Können Sie mir sagen, ob der Koordinator garantiert nicht auf verschlüsselte Daten zugreift?	Der Aggregationsdienst gibt keine verschlüsselten / Nutzerdaten an den Koordinator weiter. Der Aggregationsdienst verwendet den Koordinator für die Schlüsselverwaltung und ‑buchhaltung. Einige Details zum Koordinator finden Sie in diesem Artikel. Für die Abrechnung gibt der Aggregationsdienst nur die freigegebene ID und den Berichtsorigin mit dem PBS für die Budgetnutzung weiter. Sobald wir die Multi-Site-Funktion eingeführt haben, ersetzen wir „origin“ durch „site“. Der Aggregationsdienst wird in einem TEE ausgeführt, 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

Feedbackthema	Zusammenfassung	Chrome-Antwort
API-Verwendung	Möglichkeit für Komponentenverkäufer, Berichte an mehrere Aggregationsserver innerhalb einer TEE zu senden.	Diese Funktion wird vom aktuellen Status der Private Aggregation API nicht unterstützt. Weitere Informationen zu diesem Thema finden Sie hier.
Dokumentation	Welcher Epsilon-Wert wird in den Tests von Google verwendet?	Bei der Private Aggregation API entspricht der in einer Abfrage des Aggregationsdiensts angegebene Wert ε dem L1-Beitragsbudget von 2^16, das alle 10 Minuten fortlaufend erzwungen wird. Außerdem gibt es ein L1-Beitragsbudget von 2^20, das 24 Stunden lang angewendet wird. Der Datenschutzparameter ist also im Grunde ε auf einer rollierenden 10-Minuten-Basis und 16ε auf einer rollierenden 24-Stunden-Basis (anstelle von 144ε). Der Aggregationsdienst unterstützt derzeit eine Reihe von ε für Tests (bis zu 64), um mit verschiedenen Aggregationsstrategien zu experimentieren und Feedback zur Nützlichkeit des Systems mit verschiedenen Datenschutzparametern für die private Aggregation und andere APIs zu geben. Wir planen, den maximal zulässigen Epsilon-Wert im Laufe der Zeit noch einmal zu überprüfen, sobald wir Feedback von Testern erhalten und Funktionen hinzufügen, die eine effizientere Nutzung des Datenschutzbudgets ermöglichen.

Verdecktes Tracking einschränken

User-Agent-Reduzierung/User-Agent-Client-Hints

In diesem Quartal haben wir kein Feedback erhalten.

IP-Schutz (früher Gnatcatcher)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Resolution ID	Die Privacy Sandbox muss stärker darauf hinweisen, dass Auflösungs-IDs, die oft auf IP-Adressen basieren, für Werbetreibende nicht nachhaltig sind.	Mit der Privacy Sandbox möchten wir das websiteübergreifende Tracking reduzieren. Unsere öffentlichen Initiativen, die über Cookies hinausgehen, werden sowohl auf privacysandbox.com als auch auf GitHub veröffentlicht. Wir bemühen uns, websiteübergreifendes Tracking einzuschränken, einschließlich Tracking auf Grundlage von IP-Adressen. Letztendlich liegt es jedoch an den einzelnen Websites, ob sie websiteübergreifendes Tracking proaktiv aktivieren. In einer Zeit, in der die Einhaltung von Vorschriften immer stärker kontrolliert wird, ist es für einzelne Unternehmen ratsam, sich über die Praktiken ihrer Dienstleister zu informieren.
Chromecast	Hat der IP-Schutz Auswirkungen auf Chromecast oder andere Chrome-Geräte?	Derzeit ist nicht geplant, den IP-Schutz auf Chromecast-Geräte anzuwenden.
Liste für den IP-Schutz	Wird die Liste der Drittanbieter veröffentlicht, die möglicherweise IP-Adressen für websiteübergreifendes Tracking verwenden?	Die Liste wird veröffentlicht, sobald sie fertig ist, wie hier beschrieben.

Eindämmung von Bounce-Tracking

Feedbackthema	Zusammenfassung	Chrome-Antwort
Ausnahme für die Einmalanmeldung (SSO)	Wie werden mit BTM (Bounce Tracking Mitigation) SSO-Anwendungsfälle auf Befreiung geprüft?	BTM wird durch Chrome-Heuristiken deaktiviert. Weitere Informationen
Test zur Einstellung	Ist BTM für Websites im Testzeitraum der Einstellung von Drittanbieter-Cookies aktiviert?	Nein. BTM berücksichtigt die Cookie-Ausnahmen, die im Rahmen des Tests zur Einstellung von Drittanbieter-Cookies erstellt wurden, wie hier beschrieben.

Datenschutzbudget

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

Websiteübergreifende Datenschutzgrenzen stärken

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

Feedbackthema	Zusammenfassung	Chrome-Antwort
Feature Request (Funktionsanfrage)	Der Zugriff auf CHIPs und / oder Speicherpartitionen ist über die RWS automatisch zulässig, ohne dass die Storage Access API oder eine Nutzerinteraktion erforderlich ist.	Wir prüfen die Vorteile und Machbarkeit einer Funktion, die diese Aufgabe übernehmen könnte. Ein Aspekt ist eine potenzielle Lücke bei der plattformübergreifenden Interoperabilität, die RWS durch Nutzung der Storage Access API behebt. Es gibt derzeit kein Äquivalent zu dieser angeforderten Funktion, das in anderen Browsern unterstützt wird. Wir möchten Entwickler dazu ermutigen, ihre Anwendungsfälle zu diesem Thema hier einzureichen, um die Diskussion zu erleichtern.
Entfernung nicht konformer Sets	Wie werden Sets, die nicht mehr konform sind, aus dem Repository entfernt?	Wir arbeiten an einem entsprechenden Verfahren und halten dich auf dem Laufenden.
Durchsetzungsprozess	Die Rolle von Google bei der Durchsetzung der Richtlinien für Rezensionen ist nicht klar.	Da RWS ein laufendes Projekt ist und wir ständig neue Einreichungen erhalten, werden Aspekte des Prozesses und unsere Kriterien noch weiter konkretisiert. Wir sind uns einig, dass unsere Einreichungsrichtlinien unsere Anforderungen an die Einreichung vollständig beschreiben sollten. Wir werden unsere Einreichungsrichtlinien in Zukunft detaillierter formulieren, um weitere Unklarheiten und Verwirrung zu vermeiden. Wir möchten, dass der Einreichungsprozess so technisch wie möglich ist, damit wir die menschliche Beteiligung nach und nach einschränken und vollständig auf automatisierte Prüfungen umstellen können. Anfragen wie diese erfordern mehr menschliche Interaktion, da sie Verhaltensweisen umfassen, die wir nicht vorhergesehen haben. Sie ermöglichen es uns jedoch, weitere Bereiche für die Automatisierung zu identifizieren und unsere Richtlinien so zu formulieren, dass diese Probleme in Zukunft vermieden werden.
Daten hochladen	Es wird eine Funktion angefordert, mit der Domaininhaber angeben können, dass ein Drittanbieter auch RWS-Daten mit Nutzereinwilligung teilen 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 Berechtigungsanfrage akzeptiert hat. Wir freuen uns über Feedback von Nutzern zu bestimmten Anwendungsfällen, die ihrer Meinung nach nicht möglich sind.
Andere Speichermethoden	Werden Informationen, die im lokalen Speicher oder Sitzungsspeicher gespeichert sind, auch als Drittanbieter-Cookies interpretiert?	Lokaler Speicher, Sitzungsspeicher und andere Formen von nicht-cookiebasiertem Speicher, die in Drittanbieterkontexten verwendet werden, werden in Chrome seit Version 115 partitioniert. Weitere Informationen finden Sie in diesem Blogpost.
Limit für verknüpfte Sets	Was passiert mit Organisationen, die mehr als fünf Domains einreichen, obwohl die Anzahl auf fünf verknüpfte Websites begrenzt ist?	Diese Sets werden über den GitHub-Prozess akzeptiert, aber der Browser (Chrome) wendet die automatischen Genehmigungsregeln der Storage Access API nur auf die ersten 5 Domains an und ignoriert die restlichen Domains, wie hier beschrieben.
find_robots_txt	Die Prüfung „find_robots_txt“ funktioniert nicht bei Weiterleitungen.	Eine Lösung für dieses Problem finden Sie hier.
Nutzergeste	Die Anforderung für Nutzergesten für accessStorage() entfernen	Diese Anforderung basiert auf einem ähnlichen Design, das in allen gängigen Browsern für die requestStorageAccess API verwendet wird. Wir freuen uns über zusätzliches Feedback und Anwendungsfälle in diesem GitHub-Problem, damit wir diese Anfrage priorisieren und browserübergreifende Diskussionen ermöglichen können.
Nutzergeste	Ist eine Nutzergeste erforderlich, um nach einem Neustart von Chrome oder des Betriebssystems die Berechtigung für den Speicherzugriff von Drittanbietern zu gewähren?	Ja, aber wir freuen uns über zusätzliches Feedback aus der Community dazu, ob dieses Verhalten geändert werden sollte. Hier können Sie uns Ihr Feedback senden.

Fenced Frames API

Feedbackthema	Zusammenfassung	Chrome-Antwort
adComponent	Fehlende Dokumentation und Flexibilität bei der Verwendung von AdComponents mit eingegrenzten Frames	Wir arbeiten daran, weitere Informationen zu diesem Anwendungsfall zu veröffentlichen. Außerdem werden Anzeigenkomponenten in abgegrenzten Frames mithilfe von getNestedConfigs() unterstützt. Diese Funktion ist in der Spezifikation hier dokumentiert.
(wurde auch in früheren Quartalen erfasst) Render adComponent	Beispielcodes zum Rendern von Anzeigenkomponenten in einem abgegrenzten Frame anfordern	Wir arbeiten daran, einige Beispielcodes hier zu veröffentlichen.
Anzeigenüberprüfung durch Drittanbieter	Die Rolle der Anzeigenüberprüfung durch Drittanbieter im Zusammenhang mit abgegrenzten Frames muss genauer beschrieben werden, insbesondere im Hinblick auf die kontextbezogene/Markensicherheit.	Mit der Berichterstellung für eingeblendete Anzeigen können DSPs derzeit Daten zu Impressionen und Auktionen auf Ereignisebene an Drittanbieter-Anzeigenprüfdienste senden, um die Markensicherheit nach dem Rendern zu prüfen und die Abrechnung durchzuführen.
Erweiterbare Anzeigen	Unterstützung für erweiterbare Anzeigen anfordern	Wenn die Anzeige zwischen zwei Größen mit demselben Seitenverhältnis wechseln muss und es zwischen den beiden Größen keine funktionalen Unterschiede gibt (nur Größe), kann der Einbettungscode-Nutzer die Größe des abgegrenzten Frames an die zweite Anzeigengröße anpassen. Der Browser skaliert das abgegrenzte Frame-Element entsprechend.
(wurde auch in früheren Quartalen gemeldet) Unterstützung für Video- und natives Inventar	Unterstützt Fenced Frames Video- und natives Inventar?	Unsere Antwort ähnelt der aus den vorherigen Quartalen: 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 Rendern von Video- und nativen Anzeigen entwickelt, die mit abgegrenzten Frames kompatibel ist. Dies ist einer der Gründe, warum wir die Durchsetzung von abgegrenzten Frames auf 2026 verschoben haben. Wenn ein Partner also jetzt die Funktion „Umzäunte Frames“ erzwingt, fehlt ihm die Unterstützung für Video- und native Anzeigen.
Beratungsgremium	Er fordert die Einrichtung eines Beratungsgremiums von Anbietern von nativen Anzeigen an, um sicherzustellen, dass Fenced Frames-Implementierungen den Branchenstandards entsprechen.	Eingeschränkte Frames sind für die Verwendung in der PA API frühestens ab 2026 erforderlich. Durch die zusätzliche Zeit können wir weiterhin mit der Branche zusammenarbeiten, um Unterstützung für eine breitere Palette kritischer Anwendungsfälle zu entwickeln und zu implementieren. Wir haben bereits angekündigt, dass wir abgegrenzte Frames vor der Einführung der PA API weiterentwickeln werden, um die Unterstützung für Video- und native Anzeigen aufrechtzuerhalten. Gemäß unseren Verpflichtungen werden wir uns mit der CMA in Verbindung setzen und sie über solche Änderungen informieren. Außerdem werden wir uns weiterhin mit dem Feedback aus der Branche auseinandersetzen, bevor wir abgegrenzte Frames einfordern. Unser Engagement-Modell für das W3C-System und Werbestandardsorganisationen wie das IAB Tech Lab ermöglicht es Branchenexperten aller Art, die Designs zu leiten, bevor sie erforderlich sind.
(wurde auch in früheren Quartalen gemeldet) Größenunterschiede zwischen Plattformen	Es wird angegeben, dass die Größe der Inhalte, die im abgegrenzten Frame angezeigt werden, auf Computern und Smartphones unterschiedlich ist.	Dies ist ein bekanntes Chromium-Problem, das wir untersuchen. Hier können Sie uns zusätzliches Feedback geben.
API-Verbesserung	Wurde die Anforderung für abgegrenzte Frames auf 2025 verschoben, damit native Anzeigen jetzt in der Privacy Sandbox unterstützt werden?	Wie wir in unserer öffentlichen Mitteilung zur Durchsetzung von abgegrenzten Frames angekündigt haben, werden diese erst 2026 eingeführt. Wir haben jedoch von erheblichen Bemühungen zur Anpassung von abgegrenzten Frames erfahren. Sicherlich war Native Advertising einer davon, aber nicht der einzige Faktor. Ziel war es, mehr Zeit für die Vorbereitung des Werbesystems auf wichtige Anwendungsfälle zu haben, einschließlich, aber nicht beschränkt auf native Anzeigen.

Shared Storage API

Feedbackthema	Zusammenfassung	Chrome-Antwort
Leistung	Die Rückgabezeiten für freigegebenen Speicher außerhalb des Worklets hängen offenbar von Aktivitäten im Worklet ab.	Hier finden Sie weitere Informationen zu diesem Testergebnis.
Breitere Akzeptanz	Der gemeinsame Speicher sollte ein branchenweiter Standard sein, der plattformübergreifend verfügbar ist.	Wir nehmen dieses Feedback gerne entgegen. Das Chrome-Team nimmt weiterhin aktiv an W3C-Foren teil, einschließlich des WICG, um den Vorschlag zu unterstützen, Feedback einzuholen und die Akzeptanz zu fördern.
Bidding-Worklets	Ist es möglich, im Rahmen von „generateBid“, das bereits in einem Worklet ausgeführt wird, aus dem freigegebenen Speicher zu lesen, um Anzeigenentscheidungen / Geschäftslogik (z. B. Frequency Capping) basierend auf websiteübergreifenden Informationen anzuwenden und eine Teilmenge von Anzeigen auszuwählen?	Nein. In Gebots-Worklets kann nicht aus freigegebenem Speicher gelesen werden.

CHIPS

Feedbackthema	Zusammenfassung	Chrome-Antwort
Partitionskapazität	Verhalten bei Überschreitung der Partitionskapazität klarer formulieren	Wenn die Kapazität erreicht ist, werden die ältesten Cookies aus den Cookies entfernt, auf die am längsten nicht zugegriffen wurde, um Speicherplatz freizugeben, bis das Limit nicht mehr überschritten wird. Entwickler sehen den aktualisierten Cookie-Header in nachfolgenden Anfragen.
iFrame-Zugriff für Drittanbieter	Eingebettete iFrame-Inhalte von Drittanbietern, die einen neuen Tab/ein neues Fenster mit derselben Drittanbieterwebsite öffnen, sollten auf dieselben partitionierten Cookies wie der Öffner zugreifen können.	Wir diskutieren diesen Anwendungsfall und freuen uns über zusätzliches Feedback von der Community hier.
Doppelte Cookies	Wenn es ein partitioniertes und ein nicht partitioniertes Cookie mit demselben Namen gibt, welchen Schlüsselwert sendet der Browser?	Wenn Sie zwei Cookies mit demselben Namen haben (eines davon partitioniert), werden beide Cookies zurückgegeben. Leider gibt es keine Möglichkeit, sie zu unterscheiden. Die RFC-Spezifikation dazu finden Sie hier. Dort wird erklärt, dass die Reihenfolge, in der Cookies gesendet werden, nicht als verbindlich angesehen werden sollte.
Feature Request (Funktionsanfrage)	Aktivieren Sie partitionierte Cookies.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback von der Community. Hier können Sie es uns senden.

FedCM

In diesem Quartal haben wir kein Feedback erhalten.

Spam und Betrug bekämpfen

Private State Tokens API (und andere APIs)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Webansicht	Werden Private State Tokens (PSTs) in mehreren Webviews auf demselben Mobilgerät (Profil) beibehalten?	Jede App, die Webview verwendet, hat einen anderen lokalen Speicher. Das bedeutet, dass PST-Aussteller keine Tokens im Webview einer App ausstellen und dann später in einer separaten App die Tokeneinlösung zulassen können. Das gilt auch für andere Datenformen, die lokal in Webviews gespeichert werden, z. B. Cookies. PST-Dateien sind in WebView noch nicht vollständig verfügbar. Wir werden bis Ende des 2. Quartals ein Update dazu veröffentlichen.
Neuer Tokentyp	Vorschlag für einen neuen Tokentyp.	Wir sind für diesen Vorschlag und die fortlaufende Erforschung von Anwendungen und Anpassungen von PSTs dankbar und freuen uns darauf, in den kommenden Treffen der Anti-Fraud Community Group im 2. Quartal 2024 mehr über diesen Vorschlag zu erfahren.
Nutzeridentifikation	Wie kann ich verhindern, dass Nutzer anhand der PSTs identifiziert werden, die sie haben?	Dies wird derzeit dadurch verhindert, dass die Einlösung auf einer Website auf zwei Aussteller beschränkt ist, unabhängig davon, ob von diesem Aussteller Tokens verfügbar sind. Sie müssen einen Aussteller auf das Limit anrechnen, auch wenn keine Tokens verfügbar sind. Andernfalls könnte die Website alle Aussteller durchgehen, bis eine Übereinstimmung gefunden wird.
Anmeldung	Wie lange ist die Registrierung für PSTs erforderlich?	Eine Registrierung ist in absehbarer Zeit weiterhin erforderlich, wie hier näher erläutert.
Support für andere Chromium-Browser	Wird die PST-Ausstellerregistrierung für andere Chromium-basierte Browser über das Chrome Issuer Registration Repository unterstützt?	Chrome ruft die wichtigsten Verpflichtungen ab und verteilt sie über einen Mechanismus namens „Component Updater“ an Chrome-Clients. Wenn andere Browser die API vollständiger unterstützen, müssen sie einen Prozess einrichten, um die wichtigsten Zusagen für den Client einzuholen, entweder über eine Methode im Stil eines Komponenten-Updaters oder über eine andere Methode. Weitere Informationen finden Sie hier.