Consent Mode v2 su PrestaShop: il banner che non svuota il carrello

Un banner cookie configurato male fa perdere il carrello a chi rifiuta, e il Consent Mode v2 su PrestaShop non c’entra: regola solo come si comportano i tag di Google quando il cliente accetta o rifiuta. Il carrello vive in un cookie tecnico del core, e se il banner lo blocca insieme agli altri, chi rifiuta arriva al checkout con il carrello vuoto. È successo davvero, e il caso l’ha raccontato Max Valle pochi giorni fa, su un e-commerce alimentare: una piattaforma di consenso impostata per bloccare “tutti i cookie fino al clic su accetta, compreso quello di sessione del carrello”.

Prima di scrivere cosa configurare ho fatto il censimento vero, il 27 settembre 2026: i cookie che mette PrestaShop letti dal codice della 8.2.8, della 9.1.5 e della 9.2.0-rc.1, gli header HTTP di una demo pubblica di PrestaShop 8.2, un test del carrello cookie per cookie, e due shop PrestaShop reali che seguo, entrambi con iubenda e Consent Mode v2, guardati prima di qualsiasi clic sul banner.

⚠️ Come un banner arriva a svuotare il carrello

Una CMP, la piattaforma che mostra il banner e registra la scelta, può fare due mestieri: mostrare il banner e bloccare quello che non ha ancora il consenso. Il blocco preventivo è quello che le linee guida richiedono, ed è anche quello che rompe lo shop quando classifica male.

Su uno shop PrestaShop i punti in cui succede sono tre:

• un modulo di blocco lato server configurato su “blocca tutto finché non accetta”: se il cookie del carrello non è nella lista dei necessari, non viene scritto, e ogni pagina riparte da un carrello nuovo;
• il blocco automatico degli script della CMP, che riconosce i tracciatori dall’URL o dal codice: se per errore finisce nel blocco uno script del tema o del carrello, il bottone “Aggiungi al carrello” smette di funzionare solo per chi rifiuta;
• una classificazione a mano sbagliata, con i cookie di PrestaShop messi fra le statistiche o il marketing perché “sono cookie” e nessuno li ha guardati.

Nel primo caso il sintomo è netto: l’aggiunta al carrello va a buon fine, poi il carrello è vuoto. Nel secondo il bottone non risponde e basta. In tutti e tre i casi chi accetta non vede niente di strano, quindi il problema lo scopri dagli ordini che mancano, non dai test.

🛠️ I cookie di PrestaShop, uno per uno

Il core scrive due cookie sul front office. Il primo è quello che PrestaShop chiama semplicemente “il cookie”: un solo cookie, con dentro carrello, cliente, ospite, lingua, valuta e paese, cifrato e firmato con un checksum. Il nome è PrestaShop- seguito da un hash md5 costruito su versione, negozio e dominio: per questo cambia da shop a shop, e anche dopo un aggiornamento di versione. Dura 480 ore, cioè 20 giorni, valore di default configurabile in Parametri avanzati > Amministrazione, con SameSite=Lax e HttpOnly.

Il secondo è il PHPSESSID: dalla 1.7.8 il core apre anche una sessione PHP su ogni pagina (la classe SessionHandler, istanziata in config.inc.php). Anche questo è HttpOnly e Lax.

Per il cookie del back office il meccanismo è lo stesso, con un nome diverso: lo riceve solo chi entra nell’amministrazione.

Il test del carrello, cookie per cookie

Su una demo pubblica di PrestaShop 8.2 ho aggiunto un prodotto al carrello con una richiesta vera, poi ho chiesto il riepilogo del carrello quattro volte, cambiando solo i cookie inviati:

Il carrello non dipende dalla sessione PHP: l’id del carrello sta dentro il cookie PrestaShop-, e il codice del FrontController lo conferma, perché il carrello viene ricaricato da cookie->id_cart. Un modulo può appoggiare altro sulla sessione, quindi sul tuo shop il test va rifatto con i tuoi moduli; sul core la risposta è questa.

Il carrello di PrestaShop è un cookie solo.
Se la CMP lo tocca, il carrello non c’è più: il resto è contorno.

Due dettagli che un censimento veloce non vede

Con la full page cache il cookie arriva dopo. Entrambi gli shop reali sono serviti da LiteSpeed Cache, e la home arriva dalla cache (x-litespeed-cache: hit) senza nessun cookie PrestaShop-: nasce alla prima richiesta che la cache non serve, di solito proprio l’aggiunta al carrello. Un censimento fatto guardando solo la home lo manca, e chi configura la CMP partendo da quella lista non lo mette fra i necessari. Il censimento si fa dopo aver messo un prodotto nel carrello, non prima. Su LiteSpeed compare anche lsc_private, il cookie con cui la cache separa le pagine private: tecnico anche quello.

Il PHPSESSID scade nel 2083. Sulla demo 8.2 l’header è expires=Wed, 14 Jul 2083: il core passa alla sessione PHP una data assoluta (adesso più 480 ore) dove PHP si aspetta una durata in secondi, e il risultato sono circa 57 anni. Chrome lo taglia a 400 giorni, che è il tetto che applica a qualsiasi cookie. Il codice è identico nella 9.1.5 e nella 9.2.0-rc.1, ed è già segnalato nella issue #42432, aperta il 27 agosto. Non cambia la natura del cookie, cambia quello che scrivi nella cookie policy alla voce durata.

✅ Cookie PrestaShop: serve il consenso sì o no

La tabella che uso per classificare, con i cookie che si trovano davvero su uno shop PrestaShop. Le prime righe vengono dal core e dal test, le altre dagli shop reali e dalla documentazione dei fornitori.

La colonna “Consenso” è una classificazione tecnica, non un parere legale: dice cosa fa il cookie, non come va scritta la tua informativa. Per i casi di confine, analytics e cookie di funzionalità dei moduli, la decisione finale la prende il consulente privacy dello shop.

⚠️ Cosa ho trovato su due shop reali con iubenda

Due shop PrestaShop che seguo, entrambi con iubenda e Consent Mode v2, aperti in un browser pulito in emulazione di uno smartphone (Pixel 7), senza toccare il banner. Una misura per shop, senza rallentare la rete: i tempi sono indicativi.

• Il default è giusto. In entrambi il dataLayer riceve consent default con tutti e sette i tipi di consenso su denied. È la parte che il Consent Mode v2 chiede, e c’è.
• Il banner copre tutto lo schermo. Alto 839 pixel su 839 di schermo, compare fra 3,8 e 5,7 secondi dopo l’inizio della navigazione. Essendo sovrapposto (position: fixed) non ha spostato il layout e non è l’elemento LCP: le performance misurate non ne soffrono, l’utente sì, perché per qualche secondo vede lo shop e poi un muro.
• Al primo livello non c’è un bottone “Rifiuta”. Ci sono la X in alto, “Scopri di più” e “Accetta”. Per il Garante la X vale come rifiuto se ha la stessa evidenza grafica degli altri comandi: se ce l’ha, lo valuta il consulente.
• Qualcosa parte prima della scelta. Sul primo shop c’era già un cookie di Brevo da 181 giorni, e partivano richieste verso Microsoft Clarity e Bing. Sul secondo partivano richieste verso Clarity e verso Google Analytics con il parametro gcs=G100, cioè con statistiche e pubblicità negate.

Il cookie di Brevo prima della scelta è un problema di classificazione nella CMP, lo stesso tipo di errore che svuota i carrelli ma nel verso opposto. Le richieste di Google Analytics senza consenso, invece, sono il comportamento previsto dalla modalità avanzata del Consent Mode: i tag si caricano comunque e mandano segnali senza cookie. È legittimo? Le linee guida EDPB 2/2023 fanno rientrare nell’articolo 5(3) della direttiva ePrivacy anche pixel e link di tracciamento, perché fanno “accedere” a informazioni del dispositivo. Non è una domanda tecnica, e non la risolvo io in un articolo.

✅ Come configuro il Consent Mode v2 su PrestaShop

L’ordine che seguo, qualunque sia la CMP. Il Consent Mode non mostra nessun banner: la documentazione Google dice chiaro che il consenso lo raccogli tu, con un banner tuo o con una CMP.

1. Censimento dopo il carrello. Finestra anonima, prodotto nel carrello, poi Strumenti per sviluppatori > Application > Cookies: quella è la lista vera. Per i cookie scritti dal server basta anche curl -sI sulla pagina, guardando gli header set-cookie.

2. I cookie tecnici fuori dal blocco. PrestaShop-*, PHPSESSID e quelli della cache vanno fra i necessari, in qualunque CMP o modulo. Il nome del cookie PrestaShop- cambia con la versione: dopo un aggiornamento va ricontrollato, o meglio ancora dichiarato con il prefisso se la CMP lo permette.

3. Il default prima di ogni tag. Il comando consent default va eseguito su ogni pagina prima di qualsiasi comando che manda misurazioni. Con Google Tag Manager è il compito dell’attivatore Consent Initialization; con gtag.js è un blocco in testa al tema, prima del tag:

window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
gtag('consent', 'default', {
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    analytics_storage: 'denied',
    wait_for_update: 500,
});

