Testowanie w Chrome

Udostępniamy tryby testowania w Chrome, które umożliwiają sprawdzenie działania i funkcjonalności witryn bez stosowania plików cookie innych firm. Z tego przewodnika dowiesz się, jakie tryby testowania Chrome zamierza udostępnić i jak uzyskać dostęp do etykiet grup eksperymentalnych.

W tym kontekście przeglądarka Chrome oznacza klienta Chrome, czyli instalację Chrome na urządzeniu. Każdy katalog danych użytkownika jest oddzielnym klientem.

Grupa eksperymentalna: zestaw przeglądarek Chrome, w których włączono, wyłączono lub skonfigurowano określone funkcje. W kontekście testowania wspomaganego przez Chrome – zestaw przeglądarek, dla których ustawiono etykiety.

Etykieta: w tym kontekście wartość nagłówka żądania ustawiona dla przeglądarki należącej do grupy eksperymentalnej. Każda przeglądarka w grupie eksperymentalnej pozostanie w tej grupie przez cały okres testowania w Chrome, co zapewni, że etykieta przeglądarki będzie spójna dla wszystkich testerów.

Oferujemy 2 tryby:

  • Tryb A: od listopada 2023 r. organizacje testujące interfejsy PS R&M mogą wyrazić zgodę na otrzymywanie spójnych etykiet w przypadku części przeglądarek Chrome, aby umożliwić skoordynowane testowanie przez różnych testerów.
  • Tryb B: od 4 stycznia 2024 r. Chrome globalnie wyłącza pliki cookie innych firm w przypadku części przeglądarek Chrome.

Współpracowaliśmy z CMA, aby upewnić się, że te tryby testowania są zgodne z ramami testowania (i harmonogramem) dla firm zewnętrznych określonymi w wytycznych dotyczących testowania w branży. Dlatego CMA przewiduje, że wyniki testów w tych trybach mogą zostać wykorzystane do oceny Piaskownicy prywatności. CMA wskazało, że prawdopodobnie przypisze większą wagę wynikom z eksperymentalnej wersji 2, która używa etykiet trybu B i etykietek trybu A w grupie kontrolnej 1. Więcej informacji o wersji 2 projektu eksperymentalnego znajdziesz w wytycznych CMA z 26 października.

Do etykiet można uzyskać dostęp za pomocą tymczasowej wartości Sec-Cookie-Deprecation dostępnej w nagłówku HTTP lub interfejsie JavaScript API. Szczegółowe informacje o wdrożeniu znajdziesz w sekcji Dostęp do etykiet za pomocą wartości Sec-Cookie-Deprecation.

Prześlemy też tę propozycję w ramach zwykłego procesu rozwoju Blinka, w którym zostanie sfinalizowane techniczne zaprojektowanie i osiągnięcie kamienia milowego w Chrome. Chociaż jest to implementacja, którą chcemy wprowadzić, dalsze rozmowy i zatwierdzenia mogą spowodować, że te szczegóły ulegną zmianie. Ta strona będzie aktualizowana w miarę rozwoju planów. Nadal możesz przesyłać opinie i pytania.

Tryb A: grupy przeglądarek z etykietami

Organizacje biorące udział w testach będą mogły wyrazić zgodę na otrzymywanie stałego zestawu etykiet w przypadku części przeglądarek Chrome, co umożliwi im przeprowadzanie skoordynowanych eksperymentów z różnymi technologiami reklamowymi w tym samym zestawie przeglądarek. Jeśli na przykład przeglądarka należy do grupy eksperymentalnej label_only_3 (jak pokazano w tabeli poniżej), wszystkie uczestniczące technologie reklamowe będą mogły zobaczyć tę samą etykietę label_only_3 i odpowiednio się do niej dostosować: używać interfejsów PS R&M, ale nie używać plików cookie innych firm. Oczekujemy, że uczestnicy strony zapewnią, że etykiety są przesyłane do innych uczestników, aby umożliwić spójne eksperymentowanie w całym procesie wyboru i pomiaru reklam.

