Diese Seite wurde von der Cloud Translation API übersetzt.

Feedbackbericht – 4. Quartal 2024

Quartalsbericht für das 4. 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 Google zugestimmt, 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, 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 gestellt wurden.

Insbesondere wurden die Protokolle der Sitzungen von Webstandards-Organisationen geprüft. Für direktes Feedback wurden die Aufzeichnungen von persönlichen Stakeholder-Treffen 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 der Festlegung einer Position speziell für diese öffentliche Berichterstattung entwickelt. Entsprechend dem aktuellen Schwerpunkt der Entwicklung und Tests wurden Fragen und Feedback vor allem zu Topics, der PA API und den APIs und Technologien für die Attribution Reporting erhalten.

Für kürzlich eingegangenes Feedback gibt es möglicherweise noch keine Antwort von Chrome.

Glossar mit Akronymen

ARA: Attribution Reporting API
CHIPS: Cookies mit unabhängigem partitionierten Status
DSP: Demand-Side-Plattform
FedCM: Federated Credential Management
IAB: Interactive Advertising Bureau
IDP: Identitätsanbieter
IETF: Internet Engineering Task Force
IP-Adresse: Internet Protocol-Adresse
openRTB: Echtzeitgebote
NSZ: Origin-Testversion
PA 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
UA: User-Agent-String
UA-CH: User-Agent-Client-Hints
W3C: World Wide Web Consortium
WIPB: Willful IP Blindness

Allgemeines Feedback, keine bestimmte API/Technologie

Feedbackthema	Zusammenfassung	Chrome-Antwort
Zusicherungen	Abschnitt G der Verpflichtungen ist für die Lebensfähigkeit der Privacy Sandbox unerlässlich. Ohne Garantie dafür, dass das Werbegeschäft von Google ausschließlich auf Sandbox-Technologien basiert, steigt das Risiko, dass die Nützlichkeit der Technologie immer weiter abnimmt und Google die Technologie möglicherweise verkauft. Eine solche Veräußerung oder Einschränkung der Nutzung wäre eine existenzielle Bedrohung für die datenschutzfreundliche Adressierbarkeit im offenen Web.	Die Zusagen stellen keine Garantie dafür dar, dass das Werbegeschäft von Google ausschließlich auf Privacy Sandbox-Technologien basiert. Google beabsichtigt, einen Portfolioansatz für die Adressierbarkeit zu verwenden, der die Privacy Sandbox-Technologien umfasst, genau wie Drittanbieter sie verwenden können und tun. Uns ist bewusst, dass ein Portfolioansatz in der Anzeigenbranche üblich ist. Wir sind der Meinung, dass es für Entwickler weiterhin wichtig ist, datenschutzfreundliche Tools und Technologien zu haben. Wir werden die Privacy Sandbox-APIs weiterhin verfügbar machen und in sie investieren, um Datenschutz und Nützlichkeit weiter zu verbessern.
Governance	Das vorgeschlagene Governance-Modell enthält keine spezifischen Mechanismen für die Rechenschaftspflicht bei formellen Konsultationen oder Einspruchsverfahren.	Das ist nicht richtig. Sowohl (i) das Entscheidungssystem und die zugehörigen Publikationen als auch (ii) das Einspruchsverfahren bieten spezifische Mechanismen für Rechenschaft. Außerdem überwacht der Treuhänder für die Überwachung die Funktionsweise im Detail.
Governance	Feedback, dass das Modell keine Bestimmungen für die Erstellung und Pflege eines plattformübergreifenden Standards enthält.	Kein Governance-Modell kann andere Akteure, in diesem Fall Browser, dazu zwingen, einen Standard zu übernehmen. Daher haben wir kein Modell vorgeschlagen, das die plattformübergreifende Einführung von Standards erfordert. Google wird weiterhin an Standardsforen teilnehmen, in denen Vorschläge gemacht und Erfahrungen mit der Implementierung von Vorschlägen ausgetauscht werden.
Governance	Wir empfehlen, die Beratungszeit auf mindestens zwei Monate auszuweiten. Das vorgeschlagene Governance-Modell bietet dem Ökosystem nicht genügend Zeit, um die Auswirkungen der vorgeschlagenen Änderungen zu analysieren.	Die dreiwöchige Frist ist nicht die gesamte Feedbackphase für eine bestimmte Änderung, da bestehende Feedbackzyklen (die viel länger sind) fortgesetzt werden. Der Konsultationsprozess bietet stattdessen ein neues, formelles Feedbackfenster im Rahmen des bestehenden Prozesses für strategische Entscheidungen. Drittanbieter können während der Entwicklung von Funktionen weiterhin über verschiedene Foren (z. B. GitHub, W3C und Werbestandardsorganisationen wie das IAB Tech Lab) Feedback geben. Durch diese Strukturierung der Feedbackzyklen erhalten die Stakeholder die Möglichkeit, eine vorgeschlagene Änderung zu analysieren und ihre Meinung dazu zu äußern, ohne den Entwicklungsablauf wesentlich zu verzögern.
Governance	Details zu zukünftigen Governance-Plänen anfordern	Eine Zusammenfassung des vorgeschlagenen Governance-Modells finden Sie im Bericht des CMA für das 2. und 3. Quartal 2024 auf den Seiten 3 bis 5 hier.
Ausnahmeantrag	Sie können eine Ausnahme für den Zugriff auf Drittanbieter-Cookies für Nutzer beantragen, die ihre Einwilligung erteilt haben.	Die Einwilligung in den Gerätezugriff und die Speicherung zu bestimmten Zwecken der Datenverarbeitung bedeutet nicht, dass ein Nutzer seine Einstellung für Drittanbieter-Cookies in Chrome überschreiben möchte. Wenn die 3PC-Einstellungen eines Nutzers auf Websiteebene überschrieben werden könnten, wäre das Missbrauchspotenzial erheblich. Außerdem wäre es für Chrome nicht möglich, das Verhalten aller Websites zu prüfen, die zu einer Ausnahmeanfrage führen könnten.
Privacy Sandbox	Informationen zu den Aktivierungsraten der Privacy Sandbox API anfordern	Wir haben nicht vor, diese Informationen an das System weiterzugeben. Entwickler können die APIs, in denen sie Code bereitgestellt haben, bereits jetzt aufrufen, um die Verfügbarkeit der Privacy Sandbox APIs zu schätzen.
Ursprungstest	Ist geplant, den Ursprungstest zu verlängern?	Der Ursprungstest wurde bis zum 14. April 2025 verlängert.
Privacy Sandbox	Fordern Sie eine prägnante, nicht technische Erklärung der Privacy Sandbox an, die ihren Geschäftswert hervorhebt und die Zustimmung der Führungsebene sichert.	Wir haben vor Kurzem den Abschnitt „Ressourcen für Unternehmen“ auf privacysandbox.com hinzugefügt, in dem diese Informationen zu finden sind.
Modus B	Bleibt der aktuelle Cookie-Jar (1PC, 3PC, lokaler Speicher) erhalten oder wird er gelöscht, wenn sich ein Browser im Modus B befindet?	Der aktuelle Cookie-Jar wird nicht gelöscht. Drittanbieter-Cookies bleiben im Kontext von selbst erhobenen Daten verfügbar.
Aktualisierter Ansatz für 3PCs in Chrome	Werden 3PCs in Zukunft vollständig aus Chrome entfernt?	Wir schlagen einen aktualisierten Ansatz vor, der Nutzern mehr Auswahlmöglichkeiten bietet. Wie hier beschrieben, werden Drittanbieter-Cookies in Chrome nicht eingestellt. Stattdessen wird eine neue Funktion eingeführt, mit der Nutzer eine fundierte Entscheidung treffen können, die für ihr gesamtes Websurfen gilt. Diese Entscheidung kann jederzeit angepasst werden. Wir besprechen diesen neuen Ansatz mit den Regulierungsbehörden und werden vor der Einführung mit der Branche zusammenarbeiten.
Chrome-Tests	Bitte um weitere Verfügbarkeit von Labels für von Chrome unterstützte Tests.	Das Privacy Sandbox-Team weiß, dass Unternehmen die Labels zur Einstellung von Cookies weiterhin verwenden möchten. Die Verlängerung der Verfügbarkeit der Labels ähnelt der Verlängerung eines Testzeitraums für einen Ursprung. Dabei kann der Test jeweils nur um drei Chrome-Meilensteine verlängert werden. Beispielsweise wurde der aktuelle Chrome-Test zur beabsichtigten Verlängerung (Intent to Extend, I2EE) für Labels zur Einstellung von Cookies auf Chrome M130 bis M132 ausgeweitet. Dadurch wird die Unterstützung der Labels bis zur stabilen Version M133 Anfang Februar ermöglicht. Für weitere Erweiterungen wird derselbe Prozess verwendet. Wir empfehlen Ihnen, sich in der E-Mail-Gruppe blink-dev über Neuigkeiten zu informieren.

