Von Chrome unterstützte Tests

Zur Vorbereitung auf die Einstellung von Drittanbieter-Cookies bieten wir in Chrome unterstützte Testmodi an, mit denen Websites das Verhalten und die Funktionalität von Websites ohne Drittanbieter-Cookies testen können. Dieser Leitfaden bietet einen Überblick über die Testmodi, die in Chrome zur Verfügung gestellt werden sollen, und darüber, wie Sie auf Labels für Testgruppen zugreifen.

Chrome-Browser bezieht sich in diesem Zusammenhang auf einen Chrome-Client, also eine Chrome-Installation auf einem Gerät. Jedes einzelne Datenverzeichnis eines Nutzers stellt einen eigenen Client dar.

Testgruppe: Eine Gruppe von Chrome-Browsern, für die bestimmte Funktionen aktiviert, deaktiviert oder konfiguriert sind. Im Rahmen von Chrome-gestützten Tests eine Reihe von Browsern, für die Labels festgelegt werden.

Label: In diesem Kontext der Wert eines Anfrageheaders, der für einen Browser festgelegt wird, der zu einer Testgruppe gehört. Jeder Browser in einer Testgruppe bleibt während des Zeitraums der von Chrome unterstützten Tests in dieser Gruppe, sodass das Label für einen Browser bei allen Testern einheitlich bleibt.

Hinweis :Bei diesen Tests wird die Leistung der Privacy Sandbox-APIs für Relevanz und Messung (PS R&M APIs) gemessen: Attribution Reporting, Protected Audience, Topics, Private Aggregation, Shared Storage und Fenced Frames.

Wir bieten zwei verschiedene Modi an:

• Modus A:Seit November 2023 können Organisationen, die die PS R&M APIs testen, die Möglichkeit haben, einheitliche Labels auf einer Teilmenge von Chrome-Browsern zu erhalten, um koordinierte Tests mit verschiedenen Testern zu ermöglichen.
• Modus B:Seit dem 4. Januar 2024 wurden Drittanbieter-Cookies in Chrome für einen Teil der Chrome-Browser global deaktiviert.

Beide Modi laufen mindestens bis zum 2. Quartal 2024. Wenn Drittanbieter-Cookies in Modus B deaktiviert sind, bleiben sie während der vollständigen Einstellung der Drittanbieter-Cookies deaktiviert.

Wir haben mit der CMA zusammengearbeitet, um dafür zu sorgen, dass diese Testmodi dem Testframework (und dem Zeitplan) für Drittanbieter entsprechen, wie in den Richtlinien für Branchentests erläutert. Daher geht die CMA davon aus, dass die Ergebnisse aus Tests in diesen Modi bei der Bewertung der Privacy Sandbox verwendet werden können. Die CMA hat angegeben, dass sie den Ergebnissen von Experimental Design 2, bei dem die Labels „Modus B“ und „Modus A“ Kontrollgruppe 1 verwendet werden, wahrscheinlich mehr Gewicht geben wird. Weitere Informationen zu Experimental Design 2 finden Sie in der CMA-Leitlinien vom 26. Oktober.

Hinweis: Labels sind über den temporären Wert zur Einstellung von Cookies verfügbar, auf den über einen HTTP-Header oder die JavaScript API zugegriffen werden kann. Einzelheiten zur Implementierung finden Sie weiter unten im Abschnitt Über den Wert für die Einstellung von Cookies auf Labels zugreifen.

Wir senden diesen Vorschlag außerdem über den üblichen Blink-Entwicklungsprozess, bei dem das technische Design und der Meilenstein-Release des Chrome-Release festgelegt werden. Dies ist zwar die Implementierung, die wir gerne veröffentlichen würden, aber aufgrund zusätzlicher Diskussionen und Genehmigungen können sich die Details noch ändern. Wir aktualisieren diese Seite laufend, während die Pläne voranschreiten. Sie können uns weiterhin Feedback geben oder Fragen stellen.

Modus A: Browsergruppen mit Label

