Jak sprawdzić w GA4, czy sygnały zgody (ad_user_data, ad_personalization) są prawidłowo przesyłane?

Weryfikacja w przeglądarce, nie na słowo

Baner wejsciowyParallax

Jak sprawdzić w GA4, czy sygnały zgody (ad_user_data, ad_personalization) są prawidłowo przesyłane?

Weryfikacja w przeglądarce, nie na słowo

Autor nie posiada zdjęcia
Tomasz Piasecki
28 lutego 2024

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ć.

Cztery sygnały i to, który z nich jest nowy

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.

Żądanie do GA4 w narzędziach przeglądarki

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ą.

Menedżer tagów: przegląd zgód i tryb podglądu

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.

Asystent tagów i podgląd po stronie Google

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.

Czego szukam w samym GA4

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ą.

Błędy, na które trafiam najczęściej

Zebrałem je w jedną listę, bo powtarzają się na kontach niezależnie od branży i wielkości.

  • Brak stanu domyślnego — banner wysyła aktualizację zgody, ale nikt nie ustawił stanu wyjściowego, więc pierwsze trafienia lecą bez żadnej informacji.
  • Banner ładowany asynchronicznie po tagach — działa, ale z opóźnieniem, i przy szybkim kliknięciu użytkownika kolejność zdarzeń bywa odwrotna niż zaplanowana.
  • Zgoda zapisana w ciasteczku, ale nieprzekazywana przy kolejnych wizytach — pierwsza sesja wygląda dobrze, druga już nie. Dlatego testuję zawsze także powracającą wizytę.
  • Tag Google Ads wstawiony bezpośrednio w kodzie strony, obok kontenera Menedżera tagów. Konfiguracja zgody w kontenerze go nie obejmuje.
  • Testowanie na własnej przeglądarce z zapisaną wcześniej zgodą — najprostsza droga do fałszywie pozytywnego wyniku.

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ś.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.