Consent Mode: co naprawdę robi, a czego nie pilnuje

Consent Mode bywa sprzedawany jako „rozwiązanie tematu zgód”: wdraża się tzw. Cookie Banner, audytor odhacza i temat uznaje się za zamknięty. Tymczasem Consent Mode nie pilnuje zgody - on ją relacjonuje, i to wyłącznie tagom Google, które w zależności od konfiguracji mogą, ale nie muszą respektować informacje o tych zgodach.

W tym poście nieco więcej o anatomii wysyłania informacji (tzw. hit) z odmową oraz ze zgodą, komplet parametrów, po których można poznać stan wdrożenia w jednym query stringu, oraz miejsca, gdzie ten mechanizm kończy się szybciej, niż obiecuje marketing.

Co Consent Mode robi naprawdę

To protokół komunikacji między platformą zarządzania zgodami (CMP), reprezentowaną przez baner, a tagami Google. Baner ustawia sygnały zgody - przede wszystkim analytics_storage i ad_storage, a od wersji v2 także ad_user_data i ad_personalization, a tagi Google dostosowują do nich zachowanie.

Przy odmowie tag przechodzi w tryb bezciasteczkowy:

• nie powstaje ciasteczko _ga (ani żadne inne trwałe ciasteczko Google),

• identyfikator cid losuje się od nowa przy każdym wczytaniu strony - dwie odsłony tej samej osoby są dla Analytics dwoma niepowiązanymi zdarzeniami,

• zamiast pełnego hita wychodzi hit okrojony (ping).

Przy zgodzie tag działa w pełni: trwałe ciasteczko, stały identyfikator, pełne dane, remarketing.

Po stronie mechaniki przeglądarkowej Google zrobiło świetny mechanizm. Odmowa realnie zmienia charakter wysyłki i da się to zobaczyć i zmierzyć.

Czego Consent Mode nie robi

Nie zatrzymuje wysyłki. Ping to nadal żądanie wychodzące z urządzenia - przed zgodą i po odmowie. Nie niesie trwałego numeru, po którym można rozpoznać użytkownika w kolejnych wizytach, ale przekazuje: adres IP, adres oglądanej strony, jej tytuł, rozdzielczość ekranu, język, dane o przeglądarce i systemie. Zatem informacje o wizycie są przekazywane dalej, ale bez możliwości łączenia ich z tymi samymi zestawami danych z kolejnych dni. To pokazuje, że „odmowa” w Consent Mode znaczy „mniej”, a nie „nic”. Google używa wysyłanych pingów do modelowania konwersji, czyli statystycznego uzupełniania danych, których przez odmowy nie widać wprost. Dobrze to działa w przypadku, gdy mamy duży ruch.

Nie steruje niczym poza Google. Narzędzia nagrywające sesje, piksele społecznościowe, systemy remarketingowe, marketing automation … cała reszta ekosystemu o Consent Mode nie wie i wiedzieć nie może. Chyba że narzędzia te są osadzone przez GTM-a i korzystają z triggerów, które przekazują ustawienia użytkownika.

Nie sprawdza, czy baner mówi prawdę. Consent Mode wyłącznie przekazuje tagom taki stan zgody, jaki zgłosi mu baner. Nie weryfikuje, czy użytkownik faktycznie cokolwiek kliknął. Zatem niepoprawne wdrożenie może przekazać zgodę, której nikt nie udzielił, a tagi Google jej użyją i zadziałają w trybie pełnym: z ciasteczkiem, stałym identyfikatorem i gcs=G111 w żądaniach.

Anatomia: hit z odmową vs hit ze zgodą

Wszystko, co zostało opisane wyżej, można zaobserwować w przeglądarce. Kiedy tag Google wysyła dane, robi to przez żądanie na adres kończący się ścieżką /g/collect (analityka) lub /ccm/collect (część reklamowa). Takie pojedyncze żądanie nazywa się hitem, a cała jego zawartość wysyłana jest w adresie, w części po znaku ?, w tzw. query stringu jako parametry zmiennych GET. Nie trzeba nic deszyfrować: to zwykła lista par klucz=wartość.