Organisationen, die an den Tests teilnehmen, können eine persistente Reihe von Labels für eine Teilmenge von Chrome-Browsern aktivieren, um koordinierte Tests mit verschiedenen Anzeigentechnologien in denselben Browsern zu ermöglichen. Wenn ein Browser beispielsweise in die Testgruppe label_only_3 fällt (wie in der folgenden Tabelle dargestellt), können alle teilnehmenden Anzeigentechnologie-Anbieter dasselbe label_only_3-Label sehen und sich entsprechend koordinieren: Verwenden Sie die PS R&M APIs, aber verwenden Sie keine Drittanbieter-Cookies. Wir erwarten von den Seitenteilnehmern, dass Labels an andere Teilnehmer weitergeleitet werden, um während des gesamten Prozesses der Anzeigenauswahl und -messung konsistente Tests zu ermöglichen.

So können beispielsweise mehrere Teilnehmer Protected Audience-Auktionen ohne Drittanbieter-Cookies in einer konsistenten Gruppe von Browsern ausführen. Die Teilnehmer der Auktion geben das beobachtete Label an die Käufer weiter, um koordinierte Tests zu ermöglichen.

Die Labels wirken sich nicht auf die Funktionalität dieser Instanzen von Chrome aus, auch nicht auf die Verfügbarkeit von Drittanbieter-Cookies. Die Labels dienen der Gruppierung für unabhängige, koordinierte Tests, aber es liegt an den beteiligten Parteien, die relevanten Parameter für den Test durchzusetzen. Wenn Sie die Auswirkungen der Entfernung von Drittanbieter-Cookies testen, ist jeder Teilnehmer dafür verantwortlich, Drittanbieter-Cookie-Daten für Browser mit diesem Label auszuschließen.

Das Ziel ist, Gruppen zu haben, die für den normalen Chrome-Traffic repräsentativ sind. Das bedeutet, dass sowohl Drittanbieter-Cookies als auch die PS R&M APIs verfügbar sein sollten. Einige Nutzer haben jedoch möglicherweise Funktionen über Einstellungen oder Erweiterungen geändert oder deaktiviert.

Labels bleiben in der Regel während der gesamten Browsersitzung in Chrome und über mehrere Sitzungen hinweg dauerhaft. Dies kann jedoch nicht garantiert werden, da in seltenen Fällen auch das Zurücksetzen eines Browsers dazu führen kann, dass das aktuelle Label zurückgesetzt wird.

Wir planen, 8,5% der stabilen Chrome-Browser für Modus A aufzunehmen, und in unserem ersten Vorschlag wird diese Population in neun Gruppen aufgeteilt. Die kleineren Untergruppen sollen es AdTech-Teams ermöglichen, Labels flexibel zu kombinieren, um eigene Tests unterschiedlicher Größe zu erstellen. Gruppen überschneiden sich nicht.

Beachten Sie, dass die Labels control_1.* als „Kontrolle 1“ verwendet werden sollen, wie in den Hinweisen der CMA für Branchentests beschrieben. Daher sollten Testteilnehmer die Topics API nicht verwenden und keine Auktionen für geschützte Zielgruppen für diesen Traffic ausführen. Da die Labels keine Auswirkungen auf die Funktionalität haben, sollten Teilnehmer keine beobachteten Themen übergeben oder Protected Audience-Auktionen ausführen, wenn sie die Gruppenlabels control_1.* erkennen.

Wir freuen uns über Feedback dazu, ob diese Auswahl von Gruppen die Anforderungen der teilnehmenden Organisationen erfüllt.

Label	% des stabilen Traffics
control_1.1	0,25
control_1.2	0,25
control_1.3	0,25
control_1.4	0,25
label_only_1	1,5
label_only_2	1,5
label_only_3	1,5
label_only_4	1,5
label_only_5	1,5

Modus A label_only_-Browsergruppen sind seit November 2023 verfügbar, control_1_*-Gruppen von Modus A sind seit dem 4. Januar 2024 verfügbar. Wir senden weiterhin alle Labels für Modus A und Modus B, bis die Drittanbieter-Cookies Anfang 2025 auslaufen.