Registrierung und Attestierung

In diesem Quartal haben wir kein Feedback erhalten.

Relevante Inhalte und Werbung anzeigen

Themen

Feedbackthema	Zusammenfassung	Chrome-Antwort
Spezifikationen	Wird das Klassifizierungsmodell zwischen Android (nach App-Namen) und Chrome (nach Hostnamen) geteilt?	Nein, es sind separate Modelle, da sie unterschiedliche Taxonomien haben.
Granularität der Themen-Taxonomie	Themen sind zu allgemein, um in Kombination mit selbst erhobenen Daten nützlich zu sein.	Mit der Topics-Taxonomie soll ein Gleichgewicht zwischen Nützlichkeit und Datenschutz geschaffen werden. Wir haben zwar mögliche Mechanismen geprüft, um Themen spezifischer zu machen, haben uns aber letztendlich unter anderem aus Sicherheits- und Datenschutzgründen dagegen entschieden. Mit AdTech-Lösungen lassen sich die besten Ergebnisse erzielen, 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
API-Verwendung	Die Abdeckung der Topics API ist gering.	Typische Gründe für eine geringe Abdeckung: – Nutzereinstellungen/Deaktivierung – Einstellungen/Deaktivierung des Publishers – Eignung der Website (die folgenden Websites sind nicht für die Zuordnung zu Themen zulässig: unsichere Websites, WebView, Chrome auf iOS und Inkognitomodus) – Nutzereinschränkungen (Chrome-Nutzer unter 18 Jahren oder Nutzer im Inkognitomodus können nicht beobachtet und keine Themen zugewiesen werden) – Beobachtungsanforderungen für Verkäufer (der Anrufer muss den Nutzer zuvor auf einer Website gesehen haben, die mit einem geeigneten Thema verknüpft ist) – Zeitpunkt der Implementierung (es dauert etwa vier Wochen, bis die Beobachtung von Anrufern skaliert wird)
API-Verwendung	Anfrage zu Informationen zur Verwendung der Topics API, da auf dem Tab „Netzwerk“ ein gesendeter und aufgefangener Aufruf angezeigt wird, unter chrome://topics-internals/ jedoch kein Beobachter erfasst wird.	Wenn Sie den HTTP-Headermechanismus verwenden, um mit der Topics API zu interagieren, werden die Themen im Anfrageheader „Sec-Browsing-Topics“ gesendet. Sie werden jedoch nur berücksichtigt, wenn der Server mit dem Antwortheader „Observe-Browsing-Topics: ?1“ antwortet. Weitere Informationen finden Sie hier.
Chromium-Beteiligung	Teilen Chrome und andere Chromium-basierte Browser auf dem Computer denselben Beobachtungs- und Ranking-Kontext? Werden auf Mobilgeräten dieselben Beobachtungen und Rangfolgen für Android Chrome und andere Android-Browser verwendet, die auf Chromium bzw. In-App Chromium basieren?	Chrome gibt Topics-Daten nicht an andere Browser auf dem Gerät weiter.
Spezifikationen	Wie entscheidet die Topics API, ob ein Seitenaufruf eines Nutzers als „Eintrag im Themenverlauf“ betrachtet wird?	Damit ein Seitenaufruf für die Berechnung der wöchentlichen Themen infrage kommt, muss er einen „observe“-Aufruf enthalten (von einem beliebigen Aufrufer). Ohne „observe“-Aufruf wird der Besuch nicht für den Themenverlauf berücksichtigt.
Sicherheit	Wie verhindert die Topics API, dass ein Nutzer die Themen anderer Nutzer einsehen kann?	Hier finden Sie eine Erklärung.
Taxonomie	Wie wird die Taxonomie der Baumstruktur in der Topics API in der Beobachtung in jeder Epoche verwendet?	Bei der Berechnung der fünf wichtigsten Themen werden nur die vom Klassifikator bereitgestellten ursprünglichen Themen berücksichtigt. Die Rangfolge wird durch (i) die Häufigkeit der Seitenaufrufe und (ii) einen Priorisierungswert bestimmt (siehe Spezifikation). Bei der Berechnung der von den Nutzern beobachteten Top-5-Themen werden Nutzer berücksichtigt, die entweder das Hauptthema oder eines seiner untergeordneten Themen beobachtet haben.
Spezifikationen	Anfrage zu weiteren Informationen zu den 5% zufälligen Störungen in der Antwort.	Für jede Epoche werden immer fünf Top-Themen angezeigt. Wenn der Browserverlauf nicht fünf Themen enthält, werden Themen zufällig ausgewählt, bis fünf vorhanden sind. Wir nennen diese Themen „aufgebläht“. Aufrufer erhalten nur dann eines dieser zufällig hinzugefügten Themen, wenn sie den Nutzer in den letzten Wochen auf einer Website mit dem Thema beobachtet (d. h. die API auf ihm aufgerufen) haben. Beim Aufruf der API wird ein Hashwert pro Nutzer, pro Website und pro Epoche berechnet. Wenn dieser Hash kleiner als die Wahrscheinlichkeit ist, ein gestörtes Thema zurückzugeben, wird das zufällige Thema pro Nutzer, pro Website und pro Epoche zurückgegeben. Das gefilterte Thema wird jedoch nur zurückgegeben (d.h. nicht gefiltert), wenn der Aufrufer das entsprechende nicht gefilterte Thema für diesen Nutzer, diese Website oder diese Epoche beobachtet hat (siehe Erläuterung). Durch diese Filterung werden für den angegebenen Anrufer 5% der Zeit Themen zurückgegeben, die als unwichtig eingestuft wurden, unabhängig von der Beobachtungsfähigkeit.
Spezifikationen	Wie funktionieren Themen, die sich über mehrere Wochen erstrecken? Wählt die API unabhängig Wochen aus und führt sie dann zusammen?	Die Themen der einzelnen Wochen (Epochen) werden unabhängig voneinander berechnet. Welches Thema aus jeder Epoche zurückgegeben wird, hängt von der Website ab, auf der sich der Aufrufer befindet. Wir berücksichtigen nicht, dass das Thema für einen bestimmten Anrufer in verschiedenen Epochen wiederholt werden kann (und sollten daher ein anderes Thema auswählen). Wir freuen uns aber über zusätzliches Feedback zu diesem Problem hier.

