Co dokładnie zmienia się w nowej wersji

Mechanizm trybu uzyskiwania zgody, który Google od listopada 2023 nazywa Consent Mode v2, sam w sobie nie jest nowy — istnieje od kilku lat i polega na tym, że tagi Google dostają informację o decyzji użytkownika i dostosowują do niej swoje zachowanie. Nowością są dwa dodatkowe sygnały: ad_user_data (czy wolno wysyłać dane osobowe do Google w celach reklamowych) oraz ad_personalization (czy wolno wykorzystywać je do personalizacji i remarketingu).

Do tej pory wystarczały cztery stany, z których w praktyce liczyły się dwa: ad_storage i analytics_storage. Teraz kompletny zestaw ma sześć pozycji i brak tych dwóch nowych oznacza, że wdrożenie jest niepełne — nawet jeśli technicznie działa.

Powód jest regulacyjny, nie produktowy. Google jako podmiot objęty aktem o rynkach cyfrowych musi mieć udokumentowaną podstawę do przetwarzania danych użytkowników z Europejskiego Obszaru Gospodarczego i Wielkiej Brytanii. Od 6 marca 2024 konta, które nie przekazują nowych sygnałów, przestaną zasilać listy odbiorców danymi z tego regionu i stracą dostęp do modelowania konwersji.

Kolejność jest więc prosta: to nie zadanie „do zrobienia przy okazji”, tylko rzecz, którą kończymy w lutym, żeby mieć tydzień lub dwa na sprawdzenie efektu w raportach.

Wybór i konfiguracja banera zgody

Pierwsza decyzja dotyczy platformy zarządzania zgodami. Sprawdzam trzy rzeczy przed wyborem.

• Czy narzędzie obsługuje już nowe sygnały — większość dostawców wypuściła aktualizacje na przełomie roku, ale w wielu wdrożeniach na stronie siedzi stara wersja skryptu i trzeba ją podnieść ręcznie.

• Czy jest na liście platform certyfikowanych przez Google — dla wydawców korzystających z produktów wydawniczych Google certyfikacja stała się warunkiem obowiązkowym już w styczniu, a dla reklamodawcy jest po prostu dobrą przesłanką, że dostawca nadąża za zmianami.

• Czy potrafi rozpoznać region — jeśli obsługujesz też rynki poza Europą, chcesz mieć możliwość ustawienia innych stanów domyślnych dla różnych krajów.

Po stronie konfiguracji samego banera pilnuję jednej rzeczy: kategorie zgód w narzędziu muszą być poprawnie zmapowane na sygnały Google. Zgoda marketingowa powinna odpowiadać za ad_storage, ad_user_data i ad_personalization, zgoda statystyczna za analytics_storage. Domyślne mapowanie u części dostawców pomija nowe pozycje i to jest pierwszy punkt, który weryfikuję po aktualizacji skryptu.

Consent Initialization i stany domyślne

Tu wdrożenia sypią się najczęściej, bo problem jest niewidoczny — wszystko wygląda dobrze, a sygnał leci za późno.

W Tag Managerze istnieje osobny typ reguły: Inicjacja zgody — wszystkie strony. Ta reguła uruchamia się przed regułą „Wszystkie strony” i to jest jedyne miejsce, w którym wolno ustawiać stany domyślne. Jeśli tag ustawiający domyślną odmowę odpali się na zwykłym widoku strony, część tagów Google zdąży już wystartować bez informacji o zgodzie.

Stan domyślny dla ruchu z Europy ustawiam na odmowę wszystkich sygnałów poza bezpieczeństwem. Do tego dwa parametry, o których łatwo zapomnieć: wait_for_update daje banerowi kilkaset milisekund na przekazanie zapisanej wcześniej decyzji, a ads_data_redaction usuwa identyfikatory z żądań reklamowych przy braku zgody. Przydaje się też przekazywanie identyfikatora kliknięcia w adresie URL, jeśli konwersje mają być mierzone bez ciasteczek.

Większość dostawców banerów udostępnia gotowy szablon w galerii Tag Managera, który robi to za nas. Nie zwalnia to z obowiązku sprawdzenia, czy szablon jest przypisany do właściwej reguły i czy w jego ustawieniach zaznaczone są wszystkie sześć sygnałów.

Aktualizacja zgody po decyzji użytkownika

Drugi element to wywołanie aktualizujące stan po kliknięciu w banerze. Robi to skrypt platformy zgód, a moim zadaniem jest sprawdzić, czy faktycznie robi to poprawnie.