Modus B: 1% der Drittanbieter-Cookies werden deaktiviert.

Chrome hat seit dem 4. Januar 2024 für etwa 1% der stabilen Chrome-Browser Drittanbieter-Cookies deaktiviert (sowie in den Entwickler-, Canary- und Beta-Browsern im 4. Quartal 2023). Organisationen, die die PS R&M APIs testen, müssen diesen Modus nicht aktivieren, da er einheitlich auf die gesamte Browserpopulation angewendet wird. Es besteht natürlich die Möglichkeit, dass einige Websitefunktionen beeinträchtigt sind, wenn für die Website noch keine alternative Lösung wie CHIPS oder Gruppen ähnlicher Websites verwendet wurde.

Hinweis :Wenn du für Websitefunktionen auf Drittanbieter-Cookie-Daten angewiesen bist, findest du in unserem Leitfaden zur Vorbereitung auf die Einstellung von Drittanbieter-Cookies Informationen dazu, ob CHIPS oder Gruppen ähnlicher Websites deine Anforderungen erfüllen. Wir haben eine öffentliche Problemverfolgung eingeführt, mit der Sie Websiteprobleme melden können, die sich aus der Einstellung von Drittanbieter-Cookies ergeben. Wir arbeiten an Maßnahmen zur Erkennung, Behebung und proaktiven Benachrichtigung von Websiteinhabern, wenn diese in dieser Phase die Nutzerfreundlichkeit beeinträchtigen.

Außerdem planen wir, einen kleinen Teil des Traffics in Modus B bereitzustellen, in dem PS R&M APIs deaktiviert sind. Andere APIs wie Gruppen ähnlicher Websites, CHIPS und FedCM werden nicht deaktiviert. Wir gehen davon aus, dass diese Kombination hilfreich sein wird, um eine Leistungsgrundlage für Browser ohne Drittanbieter-Cookies und ohne die PS R&M APIs zu erstellen.

Im Rahmen von Modus B stellen wir auch Labels für die betroffenen Browser bereit. Die Labels sind dann verfügbar, wenn die APIs deaktiviert werden. Wir schlagen vor, die Bevölkerung in drei treatment_1.*-Gruppen zu unterteilen, in denen Drittanbieter-Cookies deaktiviert sind, aber PS R&M APIs verfügbar sind, und eine control_2-Gruppe, in der sowohl Drittanbieter-Cookies als auch die PS R&M APIs deaktiviert sind.

ARA-Debug-Berichte und Fehlerbehebungsberichte zur privaten Aggregation sind weiterhin für Browser im Modus B verfügbar, sofern der Nutzer Drittanbieter-Cookies nicht explizit blockiert hat. So lassen sich Fehler bei der Einbindung der Attribution Reporting API und der Private Aggregation API leichter beheben und Testteilnehmer können die Auswirkungen des Rauschens besser nachvollziehen. Fehlerbehebungsberichte sind in control_2 nicht verfügbar, da die PS R&M APIs in diesem Segment nicht verfügbar sind. Auch die Fehlerbehebung für Drittanbieter-Cookies wird eingestellt.

• Da Drittanbieter-Cookies für die Attribution Reporting API deaktiviert sind, kann das ar_debug-Cookie vom Berichtsursprung nicht festgelegt werden. Sie müssen dafür die debug_key-Felder (für Berichte zur erfolgreichen Attribution) und die debug_reporting-Felder (für ausführliche Berichte) festlegen, um den Empfang von Debugging-Berichten zu aktivieren oder zu deaktivieren.
• Für die Private Aggregation API sollte der Ursprung der Berichte enableDebugMode() aufrufen, um zu steuern, ob der Empfang von Debugging-Berichten aktiviert wird. Unternehmen sollten weiterhin überprüfen, welche regulatorischen Verpflichtungen für die Verwendung der Attribution Reporting API und der Private Aggregation API gelten können, einschließlich Debug-Berichten.