Umożliwia to np. wielu uczestnikom prowadzenie aukcji Protected Audience bez plików cookie innych firm w konsekwentnej grupie przeglądarek. Uczestnicy aukcji sprzedawców przekazują obserwowaną etykietę kupującym, aby umożliwić im przeprowadzanie testów w zgodnym z planem trybie.

Etykiety nie mają wpływu na działanie tych instancji Chrome, w tym na dostępność plików cookie innych firm. Etykiety umożliwiają grupowanie niezależnych, skoordynowanych eksperymentów, ale to uczestnicy eksperymentu muszą zastosować odpowiednie parametry. Jeśli testujesz wpływ usuwania plików cookie innych firm, każdy uczestnik jest odpowiedzialny za wykluczanie danych plików cookie innych firm w przypadku przeglądarek z taką etykietą.

Celem jest tworzenie grup, które są reprezentatywne dla normalnego ruchu w Chrome. Oznacza to, że powinny być dostępne zarówno pliki cookie innych firm, jak i interfejsy PS R&M, ale część użytkowników mogła użyć ustawień lub rozszerzeń, aby zmienić lub wyłączyć funkcje.

Etykiety są zwykle trwałe w całości sesji przeglądania w Chrome oraz w kolejnych sesjach. Nie jest to jednak gwarantowane, ponieważ w rzadkich przypadkach całkowite zresetowanie przeglądarki może spowodować zresetowanie bieżącej etykiety.

W przypadku trybu A planujemy uwzględnić 8, 5% przeglądarek Chrome w wersji stabilnej.W naszej wstępnej propozycji ta populacja została podzielona na 9 grup. Mniejsze podgrupy mają zapewnić specjalistom ds. technologii reklamowych elastyczność w kombinowaniu etykiet, aby mogli tworzyć własne eksperymenty o różnej wielkości. Grupy się nie nakładają.

Pamiętaj, że etykiety control_1.* są przeznaczone do stosowania jako „kontrola 1” zgodnie z wytycznymi CMA dotyczącymi testów branżowych, więc uczestnicy testów nie powinni używać interfejsu Topics API ani prowadzić aukcji z chronionymi odbiorcami dla tego ruchu. Ponieważ etykiety nie wpływają na działanie przeglądarki, uczestnicy nie powinni przekazywać tematów obserwowanych ani przeprowadzać aukcji Protected Audience, gdy wykryją etykiety grupy control_1.*.

Zapraszamy do przesłania opinii na temat tego, czy wybrane grupy odpowiadają potrzebom organizacji biorących udział w programie.

Etykieta % stabilnego ruchu
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

Grupy przeglądarek (label_only_) w trybie A są dostępne od listopada 2023 r., a grupy przeglądarek (control_1_*) w tym trybie – od 4 stycznia 2024 r.

Tryb B: wyłączenie 1% plików cookie innych firm

Od 4 stycznia 2024 r. Chrome wyłączył pliki cookie innych firm w przypadku około 1% przeglądarek Chrome stabilnej (a także w Chrome deweloperskiej, Canary i beta w IV kwartale 2023 r.). Organizacje testujące interfejsy PS R&M API nie muszą zgłaszać się do tego trybu, ponieważ jest on stosowany równomiernie w całej populacji przeglądarek. Jeśli witryna nie wdrożyła jeszcze alternatywnego rozwiązania, takiego jak CHIPS lub powiązane zestawy witryn, może to mieć wpływ na niektóre funkcje witryny.

Dodatkowo planujemy kierować niewielką część ruchu w ramach trybu B do interfejsów PS R&M API, które mają wyłączone. Inne interfejsy API, takie jak zestawy powiązanych witryn, CHIPS i FedCM, nie zostaną wyłączone. Spodziewamy się, że ta kombinacja pomoże ustalić podstawową skuteczność w przypadku przeglądarek bez plików cookie innych firm i bez interfejsów API R&M z Piaskownicy prywatności.

W ramach trybu B udostępniamy też etykiety dla przeglądarek, których dotyczy problem. Te etykiety są dostępne w tym samym czasie, w którym wyłączono interfejsy API. Proponujemy podzielenie populacji na 3 grupy treatment_1.*, w których pliki cookie innych firm są wyłączone, ale interfejsy PS R&M API są dostępne, oraz jedną grupę control_2, w której oba pliki cookie innych firm i interfejsy PS R&M API są wyłączone.

