Testowanie w Chrome

W ramach przygotowań do wycofania plików cookie innych firm udostępnimy tryby testowania prowadzone w Chrome, które umożliwią witrynom sprawdzenie działania i funkcjonalności witryny bez stosowania plików cookie innych firm. Ten przewodnik zawiera omówienie trybów testowania, które planuje udostępnić Chrome, oraz sposobu dostępu do etykiet grup eksperymentalnych.

Przeglądarka Chrome w tym kontekście odnosi się do klienta Chrome, czyli instalacji Chrome na urządzeniu. Katalog danych każdego użytkownika stanowi oddzielnego klienta.

Grupa eksperymentalna: grupa przeglądarek Chrome, dla których są włączone, wyłączone lub skonfigurowane określone funkcje. W kontekście testowania w Chrome jest to zestaw przeglądarek, dla których ustawiono etykiety.

Etykieta: w tym kontekście wartość nagłówka żądania ustawiona dla przeglądarki, która należy do grupy eksperymentalnej. Każda przeglądarka w grupie eksperymentalnej pozostanie w tej grupie przez cały okres testowania przeprowadzanego w Chrome, dzięki czemu etykieta przeglądarki pozostaje taka sama u wszystkich testerów.

Udostępniamy 2 różne tryby:

  • Tryb A: od listopada 2023 r. organizacje testujące interfejsy PS R&M API mogą wyrazić zgodę na otrzymywanie spójnych etykiet w podzbiorze przeglądarek Chrome, co umożliwi skoordynowane testy z udziałem różnych testerów.
  • Tryb B: od 4 stycznia 2024 r. Chrome globalnie wyłącza pliki cookie innych firm w niektórych przeglądarkach Chrome.

Oba tryby będą obowiązywać co najmniej do początku 2025 roku. Jeśli pliki cookie innych firm są wyłączone w Trybie B, pozostaną wyłączone do końca pełnego ich wycofania.

Wspólnie z CMA zadbaliśmy o to, aby te tryby testowania były zgodne z platformą (i harmonogramem) testowania usług dla firm zewnętrznych, zgodnie z wytycznymi dotyczącymi testowania w branży. W związku z tym CMA przewiduje, że wyniki testowania w tych trybach mogą zostać wykorzystane podczas oceny Piaskownicy prywatności. Organizacja CMA wskazała, że prawdopodobnie bardziej przyda się wynikom z projektu eksperymentalnego 2, w którym stosowane są etykiety Trybu B i etykiety kontrolne 1 w Trybie A. Aby dowiedzieć się więcej o projekcie eksperymentalnym 2, zapoznaj się z wytycznymi CMA opracowanymi na 26 października.

Tę ofertę pakietową wyślemy też w ramach zwykłego procesu tworzenia Blink, w ramach którego finalizujemy projekt techniczny i proces publikowania wersji Chrome. Chcemy wprowadzić te zmiany, jednak dodatkowe dyskusje i zatwierdzenia mogą jeszcze ulec zmianie. W miarę postępów w planach będziemy aktualizować tę stronę. Możesz nadal przesyłać opinie i pytania.

Tryb A: oznaczone etykietami grupy przeglądarek

Organizacje uczestniczące w testach będą mogły wyrazić zgodę na otrzymywanie stałego zestawu etykiet dla podzbioru przeglądarek Chrome, co umożliwia skoordynowane eksperymenty z różnymi technologiami reklamowymi w tym samym zestawie przeglądarek. Jeśli np. przeglądarka należy do grupy eksperymentalnej label_only_3 (jak pokazano w tabeli poniżej), wszystkie technologie reklamowe uczestniczące w programie będą mogły zobaczyć tę samą etykietę label_only_3 i odpowiednio do nich koordynować: używają interfejsów API PSR&M, ale nie używają plików cookie innych firm. Oczekujemy, że uczestnicy strony zadbają o to, aby etykiety zostały przekazane innym uczestnikom, co umożliwi spójne eksperymentowanie w całym procesie wyboru reklamy i pomiaru.

Dzięki temu wielu uczestników może na przykład prowadzić aukcje Protected Audience bez stosowania plików cookie innych firm w tej samej grupie przeglądarek. Uczestnicy aukcji przekazują zaobserwowaną etykietę kupującym, aby ułatwić skoordynowane testy.

Nie mają one wpływu na żadne funkcje w tych instancjach Chrome, w tym na dostępność plików cookie innych firm. Etykiety umożliwiają grupowanie niezależnych, skoordynowanych eksperymentów, ale to od uczestniczących w eksperymencie zależy, czy odpowiednie parametry zostaną wyegzekwowane w ramach eksperymentu. Jeśli testujesz efekty usunięcia plików cookie innych firm, każdy uczestnik odpowiada za wykluczenie danych z plików cookie innych firm w przypadku przeglądarek z tą etykietą.