Modus A wird weiterhin ausgeführt und diese Gruppen unterscheiden sich von den Modus A, da sich ein Nutzer entweder in Modus A, Modus B oder in keinem der beiden befindet. Testteilnehmer sollten den control_1.*-Traffic als Kontrollgruppe verwenden, die den Status quo mit Drittanbieter-Cookies darstellt.

Label	% des stabilen Traffics
treatment_1.1	0,25
treatment_1.2	0,25
treatment_1.3	0,25
control_2	0,25

Chrome hat Cookies auch für 20% der Chrome Canary-, Entwickler- und Beta-Clients eingeschränkt.

Label	% des vorab stabilen Traffics
prestable_treatment_1	10 %
prestable_control_2	10 %

Die Aufnahme in eine dieser Testverzweigungen hat denselben Effekt wie in der stabilen Verzweigung.

Wie auch bei Modus A kann die Verfügbarkeit der PS R&M APIs nicht garantiert werden, da Nutzer sie in den Chrome-Einstellungen Datenschutz und Sicherheit deaktivieren können. Außerdem wird nicht garantiert, dass Drittanbieter-Cookies für jedes Mitglied der control_2-Gruppe deaktiviert werden, da Nutzer auf die Benutzeroberfläche des Browsers zugreifen können, um Drittanbieter-Cookies für eine Website zuzulassen.

Testmonitoring

Beobachten Sie unbedingt das relative Zugriffsvolumen jedes Test- und Kontrolllabels. treatment_1.1 sollte in etwa die gleiche Anzahl an Zugriffen wie treatment_1.2 und treatment_1.3 haben.

Traffic, der Labels enthält, die von Chrome-Versionen vor Version 120 stammen, sollten Sie mit Bedacht vorgehen. Wenn Ihr Team, das in der Regel ungültige Zugriffe bearbeitet, User-Agents identifiziert, die Merkmale ungültiger Zugriffe aufweisen, ist es sinnvoll, diese aus den Testergebnissen herauszufiltern.

Labels vor Zeitraum

Bis Januar 2024 haben wir Vorperioden für mehrere Testverzweigungen ausgeführt. Das war ein Zeitraum, in dem Chrome die Größe genau bestimmen und statistisch unverzerrte Gruppen auswählen konnte. Diese Vorperioden liefen für alle Verzweigungen, die planmäßig im Januar beginnen sollen: die Verzweigungen „Modus B“ und die Verzweigungen Control_1.*. Es besteht hier kein Handlungsbedarf für Entwickler oder Websites. In diesen Verzweigungen vor dem Zeitraum treten keine Änderungen im Verhalten oder der API-Verfügbarkeit auf. Sie sollten jedoch wissen, dass unter Umständen das Label preperiod zurückgegeben wird. Browser, die das Label preperiod erhalten, können zwar zu einer der Testgruppen wechseln, dies ist jedoch nicht garantiert. Daher sollten Sie nicht davon ausgehen, dass Browser mit diesem Label garantiert am Test teilnehmen.

Eine Testverzweigung ist eine Teilmenge der zu untersuchenden Population, in diesem Fall eine der gekennzeichneten Gruppen.

Zugriff auf Labels über den Wert für die Einstellung von Cookies

Für die Dauer von Modus A und Modus B führen wir einen temporären Cookie-Deprecation-Wert ein, auf den über einen Opt-in-HTTP-Header und die JavaScript API zugegriffen werden kann. Dabei wird das Label für die entsprechende Testgruppe für Modus A oder B (wie oben definiert) des Browsers bereitgestellt, falls dieser in einen solchen Wert fällt.

Beim Zugriff auf Labels werden Informationen abgerufen, die auf dem Gerät des Nutzers gespeichert sind. In einigen Rechtsprechungen (z. B. in der EU und im Vereinigten Königreich) ist uns bewusst, dass diese Aktivität der Verwendung von Cookies ähnelt. Daher ist für den Zugriff auf Labels wahrscheinlich die Einwilligung des Endnutzers erforderlich. Bevor Sie Labels anfordern, sollten Sie sich rechtlich beraten lassen, ob diese Einwilligungspflicht für Sie gilt.

