Due compiti diversi

Quando un visitatore fa una scelta di consenso, devono accadere due cose distinte. Primo, il browser deve ricordare la scelta, così il banner non ricompare a ogni pagina e i tag sanno cosa possono fare. Secondo, potresti dover dimostrare in seguito che la scelta è stata fatta, cosa è stato mostrato al visitatore e quando. Questi compiti sono spesso affidati a meccanismi di memorizzazione diversi, e confonderli causa problemi reali: banner che continuano a ricomparire, scelte che svaniscono su alcuni browser o nessun registro da esibire quando qualcuno lo chiede.

Questo confronto esamina le tre opzioni più comuni — cookie first-party, storage del browser come localStorage e registri di consenso lato server — e dove si colloca ciascuna.

Opzione 1: cookie first-party

I cookie sono la sede tradizionale dello stato di consenso. I CMP TCF di solito memorizzano la stringa di consenso in un cookie first-party, e molti CMP vi memorizzano anche i propri dati sulle preferenze.

Punti di forza

• Leggibili dal server. Il cookie viene inviato con ogni richiesta, quindi il codice lato server, la logica edge e il tagging lato server possono leggere la scelta senza attendere JavaScript.
• Condivisibili tra sottodomini. Un cookie impostato sul tuo dominio registrabile può coprire i sottodomini www, blog e shop.
• Ampiamente previsti. Molte integrazioni ad tech cercano il consenso nei cookie.

Punti deboli

• Limiti di dimensione. I browser limitano la dimensione dei cookie a circa 4 KB, e una stringa TCF con molti vendor più altri valori può avvicinarsi a quel limite.
• Overhead sulle richieste. Ogni richiesta al tuo dominio porta il cookie, comprese quelle di immagini e script.
• Limiti di durata in alcuni browser. L'Intelligent Tracking Prevention di Safari limita a un massimo di sette giorni la durata dei cookie creati tramite JavaScript. I cookie impostati dal tuo server in una risposta HTTP sono in genere trattati con più larghezza, anche se ci sono eccezioni.

Opzione 2: localStorage e altri storage del browser

Alcuni CMP memorizzano preferenze dettagliate in localStorage, a volte insieme a un cookie più piccolo.

Punti di forza

• Più spazio. Diversi megabyte per origine, sufficienti per scelte dettagliate a livello di vendor.
• Nessun overhead sulle richieste. Non viene inviato automaticamente nulla al server.

Punti deboli

• Invisibile al server. Il codice lato server e la logica edge non possono leggerlo, quindi qualsiasi decisione lato server deve attendere il browser.
• Legato a una sola origine. Lo storage su www.example.com non è disponibile su shop.example.com, quindi un visitatore può rivedere il banner su ogni sottodominio.
• Soggetto a cancellazione. Safari può rimuovere lo storage scrivibile da script, localStorage incluso, per i siti con cui l'utente non ha interagito per sette giorni di utilizzo del browser, e le modalità di navigazione privata di solito lo cancellano alla fine della sessione.

Opzione 3: registri di consenso lato server

Un registro lato server è una voce memorizzata da te o dal tuo provider CMP ogni volta che viene fatta una scelta. Di solito contiene un identificatore pseudonimo, il timestamp, le scelte, la versione del banner o della policy mostrata e un contesto come la regione.

Punti di forza

• Prova durevole. Sopravvive alla cancellazione dei cookie e alle restrizioni dei browser, il che lo rende lo strumento giusto per dimostrare che il consenso è stato ottenuto.
• Verificabile. Puoi produrre report sulle scelte nel tempo e rispondere a domande su eventi specifici.
• Potenziale multi-dispositivo. Per i lettori connessi, un registro sul server può sincronizzare le scelte tra dispositivi, se lo spieghi loro.

Punti deboli

• Non sostituisce lo stato locale. I tag nel browser hanno comunque bisogno di un segnale locale rapido; interrogare un server a ogni visualizzazione di pagina per cercare il consenso aggiunge latenza.
• È esso stesso un dato personale. I registri richiedono un periodo di conservazione, controlli di accesso e un posto nella tua informativa sulla privacy.
• Dipendenza da un identificatore. I visitatori anonimi possono essere associati a un registro solo tramite un identificatore memorizzato sul loro dispositivo, il che ti riporta allo storage locale.

Riepilogo a confronto

• Migliore per ricordare la scelta sul web: cookie first-party, idealmente impostati dal tuo server con una durata stabile.
• Migliore per dati dettagliati sulle preferenze nel browser: localStorage, abbinato a un cookie che il server può leggere.
• Migliore per dimostrare la scelta: registri lato server.
• Peggior scelta singola: affidarsi solo a localStorage, che lascia il server alla cieca e rende la scelta fragile su alcuni browser.

Un approccio combinato pratico

1. Memorizza il segnale locale di riferimento — per esempio la stringa TCF e un record compatto delle preferenze — in un cookie first-party limitato al tuo dominio registrabile.
2. Usa localStorage solo per dati supplementari che non devono raggiungere il server.
3. Scrivi un registro lato server per ogni scelta, includendo la versione del banner e della policy mostrate.
4. Se una scelta memorizzata scompare, mostra di nuovo il banner invece di presumere una risposta precedente.
5. Imposta un periodo di nuova richiesta per le scelte memorizzate e riportalo nella tua policy.

Memorizzare la scelta di consenso del visitatore è in genere considerato necessario per fornire il servizio richiesto dal visitatore — ricordare la sua decisione — ma verifica le indicazioni applicabili nei tuoi mercati principali.

Punti chiave

• Ricordare una scelta e dimostrare una scelta sono compiti diversi che richiedono storage diversi.
• I cookie sono leggibili dal server e condivisibili tra sottodomini, ma limitati in dimensione e, in Safari, in durata quando impostati da script.
• localStorage offre spazio ma è invisibile al server e può essere cancellato dai browser.
• I registri lato server sono il livello di prova, non un sostituto del segnale locale.
• Combina un cookie first-party impostato dal server, uno storage del browser facoltativo e registri sul server.