Wdrożenie Google Consent Mode v2 (GCM v2) to od marca 2024 roku konieczność dla wszystkich właścicieli stron korzystających z usług Google, takich jak Analytics czy Ads. Mechanizm ten pozwala na zbieranie danych analitycznych i remarketingowych z poszanowaniem decyzji użytkownika o (nie)udzieleniu zgody na cookies. Wielu administratorów stron WordPress podjęło już próbę implementacji, ale napotkało na problemy. Komunikaty o błędach, brak danych w Google Analytics, niedziałające kampanie reklamowe – to tylko niektóre z frustrujących objawów.
Jeśli trafiłeś na ten artykuł, to prawdopodobnie szukasz odpowiedzi na pytanie: dlaczego Google Consent Mode v2 nie działa na mojej stronie? Spokojnie, nie jesteś sam. Proces wdrożenia, zwłaszcza ręcznego, jest podatny na błędy, które mogą wynikać z wielu czynników – od kolejności ładowania skryptów po konflikty z innymi elementami Twojego WordPressa.
W tym kompleksowym poradniku przeprowadzimy Cię przez proces diagnozowania i rozwiązywania siedmiu najczęstszych problemów z GCM v2. Zamiast ogólnych definicji, skupimy się na konkretnych, praktycznych rozwiązaniach, które pomogą Ci szybko wrócić na właściwe tory. Zaczynajmy!
Jak sprawdzić, czy Consent Mode v2 jest poprawnie wdrożony?
Zanim zaczniemy szukać problemów, musimy mieć pewność, że faktycznie one istnieją. Diagnoza to podstawa. Istnieją dwie główne metody weryfikacji, czy GCM v2 działa prawidłowo na Twojej stronie WordPress.
Metoda 1: Google Tag Assistant
Narzędzie Google Tag Assistant (w trybie podglądu w Google Tag Managerze) to najpewniejszy sposób na sprawdzenie statusu zgód. Po uruchomieniu debugowania dla swojej witryny, zwróć uwagę na zakładkę „Consent” w interfejsie Tag Assistant. Powinieneś tam zobaczyć:
- Stan początkowy (On-page Default): To stan zgód załadowany przy pierwszym otwarciu strony, jeszcze przed interakcją z banerem. Dla użytkowników z EOG (Europejski Obszar Gospodarczy), wszystkie wartości (np.
ad_storage,analytics_storage) powinny mieć status „Denied”. - Stan po aktualizacji (On-page Update): Po kliknięciu „Zaakceptuj wszystko” na banerze, statusy powinny zmienić się na „Granted”.
Jeśli widzisz, że stan początkowy to „Granted” lub po kliknięciu zgody nic się nie zmienia, to znak, że masz problem.
Metoda 2: Narzędzia deweloperskie przeglądarki
Możesz także użyć narzędzi deweloperskich wbudowanych w przeglądarkę (np. Chrome DevTools). Otwórz je (klawisz F12), przejdź do zakładki „Network” (Sieć) i przefiltruj żądania wpisując „google-analytics.com/g/collect”.
Kluczowy jest parametr &gcd= w wysyłanych zapytaniach. Jego wartość to ciąg cyfr i liter, który koduje statusy zgód. Przykładowo, wartość 11...1 może oznaczać, że wszystkie zgody są domyślnie odrzucone. Po wyrażeniu zgody, wartość ta powinna się zmienić na inną, np. 13...5. Jeśli parametr gcd jest nieobecny lub jego wartość nie zmienia się po interakcji z banerem, GCM v2 nie działa poprawnie.
Problem #1: Błędna kolejność wczytywania skryptów (gtag.js a baner)
To absolutnie najczęstszy błąd przy manualnej implementacji. Google Consent Mode v2 musi być zdefiniowany PRZED załadowaniem jakiegokolwiek skryptu Google (np. Google Analytics, Google Ads, GTM). Skrypt GCM v2 ustawia domyślny stan zgody (Default Consent State), informując tagi Google, jak mają się zachować, zanim użytkownik podejmie decyzję.
Zła kolejność:
- Ładowanie skryptu Google Analytics (gtag.js).
- Ładowanie skryptu banera cookies, który definiuje GCM v2.
W tym scenariuszu Google Analytics uruchomi się, zanim pozna stan zgody, co jest niezgodne z założeniami GCM v2 i może prowadzić do naruszenia prywatności oraz błędnych danych.
Prawidłowa kolejność:
- Zdefiniowanie domyślnego stanu zgody (np. wszystko na „denied”).
- Ładowanie skryptu Google Tag Managera lub gtag.js.
- Ładowanie skryptu banera cookies, który obsłuży aktualizację zgody.
Rozwiązanie: Upewnij się, że fragment kodu odpowiedzialny za ustawienie domyślnego stanu GCM v2 znajduje się w sekcji <head> Twojej strony, możliwie jak najwyżej, a na pewno przed kodami śledzącymi Google.
Problem #2: Konflikt z inną wtyczką WordPress lub motywem
Ekosystem WordPressa jest potężny, ale bywa też źródłem konfliktów. Inna wtyczka (szczególnie do optymalizacji, bezpieczeństwa lub inny baner cookies) lub nawet Twój motyw mogą zakłócać działanie skryptów GCM v2.
- Wtyczki do cache: Mogą serwować statyczną wersję strony, uniemożliwiając dynamiczną zmianę stanu zgody.
- Wtyczki do optymalizacji JS/CSS: Mogą agresywnie łączyć lub opóźniać ładowanie skryptów, zaburzając prawidłową kolejność (patrz Problem #1).
- Inne banery cookies: Posiadanie dwóch wtyczek do zarządzania zgodami to prosta droga do chaosu.
Rozwiązanie: Wykonaj standardową procedurę diagnostyczną WordPressa:
- Wyłącz wszystkie wtyczki oprócz tej, która jest odpowiedzialna za baner i GCM v2.
- Sprawdź, czy problem nadal występuje. Jeśli zniknął, włączaj wtyczki jedna po drugiej, aż znajdziesz winowajcę.
- Jeśli problem nadal istnieje, tymczasowo przełącz się na domyślny motyw WordPressa (np. Twenty Twenty-Four). Jeśli to rozwiąże problem, wina leży po stronie Twojego motywu.
Problem #3: Nieprawidłowo ustawiony domyślny stan zgody (Default Consent State)
Domyślny stan zgody to fundament GCM v2. Informuje on skrypty Google, co mają robić, zanim użytkownik kliknie cokolwiek na banerze. Częstym błędem jest brak zdefiniowania tego stanu lub ustawienie go na „granted” dla użytkowników z UE/EOG.
Przykład błędnego kodu (lub jego braku): Brak jakiejkolwiek definicji przed gtag.js.
Przykład prawidłowego kodu (dla użytkowników z UE/EOG):
<script>
// Zdefiniuj dataLayer przed wszystkim
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
// Ustaw domyślny stan zgody
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied'
});
</script>Rozwiązanie: Upewnij się, że powyższy kod (lub jego odpowiednik) jest umieszczony w sekcji <head> Twojej strony, przed tagiem GTM lub gtag.js. Wartości powinny być ustawione na „denied”.
Problem #4: Brak wysyłania aktualizacji zgody po kliknięciu (Update Command)
Samo ustawienie domyślnego stanu na „denied” to dopiero połowa sukcesu. Gdy użytkownik kliknie „Akceptuję” na banerze, Twoja strona musi wysłać do Google sygnał aktualizujący ten stan. Odpowiada za to komenda gtag('consent', 'update', ...).
Jeśli Twój baner cookies nie wywołuje tej funkcji po interakcji użytkownika, zgody nigdy nie zostaną zaktualizowane, a tagi Google nie zaczną zbierać danych poprawnie. To częsty problem przy własnoręcznie pisanych lub słabo zintegrowanych rozwiązaniach.
Rozwiązanie: Sprawdź, czy skrypt Twojego banera cookies posiada logikę, która po kliknięciu przycisku akceptacji wykonuje kod podobny do tego:
gtag('consent', 'update', {
'ad_storage': 'granted',
'analytics_storage': 'granted'
});Zweryfikuj w Tag Assistant, czy po kliknięciu w baner pojawia się zdarzenie „Consent Update”.
Problem #5: Caching na stronie uniemożliwia dynamiczne działanie skryptu
Agresywny caching to wróg numer jeden dynamicznych skryptów, a mechanizm zgód jest wysoce dynamiczny. Jeśli wtyczka cache’ująca (np. WP Rocket, LiteSpeed Cache) tworzy jedną, statyczną kopię strony dla wszystkich użytkowników, skrypt GCM v2 może nie działać prawidłowo.
Przykładowo, strona może zostać zapisana w cache ze stanem zgody „denied”. Nawet jeśli kolejny użytkownik udzieli zgody, może mu zostać wyświetlona wersja z cache, która nie odzwierciedla jego wyboru.
Rozwiązanie:
- Sprawdź ustawienia swojej wtyczki do cache.
- Wyklucz skrypty związane z banerem cookies i GCM v2 z procesów minifikacji, łączenia (combine) i opóźniania (defer/delay JS execution).
- Niektóre wtyczki do banerów (w tym platformy CMP) ustawiają własne ciasteczka, które można wykorzystać do wykluczenia z cache stron dla użytkowników, którzy jeszcze nie podjęli decyzji o zgodzie.
Problem #6: Używanie starych, niekompatybilnych kodów śledzenia (np. analytics.js)
Google Consent Mode v2 jest technologią nowoczesną i współpracuje wyłącznie z nowszymi tagami Google: gtag.js (Global Site Tag) oraz Google Tag Managerem (GTM). Jeśli na Twojej stronie wciąż znajdują się stare kody śledzące, takie jak analytics.js (dla Universal Analytics), GCM v2 po prostu nie zadziała.
Te starsze skrypty nie mają wbudowanej obsługi poleceń gtag('consent', ...) i nie potrafią dostosować swojego zachowania do sygnałów o zgodzie.
Rozwiązanie: To idealny moment na audyt kodów śledzących. Upewnij się, że całe śledzenie na stronie jest realizowane przez Google Tag Managera lub bezpośrednio przez gtag.js. Jeśli nadal używasz Universal Analytics, migracja na Google Analytics 4 jest absolutnie konieczna.
Problem #7: Nieobsługiwane regiony i błędna konfiguracja geograficzna
GCM v2 pozwala na różnicowanie domyślnego stanu zgody w zależności od regionu geograficznego użytkownika. Można na przykład ustawić domyślne „denied” dla Europy, a „granted” dla reszty świata. Błąd w tej konfiguracji może sprawić, że Google Consent Mode v2 nie działa tak, jakbyś tego oczekiwał.
Częstym błędem jest niepoprawne zdefiniowanie regionów lub brak takiej definicji, przez co rygorystyczne ustawienia są stosowane globalnie, co może niepotrzebnie ograniczać zbieranie danych z krajów spoza EOG.
Rozwiązanie: Jeśli kierujesz swoje usługi globalnie, upewnij się, że Twój mechanizm GCM v2 poprawnie implementuje parametr region. Przykład kodu ustawiającego różne domyślne stany:
gtag('consent', 'default', {
'ad_storage': 'denied',
'analytics_storage': 'denied',
'region': ['PL', 'DE', 'FR', 'ES'] // Przykładowe kraje UE
});
gtag('consent', 'default', {
'ad_storage': 'granted',
'analytics_storage': 'granted'
// Brak regionu oznacza 'reszta świata'
});Sprawdź, czy Twoja wtyczka do banera cookies obsługuje geolokalizację i pozwala na takie zróżnicowane ustawienia.
Rozwiązanie: Jak wtyczka może zautomatyzować proces i zapobiec błędom?
Jak widać, ręczna implementacja Google Consent Mode v2 w WordPressie jest pełna pułapek. Błędna kolejność skryptów, konflikty, problemy z cache – wszystko to wymaga technicznej wiedzy i czasu. Dlatego najlepszym rozwiązaniem dla większości użytkowników WordPressa jest skorzystanie z dedykowanej wtyczki typu Consent Management Platform (CMP), takiej jak Cookiebaner.
Profesjonalna wtyczka CMP automatyzuje cały proces, eliminując ryzyko popełnienia powyższych błędów:
- Gwarancja poprawnej kolejności: Wtyczka sama dba o to, by kod GCM v2 został wstrzyknięty we właściwym miejscu i czasie.
- Automatyczne blokowanie skryptów: Zaawansowane wtyczki potrafią automatycznie zidentyfikować i zablokować skrypty śledzące przed uzyskaniem zgody.
- Obsługa Default i Update: Cała logika ustawiania domyślnego stanu i jego aktualizacji jest wbudowana w mechanizm wtyczki.
- Integracja z WordPressem: Dobre wtyczki są projektowane z myślą o ekosystemie WordPressa i minimalizują ryzyko konfliktów.
- Obsługa geolokalizacji: Umożliwiają łatwe ustawienie różnych reguł zgody dla różnych krajów, bez konieczności grzebania w kodzie.
Inwestycja w sprawdzone rozwiązanie to nie tylko oszczędność czasu i nerwów, ale przede wszystkim pewność, że Twoja strona działa zgodnie z prawem i zbiera dane w sposób efektywny.
FAQ – Najczęściej zadawane pytania
Czy potrzebuję GCM v2, jeśli używam tylko Google Analytics, a nie Google Ads?
Tak. Od marca 2024 wymóg dotyczy obu usług. Bez GCM v2 dane w Twoim Google Analytics 4 (zwłaszcza dotyczące nowych użytkowników z EOG) będą niekompletne, co zaburzy analizę ruchu i skuteczności Twojej strony.
Co się stanie, jeśli zignoruję problem i mój GCM v2 nie będzie działał?
Po pierwsze, Twoje dane analityczne i remarketingowe dla użytkowników z EOG będą mocno ograniczone lub całkowicie utracone. Po drugie, narażasz się na niezgodność z regulacjami dotyczącymi prywatności (RODO/ePrivacy), ponieważ tagi Google mogą uruchamiać się bez wyraźnej zgody użytkownika.
Czy GCM v2 zwalnia mnie z obowiązku posiadania banera cookies?
Absolutnie nie. GCM v2 to mechanizm techniczny, który „tłumaczy” decyzję użytkownika na język zrozumiały dla skryptów Google. Baner cookies to interfejs, za pomocą którego użytkownik tę decyzję podejmuje. Te dwa elementy muszą ze sobą współpracować – baner zbiera zgodę, a GCM v2 ją egzekwuje.
