Consent Mode v2: obowiązek, działanie i wdrożenie

Najpierw krótkie tło: Od marca 2024 Google wymaga Consent Mode v2 od wszystkich reklamodawców docierających do użytkowników w Europejskim Obszarze Gospodarczym – bez niego remarketing i reklama spersonalizowana po prostu przestają tam działać. Mimo to w audytach regularnie widzę wdrożenia, w których baner cookie wygląda elegancko, ale sygnały zgody nigdy nie docierają do Google – albo docierają dopiero wtedy, gdy tagi dawno już odpaliły. Ten przewodnik wyjaśnia, co dokładnie robi Consent Mode v2, czym uczciwie różnią się tryby Basic i Advanced oraz jak czysto zbudować i zweryfikować wdrożenie przez CMP + Google Tag Managera.

Co to jest Consent Mode v2?

Consent Mode v2 to interfejs Google między Twoim banerem cookie (platformą zarządzania zgodami, czyli CMP) a tagami Google na Twojej stronie. Dla każdego odwiedzającego odpowiada na pytanie: co Google Ads i GA4 mogą zrobić z danymi tego użytkownika?

Odpowiedź wędruje przez cztery sygnały:

| Sygnał | Steruje | W praktyce | |--------|---------|------------| | ad_storage | Odczytem i zapisem cookies reklamowych | Cookies kliknięć do przypisywania konwersji | | analytics_storage | Cookies analitycznymi | Cookies sesji i użytkownika w GA4 | | ad_user_data | Przesyłaniem danych użytkownika do Google w celach reklamowych | np. dane dla konwersji rozszerzonych | | ad_personalization | Reklamą spersonalizowaną | Listy remarketingowe, podobne grupy odbiorców |

Każdy sygnał może mieć wartość granted (zgoda) lub denied (odmowa). Twój CMP ustawia te wartości automatycznie – w zależności od tego, co użytkownik kliknie w banerze.

Co jest nowego w „v2"? Pierwsze dwa sygnały istnieją od 2020 roku (Consent Mode v1). Wraz z v2 w marcu 2024 doszły ad_user_data i ad_personalization. Tłem jest unijny Digital Markets Act (DMA): Google został uznany za tzw. strażnika dostępu (gatekeepera) i musi wykazać, że dane użytkowników z EOG są wykorzystywane do reklamy wyłącznie za zgodą. Ten obowiązek Google przerzuca technicznie na Ciebie jako reklamodawcę – właśnie przez te sygnały.

Ważne rozróżnienie: Consent Mode nie zastępuje banera cookie – on tłumaczy jego decyzję dla Google. To, czy i jak musisz zbierać zgody, regulują RODO i przepisy ePrivacy niezależnie od tego. Ten artykuł to praktyczna wiedza trackingowa, a nie porada prawna.

Dlaczego Consent Mode v2 jest wymagany od reklamodawców w EOG

Słowo „obowiązek" warto tu doprecyzować: nie istnieje ustawa o nazwie Consent Mode. Ale od marca 2024 Google uzależnił kluczowe funkcje reklamowe w EOG od przekazywania sygnałów v2. Bez poprawnie ustawionych sygnałów, według Google:

• Remarketing przestaje działać: użytkownicy z EOG nie trafiają już na listy remarketingowe. Istniejące listy z czasem się kurczą, bo nie dopływają nowi użytkownicy – Twoje strategie remarketingowe kręcą się na pusto.
• Reklama spersonalizowana jest zablokowana: funkcje odbiorców oparte na danych użytkowników są niedostępne dla ruchu z EOG.
• Pomiar konwersji staje się mniej kompletny: bez sygnałów zgody rezygnujesz z modelowania konwersji, którym Google statystycznie domyka luki pomiarowe po odmowach zgody. Smart Bidding optymalizuje wtedy na mniejszej bazie danych – i podejmuje gorsze decyzje.

Z mojej praktyki: przypadki, w których „remarketing nagle przestał działać" albo konwersje niewytłumaczalnie spadły, zaskakująco często mają tę samą przyczynę – brakujący lub źle podpięty Consent Mode. Jeśli reklamujesz się w EOG, tego tematu nie da się ominąć.

Basic vs. Advanced: uczciwe porównanie

Consent Mode v2 występuje w dwóch wariantach, a wybór to prawdziwy kompromis – nie ma jednej „poprawnej" odpowiedzi:

| | Tryb Basic | Tryb Advanced | |---|---|---| | Tagi bez zgody | W ogóle się nie ładują | Ładują się zawsze, ale wysyłają tylko bezcookiesowe pingi | | Dane przy odmowie | Żadne – nawet sygnały anonimowe | Anonimowe pingi (bez cookies, bez identyfikatorów użytkownika) | | Modelowanie konwersji | Tylko na poziomie ogólnym (według Google) | Dokładniejsze, bo bazą są Twoje własne pingi | | Ocena pod kątem ochrony danych | Konserwatywna, łatwa do obrony | Sporna – bezcookiesowe pingi nie są prawnie jednoznacznie rozstrzygnięte | | Złożoność | Niska | Wyższa (trzeba rozumieć i udokumentować zachowanie pingów) |

Tryb Basic to wariant konserwatywny: jeśli użytkownik odmówi, nie dzieje się nic – żadnego tagu, żadnego pinga, żadnych danych. Cena: Google może brakujące konwersje modelować tylko z grubsza, bo od tych użytkowników nie ma żadnych sygnałów.

Tryb Advanced zawsze ładuje tagi, a przy odmowie wysyła bezcookiesowe pingi bez identyfikatorów użytkownika. Na ich podstawie Google modeluje konwersje precyzyjniej. Haczyk: to, czy takie pingi bez zgody są dopuszczalne, jest sporne wśród prawników, a organy nadzorcze nie zajęły jednolitego stanowiska.

Moja szczera rekomendacja z praktyki: tryb Basic to bezpieczny domyślny wybór, z którym rzadko wpadniesz w kłopoty. Advanced może się opłacać, gdy masz wysoki odsetek odmów i zależy Ci na jakości danych dla Smart Biddingu – ale wyłącznie jako świadoma decyzja, uzgodniona z inspektorem ochrony danych lub prawnikiem. Advanced „przez przypadek", bo CMP podpowiada go jako ustawienie domyślne, to najgorsza z możliwych opcji.

Wdrożenie przez CMP + Google Tag Managera

Wymagania wstępne: zainstalowany Google Tag Manager, działające śledzenie konwersji i CMP. Dalej wystarczy pięć kroków:

Krok 1: Wybierz CMP i skonfiguruj baner

Użyj CMP z natywnym wsparciem Consent Mode v2 – najlepiej z programu partnerskiego CMP Google. Popularne opcje to Cookiebot, Usercentrics i Borlabs. Ważne przy konfiguracji banera: odmowa musi być tak samo łatwa jak akceptacja, a kategorie (marketing, statystyka) muszą być czysto zmapowane na sygnały zgody.

Krok 2: Zdefiniuj stan domyślny

Zanim odpali jakikolwiek tag, wszystkie cztery sygnały dla odwiedzających z EOG muszą stać na denied. W większości CMP załatwia to automatycznie integracja szablonu. Ręcznie stan domyślny wygląda tak:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

wait_for_update daje CMP czas (tutaj 500 ms) na wczytanie już zapisanej zgody, zanim odpalą tagi – inaczej powracający użytkownicy z udzieloną zgodą są błędnie liczeni jako odmowy.

Krok 3: Ustaw szablon CMP na „Inicjowanie zgody"

GTM ma dedykowany typ triggera: Inicjowanie zgody – wszystkie strony. Gwarantuje on odpalenie przed wszystkimi innymi triggerami. Dokładnie tam należy podpiąć szablon CMP (lub Twój snippet domyślny) – a nie pod zwykły trigger wyświetlenia strony. To najczęstszy błąd w podpięciu.

Krok 4: Włącz przegląd zgód i sprawdź tagi