Celem jest utworzenie grup reprezentatywnych dla normalnego ruchu Chrome. Oznacza to, że powinny być dostępne zarówno pliki cookie innych firm, jak i interfejsy API PS R&M. Jednak niektórzy użytkownicy mogli zmienić lub wyłączyć ich funkcje w ustawieniach lub rozszerzeniach.

Etykiety są zwykle trwałe podczas jednej sesji przeglądania w Chrome i w różnych sesjach. Nie jest to jednak gwarantowane, ponieważ w rzadkich przypadkach całkowite zresetowanie przeglądarki może również spowodować zresetowanie bieżącej etykiety.

Planujemy włączyć 8,5% stabilnych przeglądarek Chrome w ramach Trybu A, a wstępna propozycja dzieli tę populację na 9 grup. Mniejsze podgrupy mają dawać technikom reklamowym elastyczność w łączeniu etykiet w celu tworzenia własnych eksperymentów o różnych rozmiarach. Grupy nie nakładają się na siebie.

Pamiętaj, że etykiety control_1.* są przeznaczone do użycia jako „Kontrola 1”, zgodnie z wytycznymi CMA dotyczącymi testowania branżowego, więc uczestnicy testów nie powinni używać interfejsu Topics API ani uruchamiać aukcji Protected Audience API w przypadku tego ruchu. Etykiety nie wpływają na funkcjonalność, więc uczestnicy nie powinni przekazywać obserwowanych tematów ani rozpoczynać aukcji Protected Audience API po wykryciu etykiet grupowych control_1.*.

Chętnie dowiemy się, czy wybrane grupy spełniają potrzeby organizacji uczestniczących w programie.

Etykieta % ruchu stabilnego
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 w trybie A label_only_ są dostępne od listopada 2023 r., a grupy w trybie A control_1_* są dostępne od 4 stycznia 2024 r. Będziemy wysyłać wszystkie etykiety trybów A i B do momentu wycofania plików cookie innych firm na początku 2025 r.

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

Od 4 stycznia 2024 r. Chrome wyłączył pliki cookie innych firm w około 1% przeglądarek stabilnych Chrome (w IV kwartale 2023 r. również w przeglądarkach deweloperskich, Canary i beta). Organizacje testujące interfejsy API PS R&M nie muszą włączać tego trybu, ponieważ będą one stosowane jednakowo w przypadku całego zapełnienia przeglądarki. Jeśli witryna nie wdrożyła jeszcze alternatywnego rozwiązania, takiego jak CHIPS lub zestawy powiązanych witryn, może to mieć wpływ na niektóre funkcje witryny.

Dodatkowo planujemy udostępnić niewielki odsetek ruchu w ramach Trybu B, w którym interfejsy API PS R&M są wyłączone. Inne interfejsy API, takie jak zestawy powiązanych witryn, CHIPS i FedCM, nie będą wyłączone. Przewidujemy, że to połączenie pomoże określić bazową wydajność przeglądarek bez plików cookie innych firm i bez interfejsów API PS R&M.

W ramach Trybu B dostarczymy też etykiety dla tych przeglądarek. Będą one dostępne w tym samym czasie, gdy interfejsy API zostaną wyłączone. Proponujemy podzielić populację na 3 grupy typu treatment_1.*, w których pliki cookie innych firm są wyłączone, ale dostępne są interfejsy API PS R&M, oraz na 1 grupę control_2, w której wyłączone są oba pliki cookie innych firm i interfejsy API PS R&M.

Aby ułatwić debugowanie interfejsu Attribution Reporting API i integracji z interfejsem Private Aggregation API oraz pomóc uczestnikom testów lepiej zrozumieć wpływ szumu, raporty debugowania AAR i raporty debugowania z agregacji prywatnej będą nadal dostępne w przeglądarkach działających w Trybie B, o ile użytkownik nie zablokował wyraźnie plików cookie innych firm. Raporty debugowania nie będą dostępne w: control_2, ponieważ interfejsy API PS R&M nie są w nim dostępne. Raporty debugowania będą nadal wycofywane, podobnie jak wycofane pliki cookie innych firm.

  • W przypadku interfejsu Attribution Reporting API, ponieważ wyłączone są pliki cookie innych firm, źródło raportów nie może skonfigurować pliku cookie ar_debug. Aby włączyć lub wyłączyć otrzymywanie raportów z debugowania, należy skonfigurować pola debug_key (w przypadku raportów o udanej atrybucji) i pola debug_reporting (w przypadku raportów szczegółowych).
  • W przypadku interfejsu Private Aggregation API źródło raportowania powinno polegać na wywołaniu enableDebugMode(), aby kontrolować zgodę na otrzymywanie raportów o debugowaniu. Firmy powinny nadal rozważać, w jaki sposób mogą obowiązywać zobowiązania prawne związane z korzystaniem z interfejsów Attribution Reporting API i Private Aggregation API, w tym z raportów debugowania.