Żądanie przeglądarki wysłane jest pod ten sam adres - niezależnie od tego, czy była odmowa, czy zgoda. Różnią się wyłącznie wartościami zmiennych, które dostępne są w adresie URL, jaki wysyła przeglądarka. Dlatego gdy chce się przejrzeć szczegóły tej komunikacji, z samej listy żądań w Network przeglądarki nie można odróżnić żądania ze zgodą i bez zgody. Aby to zrobić, trzeba kliknąć żądanie i zajrzeć w parametry (zakładka Payload). Poniżej oba warianty obok siebie, z zaznaczeniem, na co patrzeć:

Dwa żądania na ten sam endpoint /g/collect. Różnice widać w query stringu:

Hit z odmową (poprawne wdrożenie, stan przed decyzją):

POST region1.google-analytics.com/g/collect

tid=G-XXXXXXX gcs=G100 npa=1 pscdl=denied

en=page_view cid=1807194291.1786783862 - to numer wylosowany, jednorazowy

Hit ze zgodą (lub z wdrożeniem, które zgodę zmyśla):

POST region1.google-analytics.com/g/collect

tid=G-XXXXXXX gcs=G111

en=page_view cid=845201573.1699012844 - to numer stały, z ciasteczka _ga

Do tego po stronie reklamowej (/ccm/collect) w hitach z odmową pojawiają się znaczniki ograniczeń: npa=1 (non-personalized ads), ep.ads_data_redaction=1, _tu=CA. W hitach bez ograniczeń - parametr auid (advertiser user ID), czyli identyfikator reklamowy użytkownika.

Parametry zgody, które warto znać

Opisane parametry różnią się wartościami i dostępne są w adresie żądania, w części po znaku ? (query string). W DevTools nie trzeba ich wyłuskiwać ręcznie: wystarczy kliknąć żądanie na liście Network i otworzyć zakładkę Payload. Będą rozbite na listę klucz-wartość.

Parametry, po których poznaje się stan wdrożenia, wszystkie w jednym query stringu.

parametr	wartość	znaczenie
gcs	G100	oba sygnały odmówione; hit bezciasteczkowy
gcs	G111	zgoda udzielona; hit pełny z trwałym identyfikatorem
gcs	brak	Consent Mode niewdrożony; tag działa po staremu, w pełni
gcd	obecny	pełny stan czterech sygnałów v2 (także ad_user_data i ad_personalization) oraz informacja, czy ustawiono default
gcd	brak	wdrożenie starsze niż v2 albo jego brak; sygnałów v2 nie da się zweryfikować
auid	obecny	identyfikator reklamowy użytkownika - występuje tam, gdzie brak sygnału odmowy
npa=1, pscdl=denied, ep.ads_data_redaction=1	obecne	dodatkowe znaczniki ograniczeń po stronie Google

Od Consent Mode v2 obok gcs w hitach pojawia się drugi parametr: gcd. I to on niesie pełną informację, bo gcs opisuje tylko dwa sygnały (ad_storage i analytics_storage), a gcd wszystkie cztery - także ad_user_data i ad_personalization. Wygląda mniej czytelnie, np. gcd=13l3l3l3l1, ale klucz jest prosty: to sekwencja pozycji rozdzielonych cyframi, gdzie każda litera koduje stan jednego sygnału. Litera mówi dwie rzeczy naraz: jaka była decyzja (zgoda/odmowa) oraz skąd pochodzi - z defaultu ustawionego przed decyzją czy z update'u po kliknięciu. Przykładowo l oznacza brak ustawionego sygnału, p - odmowę z defaultu, t - zgodę z update'u.

W praktyce daje to coś, czego gcs nie pokaże: gcd zdradza, czy wdrożenie w ogóle ustawiło default. Jeśli w hicie widać stany wyłącznie z update'u, bez śladu defaultu, to znak, że default startuje za późno albo wcale - a to dokładnie ten błąd, przez który pierwsze hity wychodzą bez ograniczeń. Dlatego przy audycie v2 patrzenie tylko na gcs to patrzenie na połowę obrazka: dwa sygnały z czterech i zero informacji o kolejności zdarzeń.