W ustawieniach kontenera GTM włącz przegląd zgód (ikona zębatki → „Włącz przegląd zgód"). Zobaczysz tam dla każdego tagu, jakie kontrole zgody są wbudowane. Tagi Google (konwersja Google Ads, GA4) mają kontrole ad_storage i analytics_storage fabrycznie – zwykle nie musisz konfigurować dla nich dodatkowych wymagań zgody. Dla tagów spoza Google (Meta Pixel itp.) dodatkowe wymagania zgody definiujesz ręcznie.

Krok 5: Zweryfikuj zachowanie aktualizacji

Gdy użytkownik kliknie w banerze Akceptuję, CMP musi wysłać consent update:

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'analytics_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});

Przy integracjach szablonowych dzieje się to automatycznie – ale nie polegaj na tym w ciemno, tylko to przetestuj (o tym za chwilę).

Współdziałanie z Enhanced Conversions i śledzeniem server-side

Consent Mode v2 to fundament, na którym opierają się kolejne elementy trackingu – kolejność nie podlega negocjacjom:

1. Najpierw Consent Mode v2: bez czystych sygnałów zgody całej reszcie brakuje fundamentu.
2. Potem Enhanced Conversions: zahaszowane dane first-party mogą płynąć tylko wtedy, gdy ad_user_data stoi na granted. Wdrożenie Enhanced Conversions bez podpiętej zgody to problem z ochroną danych, a nie funkcja.
3. Na końcu server-side: przy server-side taggingu status zgody musi być przekazywany z przeglądarki do Twojego kontenera serwerowego. Server-side to wyraźnie nie jest sposób na obejście zgody – pełne śledzenie po stronie serwera bez zgody to naruszenie, niezależnie od tego, gdzie dane są przetwarzane. Pełny obraz znajdziesz w przewodniku po śledzeniu server-side.

Odwrócenie tej kolejności – najpierw kupić server-side, a zgodę doinstalować kiedyś – to budowanie na piasku. Kompletny fundament techniczny wraz ze strukturą GTM opisuje nasz przewodnik po konfiguracji trackingu.

Typowe błędy przy Consent Mode v2

Błąd 1: Sygnały domyślne odpalają po tagach

Klasyka. CMP ładuje się asynchronicznie gdzieś w kodzie strony, podczas gdy gtag lub GTM już odpaliły. Efekt: pierwsze hity lecą bez statusu zgody – a Google w razie wątpliwości traktuje je jako brak zgody. Rozwiązanie: snippet domyślny lub szablon CMP konsekwentnie na triggerze Inicjowanie zgody.

Błąd 2: Baner bez podpięcia

Baner się wyświetla, użytkownicy pilnie klikają – ale decyzja nigdy nie dociera do Google, bo integracja Consent Mode w CMP nigdy nie została aktywowana. Z zewnątrz wszystko wygląda poprawnie; w Tag Assistant default i update w ogóle nie istnieją. Z mojej praktyki – jedno z najczęstszych znalezisk w audytach.

Błąd 3: Ustawione tylko sygnały v1

Starsze wdrożenia przekazują ad_storage i analytics_storage, ale nie ad_user_data i ad_personalization. Skutek: remarketing dla użytkowników z EOG pada, mimo że „Consent Mode działa". Sprawdź wprost, czy wysyłane są wszystkie cztery sygnały.

Błąd 4: Podwójna logika zgody

Zaszyty na sztywno snippet domyślny w kodzie źródłowym plus szablon CMP w GTM, które wzajemnie się nadpisują. W zależności od kolejności ładowania raz wygrywa jedno, raz drugie – dane stają się nieprzewidywalne. Zdecyduj się na dokładnie jedno miejsce, w którym ustawiana jest zgoda.

Błąd 5: Advanced włączony nieświadomie

Niektóre CMP mają Advanced jako ustawienie domyślne. Jeśli jednak Twoja polityka prywatności i rejestr czynności przetwarzania zakładają Basic, dokumentacja rozjeżdża się z rzeczywistością. Sprawdź to ustawienie świadomie i udokumentuj decyzję.

Błąd 6: Powracający użytkownicy tracą swoją zgodę

Gdy brakuje wait_for_update albo wartość jest zbyt niska, tagi odpalają u powracających odwiedzających, zanim CMP zdąży wczytać zapisaną zgodę. Efekt to niepotrzebnie dużo hitów denied mimo udzielonej zgody.

Weryfikacja w Tag Assistant

Tak zweryfikujesz wdrożenie w około dziesięć minut:

1. Otwórz tagassistant.google.com i podłącz swoją domenę (okno incognito, żeby nie było zapisanej starej zgody)
2. Po wczytaniu strony otwórz po lewej zakładkę Consent: musi istnieć wpis default, w którym wszystkie cztery sygnały stoją na denied – przed pierwszym tagiem Google na liście zdarzeń
3. Kliknij w banerze Akceptuję: teraz musi pojawić się wpis update z wartościami granted
4. Odśwież stronę: zapisana zgoda musi zadziałać przy kolejnym wejściu w oknie wait_for_update
5. Kontrpróba z Odrzuć (nowe okno incognito): sygnały zostają na denied, a w trybie Basic żaden tag Google nie może odpalić
6. Dodatkowo w trybie podglądu GTM sprawdź dla każdego tagu, jaki status zgody obowiązywał w momencie odpalenia

Warto też zajrzeć w Google Ads do Cele → Konwersje → Diagnostyka: Google sygnalizuje tam problemy z sygnałami zgody.

Podsumowanie: najpierw fundament zgód, potem optymalizacja

Consent Mode v2 to nie jest miły dodatek – od marca 2024 to bilet wstępu do remarketingu i wiarygodnych danych o konwersjach w EOG. Najważniejsze punkty:

1. Cztery sygnały, dwa nowe: ad_user_data i ad_personalization stanowią różnicę między v1 a v2
2. Basic vs. Advanced to kompromis: pewność prawna kontra jakość danych – decyduj świadomie, nie zostawiaj tego domyślnym ustawieniom CMP
3. Kolejność rozstrzyga wszystko: sygnały domyślne przed wszystkimi tagami, update po decyzji w banerze
4. Testuj, zamiast mieć nadzieję: dziesięć minut w Tag Assistant wykrywa większość błędów

Jeśli nie chcesz budować tego samodzielnie albo nie masz pewności, czy Twoje obecne wdrożenie jest czysto podpięte: w ramach naszej usługi wdrożenia Consent Mode i banera cookie konfigurujemy całość w stałej cenie – niezależnie od CMP, czy to Cookiebot, Usercentrics, Borlabs czy inny system.

---

FAQ o Consent Mode v2

Czy Consent Mode v2 jest obowiązkowy?

Dla reklamodawców, którzy docierają przez Google Ads do użytkowników w EOG i chcą korzystać z remarketingu, list odbiorców lub reklamy spersonalizowanej: w praktyce tak. Od marca 2024 Google wymaga przekazywania sygnałów zgody ad_user_data i ad_personalization – bez nich użytkownicy z EOG nie trafiają już na listy remarketingowe, a pomiar konwersji staje się mniej kompletny. Nie istnieje jednak ustawa o nazwie Consent Mode: sam obowiązek zbierania zgód wynika z RODO i przepisów ePrivacy, a Consent Mode v2 to techniczny wymóg Google nałożony dodatkowo.

Czym różni się Basic od Advanced Consent Mode?

W trybie Basic tagi Google ładują się dopiero po wyrażeniu zgody – jeśli użytkownik odmówi, Google nie otrzymuje żadnych danych, nawet anonimowych pingów. W trybie Advanced tagi ładują się zawsze, ale bez zgody wysyłają tylko bezcookiesowe pingi, na podstawie których Google modeluje konwersje. Advanced daje więcej danych do modelowania, ale jest sporny pod kątem ochrony danych – tę decyzję najlepiej podjąć razem z inspektorem ochrony danych.

Jak wdrożyć Consent Mode v2 przez Google Tag Managera?

Typowa droga: CMP ze wsparciem Consent Mode (np. Cookiebot, Usercentrics lub Borlabs) ustawia sygnały domyślne na denied, zanim odpali jakikolwiek tag, i aktualizuje je po decyzji w banerze przez consent update. W GTM włączasz przegląd zgód, ustawiasz szablon CMP na trigger Inicjowanie zgody i sprawdzasz wbudowane kontrole zgody dla każdego tagu Google. Na koniec testujesz całość w Tag Assistant.

Co się stanie, jeśli nie wdrożę Consent Mode v2?

Bez sygnałów v2 ad_user_data i ad_personalization nie dodasz już użytkowników z EOG do list remarketingowych ani nie dotrzesz do nich reklamą spersonalizowaną – Twoje grupy odbiorców z czasem się wykruszają. Dodatkowo rezygnujesz z modelowania konwersji: konwersje użytkowników, którzy odmówili zgody, całkowicie znikają z Google Ads, a Smart Bidding optymalizuje na mniejszej bazie danych.

Jak sprawdzić, czy Consent Mode v2 działa poprawnie?

Otwórz tagassistant.google.com, podłącz swoją stronę i zajrzyj do zakładki Consent: przy wczytaniu strony wszystkie cztery sygnały muszą mieć default ustawiony na denied – zanim odpali jakikolwiek tag Google. Po kliknięciu Akceptuję musi pojawić się consent update na granted. Kolejność to punkt krytyczny: jeśli sygnał default pojawia się dopiero po tagach, wdrożenie jest wadliwe. Dodatkowo tryb podglądu GTM pokazuje dla każdego tagu, jaki status zgody obowiązywał w momencie odpalenia.