Tester plików cookie i Consent Mode

Ten tester pokazuje, co strona robi przed jakąkolwiek zgodą: jakie ciasteczka ustawia jej serwer w nagłówkach HTTP, jakie skrypty tagujące i banery zgody znajdują się w kodzie oraz jak skonfigurowany jest Google Consent Mode. Zaczynamy od ograniczenia, bo bez niego wynik można odczytać opacznie: narzędzie nie wykonuje JavaScriptu, więc nie widzi ciasteczek zakładanych skryptem, a tak zakładana jest większość ciasteczek analitycznych i reklamowych. To nie jest audyt ani ocena prawna.

Podaj adres strony. Sprawdzimy, co jej serwer ustawia w nagłówkach HTTP przed jakąkolwiek zgodą, jakie skrypty tagujące i banery zgody są w kodzie oraz jak skonfigurowany jest Google Consent Mode.

Co ten test sprawdza, a czego nie zobaczy

Narzędzie pobiera stronę tak, jak zrobiłby to prosty klient HTTP: wysyła jedno żądanie i czyta odpowiedź. Dzięki temu widzi dwie rzeczy w pełni: nagłówki odpowiedzi, w tym każdy Set-Cookie, oraz surowy kod HTML w takiej postaci, w jakiej wyszedł z serwera.

Nie widzi natomiast wszystkiego, co dzieje się po uruchomieniu skryptów. Ciasteczka takie jak _ga, _gid, _fbp czy _gcl_* zakłada JavaScript, więc w tym raporcie ich nie będzie, choć strona może je zakładać. Tak samo niewidoczne są skrypty tagujące i banery zgody wstrzykiwane dynamicznie - duże serwisy często ładują je własnym kodem, a nie znacznikiem w kodzie strony.

Dlatego pusty wynik w którejkolwiek sekcji znaczy „nie znaleźliśmy tego w tym, co widzimy”, a nie „tego nie ma”. Rzetelny inwentarz ciasteczek wymaga narzędzi w przeglądarce, na przykład zakładki aplikacji w narzędziach dla programistów, oraz porównania stanu przed i po kliknięciu w baner. Ten test jest szybkim pierwszym krokiem, nie zamiennikiem takiego przeglądu.

Jest jednak warstwa, którą bez przeglądarki da się zmierzyć rzetelnie, i ona jest tu najważniejsza: konfiguracja Consent Mode zapisana w kodzie strony.

Google Consent Mode v2: co musi być ustawione

Consent Mode to sposób przekazywania tagom Google informacji o tym, na co użytkownik się zgodził. Wersja druga obowiązuje od 6 marca 2024 roku dla reklamodawców kierujących działania do Europejskiego Obszaru Gospodarczego i dodała do wcześniejszych sygnałów dwa nowe: ad_user_data oraz ad_personalization. Bez nich Google nie otrzymuje kompletu informacji potrzebnych do pomiaru, personalizacji reklam i remarketingu.

Test sprawdza cztery rzeczy naraz. Po pierwsze, czy w kodzie strony jest wywołanie ustawiające domyślny stan zgody. Po drugie, jakie sygnały zostały w nim ustawione i na jaką wartość - pokazujemy je dosłownie, bez interpretacji. Po trzecie, czy obecne są oba sygnały wersji drugiej; brak choćby jednego oznacza wdrożenie w kształcie sprzed marca 2024. Po czwarte, czy domyślna zgoda została ustawiona przed konfiguracją tagu.

Ta czwarta rzecz jest najczęściej przeoczana. Tag, który wystartuje wcześniej, działa jeszcze bez żadnych ograniczeń, więc pierwsze żądania wychodzą tak, jakby zgody nie było. Sama obecność poprawnego wywołania nic nie daje, jeśli stoi ono za konfiguracją tagu.

Jeśli Consent Mode jest wdrożony szablonem w kontenerze Google Tag Managera, w kodzie strony go nie będzie. Narzędzie napisze wtedy, że ustawienie jest niewidoczne i trzeba je sprawdzić w panelu GTM. Nie napisze, że go nie ma, bo tego nie zmierzyliśmy.