Protected Audience API

Feedbackthema	Zusammenfassung	Chrome-Antwort
A/B Testing	Die hier beschriebene Lösung für freigegebenen Speicher führt zu einer erhöhten Latenz und einer hohen Fehlerrate. Das bedeutet, dass ein erheblicher Teil des Traffics ohne Populations-ID endet. Eine ID mit niedriger Entropie (z.B. 3 Bit) für effektive A/B-Tests ohne erhebliche Auswirkungen auf den Datenschutz ausreichen.	Wir sind der Meinung, dass die Lösung für freigegebenen Speicherplatz weiterhin ein gangbarer Ansatz ist. Wir prüfen diese Anfrage jedoch und freuen uns über zusätzliches Feedback aus der Community, wenn diese Funktion für Sie eine hohe Priorität hat.
Berichte	Anfordern zusätzlicher Bits in `reportWin()`, insbesondere da die neuen Klick- und Anzeigenberichte in der PA API 6–8 Bits verbrauchen, was die verbleibenden Bits für andere PA API-Berichte effektiv reduziert.	Aus Datenschutzgründen werden wir die Anzahl der Bits für „modelingSignals“ nicht mehr über die aktuellen 12 Bits hinaus erhöhen. Wir laden die Community ein, Feedback zu unserem Vorschlag für das private Modelltraining zu geben. Dieser soll die Anforderungen an das ML-Training in einer sicheren Umgebung ohne die durch die Privacy Sandbox auferlegte Bitbeschränkung unterstützen.
Interessengruppen	Wir fordern 90-tägige Lebenszyklen für Interessengruppen an, da 30 Tage nicht ausreichen.	Wie wir in unserem Blogpost erwähnt haben, möchten wir die Lebensdauer von Instagram-Inhalten auf 90 Tage verlängern. Hier finden Sie weitere Informationen. Wir arbeiten derzeit an der Implementierung und teilen einen Zeitplan für die Einführung mit, sobald er verfügbar ist.
Interessengruppen	Dynamische Aktualisierungen für die IG-Delegierung anfordern	Uns ist diese Anfrage von mehreren Stakeholdern bekannt und wir arbeiten an einer Lösung. Wir werden Sie auf GitHub über die neuesten Entwicklungen informieren und freuen uns über zusätzliches Feedback.
On-Device	Mehr Wert für das Ökosystem schaffen, um weiterhin in On-Device-PA API-Lösungen zu investieren.	Das Privacy Sandbox-Team arbeitet weiter an der Entwicklung von APIs, die auf Privacy-Enhancing Technology (PET) basieren, einschließlich der PA API, um Entwicklern mehr datenschutzfreundliche Optionen im Browser zu bieten. Diese Technologien sind jetzt in großem Umfang in allen Chrome-Browsern verfügbar (nicht nur bei 1 %, wie einige Entwickler fälschlicherweise angenommen haben). Unabhängig davon, ob Nutzer 3PCs aktivieren, können Entwickler PET-basierte Lösungen in ihre Produkte einbinden. Viele Unternehmen entscheiden sich auch für andere PET-basierte Lösungen außerhalb des Browsers. Viele Entwickler profitieren bereits von Investitionen in On-Device-PA API-Lösungen, da sie ihr deterministisches Signal für Zielgruppen mit selbst erhobenen Daten erweitern und so die Reichweite über Websites hinweg verbessern können. Uns ist bewusst, dass einige Entwickler die Privacy Sandbox APIs oder andere datenschutzorientierte Lösungen nur dann verwenden werden, wenn mehr Drittanbieter-Cookies deaktiviert werden. Diese Entwickler warten auf Informationen, anhand derer sie abschätzen können, in wie vielen Browsern Drittanbieter-Cookies weiterhin verwendet werden. Wir wissen, dass diese Entwickler warten werden, bis sie die gewünschten Informationen gefunden haben, um Produktentscheidungen zu treffen.
Interessengruppen	SSPs dürfen an der Erstellung von Anzeigen-Inventar und den zugehörigen Rollen beteiligt sein. Für SSPs ist dies ein wichtiger Teil ihres Mehrwerts und sie möchten Publishern dabei helfen, IGs über ihre SSPs zu verkaufen.	Wir haben von mehreren Stakeholdern die Anfrage erhalten, erweiterte IG-Delegierungen zu unterstützen. Wir sehen den Mehrwert von SSPs bei diesem Prozess. Wir suchen nach der besten Lösung, mit der verschiedene Parteien am Prozess der Zielgruppenerweiterung teilnehmen können. Wir werden Sie auf GitHub über die Entwicklung auf dem Laufenden halten und freuen uns über zusätzliches Feedback aus der Community.
Berichte	Abweichungen bei der Anzahl der Berichte zu Geboten mit einem Wert ungleich 0 zwischen der forDebuggingOnly API und der Private Aggregation API.	Wir gehen davon aus, dass eine Abweichung aus zwei Gründen vorliegt: Erstens ist der Debug-Modus der Private Aggregation API nur verfügbar, wenn auf dem Gerät 3 PCs zulässig sind, während die forDebuggingOnly API immer ohne Stichprobenerhebung verfügbar ist. Dieses Verhalten wird sich jedoch wie hier beschrieben ändern. Zweitens: Für die Private Aggregation API gelten Beitragslimits, für „forDebuggingOnly“ hingegen nicht. Dieses Feedback weist jedoch darauf hin, dass es möglicherweise noch andere Ursachen für die unerwartete Abweichung gibt. Wir arbeiten mit einem Drittanbieter zusammen, um dieses Problem zu beheben.
Klickfreundlichkeit	Wie im aktualisierten Vorschlag für das Klicksignal erwähnt, werden Aufrufe und Klicks registriert, indem für Anfragen, die vom Attribut „attributionsrc“ infrage kommen, ein neuer HTTP-Antwortheader zurückgegeben wird. Dieser Antwortheader enthält eine Liste von Ursprüngen, mit denen angegeben werden kann, welche anderen Parteien diese Aufrufe und Klicks in ihre zusammengefassten Zählungen aufnehmen können. Heißt das, dass die Anzeigentechnologie die Ursprünge willkürlich festlegen kann?	In der Erläuterung zur Klickfreudigkeit wird angegeben, dass eine Anzeigentechnologie, die zur aggregierten Aufruf- und Klickzahl ein Aufruf- oder Klickereignis beiträgt (eine „abgebende Quelle“), einen optionalen Parameter in der Antwortheader enthalten kann, mit dem „eine oder mehrere IG-Inhaberquellen angegeben werden können, für die dieses Ereignis in die berechneten Aufruf- und Klickzahlen aufgenommen werden kann, die für ihre `generateBid()`-Aufrufe in Protected Audience-Auktionen bereitgestellt werden“ („berechtigte Quellen“). Diese Aufrufe und Klicks werden jedoch nicht automatisch in die Aufruf- und Klickzahlen einbezogen. Stattdessen muss jede Anzeigentechnologie in ihren Richtlinien die „Anbieterquellen“ angeben, aus denen Aufruf- und Klickereignisse eingeschlossen werden sollen. Nur Daten aus diesen Anbieterquellen tragen zur Aufruf- und Klickanzahl bei, die den `generateBid()`-Aufrufen dieser Anzeigentechnologie präsentiert werden. Für diesen Mechanismus ist eine Vereinbarung auf beiden Seiten erforderlich. So wird verhindert, dass böswillige Akteure die Aufruf- und Klickzahlen anderer AdTech-Anbieter beeinflussen. Das bedeutet auch, dass eine Anzeigentechnologie, die „zulässige Quellen“ willkürlich festlegt, keine Auswirkungen auf die Anzahl der Aufrufe und Klicks dieser zulässigen Quellen hat, es sei denn, diese zulässigen Quellen schließen diese Quelle ausdrücklich und absichtlich in ihre IG ein.
Privates Modelltraining	In einigen Fällen würde DP-SGD (Differential Privacy – Stochastic Gradient Descent) den Trainingsprozess erheblich verlangsamen, da die Sparsamkeit der Gradienten, die während der Backpropagation berechnet werden, zerstört wird. Gibt es Methoden, die Sie in Betracht ziehen, um dieses Problem zu lösen, oder haben Sie Ideen dazu?	Uns sind einige Verfahren zur Wahrung der Sparsamkeit bei DP-SGD bekannt (z. B. dieses). Wir prüfen derzeit, ob diese Verfahren in der Infrastruktur für die private Modellerstellung unterstützt werden können. Wir halten Sie auf dem Laufenden und freuen uns über zusätzliches Feedback hier.
Ausschließendes Targeting	Informationen zur Einführung der hier beschriebenen Funktion zum Filtern negativer Inhalte auf Instagram	Wie in unserer Antwort hier erläutert, planen wir, negative Targeting-Optionen in Geboten für die PA API zu unterstützen. Wir teilen den Zeitplan für die Einführung mit, sobald er feststeht. Hier können Sie uns zusätzliches Feedback geben.
Gebote	Ist es möglich, beim Bidding mehrere Anzeigengruppen zu kombinieren?	Das ist derzeit mit der PA API nicht möglich. Die PA API basiert auf dem Design, dass sich die Identitätsbestätigung auf Informationen bezieht, die eine einzelne Website über den Nutzer hat. Dies war ein zentrales Thema in den Diskussionen mit dem gesamten System. Mit diesem Ansatz können Anbieter von Anzeigentechnologien eine Vielzahl von Lösungen entwickeln, mit denen Werbetreibende ihre selbst erhobenen Zielgruppen im Web erweitern können. Uns ist bewusst, dass der Vorschlag für die Ads Selection API von Microsoft ein anderes Design vorsieht, bei dem Zielgruppen auf Websiteinformationen basieren. Wir werden den Ansatz von Apple weiter beobachten. Wir würden uns aber mehr Diskussionen aus der Branche, einschließlich der Datenschutzcommunity, wünschen, bevor wir ähnliche Änderungen an Chrome in Betracht ziehen.
Native Anzeigen	Bedenken, ob die PA API die vielfältigen Formate und Renderinganforderungen von nativen Anzeigen ausreichend unterstützen kann und ob die PA API die für effektive native Anzeigen erforderliche Creative-Flexibilität und -Optimierung ermöglicht.	Wir arbeiten aktiv daran, native Anzeigen weiter zu unterstützen, und freuen uns über zusätzliches Feedback aus der Community.
Berichte	Verbesserung der Robustheit von Berichtsscripts, die mit Gebotsscripts um Ressourcen konkurrieren und verloren gehen können, wenn der laufende Auktionsframe verlassen wird.	Wir hoffen, bald eine Antwort auf GitHub zu posten. Wir gehen jedoch davon aus, dass diese Bedenken sich in der Praxis nicht wesentlich auf gültige Meldungen auswirken werden.
Makroersetzung	In der Auktionskonfiguration übergebene Makroersetzungen funktionieren mit einigen Drittanbieterkonfigurationen nicht.	Die Ursache war, dass diese Funktion nicht für alle Zugriffe mit dem Label „A/B-Modus“ aktiviert war. Vor Kurzem haben wir beschlossen, diese und andere Funktionen in derselben Situation für alle Zugriffe mit dem Label „A/B-Modus“ zu aktivieren. Wir gehen davon aus, dass diese Änderung im 1. Quartal 2025 erfolgt. Du kannst uns gern hier zusätzliches Feedback geben.
Dokumentation	Ich benötige eine Klarstellung, da es in der Dokumentation offenbar eine Abweichung bei der Maßeinheit für den Wert „Recency“ im Objekt „browserSignals“ in `generateBid()` gibt.	Hier haben wir dazu weitere Informationen veröffentlicht und unsere Dokumentation entsprechend aktualisiert. Die richtige Antwort ist „Millisekunden“.
Berichte	Anfordern von Drittanbieterberichten: Während DSPs und SSPs Impressionsbenachrichtigungen von Chrome erhalten, ist das bei technischen Anbietern der mittleren Schicht standardmäßig nicht der Fall.	Wir diskutieren diese Funktionsanfrage derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.
Interessengruppen	Anforderung einer Anleitung zum dynamischen Ausschließen von „interestGroupBuyers“ bei parallelen IG-Auktionsabläufen.	Hier finden Sie eine entsprechende Anleitung.
Native Anzeigen	Durch unabhängige PA API-Auktionen für ein bestimmtes Seitenladevorgang wird das Filtern von Anzeigen auf derselben Seite verhindert.	Wir arbeiten daran, native Anzeigen weiter zu unterstützen, einschließlich Empfehlungs-Widgets, die als „native“ bezeichnet werden und mehrere Anzeigen in einem Anzeigenblock enthalten. Wir sind uns bewusst, dass das aktuelle Design möglicherweise nicht das Filtern von Anzeigen auf derselben Seite unterstützt. Auch andere Schutzmaßnahmen wie abgegrenzte Frames können dies verhindern.
Native Anzeigen	Vorhandene PA API-Funktionen wie Creative-Scans und Berichte, die auf URL-basierten Signalen basieren, müssen möglicherweise angepasst werden, um JSON-Objekte zu verarbeiten, die in nativen Creatives verwendet werden.	Wir arbeiten derzeit an der Unterstützung weiterer nativer Anzeigen und prüfen, ob die PA API angepasst werden kann, um das Rendern nativer Anzeigen zu unterstützen.
Anzeigenüberprüfung	Die Markensicherheit von Drittanbietern in der PA API ist aufgrund von Latenz- und Caching-Einschränkungen von perBuyerSignals beeinträchtigt, was für dynamische Inhalte problematisch ist.	Wir sind uns bewusst, dass SSPs und DSPs eine optimale TTL für das Caching festlegen müssen, die die Ziele der Traffic-Optimierung und die maximalen TTLs für die Markensicherheit in Einklang bringt, damit die im Cache gespeicherten Daten für die Markensicherheit relevant bleiben. Wir untersuchen das Problem und halten dich auf dem Laufenden.
Anzeigenüberprüfung	Der Ersatz des FullpageURL-Makros durch SSPs ist erforderlich, um die Markensicherheit nach dem Gebotsabgabeprozess zu messen.	deprecatedReplaceInURN ist der aktuelle Vorschlag für SSPs, dieses Signal bereitzustellen.
Anzeigenüberprüfung	Die mangelnde Standardisierung von Makroformaten, die von SSPs für die Überprüfung nach der Gebotsabgabe verwendet werden, kann zu Inkonsistenzen und Fehlern bei der Datenverarbeitung und -analyse führen.	Sell-Side-Plattformen und Ad Verifier sollten direkt zusammenarbeiten, um klare Richtlinien und Spezifikationen für die Verwendung von Makros zu definieren. So soll die Standardisierung von Makroformaten über Sell-Side-Plattformen hinweg vorangetrieben werden, um für Konsistenz zu sorgen und Fehler bei der Datenverarbeitung und -analyse zu vermeiden. Für diese Aufgabe sind Organisationen für Anzeigenstandards wie das IAB Tech Lab gut geeignet.
Anzeigenüberprüfung	Werbetreibende und Anzeigenprüfer benötigen einen Mechanismus, mit dem sie Vor- und Nachgebotsüberprüfungen für denselben Publisher-Kontext verknüpfen können, um Fehler zu beheben.	Eine Möglichkeit für die Überprüfung nach der Gebotsabgabe besteht in auktions- und kampagnenbasierten Signalen, die in Berichte auf Ereignisebene einfließen. Dies kann Zusammenführungen mit Protokollen zu Entscheidungen vor dem Gebotsabgabe ermöglichen. Wir prüfen derzeit mögliche Muster, um dies zu erreichen, und halten Sie auf dem Laufenden.
Anzeigenüberprüfung	Anfrage zur Prüfung von TKV-Serverlösungen (Trusted Key-Value, von DSPs und Ad Verifiers) für Pre-Bid-Angebote und zur Behebung von Einschränkungen bei eingezäunten Frames nach der Gebotsabgabe	Wir prüfen diese Anfrage und freuen uns über zusätzliches Feedback aus der Branche hier, um eine Lösung zu finden, die die Markensicherheit vor der Gebotsabgabe unterstützen und die Koordinierungsanforderungen zwischen den Parteien erleichtern könnte.
Native Anzeigen	Sie möchten eine Prüfung des Renderings nach dem Gebot auf der Sell-Side für native Anzeigen anfordern.	Wir arbeiten daran, native Anzeigen weiter zu unterstützen. Dabei prüfen wir auch, ob bestehende Funktionen wie diese angepasst werden können, um das Rendern nativer Anzeigen zu verbessern.

