Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Najczęstsza odpowiedź, jaką dostaję, gdy pytam o wdrożenie nowych sygnałów zgody, brzmi: „dostawca bannera mówi, że jest zrobione”. Bywa, że faktycznie jest. Bywa też, że wtyczka została zaktualizowana, ale nikt nie zaznaczył w niej odpowiedniej opcji, albo że sygnały wychodzą dopiero po przeładowaniu strony, czyli za późno.
Dlatego wdrożenie zgód sprawdzam sam, w przeglądarce, na własnych oczach. Zajmuje to kwadrans i jest to kwadrans, po którym mogę klientowi napisać coś konkretnego, a nie przekazać dalej cudze zapewnienie.
W tekście pokazuję kilka sposobów weryfikacji: od surowego żądania sieciowego, przez narzędzia Google, po to, czego szukam w samym GA4. Kolejność jest celowa — im wcześniejszy etap, tym trudniej go oszukać.
Zanim cokolwiek sprawdzę, muszę wiedzieć, czego szukam.
Tagi Google przyjmują dziś cztery typy zgody istotne dla marketingu. Dwa starsze dotyczą przechowywania danych: reklamowego i analitycznego. Dwa nowsze mówią o tym, co wolno zrobić z danymi już przekazanymi — czy można ich użyć do celów reklamowych i czy można na ich podstawie personalizować reklamy. To właśnie te dwa nowe Google wymaga od 6 marca przy ruchu z Europejskiego Obszaru Gospodarczego i Wielkiej Brytanii, w ramach tego, co nazywa Consent Mode v2.
Kluczowa pułapka: strona może mieć wzorowo wdrożone dwa starsze sygnały i nie wysyłać żadnego z nowych. Z perspektywy raportów GA4 nie zobaczysz różnicy, bo dane nadal spływają. Zobaczysz ją dopiero w Google Ads, po tym jak listy odbiorców przestaną rosnąć.
Dlatego weryfikacja „czy GA4 zbiera dane” nie jest weryfikacją zgód. To dwie różne rzeczy i pierwsza z nich niczego nie potwierdza.
To najbardziej wiarygodny test, bo patrzę na to, co naprawdę opuszcza przeglądarkę.
Otwieram narzędzia dla programistów, zakładkę z ruchem sieciowym, i filtruję żądania frazą collect. Wchodzę na stronę w trybie prywatnym, żeby nie mieć zapisanej wcześniejszej decyzji o zgodzie. Pierwsze żądanie, jakie się pojawi, dotyczy odsłony przed kliknięciem w banner.
W adresie tego żądania szukam dwóch parametrów. Pierwszy, gcs, ma postać litery G, cyfry i dwóch znaków, które opisują tylko dwa starsze typy zgody — sam nic nie powie o nowych sygnałach. Drugi, gcd, to dłuższy zakodowany ciąg, w którym mieszczą się wszystkie cztery typy. Do tego przy ruchu z Europy dochodzą parametry informujące, że stosowane są europejskie wymogi.
Nie próbuję rozszyfrowywać tych ciągów znak po znaku, bo to droga do pomyłki. Robię coś prostszego i skuteczniejszego: zapisuję wartość parametrów z żądania przed kliknięciem w banner, potem akceptuję zgodę, wywołuję kolejną odsłonę i porównuję. Jeżeli gcd po akceptacji wygląda identycznie jak przed, to znaczy, że banner nie aktualizuje stanu zgody i nie ma o czym dyskutować. Ten sam test powtarzam z odmową.
Jeśli tagi są wdrożone przez Menedżera tagów Google, mam do dyspozycji dwa wygodne widoki.
Pierwszy to przegląd zgód w liście tagów. Pokazuje, które tagi zostały skonfigurowane z uwzględnieniem zgody, a które nie mają żadnych ustawień w tym zakresie. Nie jest to dowód, że sygnały wychodzą — to raczej mapa tego, co w kontenerze jest w ogóle świadomie ustawione. Tagi w kolumnie „nieskonfigurowane” to lista rzeczy do przejrzenia.
Drugi to tryb podglądu. Uruchamiam go, wchodzę na stronę i patrzę na stan zgody w kolejnych zdarzeniach: najpierw powinien pojawić się stan domyślny, potem — po kliknięciu w banner — jego aktualizacja. Jeżeli aktualizacja nie przychodzi wcale albo przychodzi po zdarzeniu odsłony, mam konkretną informację dla osoby wdrażającej banner, a nie ogólne „coś nie działa”.
Sprawdzam przy tym jedną rzecz, o którą łatwo się potknąć: czy stan domyślny jest ustawiony dla właściwego regionu i czy nie został przypadkiem ograniczony do jednego kraju.
Trzecie narzędzie to Asystent tagów Google, który łączy się z witryną i pokazuje przechwycone trafienia razem ze stanem zgody dla każdego z nich.
Używam go głównie do dwóch rzeczy. Po pierwsze, do sprawdzenia, czy stan zgody jest spójny między tagiem GA4 a tagiem Google Ads — spotykam wdrożenia, w których jeden z nich respektuje zgodę, a drugi nie, bo dodawał go ktoś inny i w innym czasie. Po drugie, do pokazania efektu klientowi, bo zrzut ekranu z Asystenta jest czytelniejszy niż lista żądań sieciowych.
Uzupełniająco zaglądam do diagnostyki tagu w Google Ads. Widać tam, jaka część ruchu przychodzi z odrzuconą zgodą — a to liczba, którą warto znać przed marcem, bo mówi, jak duża część pomiaru będzie odtąd szacowana.
W interfejsie GA4 nie ma raportu „stan zgód” i szukanie go jest stratą czasu. Są natomiast dwa pośrednie potwierdzenia.
Pierwsze to widok debugowania. Włączam go i przechodzę ścieżkę: odmowa zgody, potem akceptacja. Przy poprawnym wdrożeniu w wariancie rozszerzonym zdarzenia widać w obu przypadkach, ale przy odmowie są pozbawione identyfikatora użytkownika. Jeżeli po odmowie nie widzę niczego, wdrożenie jest w wariancie podstawowym — to nie błąd, tylko inna decyzja, ale trzeba o niej wiedzieć, bo oznacza mniej danych i brak podstawy do modelowania.
Drugie to modelowanie zachowań. Google udostępnia je tylko usługom, które przekazują sygnały zgody i mają odpowiednio duży ruch — w dokumentacji progi liczone są w tysiącach zdarzeń dziennie utrzymywanych przez tydzień. Jeżeli w usłudze pojawia się opcja włączenia modelowania, to mocna przesłanka, że sygnały docierają. Brak tej opcji przy dużym ruchu jest sygnałem ostrzegawczym.
Do tego dochodzi banalny test kontrolny: porównanie liczby użytkowników w GA4 z liczbą sesji w innym niezależnym źródle. Rozjazd rzędu kilkudziesięciu procent po wdrożeniu bannera zwykle oznacza, że tagi w ogóle się nie uruchamiają przed akceptacją.
Zebrałem je w jedną listę, bo powtarzają się na kontach niezależnie od branży i wielkości.
Na koniec rzecz proceduralna: wynik weryfikacji zapisuję z datą i zrzutami ekranu. Za trzy miesiące, gdy ktoś zaktualizuje wtyczkę albo przebuduje stronę, jedyne, co pozwoli szybko ustalić, czy sygnały kiedykolwiek działały, to notatka z dziś.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |