Durata del consenso
Quanto dura un consenso salvato e in quali casi il banner ricompare a un visitatore che aveva già scelto.
💡 Se un cliente chiede «perché ai miei utenti riappare il banner?», la risposta è in Quando il banner ricompare.
Una sola chiave: consentExpiryDays
La durata si imposta con consentExpiryDays, in giorni. La stessa chiave governa due cose:
- la validità del consenso: al salvataggio il core scrive nel consenso una scadenza,
adesso + consentExpiryDays. Dopo quella data il consenso non vale più e il banner ricompare; - la durata dello storage che lo contiene: con
store.type: 'cookie'il cookieavacy_consenthamax-agepari aconsentExpiryDays. Conlocal-storagela voce non scade da sola: il core la cancella quando legge un consenso scaduto.
L'id dell'archivio consensi sta dentro avacy_consent (meta.consentId), quindi scade con lui.
Nel banner legacy le due durate erano separate: il consenso scadeva secondo la configurazione, ma il cookie restava scritto un anno. Nel v3 la durata dichiarata al visitatore (sezione «Conservazione» del Centro Preferenze) è quella reale.
Il default è 180 giorni
Se la chiave manca vale 180 giorni, lo stesso valore del banner legacy (cookie_expires_in_days). Un valore non numerico, o minore o uguale a zero, ricade su 180 con un warning in console; un valore decimale viene arrotondato per difetto.
Dalla SaaS la durata si sceglie nelle Impostazioni avanzate del banner. Con i preset IAB e Google Consent Mode il minimo è 183 giorni, e scegliere un preset la imposta a 183; con il preset manuale il minimo è 1 giorno. Il massimo è 400 giorni, per il limite dei browser descritto sotto.
Il limite dei browser: 400 giorni
I browser limitano la vita di un cookie a 400 giorni (Chrome dalla versione 104; Safari, con ITP, può cancellare prima). Con un consentExpiryDays più alto il browser accorcia il cookie senza avvisare: il consenso sparisce prima della scadenza dichiarata e il banner ricompare. Nessuna configurazione lo impedisce. Per una durata dichiarata che sia anche quella reale, resta sotto i 400 giorni.
Quando il banner ricompare
A ogni caricamento di pagina il core legge il consenso salvato e decide se è valido. Il banner ricompare quando il consenso non c'è oppure non dimostra di essere valido.
Il consenso non c'è
| Caso | Cosa succede |
|---|---|
| Prima visita, o il visitatore ha cancellato i dati del sito | Nessun consenso nello storage. |
| Il browser ha cancellato il cookie | Scadenza naturale, pulizia automatica, navigazione in incognito chiusa, ITP di Safari. |
| Il visitatore arriva da un altro host | Il cookie è scritto senza attributo domain, quindi vale per l'host esatto: un consenso dato su www.esempio.it non si vede su esempio.it. |
localStorage non è accessibile | Navigazione privata, storage pieno, iframe con lo storage di terze parti bloccato. |
Il consenso c'è ma viene rifiutato
| Caso | Motivo |
|---|---|
| Scaduto | È passata la scadenza scritta al salvataggio (consentExpiryDays). |
| Versione della policy superata | policyVersion in configurazione è più alta di quella salvata col consenso. È il modo per chiedere di nuovo il consenso a tutti, per esempio dopo un cambio della policy. |
| Illeggibile | Il contenuto dello storage non si decodifica, o non ha i metadati del consenso. |
| Senza scadenza | Il consenso non dichiara una scadenza. Le nostre scritture la hanno sempre, quindi è un consenso che non possiamo dimostrare valido. |
| Raccolto da un'altra CMP | La TC String salvata ha un cmpId diverso dal nostro, oppure ha portata globale (isServiceSpecific: false). Vedi sotto. |
In tutti questi casi il consenso vale come assente: getConsent() risponde valid: false e il banner ricompare. Un consenso che non sappiamo dimostrare non viene onorato.
Ricompare anche quando lo chiedi tu: Avacy.reload() rilegge la configurazione, e se con quella il consenso non è più valido (per esempio dopo aver alzato policyVersion) rimostra il banner. Non esiste invece un comando per forzare il banner su un consenso valido.
Il consenso raccolto da un'altra CMP non si eredita. Il giorno del passaggio tutti i visitatori del sito rivedono il banner, anche quelli che avevano già scelto.
È voluto: non possiamo dimostrare un consenso che non abbiamo raccolto noi. Va detto al cliente prima della migrazione, perché scoperto dopo sembra un difetto.
Vale anche per chi passa dal banner Avacy legacy al v3: il v3 non legge oil_data, quindi anche lì il banner ricompare una volta a tutti (vedi la guida di migrazione).
Riferimenti nel codice
| Cosa | Dove |
|---|---|
Default e normalizzazione di consentExpiryDays | packages/core/src/providers/providers.types.ts (DEFAULT_CONFIG), packages/core/src/providers/config.ts |
| Scadenza scritta al salvataggio | packages/core/src/listeners/on-consent.ts |
| Regole di rifiuto | packages/core/src/consent.utils.ts: storedConsentRejection(), foreignConsentRejection() |
| Durata del cookie | packages/core/src/providers/stores/cookie.ts |
Pulizia del consenso scaduto in localStorage | packages/core/src/providers/stores/local-storage.ts |
| Analisi dei casi | openspec/changes/cmp-web-base-build/pbi/33-banner-reshow-cases.md |