Geschützte Auktion (B&A-Dienste)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Latenz	Die Latenz konnte nicht ausreichend reduziert werden. B&A-Dienste können dieses Problem langfristig zwar abmildern, Google hat sich jedoch nicht dazu verpflichtet, diese Dienste vor Änderungen an 3PCs in Chrome weithin verfügbar zu machen.	In den letzten Quartalen haben wir die Latenz auf dem Gerät verbessert. Außerdem entwickeln und skalieren wir bei Bedarf B&A-Dienste. 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 ständig an neuen Latenzverbesserungen. Einige davon finden Sie hier.
(Auch in früheren Quartalen gemeldet) Auktionssicherheit	Bitte um weitere Erläuterungen zu Ansätzen zur Verhinderung oder Minimierung von Manipulationsversuchen bei der On-Device-Auktion (z.B. ob Google dies als erhebliches Risiko betrachtet).	Unsere Antwort hat sich seit den vorherigen Quartalen nicht geändert: „Die Berichtsmechanismen der PA API-Anzeigen behalten die Informationen bei, die derzeit verwendet werden, um zwischen Nutzer- 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.“
On-Premise-Lösungen	Bedenken, dass die größten Anbieter die Privacy Sandbox oder B&A aufgrund der fehlenden Unterstützung für die Private Cloud und der langen und undurchsichtigen Roadmap zur Unterstützung nicht einführen könnten.	Wir arbeiten daran, die Infrastrukturen zu erweitern, auf denen Privacy Sandbox-Dienste ausgeführt werden. Vor Kurzem haben wir die Unterstützung für die Azure-Cloud angekündigt und prüfen weiterhin mögliche Lösungen, um ähnliche Datenschutz- und Sicherheitsvorkehrungen für private Clouds bereitzustellen. Seit unserer Mitteilung im Oktober haben wir Fortschritte gemacht. Wir arbeiten weiter an potenziellen Ansätzen, um die Privatsphäre von Chrome-Nutzern in einer On-Premise-Trusted Execution Environment (TEE) zu schützen. Wir befinden uns jetzt in einer Phase unserer Forschung, in der wir verschiedene Ansätze mit Stakeholdern des Ökosystems validieren möchten. Wir planen, im 1. Quartal damit zu beginnen, Input zu sammeln. Feedback und Zusammenarbeit im Ökosystem helfen dabei, mögliche Lösungen zu optimieren.
Test	Ist es möglich, TEEs zum Testen von Lösungen für die PA API-Berichterstellung (Echtzeitberichte und Private Aggregation) zu erstellen?	Für Aggregationsdienste können Anbieter von Anzeigentechnologien Testdaten und Tools für lokale Tests verwenden, um Zusammenfassungsberichte für Funktionstests zu generieren. Das Codelab zum lokalen Testen finden Sie hier. Zum Testen der Aggregation in TEE müssen Anbieter von Anzeigentechnologien die Registrierung wie in den Codelab-Voraussetzungen oben beschrieben abschließen. Du kannst uns hier zusätzliches Feedback zu dieser Anfrage geben.
Deal-K/V-Integration	Möglichkeit anfordern, dealbasierte Informationen aus KV für Geschäftsanwendungsfälle abzurufen.	Wir prüfen diese Feature-Anfrage und werden auf GitHub ein Update dazu veröffentlichen.
Deal-Messwert für keinen Gewinn	Signal anfordern oder die Möglichkeit erhalten, zu erfahren, wann eine SSP nicht den Zuschlag erhalten hat und warum.	Wir prüfen diesen Antrag und informieren Sie auf GitHub über den aktuellen Stand.
Feature Request (Funktionsanfrage)	Für die Privacy Sandbox wird eine Dictionary-Struktur angefordert, mit der eine Gruppe von Anzeigen den entsprechenden Deal-IDs zugeordnet werden kann.	Wir prüfen diese Anfrage zusammen mit anderen Möglichkeiten, die Größe von Anzeigenaufträgen im Hinblick auf das Speichern von Deal-IDs zu reduzieren. Wir werden auf GitHub ein Update veröffentlichen.
Leistung	Lösungen zur Messung möglicher verpasster Chancen bei Anzeigenauktionen, die möglicherweise auf die Größe des Gebotsscripts zurückzuführen sind.	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback hier.
Spezifikationen	Derzeit liest B&A nur das Feld „prevWins“ anstelle des neuesten Felds „prevWinMs“, das „prevWins“ in der Spezifikation ersetzt hat.	Es ist richtig, dass B&A die Dauer in Millisekunden in „prevWins“ nicht an `generatebid()` übergibt. Chrome sendet die Dauer in Sekunden, um weniger Overhead bei der Nutzlast zu gewährleisten. Die Lösung besteht darin, dass B&A die Umwandlung von Sekunden in Millisekunden vornimmt. B&A stellt sowohl „prevWins“ als auch „prevWinsMs“ in „browserSignals“ bereit, um die Kompatibilität mit On-Device-Auktionen zu gewährleisten. Hinweis: Auch bei On-Device-Auktionen für das Web entsprechen „prevWins“ und „prevWinsMs“ demselben Wert und „prevWinsMs“ = „prevWins“ * 1.000. Wir arbeiten an einer Lösung.
Dokumentation	In der Dokumentation wird nicht klar beschrieben, wie das Seller Front End (SFE) getestet werden soll. Es wäre hilfreich, direkt nach Abschluss der Bereitstellung zusätzliche Informationen zum Testen sowie zur Verwendung von Bazel für Builds zu erhalten.	Dieses Codelab wurde als Leitfaden veröffentlicht, um es dem gesamten Ökosystem zu erleichtern, seine SFEs zu testen.
Bereitstellung	Sind vorkonfigurierte Binärdateien für B&A geplant?	Wir überlegen, vorgefertigte Binärdateien für B&A bereitzustellen. Wir haben jedoch noch keine konkreten Zeitpläne dafür. Bis dahin können Anbieter von Anzeigentechnologien die Binärdateien selbst erstellen und mit den bereitgestellten Hashes validieren.
Bereitstellung	Sollten alle Orchestrierungstypen (Server, Client, gemischt) unterstützt werden oder gibt es einen, der gegenüber den anderen priorisiert werden sollte?	Wir haben keine konkreten Empfehlungen dazu, welche Modi die Anzeigentechnologie implementiert. Die Wahl hängt von verschiedenen Faktoren ab, aber letztendlich davon, was im besten Interesse Ihrer Kunden ist.
Test	Ich benötige eine Klarstellung zu fehlgeschlagenen Tests während des B&A-Builds.	Dies kann auf einen fehlerhaften Test zurückzuführen sein. Wir haben dem Anbieter von Anzeigentechnologien empfohlen, das Flag `--no-tests` für alle `build_and_test_all_in_docker`-Build-Befehle zu verwenden, um das Ausführen der Tests zu überspringen.
Logs	Ich möchte wissen, warum die Protokolle im Log Explorer in der GCP im Testmodus der VM-Instanz getaggt sind, auf der die SFE ausgeführt wird, im Produktionsmodus jedoch nicht.	Es ist schwierig, eine allgemeine Aussage zu treffen, da es darauf ankommt, was genau zu sehen war. Generell gilt jedoch Folgendes: – Die Protokolle von „non_prod“ sind wahrscheinlich die stderr-Protokolle, die vom Cloud-Anbieter (in diesem Fall GCP) umgeleitet wurden und das Tag von GCP hinzugefügt wurde. – Von der VM erstellte Protokolle sind in der Regel mit der VM-Instanz getaggt, während Protokolle, die vom Binärprogramm erstellt werden, von GCP nicht getaggt werden. – Die Logs aus der Produktion werden von Open Telemetry in TEE exportiert und haben unterschiedliche Tags. Hier finden Sie einige Details zu den Inhalten unter „non_prod“ und „prod“.
B&A	403-Fehler bei fehlenden Secrets, wenn das OTEL-Logging deaktiviert ist	Dieses Problem wurde mit dem Update auf Version 4.1 behoben und die Dokumentation wurde entsprechend überarbeitet.
B&A	Fehlende outputs.tf-Datei für die GCP-Terraform-Konfiguration führt zu einem Fehler.	Dieser Fehler wurde jetzt behoben.
Test	Fehler beim Abrufen des privaten Schlüssels im Testmodus	Achten Sie in diesen Fällen darauf, dass die Server mit TEST_MODE=true ausgeführt werden. Weitere Informationen
Roadmap	Sind Pläne für getInterestGroupAdAuctionData geplant, um mehr als einen Verkäuferursprung zu akzeptieren und eine Zuordnung des Verkäuferursprungs zum B&A-Nutzlast-Chiffretext zurückzugeben?	Ja, wir planen, die Funktion navigator.getInterestGroupAdAuctionData() so zu erweitern, dass mehrere Verkäufer unterstützt werden.
KV-Spezifikationen	Kann die KV-URL (trustedScoringSignalsURL) als Promise gesendet werden?	Weitere Informationen
B&A	Erstellen eines neuen Plattform-Headers, um der B&A-Verkäuferseite anzugeben, welche Funktionen der Client (Browser) für eine private Auktion benötigt.	Wir diskutieren diese Funktionsanfrage derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.
Anpassung an Traffic	Vorschlag zur Senkung der zusätzlichen Kosten für das Hosting von B&A-Servern, insbesondere für DSPs.	Wir diskutieren diesen Vorschlag derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.
Bring-Your- Own-Binary	Aktualisieren Sie die Erläuterung, um ausdrücklich darauf hinzuweisen, dass alle Binärdateien unterstützt werden.	Dieser Artikel wurde aktualisiert. Eine entsprechende Erklärung findest du hier.
KV-Anrufe	Wartet `generateBid()`, bis alle Key-Value-Store-Aufrufe abgeschlossen sind, oder werden sie unabhängig voneinander ausgeführt? Wie wirkt sich das KV-Batching auf das Timing aus?	Weitere Informationen
Leistung	Erläuterung der Wiederverwendung von Gebotsscripts und Empfehlung zum Festlegen von Cache-Control-Headern für Scripts	Die entsprechende Dokumentation finden Sie hier.
Leistung	Bitte prüfen Sie, ob Ressourcen (z.B. Gebotsscripts) asynchron geladen werden können, um die On-Device-Auktionslatenz zu reduzieren.	Wir diskutieren diese Funktionsanfrage derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.
Einwilligungsprotokollierung	Klärung erforderlich für Fehler, der beim Versuch auftritt, die Einwilligungsprotokollierung durch Festlegen des CONSENTED_DEBUG_TOKEN zu verwenden.	Prüfen Sie in diesen Fällen, ob CONSENTED_DEBUG_TOKEN im Secret Manager vorhanden ist, ENABLE_OTEL_BASED_LOGGING auf true und TELEMETRY_CONFIG auf mode: PROD gesetzt ist. Hier finden Sie eine Erläuterung, die auf die Quelle hier verweist.
Logs	Sind Ereignisse vom Typ „forDebuggingOnly“ über B&A verfügbar?	„forDebuggingOnly“ für B&A ist seit April 2024 für Auktionen mit einem einzelnen Verkäufer verfügbar. Wir planen, die Funktion schon bald für Auktionen mit mehreren Verkäufern zu aktivieren.
Worklet-Protokolle	Anfrage, Worklet-Protokollierung mit ChromeDriver kompatibel zu machen	Wir prüfen diesen Antrag und freuen uns über zusätzliches Feedback hier.