Hinweis :Wie bei allen Funktionen, die wir in Chromium veröffentlichen, haben wir im Rahmen des Blink-Entwicklungsprozesses einen Intent to Prototype (I2P) gesendet. Wir schlagen die folgenden Implementierungsdetails vor. Diese können sich jedoch vor der Auslieferung der Funktion in der stabilen Chrome-Version ändern. Wir werden diese Dokumentation weiterhin aktualisieren. Sie können auch der öffentlichen Diskussion folgen, wenn die Intents in der Mailingliste blink-dev veröffentlicht werden.

Auf den HTTP-Header „Sec-Cookie-Deprecation“ zugreifen

Damit der Sec-Cookie-Deprecation-Anfrageheader empfangen wird, muss eine Website zuerst das receive-cookie-deprecation-Cookie setzen. Dieses Cookie muss das Attribut Partitioned verwenden. Das bedeutet, dass die Aktivierung für den Empfang des Headers für jede Website der obersten Ebene erfolgen muss.

Wenn 3p-example.site beispielsweise den Sec-Cookie-Deprecation-Header für seine in example.com eingebetteten Ressourcen empfangen möchte, muss 3p-example.site das folgende Cookie in diesem Kontext setzen.

Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned;  Max-Age=15552000

Die Cookie-Attribute Secure, HttpOnly, SameSite und Partitioned sind obligatorisch. Die anderen Attribute Domain, Path, Expires und Max-Age können entsprechend Ihren Anforderungen festgelegt werden. Path=/ ist jedoch ein guter Standardwert. In diesem Beispiel wird Max-Age=15552000 so festgelegt, dass das Cookie erst nach 180 Tagen abläuft.

Es empfiehlt sich, das Cookie receive-cookie-deprecation=1 vor Beginn der von Chrome unterstützten Testphase zu setzen, damit Browser in einer Testgruppe den Anfrageheader Sec-Cookie-Deprecation enthalten, sobald er verfügbar ist.

Wenn sich der Browser beispielsweise in der Gruppe example_label_1 befindet, enthalten nachfolgende Anfragen, die dieses Cookie enthalten, auch den Header Sec-Cookie-Deprecation.

Sec-Cookie-Deprecation: example_label_1

Wenn der Browser nicht Teil einer Gruppe ist, wird kein Header gesendet. Labels sind an das Vorhandensein des Cookies gebunden. Wenn das Cookie also gelöscht, vollständig blockiert oder für eine bestimmte Website blockiert wird, werden keine Labels gesendet. Da das Attribut Partitioned auch nach der Einstellung von Drittanbieter-Cookies weiterhin verwendet werden kann, können Partitioned-Cookies festgelegt werden, wenn Drittanbieter-Cookies blockiert werden.

Auf die cookieDeprecationLabel JavaScript API zugreifen

Auf den Wert Cookie-Deprecation kann auch über die navigator.cookieDeprecationLabel.getValue() JavaScript API zugegriffen werden. Dadurch wird ein Versprechen zurückgegeben, das zu einem String mit dem entsprechenden Gruppenlabel aufgelöst wird. Wenn sich der Browser beispielsweise in der Gruppe example_label_1 befand:

// Feature detect temporary API first
if ('cookieDeprecationLabel' in navigator) {
 // Request value and resolve promise
 navigator.cookieDeprecationLabel.getValue().then((label) => {
   console.log(label);
   // Expected output: "example_label_1"
 });
}

Wenn der Browser nicht Teil einer Gruppe ist, ist die API entweder nicht verfügbar oder der Wert ist ein leerer String. Achten Sie daher darauf, dass Sie eine Featureerkennung verwenden.

Die JavaScript API kann unabhängig davon aufgerufen werden, ob das receive-cookie-deprecation-Cookie vorhanden ist. Wenn Cookies jedoch vollständig oder speziell für die Website blockiert werden, ist die API wieder entweder nicht verfügbar oder gibt einen leeren String zurück.