Tryb A nadal działa, a te grupy różnią się od grup trybu A, ponieważ użytkownik znajduje się w trybie A, w trybie B albo w żadnym z nich. Uczestnicy testów powinni używać ruchu control_1.* jako grupy kontrolnej, która reprezentuje stan za pomocą plików cookie innych firm.

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

Przeglądarka Chrome ograniczyła też pliki cookie w 20% klientów Chrome Canary, Dev i beta.

Etykieta % ruchu przed stabilizacją
prestable_treatment_1 10%
prestable_control_2 10%

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

Podobnie jak w przypadku Trybu A, nie gwarantujemy dostępności interfejsów PS R&M API, ponieważ użytkownicy mogą je wyłączyć w ustawieniach Chrome Prywatność i bezpieczeństwo. Podobnie pliki cookie innych firm nie zostaną wyłączone w przypadku każdego członka grupy control_2, ponieważ użytkownicy mogą otworzyć interfejs przeglądarki, aby zezwolić na pliki cookie innych firm w przypadku danej witryny.

Monitorowanie eksperymentu

Pamiętaj o monitorowaniu względnego natężenia ruchu w każdej fazie eksperymentu i w kategorii kontrolnej. Ruch z treatment_1.1 powinien być taki sam jak w przypadku treatment_1.2 i treatment_1.3.

Zalecamy rozważne podejście do ruchu zawierającego etykiety pochodzące z Chrome w wersjach starszych niż 120. Jeśli zespół, który zajmuje się zwykle nieprawidłowym ruchem, identyfikuje klienty użytkownika wykazujące cechy nieprawidłowego ruchu, wtedy warto odfiltrowywać je z wyników testów.

Etykiety okresów przed

Do stycznia 2024 r. prowadziliśmy okresy poprzedzające dla wielu grup eksperymentalnych. Był to okres, który pozwalał Chrome na precyzyjne określenie rozmiaru i wybór grup o obiektywnych statystycznie danych. Okresy wstępne obejmowały wszystkie grupy, które miały się rozpocząć w styczniu: grupy w trybie B i grupy Control_1.*. Nie ma potrzeby podejmowania działań przez dewelopera ani w witrynie – w tych grupach sprzed okresu przedpremierowego działanie i dostępność interfejsów API się nie zmienią. Pamiętaj jednak, że w niektórych sytuacjach możesz zobaczyć etykietę preperiod. Przeglądarki otrzymujące etykietę preperiod mogą zostać przeniesione do jednej z grup eksperymentalnych, ale nie jest to gwarantowane, dlatego nie należy zakładać, że przeglądarki z tą etykietą będą uwzględnione w eksperymencie.

Grupa eksperymentalna jest podzbiorem badanej populacji: w tym przypadku jedna z grup oznaczonych etykietami.

Na czas trwania Trybu A i B wprowadzimy tymczasową wartość Cookie-Deprecation dostępną za pomocą opcjonalnego nagłówka HTTP i interfejsu JavaScript API, która udostępni etykietę odpowiedniej grupy eksperymentalnej w trybie A lub B (zgodnie z powyższymi wartościami procentowymi), jeśli pasuje do jednej z tych grup.

Uzyskiwanie dostępu do etykiet obejmuje dostęp do informacji zapisanych na urządzeniu użytkownika. Zdajemy sobie sprawę, że w niektórych jurysdykcjach (np. w Unii Europejskiej i Wielkiej Brytanii) taka aktywność jest podobna do korzystania z plików cookie, więc dostęp do etykiet prawdopodobnie wymaga zgody użytkownika. Zanim zaczniesz zgłaszać żądania etykiet, zalecamy skonsultowanie się z prawnikiem, aby ustalić, czy to zobowiązanie Cię dotyczy.

Aby otrzymać nagłówek żądania Sec-Cookie-Deprecation, witryna musi najpierw utworzyć plik cookie receive-cookie-deprecation. Ten plik cookie musi korzystać z atrybutu Partitioned, co oznacza, że akceptacja nagłówka musi zostać dokonana dla każdej witryny najwyższego poziomu.

Jeśli np. strona 3p-example.site chce otrzymać nagłówek Sec-Cookie-Deprecation w swoich zasobach umieszczonych w witrynie example.com, musi w tym kontekście 3p-example.site ustawić ten 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. Pozostałe atrybuty: Domain, Path, Expires i Max-Age można ustawić zgodnie z Twoimi potrzebami, chociaż Path=/ to domyślna wartość. W tym przykładzie ustawiamy Max-Age=15552000, tak aby plik cookie nie tracił ważności przez 180 dni.

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