Poprawna kolejność w kodzie wygląda tak, jak niżej. Najpierw domyślny stan zgody z kompletem sygnałów, dopiero potem konfiguracja tagu. Wartość wait_for_update mówi, ile milisekund tagi mają czekać na aktualizację zgody z banera, zanim zaczną działać w trybie ograniczonym.

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  functionality_storage: 'granted',
  security_storage: 'granted',
  wait_for_update: 500
});
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');

Dwa sygnały z tej listy warto omówić osobno. functionality_storage odpowiada za pamięć potrzebną do działania strony, na przykład zapamiętanie wybranego języka, a security_storage za mechanizmy bezpieczeństwa, takie jak ochrona przed nadużyciami. Oba zwykle ustawia się na przyzwolenie, bo dotyczą funkcji, bez których strona przestaje działać poprawnie, a nie profilowania.

Ciasteczka przed zgodą: co widać w nagłówkach HTTP

Ciasteczka ustawiane przez serwer przychodzą w nagłówku Set-Cookie pierwszej odpowiedzi, czyli przed jakąkolwiek interakcją z banerem. Dla każdego pokazujemy nazwę, retencję, zakres oraz flagi bezpieczeństwa. Samej wartości nie pokazujemy celowo - bywa identyfikatorem sesji osoby, która akurat weszła na badaną stronę, a narzędzie diagnostyczne nie ma powodu jej wyświetlać.

Retencja to najczęściej pomijana informacja. Ciasteczko z terminem ważności liczonym w latach zostaje na urządzeniu bardzo długo, a przy ciasteczkach analitycznych rzadko jest to potrzebne. Podajemy ją w jednostce dopasowanej do rzędu wielkości: dziesięć minut zobaczysz jako minuty, a nie jako zaokrąglone zero dni.

Zakres mówi, czy ciasteczko należy do domeny badanej strony, czy do innej. Flagi to Secure (wysyłane tylko po HTTPS), HttpOnly (niedostępne dla skryptów, co utrudnia kradzież sesji) oraz SameSite, który decyduje o wysyłaniu ciasteczka przy żądaniach z innych witryn. Brak SameSite nie jest sam w sobie usterką, ale warto wiedzieć, że tak jest.

Kolejność ładowania: baner zgody przed tagami

Jeśli rozpoznamy baner zgody, sprawdzamy dodatkowo, czy jego skrypt stoi w dokumencie przed pierwszym skryptem tagującym. Odwrotna kolejność to częsty i łatwy do przeoczenia błąd wdrożenia: przeglądarka wczytuje dokument od góry, więc tag umieszczony wyżej może zdążyć się uruchomić, zanim baner w ogóle ustali, na co użytkownik się zgadza.

Rozpoznajemy sygnatury kilkunastu popularnych rozwiązań. Baner autorski albo wstrzykiwany skryptem nie zostanie wykryty, dlatego w takim wypadku narzędzie mówi „nie rozpoznaliśmy”, a nie „nie ma”. Ta różnica jest istotna: pierwsze zdanie opisuje granicę naszego pomiaru, drugie byłoby twierdzeniem o cudzej stronie, którego nie sprawdziliśmy.

Najczęstsze błędy wdrożeń

  • Domyślna zgoda ustawiona po konfiguracji tagu - wdrożenie wygląda kompletnie, a pierwsze żądania i tak wychodzą bez ograniczeń.
  • Brak sygnałów wersji drugiej - konfiguracja z samym ad_storage i analytics_storage pochodzi sprzed marca 2024 i nie przekazuje pełnej informacji.
  • Domyślny stan ustawiony na przyzwolenie - technicznie to poprawne wywołanie, ale w praktyce oznacza, że domyślnie zgoda jest udzielona, co przy odbiorcach z Europejskiego Obszaru Gospodarczego zwykle nie jest tym, czego wdrożenie miało dotyczyć.
  • Baner wczytywany po tagach - patrz sekcja wyżej.
  • Ciasteczka analityczne z retencją liczoną w latach - rzadko potrzebna, a długo zostaje na urządzeniu.
  • Brak Secure przy ciasteczku na stronie HTTPS - drobiazg, który łatwo poprawić i który widać w tym raporcie od razu.

