Von Chrome unterstützte Tests

Als Vorbereitung auf die Einstellung von Drittanbieter-Cookies bieten wir von Chrome unterstützte Testmodi, mit denen Websites eine Vorschau auf das Verhalten und die Funktionen von Websites ohne Drittanbieter-Cookies erhalten. In dieser Anleitung erhalten Sie eine Übersicht über die in Chrome geplanten Testmodi. Außerdem erfahren Sie, wie Sie auf Labels von Testgruppen zugreifen.

Chrome-Browser bezieht sich in diesem Kontext auf einen Chrome-Client: eine Chrome-Installation auf einem Gerät. Jedes einzelne Nutzerdatenverzeichnis stellt einen eigenen Client dar.

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

Label: In diesem Kontext ein Wert für den Anfrageheader, der für einen Browser festgelegt wird, der zu einer Testgruppe gehört. Jeder Browser in einer Testgruppe bleibt während der gesamten von Chrome unterstützten Tests in dieser Gruppe. Dadurch wird sichergestellt, dass das Label für einen Browser bei allen Testern einheitlich bleibt.

Es gibt zwei verschiedene Modi:

• Modus A:Seit November 2023 können Organisationen, die die PS R&M APIs testen, festlegen, dass sie für einen Teil der Chrome-Browser einheitliche Labels erhalten, um koordinierte Tests mit verschiedenen Testern zu koordinieren.
• Modus B:Seit dem 4. Januar 2024 wurden Drittanbieter-Cookies in einem Teil der Chrome-Browser in Chrome weltweit deaktiviert.

Wenn Drittanbieter-Cookies in Modus B deaktiviert sind, bleiben sie für die gesamte Phase der Abschaffung von 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 der Anleitung für Branchentests erläutert. Daher erwartet die CMA, dass die Ergebnisse der Tests in diesen Modi bei ihrer Bewertung der Privacy Sandbox verwendet werden können. Die CMA hat angegeben, dass sie den Ergebnissen von Experimental Design 2, das die Labels Modus B und Kontrolle 1 für Modus A verwendet, wahrscheinlich mehr Gewicht beisteuern wird. Weitere Informationen zu Experimental Design 2 finden Sie in den CMA-Richtlinien vom 26. Oktober.

Auf Labels kann über den temporären Cookie-Deprecation-Wert zugegriffen werden, der über einen HTTP-Header oder die JavaScript API verfügbar ist. Implementierungsdetails finden Sie im späteren Abschnitt Über den Wert für die Einstellung von Cookies auf Labels zugreifen.

Wir senden dieses Angebot auch im Rahmen des üblichen Blink-Entwicklungsprozesses, bei dem das technische Design und der Chrome-Release-Meilenstein fertiggestellt werden. Dies ist die Implementierung, die wir gerne veröffentlichen würden. Weitere Diskussionen und Genehmigungen bedeuten, dass diese Details noch geändert werden können. Wir aktualisieren diese Seite im Verlauf der Pläne. Sie können uns auch weiterhin Feedback geben oder Fragen stellen.

Modus A: Browsergruppen mit Label

Organisationen, die an den Tests teilnehmen, können festlegen, dass sie für einen Teil der Chrome-Browser einen festen Satz von Labels erhalten möchten. So lassen sich Tests mit verschiedenen Anzeigentechnologien auf denselben Browsern koordinieren. Wenn ein Browser beispielsweise zur Testgruppe label_only_3 gehört (wie in der folgenden Tabelle gezeigt), können alle teilnehmenden Anzeigentechnologie-Anbieter dasselbe label_only_3-Label sehen und sich entsprechend koordinieren: Sie können die PS R&M APIs verwenden, aber keine Drittanbieter-Cookies. Wir erwarten, dass die Teilnehmer auf der Seite dafür sorgen, dass Labels an andere Teilnehmer weitergeleitet werden, um einheitliche Tests im gesamten Prozess der Anzeigenauswahl und -messung zu ermöglichen.

So können beispielsweise mehrere Teilnehmer Protected Audience-Auktionen ohne Drittanbieter-Cookies in einer einheitlichen Browsergruppe ausführen. Die Teilnehmer an der Auktion leiten das beobachtete Label an die Käufer weiter, um die koordinierten Tests zu ermöglichen.