Digitale Anzeigen analysieren

Attributionsberichte (und andere APIs)

Feedbackthema	Zusammenfassung	Chrome-Antwort
Debug-Berichte	Wie stehen ARA-Fehlerbehebungsberichte nach der Aktualisierung des Ansatzes für Drittanbieter-Cookies in Chrome für Werbetechnologien zur Verfügung? Sollten Anbieter von Anzeigentechnologien weiterhin Zugriff auf ARA-Debugberichte für Nutzer haben, die Drittanbieter-Cookies beibehalten und die Privacy Sandbox APIs aktiviert haben?	Anbieter von Anzeigentechnologien haben Zugriff auf cookiebasierte und sitzungsbasierte Lösungen zur Fehlerbehebung für Nutzer, bei denen sowohl Drittanbieter-Cookies als auch ARA aktiviert sind. Wenn Cookies deaktiviert sind, haben sie nur Zugriff auf die aggregierte Debugging-Lösung. Weitere Informationen zu den Lösungen zur Fehlerbehebung finden Sie hier und hier.
Feature-Erkennung	Anfrage zur Funktionsweise der serverseitigen Funktionserkennung für ARA	Derzeit kann die Unterstützung von ARA-Funktionen anhand der Chrome-Version im User-Agent-String ermittelt werden. Wir freuen uns über weiteres Feedback zum Google Play-Ökosystem.
Feature Request (Funktionsanfrage)	Wir möchten, dass die in ARA Aggregate shared_info verwendete „source_registration_time“ detaillierter ist, z.B. auf eine Stunde oder eine Minute abgerundet (anstelle eines Tages) und konfigurierbar, um die Zeitzone zu berücksichtigen (derzeit nur UTC).	Das Runden des Felds „source_registration_time“ auf den nächsten Tag ist ein Datenschutzmechanismus, mit dem die Möglichkeit für Anbieter von Anzeigentechnologien eingeschränkt wird, einen bestimmten Nutzer mit einer bestimmten Quellenregistrierung zu verknüpfen. Derzeit basiert „source_registration_time“ auf der UTC-Zeit. Anbieter von Anzeigentechnologien können ihre Anzeigenberichte entsprechend anpassen. Wir freuen uns über zusätzliches Feedback zum Google-System in Bezug auf diese Anfrage. Hier können Sie es uns senden.
Spezifikationen	Bitte um Klärung der Spezifikation von „trigger_data“ und „priority“, insbesondere wenn sie mit einem Arraywert verwendet werden.	In diesen Feldern sind keine Arraywerte zulässig. Die eckigen Klammern in der Erläuterung stehen nicht für ein Array, sondern geben an, dass der Text kein Beispielwert, sondern ein Platzhalter mit einer Beschreibung ist. Wie der Text in den eckigen Klammern andeutet: – trigger_data ist ein int-64 – priority ist ein signierter int-64 In keinem der Felder sind Arraywerte zulässig. Du kannst auch das Header-Validator-Tool für ARA verwenden, um mit verschiedenen Werten zu experimentieren und Fehler zu finden, wenn die Dokumentation verwirrend ist.
Unterstützung für AMP-Anzeigen (Accelerated Mobile Pages)	Unterstützt ARA AMP-Anzeigen?	Hier finden Sie unseren Vorschlag, wie wir AMP unterstützen könnten. Wir freuen uns über zusätzliches Feedback.
Spezifikationen	Welche URL wird als „Quellwebsite“ für mehrschichtig eingebettete Anzeigen für ARA betrachtet?	Die URL der Website auf oberster Ebene.
(Auch in früheren Quartalen gemeldet) Funktionsanfrage	Der Mindestwert für „event_report_window“ soll von 3.600 Sekunden (1 Stunde) auf 1.800 Sekunden (30 Minuten) gesenkt werden.	Bei der Festlegung des Mindestzeitraums für Berichte müssen Nützlichkeit und Datenschutz berücksichtigt werden. Das Mindestzeitraum von einer Stunde für Berichte auf Ereignisebene ist wichtig, um die Privatsphäre zu schützen und bestimmte Arten von Angriffen auf den Verlauf zu verhindern. Du kannst uns hier zusätzliches Feedback zu dieser Anfrage geben.
Geräusch	Sie möchten mehr darüber erfahren, wie Rauschen in Berichten auf ARA-Ereignisebene implementiert wird, um eine korrekte Interpretation und Nutzung der Daten zu ermöglichen.	Weitere Informationen finden Sie in diesem Artikel und in diesem Artikel.
Berichte	„shared_info“ in zusammengefassten Berichten enthält standardmäßig nicht mehr „source_registration_time“.	Das liegt an API-Änderungen. Weitere Informationen dazu findest du hier.
Berichte	Die `filtering_id` ist auf dem Tab „Zusammenführbare Berichte“ der Benutzeroberfläche von chrome://attribution-internals/ nicht vorhanden.	Das Symbol `filtering_id` ist derzeit auf dem Tab „Triggerregistrierungen“ in den Details einer Zeile zu sehen, wenn Sie darauf klicken. So können Sie die Gültigkeit prüfen. Wir sind uns bewusst, dass es sinnvoll ist, diese Daten auf dem Tab „Zusammenführbare Berichte“ anzuzeigen. Hier finden Sie weitere Informationen dazu.
Attributionsquelle	Klärung zur Funktionsweise der Attributionsquelle	Weitere Informationen
App-zu-Web-Attribution	Anfrage nach Anleitung für Implementierungen, bei denen nicht klar ist, ob die Quellen aus dem Betriebssystem oder dem Web stammen.	Hier finden Sie eine Anleitung.