ad_user_data e ad_personalization sono i due parametri che fanno la “v2”: riguardano l’invio di dati utente a Google per la pubblicità e la pubblicità personalizzata, e per il traffico dello Spazio economico europeo Google li richiede da marzo 2024 per usare le funzioni pubblicitarie: senza quei segnali, misurazione, remarketing e pubblicità personalizzata di Google non sono più tutti disponibili. wait_for_update dà alla CMP il tempo, in millisecondi, di leggere una scelta già salvata prima che i tag partano. Su PrestaShop questo blocco va in un hook di testa del tema o nel modulo della CMP: non dentro un modulo che carica i suoi script a fine pagina.

4. L’aggiornamento lo fa la CMP. Quando il cliente sceglie, la CMP manda consent update con i valori concessi. Le CMP integrate con Google lo fanno da sole: il controllo è che il dataLayer riceva l’update dopo il clic.

5. Base o avanzata. In modalità base i tag Google restano bloccati finché non c’è il consenso e senza consenso non parte niente, nemmeno lo stato. In modalità avanzata partono subito e, a consenso negato, mandano segnali senza cookie che Google usa per la modellazione delle conversioni. La differenza tecnica è questa, la scelta è del consulente privacy (vedi il punto EDPB qui sopra).

6. Il banner sopra la pagina, non dentro. Un banner inserito nel flusso della pagina spinge giù il contenuto e sporca il CLS; sovrapposto non lo fa. Sui due shop reali è così.

7. La prova che conta. Finestra anonima, X o “Rifiuta”, un prodotto nel carrello, cambio pagina, ricarica: il carrello deve esserci ancora, e il checkout deve arrivare fino al pagamento. Poi, strumenti per sviluppatori aperti, si guarda la rete: nessuna richiesta di tracciamento con cookie prima della scelta, e le richieste Google col parametro gcs, che trasporta lo stato di ad_storage e analytics_storage.

⚠️ Il consent rate, con i numeri di chi vende i banner

Nella live di Tag Manager Italia del 25 settembre iubenda ha presentato il consent rate come “la prima conversione del sito” e ha portato due dati: meno dell’1,5% degli utenti personalizza le preferenze, e gli agenti AI che navigano da browser tendono a rifiutare. Sono dati di un fornitore di CMP, non pubblicati con un metodo che si possa verificare: li riporto per quello che sono. Il punto utile resta: quasi nessuno apre le preferenze, quindi quello che il cliente vede al primo livello del banner decide tutto.

⚠️ Cosa resta al consulente privacy

Questo pezzo copre l’implementazione. Restano fuori, e vanno portate al consulente privacy dello shop:

• la scelta fra modalità base e avanzata del Consent Mode;
• se gli analytics si possono trattare come tecnici, con le condizioni del Garante (dati minimizzati, solo statistiche aggregate, nessun incrocio da parte del fornitore);
• se la X del banner ha l’evidenza grafica che il Garante chiede, o se serve un “Rifiuta” esplicito;
• il testo della cookie policy, durate comprese.

Dal lato tecnico gli porti la lista dei cookie reali e la prova del carrello: è il materiale che serve per decidere, invece di una lista generica presa da un modello.

✅ Prima di toccare il banner

Il Consent Mode v2 si configura in un pomeriggio, la parte lunga è sapere cosa gira davvero sullo shop: quali cookie nascono dopo il carrello, quali tag partono prima della scelta, quali moduli la CMP blocca senza che nessuno se ne accorga. È il tipo di controllo che faccio come assistenza PrestaShop, su una copia dello shop quando serve, prima che il banner costi ordini. Scrivimi da uno dei canali qui sotto: dimmi che CMP usi e da quando l’hai messa.

Fonti primarie: linee guida cookie del Garante, provvedimento n. 231 del 10 giugno 2021, FAQ del Garante sui cookie, EDPB, Guidelines 2/2023 sull’ambito tecnico dell’art. 5(3) ePrivacy, versione 2.0 adottata il 7 ottobre 2024, concetti del Consent Mode, configurazione del Consent Mode, aggiornamenti del Consent Mode per il traffico SEE, FAQ Google sulla EU user consent policy, cookie di Google Analytics, componente Cookie nella devdocs PrestaShop, classes/Cookie.php della 9.1.5, config.inc.php della 9.2.0-rc.1, issue #42432 sul PHPSESSID, cookie delle preferenze di iubenda. Il caso del carrello svuotato è di Max Valle (23 settembre 2026); i dati sul consent rate sono di iubenda, nella live di Tag Manager Italia del 25 settembre 2026. Header, test del carrello e rilevazioni sugli shop sono del 27 settembre 2026: una demo pubblica di PrestaShop 8.2 (ps8.2.demopresta.it), due shop PrestaShop reali con LiteSpeed Cache e iubenda, anonimi.