Aby ułatwić debugowanie integracji interfejsów Attribution Reporting API i Private Aggregation API oraz pomóc uczestnikom testów w lepszym zrozumieniu wpływu szumu, raporty o błędach ARA i raporty o błędach Private Aggregation będą nadal dostępne w przeglądarkach w trybie B, o ile użytkownik nie zablokuje wyraźnie plików cookie innych firm. Raporty debugowania nie będą dostępne w sekcji control_2, ponieważ interfejsy API R&M w PS nie są dostępne w tym przekroju.

  • W przypadku interfejsu Attribution Reporting API, ponieważ pliki cookie innych firm są wyłączone, źródło raportowania nie będzie mogło ustawić pliku cookie ar_debug i powinno zamiast tego ustawić pola debug_key (w przypadku raportów o skuteczności atrybucji) i pola debug_reporting (w przypadku szczegółowych raportów), aby wyrazić zgodę na otrzymywanie raportów debugowania lub zrezygnować z ich otrzymywania.
  • W przypadku interfejsu Private Aggregation API źródło raportowania powinno wywoływać funkcję enableDebugMode(), aby kontrolować zgodę na otrzymywanie raportów debugowania. Firmy powinny nadal uwzględniać obowiązujące zobowiązania regulacyjne w przypadku korzystania z interfejsów Attribution Reporting API i Private Aggregation API, w tym raportów debugowania.

Tryb A nadal działa, a te grupy różnią się od grup trybu A, ponieważ użytkownik będzie w trybie A, trybie B lub w żadnym z nich. Uczestnicy testów powinni użyć ruchu control_1.* jako grupy kontrolnej, która reprezentuje stan obecny z plikami cookie innych firm.

Etykieta % stabilnego ruchu
treatment_1.1 0,25
treatment_1.2 0,25
treatment_1.3 0,25
control_2 0,25

Chrome ograniczył też pliki cookie w 20% klientów Chrome Canary, deweloperskiej i beta.

Etykieta Procent ruchu z czasu poprzedzającego stabilną wersję
prestable_treatment_1 10%
prestable_control_2 10%

Uwzględnienie w jednej z tych grup eksperymentalnych będzie miało taki sam skutek jak w przypadku ich odpowiedników w wersji stabilnej.

Podobnie jak w przypadku trybu A, nie ma gwarancji, że interfejsy PS R&M będą dostępne, ponieważ użytkownicy mogą je wyłączyć w ustawieniach Chrome Prywatność i bezpieczeństwo. Nie ma też gwarancji, że pliki cookie innych firm są wyłączone dla wszystkich członków grupy control_2, ponieważ użytkownicy mogą uzyskać dostęp do interfejsu przeglądarki, aby zezwolić na pliki cookie innych firm w witrynie.

Monitorowanie eksperymentu

Pamiętaj, aby monitorować względną wielkość ruchu w przypadku każdej grupy eksperymentalnej i grupy kontrolnej. Wartość treatment_1.1 powinna być zbliżona do wartości treatment_1.2 i treatment_1.3.

Zalecamy ostrożność w przypadku ruchu zawierającego etykiety z wersji Chrome starszych niż 120. Jeśli zespół, który zwykle zajmuje się nieprawidłowym ruchem, wykryje przeglądarki użytkowników wykazujące cechy nieprawidłowego ruchu, warto je odfiltrować z wyników testów.

Etykiety przed okresem

Do stycznia 2024 r. mieliśmy okresy wstępne w przypadku kilku grup eksperymentalnych. Te czasy z okresu poprzedzającego pozwoliły Chrome na dokładne określenie rozmiaru i wybór statystycznie bezstronnych grup. Te okresy wstępne obejmowały wszystkie grupy eksperymentalne zaplanowane na styczeń: grupy eksperymentalne w trybie B i grupy eksperymentalne Control_1.*. Nie musisz tutaj podejmować żadnych działań związanych z deweloperem ani witryną – w tym okresie nie nastąpi żadna zmiana w zachowaniu ani dostępności interfejsu API. Pamiętaj jednak, że w niektórych sytuacjach możesz zobaczyć etykietę preperiod. Chociaż przeglądarki z oznaczeniem preperiod mogą zostać przeniesione do jednej z grup eksperymentalnych, nie jest to gwarantowane. Nie należy więc zakładać, że przeglądarki z tym oznaczeniem z pewnością uczestniczą w eksperymencie.

