Cookies încă se setează după Reject

De ce contează

Un buton Reject care nu blochează cu adevărat prelucrarea opțională este unul dintre cele mai clare semne că mecanismul de consimțământ nu este aplicat corect.

Cum verificați manual

1. Respingeți prelucrarea opțională într-o sesiune curată și reîncărcați pagina.
2. Inspectați cookies și cererile de rețea după Reject.
3. Comparați comportamentul înainte și după Reject pentru a confirma dacă storage-ul opțional chiar se oprește.

Cauze tipice

• Reject actualizează doar starea vizuală a bannerului, dar nu propagă un status denied.
• Tag-urile opționale pornesc din nou la reload în ciuda alegerii de respingere.
• Valorile de consimțământ stocate sunt citite greșit sau ignorate după navigare.

Remediere în GTM

1. Asigurați-vă că starea denied este citită înainte ca tag-urile să poată porni din nou după reload.
2. Aplicați controale de consimțământ tuturor tag-urilor opționale, nu doar evenimentelor de first-load.
3. Verificați în GTM Preview că Reject persistă corect între reload-uri.

Remediere în WordPress sau pluginuri CMP

1. Revizuiți integrările de plugin care continuă să încarce tag-uri opționale după Reject.
2. Verificați că pluginul CMP stochează și aplică starea denied pe toate pageload-urile.
3. Eliminați pluginurile de tracking suprapuse care ignoră starea CMP.

Remediere generică pentru dezvoltatori

1. Tratați Reject ca pe un status runtime executabil, nu doar ca pe o acțiune UI.
2. Blocați loader-ele opționale pe fiecare pagină când starea de consimțământ stocată este denied.
3. Testați scenariile de reload, revisit și navigare cross-page, nu doar first-load.

Cum confirmați că remedierea funcționează

• Reject și reload: confirmați că cookies opționale rămân absente.
• Reject și reload: confirmați că cererile opționale rămân blocate.
• Rulați o nouă scanare și verificați că findings-urile legate de Reject dispar.