GA4 Consent Mode v2: parametr gcd, wyścigi CMP i debugowanie po stronie serwera

gcd jest wskazówką diagnostyczną w żądaniach Google. Parametr nie zastępuje weryfikacji zgody ani kontroli wysyłanych danych. Przy asynchronicznym ładowaniu platformy zarządzania zgodą (CMP) znaczenie ma kolejność: stan domyślny, zapisany wybór, aktualizacja, zdarzenie pomiarowe i rzeczywista transmisja.

Cztery sygnały o różnych zadaniach

Zgoda na analitykę nie jest ogólną zgodą marketingową. W szczególności ad_user_data nie oznacza automatycznej zgody na Meta CAPI. Inni odbiorcy i cele wymagają osobnego powiązania z rzeczywiście zarejestrowanym wyborem.

Informacje w gcs i gcd

Według Google gcs przenosi stany ad_storage i analytics_storage. Parametr gcd zawiera bardziej szczegółowe informacje o zgodzie i jest wysyłany także bez aktywnego Consent Mode. Sama obecność parametru nie potwierdza poprawnej konfiguracji.

Google wyraźnie zaznacza możliwość zmian zakodowanych pól HTTP. Tabele liter oparte na obserwacjach oraz stałe pozycje znaków nie stanowią trwałego, udokumentowanego interfejsu. Warunek taki jak gcd.charAt(6) nie powinien sterować zezwoleniem na dalsze przekazywanie danych. Pozornie zgodna wartość nie dowodzi ważnej zgody ani pełnej historii wszystkich decyzji.

Sprawdzanie wyścigu z CMP

Inny wzorzec zgody w pierwszym żądaniu niż w kolejnych może wskazywać na opóźnioną aktualizację. Możliwe są jednak także zwykła późniejsza akceptacja, różnice regionalne lub częściowa aktualizacja. Samo porównanie żądań nie dowodzi przyczyny.

1. W nowej sesji Tag Assistant sprawdzić najwcześniejsze zdarzenie zgody i wszystkie cztery wartości domyślne.
2. Zarejestrować moment inicjalizacji CMP i ewentualny zapisany wybór. Wybór musi odpowiadać aktualnym celom i konfiguracji dostawców.
3. Sprawdzić cztery wartości aktualizacji i moment przetworzenia względem pierwszego zdarzenia pomiarowego.
4. Skontrolować warunki zgody i przyczynę uruchomienia badanego tagu, a następnie przypisać odpowiednie żądanie przeglądarki.
5. Powtórzyć próbę dla nowej sesji, zapisanej odmowy, zapisanej akceptacji, zgody częściowej, wycofania zgody i wolnego ładowania CMP. Osobno sprawdzić warianty regionalne.

Uzasadniony wniosek może brzmieć: istniała właściwa zapisana akceptacja, lecz aktualizacja stanu zgody została przetworzona dopiero po badanym zdarzeniu pomiarowym. Taka oś czasu pozwala odróżnić problem kolejności od prawidłowej późniejszej decyzji.

Poprawna kolejność i ograniczony czas oczekiwania

W GTM odpowiedni szablon zgody powinien ustawiać wartości domyślne przy wyzwalaczu Consent Initialization – All Pages. Szablony korzystają z setDefaultConsentState i updateConsentState. Wywołanie gtag('consent', ...) wewnątrz szablonu może zostać opóźnione przez kolejkę. Wczesne uruchomienie szablonu nie gwarantuje jednak zakończenia asynchronicznego ładowania CMP.

W bezpośredniej integracji gtag.js wartości domyślne muszą poprzedzać polecenia pomiarowe config lub event. Parametr wait_for_update wyznacza ograniczony czas oczekiwania na aktualizację. Często podawane 500 milisekund to przykład, a nie pewna górna granica czasu ładowania CMP. Po upływie limitu obowiązuje dostępny w danym momencie stan zgody.

Udokumentowane zdarzenie CMP może być elementem właściwej strategii uruchamiania tagów. Wymyślona nazwa zdarzenia albo dodatkowa odsłona po każdej zmianie zgody może natomiast powodować utratę lub dublowanie pomiarów. Uruchomienia, powtórzenia i przejścia między stronami wymagają wspólnych testów.

Różnica między Basic a Advanced

Basic Consent Mode blokuje odpowiednie tagi Google do uzyskania wymaganej zgody. W Advanced Consent Mode załadowane tagi mogą po odmowie wysyłać ograniczone sygnały bez odpowiednich plików cookie. Stan denied nie oznacza zatem automatycznie braku ruchu sieciowego. Wymóg całkowitego braku danej transmisji przed zgodą wymaga sprawdzenia blokady na wszystkich uczestniczących ścieżkach.

Kontrola serwera aż do odbiorcy

W opisanej przez Google konfiguracji klient GA4 przetwarza żądanie w kontenerze serwerowym, a tagi Google obsługujące zgodę uwzględniają przesłane sygnały. Zachowanie zależy od celu i tagu. Żądanie GA4 nie jest obowiązkowym nośnikiem danych dla wszystkich innych klientów serwerowych i dostawców.

Podgląd serwera powinien łączyć żądanie wejściowe, odpowiedzialnego klienta, utworzone zdarzenie, uruchomione tagi oraz żądania wyjściowe. Szablony zewnętrznych dostawców wymagają jawnie sprawdzonych reguł dla każdego odbiorcy i celu. Pole zgody dostarczone z zewnątrz nie stanowi również kryptograficznego dowodu udzielenia zgody.

Brakujące lub niezrozumiałe sygnały powinny pozostać widoczne jako osobny błąd i nie mogą oznaczać zezwolenia. Ograniczony zapis testu może obejmować przypadek, czas zdarzenia, wersję tagu, decyzję o uruchomieniu i odbiorcę. Pełne adresy URL oraz dane użytkowników nie powinny trafiać do logów diagnostycznych bez kontroli zawartości i potrzeby zapisu.

Pytania i odpowiedzi

Czy brak gcd dowodzi odmowy?

Nie. Inna ścieżka transmisji może pomijać parametr. Konieczna jest kontrola źródła, klienta i oczekiwanego formatu. Stan nieznany i jawna odmowa to różne sytuacje diagnostyczne.

Czy gcs dowodzi braku zapisu plików cookie?

Nie. Parametr opisuje przesłane stany. Rzeczywisty dostęp do plików cookie i żądania wymagają dodatkowej kontroli w przeglądarce oraz, w odpowiednich przypadkach, na serwerze.

Czy Consent Mode gwarantuje zgodność z prawem?

Nie. Sygnały techniczne nie zastępują oceny zgody, celów, odbiorców, treści danych i czasu przechowywania. Udany zestaw testów potwierdza wyłącznie sprawdzone przebiegi i wersje.

Źródła

• Consent mode overview
• Troubleshoot consent mode with Tag Assistant
• Consent Mode implementation
• Create a consent mode template
• Implement consent mode with server-side Tag Manager
• gtag.js reference