Zusammenfassungsdienst

Feedbackthema	Zusammenfassung	Chrome-Antwort
Feature Request (Funktionsanfrage)	Anforderung einer konfigurierbaren Zeitüberschreitung für AgS und/oder mehr Transparenz beim Jobstatus bei langwierigen Ausführungen.	Wir prüfen derzeit Funktionen, mit denen sich langlaufende Jobs überwachen lassen. Wir freuen uns über weiteres Feedback zum Google Play-Ökosystem.
Terraform	Terraform versucht, die IAM-Richtlinie des Kontos zu ändern, auch wenn „service_account_token_creator_list“ nicht festgelegt ist.	Entwickler können die hinzugefügten Berechtigungen in der lokalen Datei „modules/adtech_setup/main.tf“ hinzufügen.
Anforderung von Dokumenten	Dokumentation oder Codelab anfordern, in dem beschrieben wird, wie die Gesundheit des Aggregationsdiensts überwacht wird	Eine Beschreibung der vorhandenen Benachrichtigungen, mit denen der Dienst- und Jobstatus überwacht werden kann, finden Sie in den entsprechenden Terraform-Dateien des Bedieners (alarms.tf und monitoring.tf) im Repository coordinator-services-and-shared-libraries. Wir veröffentlichen demnächst weitere Dokumente und Anleitungen zur Überwachung von Aggregationsdiensten.
Skalierung	Wie kann ich die Skalierungsprobleme im Blick behalten?	Wir haben eine aktualisierte Version dieser Anleitung veröffentlicht, in der die größere Skalierung des Aggregationsdiensts dokumentiert ist. Es gibt derzeit kein direktes Signal, das darauf hinweist, dass ein Fehler aufgetreten ist, weil der Computer die Größe des Jobs nicht verarbeiten kann. Beispiele für indirekte Signale: 90% Arbeitsspeichernutzung vor einem Fehler, ein Job, der wiederholt fehlschlägt. Wir freuen uns über Feedback zum Thema.
Spezifikationen	Wie lange dauert die Ausführung von Berichtsbatches für die Analyse der Zugriffsquellen in der Regel?	Weitere Informationen finden Sie in diesem Hilfeartikel.

