Menu dokumentacji

Troubleshooting

Rozwiązywanie problemów z CookieHug: baner się nie pokazuje, skrypty nie są blokowane, GTM, Debug Mode i zgody late-consent.

FAQ / Rozwiązywanie problemów

Skrypty nie są blokowane

Sprawdź, czy data-cookiehug-blockingmode jest ustawiony na "auto" (lub nie jest ustawiony wcale)
Skrypt może być na białej liście (popularne biblioteki jak jQuery nie są blokowane)
Do ręcznej kontroli użyj atrybutów data-cookiehug-consent

Google Tag Manager nie otrzymuje sygnałów zgody

Sprawdź, czy data-cookiehug-consentmode nie jest ustawiony na "disabled"
Sprawdź, czy gtag lub dataLayer są dostępne na stronie
Użyj konsoli przeglądarki do weryfikacji: dataLayer powinien zawierać zdarzenia zgody

Zgoda nie jest zachowywana między ładowaniami strony

Sprawdź, czy localStorage jest dostępny i nie jest blokowany
Sprawdź, czy cookies nie są czyszczone przez ustawienia przeglądarki
Sprawdź, czy zgoda nie wygasła (domyślnie 30 dni)

Jak testować zgodę bez czyszczenia cookies za każdym razem?

Użyj CookieHug.withdraw() w konsoli przeglądarki, aby zresetować stan zgody. Czyści wszystkie dane zgody, resetuje Google Consent Mode do denied i automatycznie przeładowuje stronę, aby upewnić się, że wcześniej dopuszczone skrypty zostaną prawidłowo zablokowane.

Jak sprawdzić stan zgody w konsoli przeglądarki?

// Pełny stan zgody
console.log(window.CookieHug.consent);

// Czy użytkownik odpowiedział?
console.log(window.CookieHug.hasResponse);

// Jakie regulacje obowiązują?
console.log(window.CookieHug.regulations);

Debug Mode i diagnostyka

CookieHug zawiera wbudowany Debug Mode, który proaktywnie sprawdza, czy default command Consent Mode (oraz ewentualny TCF stub) ładują się zanim odpalą się tagi Google. Nie wpływa na banner ani na zgody — jest obserwatorem, który zgłasza błędną konfigurację.

Aktywuj go na jeden z trzech sposobów:

dodaj ?cookiehug_debug=1 do adresu strony,
ustaw localStorage.cookiehugDebug = '1' w konsoli przeglądarki,
albo włącz Debug Mode na 24h w panelu CookieHug (szczegóły domeny → diagnostyka).

Po aktywacji w prawym dolnym rogu pojawia się znaczek CookieHug debug (zielony = OK, bursztynowy = ostrzeżenia, czerwony = błędy). Kliknij go, aby zobaczyć pełny raport w konsoli. Raporty trafiają też do panelu i wyzwalają proaktywne powiadomienia e-mail oraz banner w panelu.

Komunikaty debugowania

CHUG_ORDER_OK — konfiguracja poprawna: default command ustawiony przed tagami.
CHUG_GA_BEFORE_SDK / CHUG_ORDER_LATE — tag Google odpalił się za późno. Zobacz Co zrobić, gdy tag jest late.
CHUG_NO_DEFAULT_CONSENT — brak default command; tagi mogły uruchomić się bez zgody.
CHUG_TCF_STUB_PRESENT — wykryto TCF stub __tcfapi; upewnij się, że ładuje się przed tagami.

Co zrobić, gdy tag jest „late”

Debug Mode oznacza tag jako „late” (CHUG_GA_BEFORE_SDK / CHUG_ORDER_LATE), gdy skrypt Google (GA4, Google Ads, GTM) odpala się zanim CookieHug ustawi domyślny stan zgód. W efekcie tag może wykonać się bez sygnału Consent Mode.

Krok 1 — najpierw sprawdź, czy tag korzysta z Google Tag Gateway (GTG). To kluczowe: przy GTG tag Google jest serwowany z Twojej własnej domeny (first-party), więc pomiary czasu ładowania wyglądają inaczej i tag może zostać błędnie zgłoszony jako „late”.

Jak sprawdzić, czy tag przyjął GTG

Otwórz DevTools → Network i przeładuj stronę.
Znajdź żądanie ładujące tag Google (np. gtag/js, gtm.js, collect).
Sprawdź domenę żądania: jeśli tag ładuje się z Twojej domeny (np. metrics.twojadomena.pl) zamiast z googletagmanager.com / google-analytics.com, prawdopodobnie korzysta z GTG → zobacz Google Tag Gateway (GTG).

Jeśli tag NIE korzysta z GTG — napraw kolejność

Gdy tag ładuje się bezpośrednio z domen Google, „late” oznacza realny problem z kolejnością. Umieść skrypt CookieHug jako pierwszy w <head>, przed jakimkolwiek gtag.js, gtm.js czy tagiem GA4, a następnie przeładuj z ?cookiehug_debug=1 i potwierdź, że pojawia się CHUG_ORDER_OK.

