I cookie continuano a essere impostati dopo Reject

Perché è importante

Un pulsante Reject che non blocca davvero il trattamento opzionale è uno dei segnali più chiari che il meccanismo di consenso non viene applicato correttamente.

Come verificare manualmente

1. Rifiuta il trattamento opzionale in una sessione pulita e ricarica la pagina.
2. Ispeziona cookie e richieste di rete dopo Reject.
3. Confronta il comportamento prima e dopo Reject per verificare se lo storage opzionale si arresta davvero.

Cause tipiche

• Reject aggiorna solo lo stato visuale del banner, ma non propaga uno stato denied.
• I tag opzionali ripartono al reload nonostante la scelta rifiutata.
• I valori di consenso salvati vengono letti male o ignorati dopo la navigazione.

Correzione in GTM

1. Assicurati che lo stato denied venga letto prima che i tag possano ripartire dopo il reload.
2. Applica controlli di consenso a tutti i tag opzionali, non solo agli eventi del primo caricamento.
3. Verifica in GTM Preview che Reject persista correttamente attraverso i reload.

Correzione in WordPress o plugin CMP

1. Controlla integrazioni di plugin che continuano a caricare tag opzionali dopo Reject.
2. Verifica che il plugin CMP salvi e applichi lo stato denied su tutti i caricamenti di pagina.
3. Rimuovi plugin di tracking ridondanti che ignorano lo stato CMP.

Correzione generica lato sviluppo

1. Tratta Reject come uno stato runtime eseguibile e non solo come un'azione UI.
2. Blocca loader opzionali su ogni pagina quando il consenso salvato è denied.
3. Testa reload, revisit e navigazione cross-page, non solo il primo caricamento.

Come confermare che la correzione funziona

• Reject e reload: conferma che i cookie opzionali restino assenti.
• Reject e reload: conferma che le richieste opzionali restino bloccate.
• Esegui una nuova scansione e verifica che i finding legati a Reject scompaiano.