Private Aggregation API

Feedbackthema	Zusammenfassung	Chrome-Antwort
Feature Request (Funktionsanfrage)	Anfrage, dass Beiträge von Gleitkommawerten (einschließlich negativer Werte) für „contributeToHistogramOnEvent“ mit einer Empfindlichkeit von 2^16 zulässig sind	Wir diskutieren diesen Vorschlag derzeit in diesem Artikel und freuen uns über zusätzliches Feedback.

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
Geolocation	Anfrage für Geolocation-Datei für den IP-Schutz	Die Datei, in der IP-Adressen ungefähren Standorten für den IP-Schutz zugeordnet werden, finden Sie hier. Diese Datei wird regelmäßig aktualisiert.

Eindämmung von Bounce-Tracking

Feedbackthema	Zusammenfassung	Chrome-Antwort
Zulassungsliste	In der aktualisierten Position wird nicht mehr auf die Zulassungsliste oder ähnliche Mechanismen verwiesen, die unabhängig vom Entscheidungsprozess von Google sind.	Google plant keine Zulassungslisten für die Minderung von Bounce-Tracking-Effekten. Die Schutzmaßnahmen werden einheitlich auf alle Domains angewendet.
Compliance	Die ICO sollte für die Einhaltung des Datenschutzes zuständig sein.	Der Compliance-Status hat keinen Bezug zur Anwendung von BTM und Google trifft keine Entscheidungen hinsichtlich der Compliance bei der Implementierung von BTM.
Wettbewerb	Offenbar ist es Google erlaubt, PET-Wettbewerber mithilfe von BTM (oder anderen Maßnahmen) auszuschließen und dann nach eigenem Ermessen zu entscheiden, ob sie wieder auf den Markt dürfen. Aufgrund des aktuellen Einspruchsverfahrens können Mitbewerber von Anbietern von persönlichen Empfehlungen vorübergehend keine BTM oder ähnliche Maßnahmen verwenden.	Der aktuelle BTM-Vorschlag richtet sich an das Bounce-Tracking als Verfahren. Google möchte zwar verhindern, dass bestimmte Anwendungsfälle, die ähnliche Techniken beinhalten, nicht mehr möglich sind, plant aber nicht, individuelle Ausnahmen von der BTM-Richtlinie zu gewähren. Daher stellt sich nicht die Frage, ob Google die Präsenz von Mitbewerbern nach eigenem Ermessen steuern darf.

