Consent Mode v2 i poprawna kolejność ładowania

Ten artykuł dotyczy integracji, w których korzystasz z SEIGI Cookie & Consent, ale za analitykę odpowiada inny moduł GA4 / GTM albo własna implementacja.

Jeżeli korzystasz z SEIGI Tag Manager GA4 albo SEIGI Tag Manager GTM, ten poradnik najczęściej nie będzie potrzebny. W tych wdrożeniach kolejność zgód i analityki jest obsługiwana w sposób natywny i event-based.

Kiedy ten artykuł jest potrzebny

Ten materiał jest dla Ciebie, jeżeli:

w konsoli przeglądarki widzisz komunikat: A tag read consent state before a default was set,
korzystasz z zewnętrznego modułu GA4 lub GTM,
masz własny kod analityczny i chcesz poprawnie wdrożyć Consent Mode v2,
chcesz sprawdzić, czy zgody są ustawiane zanim wystartują tagi Google.

Najczęstszy problem

Najczęściej spotykanym błędem jest sytuacja, w której moduł analityczny ładuje się szybciej niż kod odpowiedzialny za ustawienie zgód.

W praktyce oznacza to, że Google Tag Manager lub Google Analytics 4 próbuje odczytać stan zgody zanim zostanie ustawiony consent default. To może prowadzić do:

błędów w implementacji Consent Mode v2,
nieprawidłowej kolejności zdarzeń,
niespójnego działania analityki,
utraty części danych.

Poprawna kolejność

Dla wdrożeń opartych o Google Consent Mode v2 kolejność powinna wyglądać następująco:

ustawienie domyślnego stanu zgód: consent default,
aktualizacja zgód: consent update,
uruchomienie konfiguracji GA4 / GTM,
dopiero potem wysyłka zdarzeń i page view.

Przykład logicznej kolejności:

// 1. Domyślny stan zgód
gtag('consent', 'default', {...});

// 2. Aktualizacja po decyzji użytkownika
gtag('consent', 'update', {...});

// 3. Konfiguracja GA4 / GTM
gtag('config', 'G-XXXXXXXX');

// 4. Zdarzenia
gtag('event', 'page_view');
dataLayer.push({ event: 'page_view' });

Błędna implementacja

Poniższy przykład pokazuje sytuację, w której kod Google ładuje się przed ustawieniem zgód:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXX"></script>
<script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-XXXXXX');
</script>

<script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('consent', 'default', { /**/ });
</script>

W takim układzie konfiguracja GA4 startuje zbyt wcześnie.

Poprawna implementacja

Najpierw należy ustawić zgody, a dopiero potem ładować konfigurację analityki:

<script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('consent', 'default', { /**/ });
    gtag('consent', 'update', { /**/ });
</script>

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXX"></script>
<script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-XXXXXX');
</script>

Integracja w PrestaShop

1. SEIGI Tag Manager GA4 / GTM

To wariant rekomendowany.

Nie wymaga ręcznego pilnowania kolejności hooków ani dodatkowych obejść opartych o opóźnienia. Integracja działa w sposób spójny z modułem SEIGI Cookie & Consent.

2. Inne moduły GA4 / GTM

Jeżeli korzystasz z zewnętrznego modułu, musisz samodzielnie zadbać o to, aby kod zgód został załadowany wcześniej niż kod analityczny.

Najczęściej oznacza to:

upewnienie się, że moduł Cookie ładuje się przed modułem GA4 / GTM,
zmianę pozycji modułu w hookach,
użycie hooka displayAfterTitleTag w PrestaShop 1.7+,
w trudniejszych przypadkach ręczne osadzenie kodu wyżej w sekcji <head>.

Przykład dla PrestaShop:

{hook h="displayHeaderSeigiCookieConsent"}

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXX"></script>
<script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-XXXXXX');
</script>

{hook name="displayHeader"}

Delay i `wait_for_update`

Niektóre zewnętrzne moduły GA4 / GTM oferują wsparcie dla wait_for_update albo własnego mechanizmu delay.

To może pomóc w uzyskaniu kompatybilności, ale warto traktować to jako rozwiązanie kompromisowe, a nie docelowy model wdrożenia.

Dlaczego?

działa na opóźnieniu czasowym,
zależy od szybkości ładowania modułów i warunków po stronie użytkownika,
przy słabszym internecie lub wolniejszym urządzeniu może nadal prowadzić do niespójności,
może zwiększać ryzyko utraty części danych.

Jeżeli korzystasz z modułu zewnętrznego i nie masz możliwości wdrożenia pełnej komunikacji event-based, wait_for_update może być pomocne jako mechanizm zgodności. Nie powinno być jednak traktowane jako najlepszy wariant architektury.

Kiedy przejść na wdrożenie event-based

Jeżeli:

chcesz ograniczyć ryzyko utraty danych,
nie chcesz opierać się na sztucznych opóźnieniach,
zależy Ci na stabilnej współpracy Cookie + Consent + analityki,
nie chcesz ręcznie utrzymywać dodatkowych obejść,

najbardziej spójnym rozwiązaniem będzie przejście na SEIGI Tag Manager GA4 albo SEIGI Tag Manager GTM.

Dalsze kroki

Jeżeli dopiero wybierasz sposób wdrożenia, wróć do strony głównej działu i sprawdź porównanie modeli integracji.
Jeżeli chcesz zbudować własną logikę ładowania po zgodach, przejdź do działu Zaawansowana implementacja.
Jeżeli korzystasz z niestandardowych integracji i iframe, sprawdź również sekcję o implementacji zaawansowanej.

Cookie & Consent Manager Consent Mode v2 i poprawna kolejność ładowania