Problemy zgody przy server-side GTM

Dlaczego to ważne

Server-side GTM może ograniczać wycieki po stronie klienta, ale może też ukrywać błędy zgody, jeśli eventy są proxy'owane bez respektowania stanów denied.

Jak zweryfikować to ręcznie

1. Sprawdź, czy requesty client-side nadal proxy'ują eventy analytics albo ads do kontenera serwerowego przed zgodą.
2. Zweryfikuj, jak stan zgody jest przekazywany do requestów GTM server-side.
3. Porównaj flow Accept i Reject, aby potwierdzić, że stan denied blokuje też dispatch po stronie serwera.

Typowe przyczyny

• Server-side GTM otrzymuje eventy bez kontekstu zgody.
• Kod client-side przekazuje pageview do endpointu serwerowego przed zgodą.
• Kontrole zgody istnieją w kontenerze przeglądarkowym, ale nie w kontenerze serwerowym.

Naprawa w GTM

1. Przekazuj jawny stan zgody do eventów wysyłanych do GTM server-side.
2. Odtwórz kontrole zgody w kontenerze serwerowym zamiast ufać tylko defaultom po stronie klienta.
3. Audytuj tagi w kontenerach browser i server pod kątem duplikatów lub bypassów.

Naprawa w WordPressie lub wtyczkach CMP

1. Sprawdź, czy pluginy albo snippets motywu automatycznie nie wysyłają eventów do endpointu GTM server-side.
2. Wyłącz server-side forwarding analytics, dopóki stan zgody nie będzie poprawnie podłączony.
3. Przetestuj ponownie zachowanie przeglądarki i sieci po aktualizacjach.

Ogólna poprawka developerska

1. Traktuj server-side GTM jako dodatkową warstwę enforcement, a nie wyjątek od logiki zgody.
2. Jawnie propaguj stany denied i blokuj proxy'owanie opcjonalnych eventów przed zgodą.
3. Udokumentuj, jak tagging browser i server współdzielą to samo źródło prawdy dla zgody.

Jak potwierdzić, że poprawka działa

• Potwierdź, że żadne opcjonalne eventy nie są proxy'owane do GTM server-side przed zgodą.
• Potwierdź, że Accept aktywuje zamierzony flow eventów, a Reject utrzymuje go w denied.
• Uruchom nowy skan i sprawdź, że problemy zgody wokół server-side GTM są rozwiązane.