Zazwyczaj patrzy się na cztery zmienne: gcs + gcd + auid + ciasteczko _ga. Wdrożenie poprawne przed decyzją to gcs=G100, gcd ze stanami z defaultu, brak auid, brak _ga.

Niepoprawne wdrożenie zdradza się zwykle wszystkimi czterema naraz: brak gcs (albo G111 bez kliknięcia), gcd bez śladu defaultu, auid w żądaniach, _ga zapisane przed decyzją. Pojedynczy sygnał bywa mylący, cztery niezależne - już nie.

Uwaga techniczna, na którą warto zwrócić uwagę - kolumna Url w zakładce Network jest ucięta i gcs w niej nie widać w sposób jawny. Co gorsza, ucięta ścieżka pagead2.googlesyndication.com/ccm/collect wygląda jak zwykły /collect - można błędnie sklasyfikować pingi jako pełne hity (albo odwrotnie). Należy kliknąć żądanie i czytać pełny query string w szczegółach, a najlepiej pracować na wyeksportowanym pliku HAR.

Plik HAR (HTTP Archive) to zapis wszystkiego, co było w zakładce Network. Plik można wyeksportować i pobrać przez kliknięcie przycisku pobierania (strzałka w dół nad w zakładce Network narzędzie DevTool) - opcja Export HAR„. To różnica między zrzutem ekranu a materiałem źródłowym. Na zrzucie kolumna Url jest ucięta i parametru gcs nie widać, a w pliku HAR jest wszystko. Dlatego zrzut nadaje się do pokazania, a HAR do udowodnienia.

Dwa tryby Consent Mode: podstawowy i zaawansowany

Consent Mode ma dwa tryby i różnica jest fundamentalna:

• Zaawansowany (advanced) - domyślny w większości wdrożeń: tagi Google ładują się zawsze i wysyłają pingi także przy odmowie. To ten tryb opisuję wyżej. Google dostaje sygnał do modelowania, a my otrzymujemy pełniejsze raporty. W tym trybie wysyłane są ograniczone dane użytkownika.

• Podstawowy (basic) - tagi Google w ogóle się nie ładują, dopóki nie ma zgody. Zero żądań przed decyzją, zero pingów po odmowie. Mniej danych do modelowania, za to „odmowa” oznacza dokładnie to, co użytkownik myśli, że znaczy.

Wybór między nimi to decyzja biznesowa. Problem w tym, że w praktyce prawie nikt jej świadomie nie podejmuje: zostaje tryb zaawansowany, bo taki wychodzi z domyślnej konfiguracji.

Jak poprawnie użyć Consent Mode w GTM

• Domyślny stan przed czymkolwiek - CMP (lub szablon zgody w GTM) musi ustawić default ze stanem „denied” na etapie Consent Initialization, zanim wystartuje jakikolwiek tag. Jeśli default ustawia się za późno, pierwsze hity wychodzą bez ograniczeń.

• Aktualizacja po decyzji - kliknięcie na banerze wywołuje update z nowym stanem. Sprawdzić to należy w obie strony: po akceptacji gcs w kolejnych hitach ma się zmienić na G111. Jeśli zostaje G100 mimo zgody, to oznacza, że sygnał nie dochodzi i zgoda też nie działa. Analogicznie z wycofaniem zgody.

• Consent Settings dla tagów spoza Google - narzędzia nagrywające, piksele społecznościowe, marketing automation należy wpinać w GTM przez „Require additional consent” z odpowiednim sygnałem. To jedyne miejsce, jakie mamy w Google Tag Managerze, i jeśli tego nie użyjemy, tagi z usługami zewnętrznymi będą uruchamiane bez względu na decyzje użytkownika.

Warto wspomnieć, aby po każdej zmianie banera lub CMP sprawdzić gcs w obu stanach - przed decyzją i po odmowie. Jedno spojrzenie w query string mówi o wdrożeniu więcej niż niejeden raport zgodności ;)