Cookies są nadal ustawiane po Reject

Dlaczego to ważne

Przycisk Reject, który nie blokuje realnie opcjonalnego przetwarzania, jest jednym z najczytelniejszych sygnałów, że mechanizm zgody nie jest poprawnie egzekwowany.

Jak zweryfikować to ręcznie

1. Odrzuć opcjonalne przetwarzanie w czystej sesji i przeładuj stronę.
2. Sprawdź cookies i requesty sieciowe po Reject.
3. Porównaj zachowanie przed i po Reject, aby potwierdzić, czy opcjonalny storage faktycznie się zatrzymuje.

Typowe przyczyny

• Reject aktualizuje tylko wizualny stan bannera, ale nie propaguje stanu denied.
• Opcjonalne tagi odpalają się ponownie po reloadzie mimo odrzuconego wyboru.
• Zapisane wartości zgody są błędnie odczytywane lub ignorowane po nawigacji.

Naprawa w GTM

1. Upewnij się, że stan denied jest odczytywany zanim tagi będą mogły ruszyć po reloadzie.
2. Podłącz kontrole zgody do wszystkich opcjonalnych tagów, a nie tylko do eventów first-load.
3. Sprawdź w GTM Preview, że Reject poprawnie utrzymuje się przez reloady.

Naprawa w WordPressie lub wtyczkach CMP

1. Sprawdź integracje pluginów, które po Reject nadal ładują opcjonalne tagi.
2. Zweryfikuj, że plugin CMP zapisuje i egzekwuje stan denied na wszystkich page loadach.
3. Usuń nakładające się pluginy trackingowe, które ignorują stan CMP.

Ogólna poprawka developerska

1. Traktuj Reject jako egzekwowalny stan runtime, a nie tylko akcję UI.
2. Blokuj opcjonalne loadery na każdej stronie, gdy zapisany stan zgody to denied.
3. Testuj scenariusze reload, revisit i cross-page, a nie tylko first-load.

Jak potwierdzić, że poprawka działa

• Reject i reload: potwierdź, że opcjonalne cookies pozostają nieobecne.
• Reject i reload: potwierdź, że opcjonalne requesty pozostają zablokowane.
• Uruchom nowy skan i sprawdź, że findings związane z Reject znikają.