Interesują mnie dwie sytuacje. Kiedy użytkownik akceptuje wszystko, stany powinny zmienić się na zgodę i tagi wstrzymane wcześniej muszą wystartować — same, bez odświeżania strony. Kiedy użytkownik odrzuca, stany zostają na odmowie, a tagi Google wysyłają wyłącznie żądania pozbawione identyfikatorów.

Trzecia, rzadziej sprawdzana: użytkownik, który zdecydował wcześniej i wraca na stronę. Wtedy baner nie powinien się pokazać, a zapisana decyzja musi zostać odtworzona przed pierwszym tagiem. Właśnie na tym etapie widzę najwięcej wdrożeń, w których zgoda działa tylko dla pierwszej sesji.

Jeśli baner zamiast standardowego wywołania publikuje własne zdarzenie do warstwy danych, trzeba dodatkowo upewnić się, że nazwa zdarzenia zgadza się z tym, na co nasłuchuje reguła w kontenerze. Literówka w nazwie zdarzenia to najtańszy w naprawie i najtrudniejszy do zauważenia błąd w całym wdrożeniu.

Ustawienia zgody na poziomie tagów

Tagi Google — Google Ads, GA4, tag Google — mają wbudowane sprawdzanie zgody i respektują stany bez dodatkowej konfiguracji. Dlatego nie blokuję ich regułami wyjątków, bo wtedy tracę sens całego mechanizmu: przy odmowie nie polecą nawet żądania bez identyfikatorów, a bez nich nie ma modelowania.

Inaczej jest z tagami, które nie należą do Google. Piksel serwisu społecznościowego, narzędzie do nagrywania sesji, skrypt afiliacyjny — dla nich w Tag Managerze w zakładce ustawień zgody trzeba jawnie wskazać, że tag wymaga dodatkowej zgody. Dopóki tego nie zrobisz, kontener uruchomi je niezależnie od decyzji użytkownika.

Warto też przejrzeć stronę pod kątem tagów wpisanych na sztywno w szablon albo dodanych przez wtyczkę. Kod Google Ads zaszyty bezpośrednio w motywie sklepu nie wie nic o kontenerze i wywołaniach zgody, więc będzie omijał cały mechanizm. Takie znaleziska przenoszę do kontenera albo usuwam.

Jak sprawdzić, że to faktycznie działa

Nie kończę wdrożenia na publikacji kontenera. Weryfikacja zajmuje kwadrans i zamyka temat na dobre.

Zaczynam od trybu podglądu w Tag Managerze, gdzie widać stan wszystkich sygnałów w każdym kroku — przed decyzją, po akceptacji i po odrzuceniu. Potem podglądam żądania w narzędziach programisty przeglądarki: w wywołaniach do Google jest parametr opisujący stan zgody i po jego wartości od razu widać, czy zmiana została przekazana.

Trzeci krok to test w trybie prywatnym, w którym symuluję trzy scenariusze: akceptację, odrzucenie i brak jakiejkolwiek reakcji. Odrzucenie sprawdzam zawsze, bo to ścieżka, której nikt nie testuje, a właśnie w niej wychodzą błędy mapowania kategorii.

Na koniec zaglądam do diagnostyki tagu w Google Ads i do ustawień strumienia danych w Analytics — informacja o odbieranych zgodach pojawia się tam z opóźnieniem, ale to jedyne potwierdzenie, że sygnał dociera po stronie Google, a nie tylko wychodzi z przeglądarki.

Błędy, które widzę najczęściej

Zbiorczo, w kolejności od najkosztowniejszych.

• Stan domyślny ustawiony na zgodę, żeby „nie tracić danych”. To wdrożenie pozorne — dane zbierane są bez podstawy, a przy audycie nie ma czego obronić.

• Aktualizacja tylko dwóch starych sygnałów. Baner został podniesiony, ale mapowanie nowych pozycji nie zostało dodane i po marcu konto zachowa się tak, jakby zgód nie było.

• Tag ustawiający stany domyślne na zwykłej regule strony zamiast na inicjacji zgody. Klasyczny wyścig, który daje różne wyniki w zależności od szybkości łącza.

• Blokowanie tagów Google wyjątkami — najczęściej pozostałość po starszym wdrożeniu, w którym baner po prostu wstrzymywał wszystko.

• Brak testu ścieżki odmowy. Sprawdzone tylko „akceptuję wszystko”, więc połowa mechanizmu nigdy nie została uruchomiona.

Jeśli miałbym wskazać jedną rzecz do zrobienia jutro, to nie byłaby to zmiana w kontenerze, a rozmowa z osobą odpowiedzialną za baner: która wersja skryptu jest wgrana i czy dostawca opublikował już aktualizację. Bez tego reszta pracy nie ma na czym stanąć.