Die Labels wirken sich nicht auf das Verhalten in diesen Instanzen von Chrome aus, einschließlich der Verfügbarkeit von Drittanbieter-Cookies. Die Labels ermöglichen die Gruppierung unabhängiger, koordinierter Tests. Die für den Test relevanten Parameter müssen jedoch von den teilnehmenden Parteien festgelegt werden. Wenn Sie die Auswirkungen des Entfernens von Drittanbieter-Cookies testen, sind alle Teilnehmer dafür verantwortlich, Drittanbieter-Cookie-Daten bei Browsern mit diesem Label auszuschließen.

Ziel sind Gruppen, 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 Einstellungen oder Erweiterungen verwendet, um Funktionen zu ändern oder zu deaktivieren.

Labels sind in der Regel während einer Browsersitzung in Chrome und über mehrere Sitzungen hinweg dauerhaft. Dies ist jedoch nicht garantiert, da in seltenen Fällen auch das aktuelle Label zurückgesetzt werden kann, wenn Sie einen Browser vollständig zurücksetzen.

Wir planen, 8,5% der stabilen Chrome-Browser für Modus A einzubeziehen.Unser ursprünglicher Vorschlag teilt diese Population in neun Gruppen auf. Die kleineren Untergruppen sollen es den Anzeigentechnologie-Anbietern ermöglichen, Labels zu kombinieren, um eigene Tests mit unterschiedlichen Größen zu erstellen. Gruppen überschneiden sich nicht.

Beachten Sie, dass die control_1.*-Labels als „Kontrolle 1“ verwendet werden sollen, wie in den Richtlinien für Branchentests der CMA beschrieben. Daher sollten Testteilnehmer für diesen Traffic keine Topics API verwenden oder Protected Audience-Auktionen durchführen. Da die Labels keinen Einfluss auf das Browserverhalten haben, sollten die Teilnehmer keine beobachteten Themen weitergeben und keine Protected Audience-Auktionen durchführen, wenn sie die control_1.*-Gruppenlabels 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

label_only_-Browsergruppen für Modus A sind seit November 2023 verfügbar, control_1_*-Gruppen für Modus A sind seit dem 4. Januar 2024 verfügbar.

Modus B: 1% der Drittanbieter-Cookies deaktivieren

Ab dem 4. Januar 2024 wurden Drittanbieter-Cookies für etwa 1% der stabilen Chrome-Browser in Chrome deaktiviert. Im 4. Quartal 2023 wurden auch in Dev-, Canary- und Beta-Browsern Drittanbieter-Cookies deaktiviert. Organisationen, die die PS R&M APIs testen, müssen diesen Modus nicht aktivieren, da er einheitlich auf die gesamte Browserpopulation angewendet wird. Natürlich besteht die Möglichkeit, dass einige Websitefunktionen beeinträchtigt werden, wenn für die Website noch keine alternative Lösung wie CHIPS oder Gruppen ähnlicher Websites verwendet wird.

Außerdem planen wir, einen kleinen Teil des Traffics innerhalb von Modus B bereitzustellen, bei dem die 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 Leistungsbasislinie für Browser ohne Drittanbieter-Cookies und ohne PS R&M APIs zu schaffen.

Als Teil von Modus B stellen wir auch Labels für die betroffenen Browser bereit. Die Labels sind verfügbar, wenn die APIs deaktiviert sind. Wir empfehlen, die Population 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-Fehlerbehebungsberichte und Fehlerbehebungsberichte für private Aggregationen sind weiterhin für Browser in Modus B verfügbar, um die Fehlerbehebung für die Einbindung der Attribution Reporting API und der Private Aggregation API zu erleichtern und die Testteilnehmer dabei zu unterstützen, die Auswirkungen des Rauschens besser zu verstehen. Voraussetzung ist, dass der Nutzer Drittanbieter-Cookies nicht explizit blockiert hat. Debug-Berichte sind in control_2 nicht verfügbar, da PS R&M APIs in diesem Slice nicht verfügbar sind. Fehlerbehebungsberichte werden mit der Einstellung von Drittanbieter-Cookies ebenfalls eingestellt.

