Ten artykuł pokazuje możliwe sposoby wdrożenia SEIGI Cookie & Consent w połączeniu z analityką i tagowaniem.

Celem nie jest tylko uruchomienie banera cookie, ale zapewnienie poprawnej współpracy między:

  • banerem zarządzania zgodami,
  • Consent Mode,
  • Google Analytics 4,
  • Google Tag Manager,
  • innymi skryptami marketingowymi.

W praktyce największa różnica między wdrożeniami polega na tym, czy komunikacja między zgodami i analityką działa event-based, czy też opiera się na opóźnieniach typu delay / wait_for_update.

Najważniejsza różnica

Wdrożenie event-based

W podejściu event-based analityka i tagi reagują na rzeczywisty stan zgód oraz na zdarzenia wysyłane przez moduł Cookie & Consent.

To podejście jest:

  • bardziej przewidywalne,
  • stabilniejsze,
  • mniej podatne na problemy z kolejnością ładowania,
  • mniej ryzykowne pod kątem utraty danych.

Wdrożenie oparte o delay / wait_for_update

W tym modelu system próbuje „odczekać“, aż stan zgód zostanie ustawiony, zanim ruszy analityka.

To rozwiązanie może być pomocne jako mechanizm kompatybilności, ale nie jest wariantem docelowym, ponieważ:

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

Dostępne modele wdrożenia

To jest wariant rekomendowany.

W tym modelu moduł zgód i moduł analityczny działają w jednym, spójnym środowisku. Dzięki temu wdrożenie nie musi opierać się na sztucznych opóźnieniach i może działać w sposób event-based.

Najważniejsze korzyści:

  • poprawna współpraca Cookie + Consent + analityki,
  • brak konieczności opierania wdrożenia na delay,
  • mniejsze ryzyko błędów implementacyjnych,
  • mniejszy zakres dodatkowej konfiguracji,
  • prostsze utrzymanie w dłuższym okresie.

To rozwiązanie będzie najlepsze, jeżeli zależy Ci na:

  • stabilnym wdrożeniu,
  • ograniczeniu ryzyka utraty danych,
  • przewidywalnej kolejności ładowania,
  • możliwie najmniejszej liczbie obejść i wyjątków.

To wariant kompatybilnościowy.

Jest możliwy do wdrożenia, ale jego jakość zależy od tego, jak działa zewnętrzny moduł analityczny i czy pozwala poprawnie zsynchronizować zgody z uruchomieniem tagów.

W praktyce bardzo często oznacza to konieczność stosowania:

  • delay,
  • wait_for_update,
  • zmian kolejności ładowania w <head>,
  • zmian hooków,
  • ręcznych poprawek wdrożeniowych.

To może działać poprawnie, ale trzeba pamiętać, że takie wdrożenie zwykle pozostaje kompromisem. Jeżeli zewnętrzny moduł nadal opiera się na opóźnieniach, ryzyko niespójności i utraty części danych będzie wyższe niż w wariancie event-based.

Ten model ma sens wtedy, gdy:

  • chcesz zachować obecny moduł GA4 / GTM,
  • nie planujesz jeszcze migracji,
  • akceptujesz większy zakres konfiguracji,
  • traktujesz to jako etap przejściowy.

To najbardziej zróżnicowana grupa wdrożeń.

Dotyczy sytuacji, w których:

  • korzystasz z innego CMP,
  • masz własny loader skryptów,
  • część logiki działa niestandardowo,
  • na stronie są dodatkowe integracje, iframe lub zewnętrzne domeny.

W takich wdrożeniach bardzo często kończy się na modelu opartym o delay albo na własnej logice integracyjnej. Ostateczna jakość wdrożenia zależy wtedy od tego, czy uda się zbudować poprawną komunikację event-based.

Jeżeli nie, pozostaje wariant oparty o opóźnienia i ręczne obejścia.

Porównanie modeli wdrożenia

Połączenie Model działania Ryzyko utraty danych Nakład konfiguracji Ocena
SEIGI Cookie & Consent + SEIGI Tag Manager GA4 / GTM Event-based Niskie Niski Zalecane
SEIGI Cookie & Consent + inny moduł GA4 / GTM Najczęściej delay / wait_for_update Wyższe Średni Kompatybilność

Kiedy który model wybrać

Wybierz SEIGI Tag Manager GA4 / GTM, jeśli:

  • chcesz ograniczyć ryzyko błędów i utraty danych,
  • nie chcesz opierać wdrożenia na delay,
  • zależy Ci na możliwie najstabilniejszym modelu,
  • chcesz uprościć utrzymanie wdrożenia.

Pozostań przy innym module GA4 / GTM, jeśli:

  • z jakiegoś powodu musisz zachować obecne rozwiązanie,
  • akceptujesz dodatkową konfigurację,
  • jesteś gotowy na ręczne pilnowanie kolejności ładowania,
  • rozumiesz ograniczenia wdrożeń opartych o opóźnienia.

Wybierz wdrożenie niestandardowe, jeśli:

  • masz nietypową architekturę sklepu,
  • potrzebujesz własnej logiki ładowania,
  • integrujesz wiele skryptów i systemów jednocześnie,
  • wdrożenie realizuje deweloper, który będzie utrzymywał tę logikę.

Co dalej

  • Jeżeli chcesz sprawdzić techniczne wymagania dotyczące kolejności zdarzeń, przejdź do artykułu Consent Mode v2 i poprawna kolejność ładowania.
  • Jeżeli chcesz wdrażać własne skrypty zależnie od zgód, przejdź do działu Zaawansowana implementacja.
  • Jeżeli dopiero planujesz wdrożenie, zacznij od strony głównej działu i porównania rozwiązań.