CookiePilot i Google Tag Manager

Sekcja Installation → Google Tag Manager w aplikacji nie jest zwykłym blokiem kodu do skopiowania. Backend generuje trzy warianty instalacji dla twojej domeny: directSnippet (instalacja bezpośrednia — asynchroniczny cookiepilot.js z atrybutem data-cpkey), stubSnippet (sam synchroniczny stub Consent Mode do wklejenia w head) oraz gtmSnippet do tagu Custom HTML w GTM.

Wariant GTM łączy stub z dynamicznym doładowaniem głównego skryptu: najpierw synchronicznie ustawia default consent, a potem przez createElement dokłada cookiepilot.js z kluczem domeny przekazanym w parametrze ?cpkey=. Klucz w formacie cp_live_… jest z założenia publiczny — identyfikuje tylko domenę i służy do pobrania konfiguracji banera.

To jest ważne, bo GTM potrafi odpalić tagi bardzo wcześnie. CookiePilot nie powinien być kolejnym późnym tagiem marketingowym, tylko pierwszą warstwą decyzyjną dla zgody — dlatego tag zawsze wpinamy na trigger Consent Initialization – All Pages.

Stub wykonuje się synchronicznie jako pierwszy skrypt. Tworzy window.dataLayer, definiuje window.gtag i ustawia default consent dla wszystkich siedmiu sygnałów Consent Mode v2: wszystko na denied z wyjątkiem security_storage (granted), z wait_for_update: 500 ms. Ma też zabezpieczenie przed podwójnym ustawieniem default, gdyby na stronie działał już inny fragment stubu.

Jeżeli użytkownik wraca z zapisaną zgodą, stub odczytuje cookie cookiepilot_consent i natychmiast wykonuje consent update — zanim jakikolwiek tag Google odczyta stan zgody. Mapowanie kategorii jest stałe w całym produkcie: analytics → analytics_storage; marketing → ad_storage, ad_user_data i ad_personalization; preferences → functionality_storage i personalization_storage.

Samo cookie przechowuje decyzję jako JSON z polem wersji polityki (v). Gdy w panelu podbijesz consentVersion, widget uzna wcześniejsze zgody za nieaktualne i zapyta użytkowników ponownie — to mechanizm na istotne zmiany polityki cookies.

CookiePilot ma też własny szablon tagu GTM (Community Template „CookiePilot CMP”): wklejasz klucz domeny w pole formularza, ustawiasz trigger Consent Initialization – All Pages i publikujesz kontener — bez ręcznego kopiowania kodu. Pole klucza waliduje format cp_live_… jeszcze przed zapisem tagu.

Szablon deklaruje dokładnie trzy uprawnienia sandboxa GTM i nic ponadto: dostęp do stanu zgody (7 sygnałów Consent Mode), odczyt jednego cookie cookiepilot_consent oraz wstrzykiwanie skryptu wyłącznie z https://cdn.cookiepilot.io. Nie wysyła żadnych beaconów i nie czyta innych danych — to dokładnie to, co administrator GTM zatwierdza przy imporcie.

W pliku szablonu są wbudowane cztery testy jednostkowe (m.in. scenariusz z uszkodzonym cookie), które można uruchomić w edytorze szablonów GTM przyciskiem Run all tests.

Tagi Google powinny czytać Consent Mode v2: analytics_storage dla GA4 oraz ad_storage, ad_user_data i ad_personalization dla Google Ads. CookiePilot ustawia te wartości na denied przed zgodą i aktualizuje je po decyzji użytkownika.

Meta Pixel, TikTok, Hotjar, Klaviyo i podobne tagi zwykle nie respektują wystarczająco Google Consent Mode. Dla nich CookiePilot publikuje dataLayer event cookiepilot_consent_update z obiektem cookiepilot_consent. W GTM budujesz Custom Event Trigger z warunkiem na marketing, analytics albo preferences. Event jest emitowany nie tylko przy decyzji — także przy każdej odsłonie dla powracającego użytkownika, więc triggery działają na każdej stronie.

Jeżeli jakiś tracker jest wklejony poza GTM bezpośrednio w motywie, GTM go nie zatrzyma. Wtedy trzeba usunąć duplikat albo uruchamiać go po natywnym zdarzeniu cookiepilot:consent (CustomEvent z pełnym obiektem zgody w e.detail).

Najwcześniejszy hook GTM — Consent Initialization — i tak wykonuje się dopiero po sparsowaniu HTML. Trackery wpisane na sztywno w kod strony wykonają się przed każdym tagiem GTM i żaden CMP oparty wyłącznie o GTM ich nie cofnie. Jeżeli masz takie skrypty, wybierz instalację bezpośrednią w head albo wtyczkę WordPress.

Instalacja natywna ma jeszcze dwie zalety: pełne pokrycie autoblokowania (skrypt jest pierwszy w head) i odporność na adblockery, które potrafią blokować sam kontener GTM — banner zgody wtedy dalej działa. Z kolei GTM wygrywa, gdy wszystkie tagi już przechodzą przez kontener i zespół zarządza nimi centralnie.

Dla sklepów i stron na WordPressie najprostsza jest wtyczka z oficjalnego katalogu WordPress.org — sama wstrzykuje stub we właściwej kolejności, wykrywa WooCommerce i dodaje checklistę „no trackers before consent”. Pamiętaj: wybierz jedną metodę instalacji dla domeny — szablon GTM i instalacja natywna wykluczają się wzajemnie, żeby default consent ustawiał się dokładnie raz.

Testuj w oknie incognito i w trybie Preview GTM. Przed zgodą: brak cookies _ga, _gid, _fbp, _gcl_* i IDE; brak żądań do google-analytics.com/g/collect, doubleclick.net, googleadservices.com i facebook.com/tr; w dataLayer wpis consent default z wait_for_update: 500, a zakładka Consent w Preview pokazuje wszystkie nieistotne sygnały jako denied.

Po Zaakceptuj wszystkie: w dataLayer pojawia się consent update z granted oraz event cookiepilot_consent_update, tagi Google startują, a przeglądarka zapisuje cookie cookiepilot_consent. Po Odrzuć wszystkie: sygnały zostają denied, a cookie zapisuje analytics: false, marketing: false, preferences: false. Dla powracającego użytkownika banner nie wraca, a consent update wykonuje się przed tagami.

Typowe problemy: zgoda niezapamiętana po odświeżeniu to zwykle zmieniona nazwa cookie (szablon GTM czyta wyłącznie domyślne cookiepilot_consent); Meta lub TikTok odpalające przed zgodą to tagi spoza Consent Mode — steruj nimi eventem cookiepilot_consent_update albo włącz wymuszanie blokowania; zablokowany injectScript to niemal zawsze adblocker — rozważ instalację natywną.