• Da Drittanbieter-Cookies für die Attribution Reporting API deaktiviert sind, kann die Quelle der Berichterstellung nicht das Cookie ar_debug speichern und sollte nur die debug_key-Felder (für Attributions-Erfolgsberichte) und die debug_reporting-Felder (für ausführliche Berichte) festlegen, um den Erhalt von Fehlerbehebungsberichten zu aktivieren oder zu deaktivieren.
• Bei der Private Aggregation API sollte für den Ursprung der Berichterstellung enableDebugMode() aufgerufen werden, um zu steuern, ob Sie Debugging-Berichte erhalten möchten. Unternehmen sollten sich auch weiterhin überlegen, welche gesetzlichen Verpflichtungen für die Nutzung der Attribution Reporting API und der Private Aggregation API gelten, einschließlich Debugging-Berichten.

Modus A wird weiterhin ausgeführt und diese Gruppen unterscheiden sich von Modus A, da sich ein Nutzer entweder in Modus A, Modus B oder in keinem von 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 außerdem die Nutzung von Cookies für 20% der Chrome Canary-, Dev- und Beta-Clients eingeschränkt.

Label	% des vorstabilen Traffics
prestable_treatment_1	10 %
prestable_control_2	10 %

Die Aufnahme in eine dieser Testverzweigungen hat denselben Effekt wie für ihre stabilen Äquivalente.

Wie bei Modus A kann nicht garantiert werden, dass die PS R&M APIs verfügbar sind, da Nutzer sie in den Chrome-Einstellungen unter Datenschutz und Sicherheit deaktivieren können. Ebenso kann nicht garantiert werden, dass Drittanbieter-Cookies für jedes Mitglied der Gruppe control_2 deaktiviert werden, da Nutzer auf die Browser-Benutzeroberfläche zugreifen können, um Drittanbieter-Cookies für eine Website zuzulassen.

Monitoring von Tests

Beobachten Sie unbedingt das relative Traffic-Volumen für jedes Test- und Kontrolllabel. treatment_1.1 sollte etwa die gleiche Menge an Traffic wie treatment_1.2 und treatment_1.3 haben.

Traffic mit Labels, die von Chrome-Versionen vor Version 120 stammen, sollte mit Bedacht behandelt werden. Wenn dein für ungültige Zugriffe zuständiges Team User-Agents identifiziert, die Merkmale ungültiger Zugriffe aufweisen, ist es sinnvoll, diese aus den Testergebnissen herauszufiltern.

Labels für den vorherigen Zeitraum

Bis Januar 2024 haben wir Vorperioden für mehrere Testverzweigungen verwendet: einen Zeitraum, in dem Chrome die Größe und die Auswahl statistisch unbeeinflusster Gruppen richtig anpassen konnte. Diese Vorperioden liefen für alle Verzweigungen, die laut Plan im Januar beginnen sollten: Modus-B-Verzweigungen und Kontrollgruppe_1.*-Verzweigungen. Entwickler oder Websites müssen nichts weiter tun. In diesen Verzweigungen aus dem vorherigen Zeitraum wird sich weder das Verhalten noch die API-Verfügbarkeit ändern. Unter Umständen wird aber unter Umständen das Label preperiod zurückgegeben. Browser, die das Label preperiod erhalten, können zwar zu einer der Testgruppen wechseln, dies ist jedoch nicht garantiert. Sie sollten daher nicht davon ausgehen, dass Browser mit diesem Label garantiert im Test enthalten sind.

Eine Testverzweigung ist eine Teilmenge der zu untersuchenden Population – in diesem Fall eine der mit Labels versehenen Gruppen.

Mit dem Wert „Cookie-Einstellung“ auf Labels zugreifen

Für die Dauer von Modus A und Modus B wurde ein temporärer Cookie-Deprecation-Wert eingeführt, auf den über einen Opt-in-HTTP-Header und die JavaScript API zugegriffen werden kann. Diese API stellt das Label für die entsprechende Testgruppe zu Modus A oder B des Browsers (gemäß der Definition oben) bereit, wenn er unter eine dieser Gruppen fällt.

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

Auf den HTTP-Header Sec-Cookie-Deprecation zugreifen

Um den Anfrageheader Sec-Cookie-Deprecation zu empfangen, muss eine Website zuerst das Cookie receive-cookie-deprecation setzen. Für dieses Cookie muss das Attribut Partitioned verwendet werden. Das bedeutet, dass der Empfang des Headers für jede Website auf oberster Ebene aktiviert werden 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 Cookieattribute Secure, HttpOnly, SameSite und Partitioned sind obligatorisch. Die anderen Attribute: Domain, Path, Expires und Max-Age können so festgelegt werden, wie es Ihren Anforderungen am besten entspricht, obwohl Path=/ eine gute Standardeinstellung ist. Im folgenden Beispiel wird Max-Age=15552000 so festgelegt, dass das Cookie erst nach 180 Tagen abläuft.