Grupa eksperymentalna to podzbiór populacji badanej w eksperymencie; w tym przypadku jedna z oznaczonych grup.

Na czas trwania trybu A i B wprowadziliśmy tymczasową wartość Sec-Cookie-Deprecation, do której można uzyskać dostęp za pomocą nagłówka HTTP i interfejsu API JavaScriptu. Umożliwia ona określenie etykiety grupy eksperymentalnej trybu A lub B przeglądarki (zdefiniowanej przez powyższe wartości procentowe), jeśli przeglądarka należy do jednej z nich.

Dostęp do etykiet wymaga dostępu do informacji przechowywanych na urządzeniu użytkownika. W niektórych jurysdykcjach (np. w UE i Wielkiej Brytanii) ta czynność jest analogiczna do korzystania z plików cookie, dlatego dostęp do etykiet prawdopodobnie wymaga zgody użytkownika. Zanim poprosisz o etykiety, zalecamy zasięgnięcie porady prawnej, czy obowiązek uzyskania zgody dotyczy Twojej firmy.

Aby otrzymać nagłówek żądania Sec-Cookie-Deprecation, witryna musi najpierw ustawić plik cookie receive-cookie-deprecation. Plik cookie musi zawierać atrybut Partitioned, co oznacza, że zgoda na otrzymywanie nagłówka musi być wyrażana osobno dla każdej witryny najwyższego poziomu.

Jeśli np. 3p-example.site chce otrzymywać nagłówek Sec-Cookie-Deprecation w zasobach umieszczonych w example.com, 3p-example.site musi ustawić w tym kontekście następujący plik cookie:

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

Atrybuty plików cookie Secure, HttpOnly, SameSite i Partitioned są wymagane. Atrybuty Domain, Path, Expires i Max-Age możesz ustawić tak, jak Ci odpowiada, choć domyślnie jest to Path=/. W tym przykładzie parametr Max-Age=15552000 ma wartość 180, co oznacza, że plik cookie nie wygaśnie przed upływem 180 dni.

Warto zacząć konfigurować plik cookie receive-cookie-deprecation=1 przed rozpoczęciem okresu testowania w Chrome, aby mieć pewność, że przeglądarki w grupie eksperymentalnej będą zawierać nagłówek żądania Sec-Cookie-Deprecation, gdy tylko będzie on dostępny.

Jeśli np. przeglądarka znajduje się w grupie example_label_1, kolejne żądania zawierające ten plik cookie będą też zawierać nagłówek Sec-Cookie-Deprecation.

Sec-Cookie-Deprecation: example_label_1

Jeśli przeglądarka nie należy do grupy, nagłówek nie zostanie wysłany. Etykiety są powiązane z obecnością pliku cookie, więc jeśli plik cookie zostanie usunięty, całkowicie zablokowany lub zablokowany w konkretnej witrynie, etykiety nie będą wysyłane. Atrybut Partitioned jest przeznaczony do dalszego używania po całkowitym wycofaniu plików cookie innych firm, co oznacza, że pliki cookie Partitioned mogą być ustawiane, gdy pliki cookie innych firm są zablokowane.

Dostęp do interfejsu cookieDeprecationLabel JavaScript API

Do wartości Sec-Cookie-Deprecation można też uzyskać dostęp za pomocą interfejsu JavaScript API navigator.cookieDeprecationLabel.getValue(). Zwraca obietnicę, która przekształca się w ciąg znaków zawierający odpowiednią etykietę grupy. Na przykład, jeśli przeglądarka była w grupie example_label_1:

// 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"
 });
}