<head>
  <!-- 1) CookieHug jako pierwszy -->
  <script src="https://cookiehug.com/api/script/TWOJ-KLUCZ-LICENCJI.js"></script>

  <!-- 2) dopiero potem Google -->
  <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXX"></script>
</head>

Google Tag Gateway (GTG)

Google Tag Gateway (GTG) to sposób serwowania tagów Google (Google tag / GA4 / cały kontener GTM) z Twojej własnej domeny (first-party) zamiast bezpośrednio z googletagmanager.com. Żądania przechodzą przez lekki gateway na Twojej infrastrukturze (CDN/serwer), co poprawia trwałość pomiaru w przeglądarkach ograniczających skrypty third-party.

Wpływ na zgody — przeczytaj najpierw. GTG jest często włączany przez integrację CDN „jednym kliknięciem" (np. bezpośrednio z Cloudflare). Ta wygoda ma cenę: to CDN wstrzykuje i uruchamia tag Google za Ciebie, więc klient zwykle traci kontrolę nad kolejnością ładowania skryptów. Gateway może wykonać tag Google *zanim* zadziała default command Consent Mode z Twojego CMP — i to właśnie generuje sygnał „late” w Debug Mode CookieHug. GTG zmienia *skąd i kiedy* ładuje się tag, ale tag nadal czyta Consent Mode; wyzwaniem jest zagwarantowanie, że default command wykona się pierwszy.

Oficjalna dokumentacja Google: Google tag gateway for advertisers · Przewodnik startowy · Konfiguracja CDN jednym kliknięciem (Cloudflare).

Jak sprawdzić, czy tag jest objęty GTG

Otwórz DevTools → Network i przeładuj stronę.
Znajdź żądanie ładujące tag Google (np. gtag/js, gtm.js, collect).
Sprawdź domenę żądania: jeśli ładuje się z Twojej domeny / subdomeny (np. metrics.twojadomena.pl) zamiast z googletagmanager.com / google-analytics.com, tag jest objęty GTG.
Zweryfikuj dodatkowo w ustawieniach Google Ads / GA4 → Google tag gateway, gdzie wypisane są objęte domeny.

Dlaczego GTG bywa mylnie zgłaszany jako „late”

Debug Mode CookieHug porównuje czas startu żądań Google z momentem inicjalizacji SDK. Przy GTG tag ładowany jest z Twojej domeny i często wcześniej/szybciej, więc heurystyka może oznaczyć go jako „late”, mimo że Consent Mode działa poprawnie. Zawsze zweryfikuj objęcie GTG, zanim uznasz ostrzeżenie za realny problem.

Sygnał „late” na tagu objętym GTG — zalecana naprawa

Jeśli Debug Mode zgłasza sygnał „late” (`CHUG_ORDER_LATE`) oraz potwierdziłeś, że tag jest objęty GTG, kolejność ładowania kontroluje zwykle CDN, a nie Ty. Wybierz jedną z opcji, w kolejności preferencji:

Zalecane — przejdź na U+C (advanced Consent Mode). Dla tagów objętych GTG U+C (advanced Consent Mode) jest zalecanym mechanizmem, bo jest kompatybilny z ręcznym GTG: tag zawsze się ładuje i sam dostosowuje zachowanie na podstawie sygnału zgody, więc nie zależy od wygrania wyścigu o kolejność ładowania. Następnie w produkcie Google włącz Data Transmission Controls oraz Global Consent Defaults stosownie do potrzeb, aby redakcja danych i domyślne zgody były egzekwowane po stronie Google.
Albo przenieś wszystko do kontenera GTM i wdróż GTM przez GTG. Przenieś tagi Google do jednego kontenera GTM i serwuj ten kontener przez gateway. Zgoda jest wtedy podłączona raz wewnątrz GTM (Consent Settings per tag), a default command CookieHug jest respektowany zanim tagi kontenera się wykonają.
Albo skonfiguruj GTG ręcznie (zamiast integracji CDN jednym kliknięciem), tak aby to Ty kontrolował kolejność importu skryptów — załaduj default command Consent Mode CookieHug przed tagiem gateway.

Jak pracować z GTG w CookieHug

Zostaw skrypt CookieHug jako pierwszy w <head> — nawet przy GTG default command musi zostać wysłany przed inicjalizacją tagu.
Potwierdź, że default command jest respektowany: otwórz GA4 → Administracja → DebugView i sprawdź analytics_storage / ad_storage na zdarzeniach.
W konsoli sprawdź window.CookieHug.consent — powinien odpowiadać wyborowi użytkownika.
Jeśli zgoda jest respektowana, ostrzeżenie „late” z GTG potraktuj jako fałszywy alarm wynikający z first-party timingu.
Jeśli zgoda nie jest respektowana (tag zbiera dane mimo denied), zastosuj naprawę powyżej.