Websiteübergreifende Datenschutzgrenzen stärken

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

Feedbackthema	Zusammenfassung	Chrome-Antwort
(Auch in vorherigen Quartalen erfasst) Domainlimit für Gruppen ähnlicher Websites	Die aktuelle Beschränkung auf fünf verknüpfte Domains ist nicht ausreichend, um Anwendungsfälle für websiteübergreifende Messungen zu ermöglichen.	Unsere Antwort ähnelt der aus den vorherigen Quartalen: Wir gehen derzeit nicht davon aus, dass die Obergrenze erhöht wird. Das Limit wurde auf Grundlage von Datenschutzüberlegungen für Nutzer, Feedback von Stakeholdern des W3C-Systems und vergleichbaren Implementierungen in anderen Browsern festgelegt. Weitere Informationen finden Sie in unseren Blogposts (1, 2). Wir empfehlen, Anwendungsfälle zu prüfen, für die ein websiteübergreifender Cookie-Zugriff über die numerische Grenze hinaus erforderlich ist. Außerdem sollten Sie unsere Richtlinien für Anwendungsfälle für Identitäten, authentifizierte Einbettungen und Anwendungsfälle für Werbung beachten. Du kannst uns hier zusätzliches Feedback zu diesem Problem geben.

Fenced Frames API

Feedbackthema	Zusammenfassung	Chrome-Antwort
Native Anzeigen	Das Rendern nativer Anzeigen in Fenced Frames stellt eine Herausforderung dar, da die Übernahme des Stils des Publishers aufgrund von Einschränkungen bei der Kommunikation zwischen dem iFrame und der Seite des Publishers eingeschränkt ist.	Wir arbeiten derzeit an einer weiteren Unterstützung für native Anzeigen, einschließlich der Unterstützung nach der Durchsetzung von abgegrenzten Frames. Du kannst uns hier zusätzliches Feedback zu diesem Problem geben.

Shared Storage API

Feedbackthema	Zusammenfassung	Chrome-Antwort
API-Verwendung	Die Shared Storage API ist auf einigen Geräten nicht verfügbar, wenn andere Privacy Sandbox APIs funktionieren.	Dieses Verhalten ist bei einer kleinen Gruppe von Nutzern (ungefähr 1%) zu erwarten, die am Holdback-Test für den freigegebenen Speicher teilnehmen. Mit dieser experimentellen Einrichtung wird die Leistung und Akzeptanz von APIs in verschiedenen Szenarien bewertet.
API-Verwendung	Werden Schreibvorgänge in Shared Storage unter dem Ursprung des Publishers oder des Bidding-Scripts ausgeführt? Bei ersten Tests wurden keine Schreibvorgänge erkannt, wenn sich die Publisher-Quelle von der Script-Quelle unterschied.	Dieses Problem wurde behoben und bleibt nur im Falle eines möglichen devtools-Fehlers offen. Weitere Informationen finden Sie hier. Der gemeinsame Speicher schreibt im Gebotskontext des `generateBid`-Aufrufs an den Käuferursprung. Die Schreibaktion ist nicht an den Publisher-Ursprung gebunden, auch wenn sich die Publisher-Seite auf einer anderen Domain befindet.
API-Verwendung	Welche Schutzmaßnahmen gibt es, damit böswillige Akteure keine Berichte zum freigegebenen Speicher lesen können?	Der freigegebene Speicher wird durch Aufrufen von origin partitioniert, damit böswillige Akteure oder Anzeigentechnologien keine Daten aus dem freigegebenen Speicher einer anderen Anzeigentechnologie lesen können. Berichte zur privaten Aggregation werden über TLS direkt an dieselbe Quelle gesendet, sodass sie nicht abgefangen werden können.

CHIPS

Feedbackthema	Zusammenfassung	Chrome-Antwort
Partitionierte Cookies	In Chrome und Firefox werden Cookies auf verschiedenen localhost-Ports nicht einheitlich behandelt, insbesondere bei Verwendung des Partitionsattributs.	Firefox behandelt localhost mit unterschiedlichen Ports als unterschiedliche Partitionsschlüssel. Dieses Verhalten entspricht zwar den Sicherheitsprinzipien, weicht jedoch von der Spezifikation und dem Ansatz von Chrome ab. Wir werden diese Angelegenheit in einer Diskussion zur HTML-Spezifikation mit anderen Browsern besprechen und das System benachrichtigen, falls dies zu einer Änderung des CHIPS-Partitionsschlüssels führt. Hier können Sie uns zusätzliches Feedback zu diesem Problem geben.
Partitionierte Cookies	Der Entwurf für „Websitedaten löschen“ ermöglicht fälschlicherweise das Löschen über die Partition der ausstrahlenden Website hinaus, was im Widerspruch zu früheren Diskussionen steht, auf die hier verwiesen wird.	Dies ist ein Fehler im Dokument mit der Standardspezifikation, den wir bald beheben werden. Das korrekte Verhalten wird in diesem Abschnitt der Erläuterung angegeben und entspricht dem Verhalten anderer Browser im Repository mit Erläuterungen zur Speicherpartitionierung. Die Implementierung in Chrome funktioniert bereits ordnungsgemäß.