Jeśli przeglądarka nie należy do grupy, interfejs API będzie niedostępny lub jego wartość będzie pustym ciągiem znaków. Dlatego pamiętaj o wykrywaniu funkcji.

Interfejs JavaScript API może być wywoływany niezależnie od obecności pliku cookie receive-cookie-deprecation. Jeśli jednak pliki cookie są całkowicie zablokowane lub zablokowane tylko w przypadku danej witryny, interfejs API znowu będzie niedostępny lub zwróci pusty ciąg znaków.

Podobnie jak w przypadku innych wartości przekazywanych przez klienta, przed użyciem wartości z nagłówka lub interfejsu JavaScript API należy ją sprawdzić i sprawdzić.

Wersja demonstracyjna i testowanie

Od wersji 120 Chrome dostępne są flagi umożliwiające testowanie lokalnie przez deweloperów przesyłania i odczytywania etykiet.

Flaga chrome://flags/#tpc-phase-out-facilitated-testing umożliwia włączenie wybranych etykiet testowych. Etykiety te mają przedrostek fake_, aby odróżnić je od rzeczywistych etykiet. Włączenie tej opcji nie powoduje dołączenia przeglądarki do żadnej grupy eksperymentalnej.

Etykiety możesz zobaczyć w akcji na stronie goo.gle/cft-demo.

Rejestracja jest wymagana w przypadku interfejsów API Piaskownicy prywatności służących do pomiaru trafności i relewantności. W przypadku testów lokalnych konieczne może być zastąpienie wymuszania za pomocą interfejsu chrome://flags/#privacy-sandbox-enrollment-overrides i podania adresu origin demo. Jeśli uruchamiasz Chrome z terminala, możesz też użyć tej flagi wiersza poleceń:--args --disable-features=EnforcePrivacySandboxAttestations

chrome://flags/#tpc-phase-out-facilitated-testing
Ustawienia flagi testowania ułatwionego przez Chrome

W menu flagi jest kilka opcji. Testerzy będą zainteresowani głównie wpisami oznaczonymi jako „Wymuś”, ponieważ zapewniają one włączenie zachowania eksperymentalnego niezależnie od innych konfiguracji urządzenia.

Aby przetestować tylko etykiety grup eksperymentalnych, wybierz „Włączona kontrola wymuszona 1” lub „Włączona kontrola wymuszona – tylko etykiety”. W efekcie przeglądarka wyśle etykiety „fake_control_1.1” lub „fake_label_only_1.1”.

W Chrome M120 lub nowszej możesz też używać tych wpisów.

Aby przetestować blokowanie plików cookie innych firm, wybierz „Włączone wymuszanie grupy eksperymentalnej”. Spowoduje to wysłanie etykiety grupy eksperymentalnej „fake_treatment_1.1”, ale też zmodyfikuje stronę ustawień plików cookie i obecne ustawienie pliku cookie, aby blokować pliki cookie innych firm.

Aby przetestować blokowanie plików cookie innych firm bez interfejsów API reklam prywatnych, wybierz „Wymuś grupę kontrolną 2”. Spowoduje to wysłanie etykiety grupy eksperymentalnej „fake_control_2”, zaktualizuje stronę ustawień plików cookie, zablokuje pliki cookie innych firm i wyłączy nowe interfejsy API reklam prywatnych.

Pamiętaj, że w przypadku tej flagi przeglądarka będzie nadal wyświetlać nową stronę ustawień plików cookie, która blokuje pliki cookie innych firm, nawet jeśli ją wyłączysz. Pracujemy nad rozwiązaniem tego problemu, ale w międzyczasie możesz przetestować te wartości flagi w osobnym katalogu danych Chrome, uruchamiając Chrome z flagą wiersza poleceń --user-data-dir=<new dir>.

Prześlij opinię

Aby zarządzać pytaniami, używamy etykiety „chrome-testing” w repozytorium pomocy dla deweloperów na GitHubie. Czekamy na Twoją opinię i dyskusję na temat początkowych pytań:

Możesz też zadawać nowe pytania lub prowadzić dyskusje w repozytorium za pomocą szablonu „Testowanie przy użyciu Chrome”.