Jeśli np. przeglądarka należy do grupy 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 zostanie on usunięty, całkowicie zablokowany lub zablokowany w danej witrynie, etykiety nie będą wysyłane. Atrybut Partitioned jest przeznaczony do dalszego użycia po całkowitym wycofaniu plików cookie innych firm, co oznacza, że pliki cookie Partitioned mogą być tworzone, gdy zostaną zablokowane pliki cookie innych firm.

Dostęp do interfejsu API JavaScript DeprecationLabel

Dostęp do wartości Cookie-Deprecation możesz też uzyskać za pomocą interfejsu navigator.cookieDeprecationLabel.getValue() JavaScript API. Zwróci to obietnicę, która kończy się ciągiem znaków zawierającym odpowiednią etykietę grupy. Jeśli na przykład przeglądarka należy do grupy 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 wartość będzie pustym ciągiem znaków, więc 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 zostaną zablokowane całkowicie lub tylko w przypadku danej witryny, interfejs API znowu nie będzie dostępny lub zwróci pusty ciąg znaków.

Podobnie jak w przypadku każdej wartości dostarczanej przez klienta, przed użyciem musisz oczyścić i zweryfikować wartość z nagłówka lub interfejsu JavaScript API.

Wersja demonstracyjna i testowanie

Od Chrome 120 dostępne są flagi umożliwiające lokalnym programistom testowanie żądań i odczytywania etykiet.

Flaga chrome://flags/#tpc-phase-out-facilitated-testing umożliwia włączenie wybranych etykiet testowych. Mają one prefiks fake_, co pozwala odróżnić je od rzeczywistych. Włączenie flagi nie powoduje włączenia przeglądarki do żadnej z grup eksperymentalnych.

Działanie etykiet możesz sprawdzić na stronie goo.gle/cft-demo.

Ponieważ rejestracja w przypadku interfejsów API trafności i pomiarów Piaskownicy prywatności jest egzekwowana, może być konieczne zastąpienie egzekwowania zasad w przypadku testów lokalnych. W tym celu należy użyć parametru chrome://flags/#privacy-sandbox-enrollment-overrides i podać źródło wersji demonstracyjnej. Jeśli korzystasz z Chrome z terminala, możesz też dodać tę flagę wiersza poleceń: --args --disable-features=EnforcePrivacySandboxAttestations

chrome://flags/#tpc-phase-out-facilitated-testing

Menu flag zawiera wiele opcji. Testerzy będą przede wszystkim zainteresowani wpisami oznaczonymi jako „Force”, bo zapewniają one, że zachowanie eksperymentu jest włączone niezależnie od innych konfiguracji urządzenia.

Aby przetestować tylko etykiety grupy eksperymentu, wybierz „Włączono kontrolę wymuszoną 1” lub „Włączono tylko wymuszenie etykiety”. Spowodowałoby to wysłanie przez przeglądarkę etykiety „fake_control_1.1” lub „fake_label_only_1.1”.

W Chrome M120 i nowszych możesz też używać tych wpisów:

Aby przetestować blokowanie plików cookie innych firm, wybierz „Włączono wymuszanie traktowania”. Spowoduje to wysłanie etykiety grupy eksperymentalnej „fake_treatment_1.1”, a także zmianę strony ustawień plików cookie i bieżącego ustawienia plików cookie, aby blokować pliki cookie innych firm.

Aby przetestować blokowanie plików cookie innych firm bez interfejsów API reklam prywatnych, wybierz „Force Control 2”. Spowoduje to wysłanie etykiety grupy eksperymentalnej „fake_control_2”, zaktualizowanie strony ustawień plików cookie, zablokowanie plików cookie innych firm oraz wyłączenie nowych interfejsów API reklam prywatnych.

Zwróć uwagę, że obecnie w przeglądarce występuje problem, który powoduje, że w przeglądarce pozostaje nowa strona ustawiania plików cookie i ustawienie blokujące pliki cookie innych firm, nawet jeśli wyłączysz flagę. Pracujemy nad rozwiązaniem tego problemu, a tymczasem możesz przetestować te wartości flag w osobnym katalogu danych Chrome, uruchamiając Chrome z flagą wiersza poleceń --user-data-dir=<new dir>.

Prześlij opinię

Do zarządzania pytaniami używamy etykiety „chrome-testing” w repozytorium pomocy dla programistów na GitHubie. Czekamy na opinie i dyskusje dotyczące początkowych pytań:

Możesz też promować nowe pytania lub dyskusje w repozytorium, korzystając z szablonu „Testy obsługiwane przez Chrome”.