Cookies vis tiek nustatomi po Reject

Kodėl tai svarbu

Reject mygtukas, kuris realiai neblokuoja optional processing, yra vienas aiškiausių ženklų, kad sutikimo mechanizmas neįgyvendinamas tinkamai.

Kaip tai patikrinti rankiniu būdu

1. Atmeskite optional processing švarioje sesijoje ir perkraukite puslapį.
2. Patikrinkite cookies ir network užklausas po Reject.
3. Palyginkite elgseną prieš ir po Reject, kad patvirtintumėte, jog optional storage tikrai sustoja.

Tipinės priežastys

• Reject atnaujina tik vizualinę bannerio būseną, bet neperduoda denied būsenos.
• Optional tagai po reload vėl startuoja nepaisydami vartotojo atmetimo.
• Išsaugotos sutikimo reikšmės po navigacijos perskaitomos neteisingai arba ignoruojamos.

Pataisa GTM

1. Užtikrinkite, kad denied būsena būtų perskaitoma prieš tagams vėl startuojant po reload.
2. Susiekite sutikimo patikras su visais optional tagais, o ne tik su first-load įvykiais.
3. Patvirtinkite GTM Preview, kad Reject būklė išsilaiko tarp reloadų.

Pataisa WordPress ar CMP įskiepiuose

1. Peržiūrėkite įskiepių integracijas, kurios po Reject toliau įkelia optional tagus.
2. Patvirtinkite, kad CMP įskiepis išsaugo ir taiko denied būseną kiekvieno page load metu.
3. Pašalinkite persidengiančius tracking įskiepius, kurie ignoruoja CMP būseną.

Bendra kūrėjų pataisa

1. Traktuokite Reject kaip vykdytiną runtime būseną, o ne tik kaip UI veiksmą.
2. Blokuokite optional loaderius kiekviename puslapyje, kai išsaugota sutikimo būsena yra denied.
3. Testuokite reload, revisit ir cross-page navigation scenarijus, ne tik pirmą įkėlimą.

Kaip patvirtinti, kad pataisa veikia

• Reject ir reload: patvirtinkite, kad optional cookies vis dar neegzistuoja.
• Reject ir reload: patvirtinkite, kad optional užklausos lieka blokuotos.
• Paleiskite naują scan ir patikrinkite, kad su Reject susiję findings išnyksta.