Wir empfehlen, das Cookie receive-cookie-deprecation=1 vor Beginn der von Chrome unterstützten Testphase zu setzen, damit die 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 Sec-Cookie-Deprecation-Header.

Sec-Cookie-Deprecation: example_label_1

Wenn der Browser keiner Gruppe angehört, wird kein Header gesendet. Labels sind an das Vorhandensein des Cookies gebunden. Wenn das Cookie also gelöscht, vollständig oder für eine bestimmte Website blockiert wird, werden auch keine Labels gesendet. Da das Attribut Partitioned weiter verwendet werden kann, nachdem Drittanbieter-Cookies vollständig eingestellt wurden, können Partitioned-Cookies gesetzt 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 in einen String aufgelöst wird, der das entsprechende Gruppenlabel enthält. Wenn sich der Browser beispielsweise in der Gruppe example_label_1 befindet:

// 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 zu einer Gruppe gehört, ist die API entweder nicht verfügbar oder der Wert ist ein leerer String. Stellen Sie also sicher, dass Sie eine Feature-Erkennung durchführen.

Die JavaScript API kann unabhängig davon aufgerufen werden, ob das Cookie receive-cookie-deprecation 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 jedem vom Client bereitgestellten Wert 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 lokale Entwicklertests zum Anfordern und Lesen der 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 fake_ vorangestellt, um sie von den echten Labels zu unterscheiden. Wenn Sie das Flag aktivieren, wird der Browser in keiner der Testgruppen aktiviert.

Unter 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 die Erzwingung für lokale Tests möglicherweise überschreiben. Verwenden Sie dazu chrome://flags/#privacy-sandbox-enrollment-overrides und geben Sie den Demo-Ursprung an. Alternativ können Sie das folgende Befehlszeilen-Flag verwenden, wenn Sie Chrome über ein Terminal ausführen: --args --disable-features=EnforcePrivacySandboxAttestations

Das Drop-down-Menü für Meldungen enthält mehrere Optionen. Tester sind in erster Linie an den mit „Force“ gekennzeichneten Einträgen interessiert, da diese dafür sorgen, dass das Testverhalten unabhängig von anderen Gerätekonfigurationen aktiviert ist.

Wenn Sie nur Labels von Testgruppen testen möchten, wählen Sie „Aktiviert – Steuerung erzwingen 1 erzwingen“ oder „Aktiviert – Nur Label erzwingen“ 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 die Blockierung von Drittanbieter-Cookies testen möchten, wählen Sie „Aktiviert erzwungene Behandlung“ aus. Dadurch wird das Gruppenlabel „fake_treatment_1.1“ gesendet, aber auch die Seite mit den Cookie-Einstellungen und die aktuelle Cookie-Einstellung werden so geändert, dass Cookies von Drittanbietern blockiert werden.

Wählen Sie „Kontrolle 2 erzwingen“ aus, um die Blockierung von Drittanbieter-Cookies ohne private Ads APIs zu testen. 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.

Beachten Sie, dass im Browser die neue Seite mit den Cookie-Einstellungen und die Einstellung beibehalten wird, durch die Drittanbieter-Cookies auch dann blockiert werden, wenn Sie das Flag deaktivieren. Wir arbeiten an der Lösung dieses Problems. In der Zwischenzeit können Sie diese Flag-Werte in einem separaten Chrome-Datenverzeichnis testen. Starten Sie dazu Chrome mit dem Befehlszeilen-Flag --user-data-dir=<new dir>.

Feedback

Wir verwenden das Label "chrome-testing" im Repository für Entwicklersupport auf GitHub zur Verwaltung von Fragen. Wir freuen uns über Feedback und Diskussionen zu den ersten Fragen:

• Hast du vor, Modus A, Modus B oder beides zu verwenden?
• Labelgrößen für von Chrome unterstützte Tests auswählen
• Verwendung von Client Hints für Chrome-gestützte Tests

Mit der Vorlage für von Chrome unterstützte Tests können Sie auch neue Fragen stellen oder Diskussionen im Repository stellen.