Wie bei allen vom Client bereitgestellten Werten müssen Sie den Wert vor der Verwendung aus dem Header oder der JavaScript API bereinigen und validieren.

Demo und Tests

Ab Chrome 120 sind Flags verfügbar, um die lokalen Entwicklertests für das Anfordern und Lesen von Labels zu ermöglichen.

Mit dem Flag chrome://flags/#tpc-phase-out-facilitated-testing können Sie eine Auswahl von Testlabels aktivieren. Diesen Labels ist das Präfix fake_ vorangestellt, um sie von den echten Labels zu unterscheiden. Wenn Sie das Flag aktivieren, wird der Browser nicht in eine der Testgruppen aufgenommen.

Über goo.gle/cft-demo können Sie die Labels in Aktion sehen.

Da die Registrierung für die Privacy Sandbox-APIs für Relevanz und Messung erzwungen wird, müssen Sie möglicherweise die Erzwingung für lokale Tests mit chrome://flags/#privacy-sandbox-enrollment-overrides überschreiben und den Demo-Ursprung angeben. Alternativ können Sie das folgende Befehlszeilen-Flag einfügen, wenn Sie Chrome über ein Terminal ausführen: --args --disable-features=EnforcePrivacySandboxAttestations

Das Flag-Drop-down-Menü enthält mehrere Optionen. Für Tester sind vor allem die mit "Force" gekennzeichneten Einträge interessant, da diese sicherstellen, dass das Testverhalten unabhängig von anderen Gerätekonfigurationen aktiviert wird.

Wenn Sie nur Labels für Testgruppen testen möchten, wählen Sie „Enabled Force Control 1“ oder „Enabled Force LabelOnly“ aus. Dies führt dazu, dass der Browser die Labels "fake_control_1.1" oder "fake_label_only_1.1" sendet.

In Chrome M120 oder höher können Sie auch die folgenden Einträge verwenden.

Wenn Sie das Blockieren von Drittanbieter-Cookies testen möchten, wählen Sie „Erzwungene Behandlung aktiviert“ aus. Dadurch wird das Testgruppenlabel „fake_treatment_1.1“ gesendet, aber auch die Seite „Cookie-Einstellungen“ und die aktuelle Cookie-Einstellung geändert, um Drittanbieter-Cookies zu blockieren.

Wenn Sie das Blockieren von Drittanbieter-Cookies ohne APIs für private Anzeigen testen möchten, wählen Sie „Kontrolle 2 erzwingen“ aus. Dadurch wird das Testgruppenlabel „fake_control_2“ gesendet, die Seite mit den Cookie-Einstellungen aktualisiert, Drittanbieter-Cookies blockiert und die neuen APIs für private Anzeigen unterdrückt.

Hinweis: Es gibt derzeit ein Problem, bei dem die neue Seite mit den Cookie-Einstellungen im Browser beibehalten wird und diese Einstellung Drittanbieter-Cookies blockiert, auch wenn Sie das Flag deaktivieren. Wir arbeiten daran, dieses Problem zu beheben. In der Zwischenzeit können Sie diese Flag-Werte in einem separaten Chrome-Datenverzeichnis testen. Starten Sie dazu Chrome mit dem --user-data-dir=<new dir>-Befehlszeilen-Flag.

Feedback

Wir verwenden das Label "chrome-testing" im Entwickler-Support-Repository auf GitHub, um Fragen zu verwalten. Wir freuen uns über Feedback und Diskussionen zu den ersten Fragen:

• Hast du vor, Tests in Modus A, Modus B oder beidem durchzuführen?
• Labelgrößen für von Chrome unterstützte Tests auswählen
• Verwendung von Clienthinweisen für von Chrome unterstützte Tests

Sie können auch neue Fragen oder Diskussionen im Repository stellen. Verwenden Sie dazu die Vorlage „Chrome-gestützte Tests“.