Czego to narzędzie nie robi

  • Nie uruchamia strony w przeglądarce i nie klika w baner, więc nie sprawdza, co dzieje się po wyrażeniu albo odrzuceniu zgody.
  • Nie wystawia oceny prawnej. Nie znajdziesz tu werdyktu ani punktacji dla całej strony, bo na podstawie tego, co widzimy, taki werdykt byłby nieuczciwy.
  • Nie generuje polityki prywatności ani treści banera.
  • Nie przechowuje wyników dłużej niż przez krótki czas pamięci podręcznej, potrzebny po to, żeby powtórzone sprawdzenie tego samego adresu nie obciążało cudzego serwera.
  • Nie sprawdza podstron. Badamy dokładnie ten adres, który podasz, i pokazujemy adres końcowy, jeśli po drodze wystąpiło przekierowanie.

Co zrobić z wynikiem

Wynik jest punktem wyjścia do trzech konkretnych czynności, w tej kolejności. Pierwsza: jeśli domyślna zgoda stoi po konfiguracji tagu albo brakuje sygnałów wersji drugiej, popraw to w pierwszej kolejności, bo od tego zależy, czy pozostałe ustawienia mają jakiekolwiek znaczenie. Jeśli wdrożenie idzie przez Google Tag Managera, zmiana jest w kontenerze, nie w kodzie strony.

Druga: przejrzyj listę ciasteczek z nagłówków i zapytaj o każde, czy jest potrzebne przed zgodą i czy jego retencja ma uzasadnienie. Ciasteczko sesyjne serwera aplikacji zwykle ma, dwuletnie ciasteczko analityczne zwykle nie. Trzecia: otwórz stronę w przeglądarce, w narzędziach dla programistów wejdź w zakładkę z ciasteczkami i porównaj stan przed kliknięciem w baner oraz po odrzuceniu zgody. To jedyny sposób, żeby zobaczyć warstwę, której ten test nie widzi, i zajmuje kilka minut.

Jeśli sprawdzasz stronę pod kątem samego pomiaru, a nie ustawień zgody, przyda się też sprawdzenie, czy w ogóle wpuszczasz roboty tam, gdzie zamierzasz. Do tego mamy tester pliku robots.txt, a do znaczników udostępniania w mediach społecznościowych debugger Open Graph.

Najczęściej zadawane pytania

Czy ten test wykryje wszystkie ciasteczka na mojej stronie?

Nie. Narzędzie pobiera stronę z serwera i nie wykonuje JavaScriptu, więc widzi wyłącznie ciasteczka ustawiane nagłówkami HTTP. Ciasteczka zakładane skryptem, czyli większość analitycznych i reklamowych, pozostają dla niego niewidoczne. Pełny inwentarz wymaga narzędzi w przeglądarce.

Czym jest Google Consent Mode w wersji 2?

To sposób przekazywania tagom Google informacji o zgodzie użytkownika. Wersja druga, obowiązująca od marca 2024 roku, dodała dwa sygnały do wcześniejszych: ad_user_data oraz ad_personalization. Wdrożenie, w którym tych dwóch sygnałów nie ma, pochodzi sprzed tej zmiany.

Dlaczego domyślna zgoda musi być ustawiona przed konfiguracją tagu?

Ponieważ tag, który wystartuje wcześniej, działa jeszcze bez żadnych ograniczeń. Wywołanie ustawiające domyślny stan zgody musi więc znaleźć się w kodzie przed wywołaniem konfigurującym tag, inaczej pierwsze żądania wychodzą tak, jakby zgody nie było.

Co znaczy wynik „nie rozpoznaliśmy banera zgody”?

Że wśród sygnatur kilkunastu popularnych rozwiązań nie znaleźliśmy żadnej. Baner autorski albo wstrzykiwany skryptem nie zostanie tu wykryty, więc taki wynik nie oznacza, że strona banera nie ma.