Salta al contenuto
Analisi

Banner cookie: CMP di terze parti o soluzione propria? Come abbiamo deciso

Abbiamo sostituito una CMP commerciale con una soluzione interna. Le tre condizioni che l'hanno resa praticabile, la funzione che abbiamo dovuto ricostruire da zero e perché per molte aziende non conviene.

SynSphere Italia Pubblicato il 11 min di lettura
Confronto fra CMP di terze parti e banner di consenso cookie sviluppato internamente

Il 29 luglio 2026 abbiamo tolto da questo sito la CMP commerciale che gestiva il consenso ai cookie e l’abbiamo sostituita con una soluzione sviluppata internamente. Non è una scelta che consigliamo a tutti — e la parte utile di questo articolo è capire quando non conviene.

Perché il risparmio di canone è la ragione peggiore per farlo, e la funzione che si perde senza accorgersene può costare molto più della licenza.

Le tre condizioni che l’hanno resa praticabile

Non l’abbiamo fatto perché sappiamo scrivere codice. L’abbiamo fatto perché ricorrevano tre condizioni insieme, e se ne manca una il conto cambia segno:

  1. Un solo servizio terzo richiede il consenso. Su questo sito è Google Analytics 4, e nulla più. Cloudflare Turnstile, che protegge il form di contatto, è una misura strettamente necessaria e non richiede consenso. Con dieci script di terze parti, la mappatura e il blocco preventivo di ognuno diventano il lavoro, e una CMP commerciale lo fa già.
  2. La cookie policy è contenuto nostro, una pagina che scriviamo e manteniamo, non un documento generato e ospitato dal fornitore. Chi usa l’informativa generata dalla CMP, sostituendola, perde anche quella.
  3. Il codice resta manutenibile da noi. Una CMP non è un progetto che si chiude: cambiano le indicazioni delle autorità, cambiano gli script del sito. Se non c’è chi la segue nei prossimi tre anni, è un debito.

Se queste tre non ci sono, una CMP commerciale costa meno del lavoro che evita. È il caso della maggior parte dei siti aziendali, e vale la pena dirlo chiaramente prima di raccontare la parte tecnica.

La funzione che abbiamo dovuto ricostruire da zero

Qui sta l’unica lezione davvero trasferibile di tutta la migrazione, e la abbiamo capita progettando, non dopo.

Il cookie di consenso non è una prova del consenso.

L’art. 7, par. 1 del GDPR chiede al titolare di essere in grado di dimostrare che il consenso è stato prestato. Il cookie risiede sul dispositivo dell’utente: è sotto il suo controllo, non sotto il nostro. Può cancellarlo, modificarlo, cambiare dispositivo. Come prova non vale nulla.

Le CMP commerciali questa cosa la fanno, e la fanno in silenzio: conservano i record di consenso sui propri server. Sostituendole senza ricostruire quella capacità, la si perde — e non c’è nessun errore, nessun avviso, nessun test che fallisce. Il banner funziona perfettamente, l’azienda semplicemente non è più in grado di dimostrare nulla.

Per questo la parte più delicata del lavoro non è stata il banner: è stato un registro delle prove lato server.

Come si progetta un registro delle prove senza costruire un profilo

Un registro dei consensi è un archivio che nasce per dimostrare la conformità. È perciò il posto più imbarazzante in cui violare il principio di minimizzazione — e la tentazione c’è, perché “più dati, più prova” sembra ragionevole.

Non lo è. Serve dimostrare che il consenso è stato dato e su quali finalità, non chi l’ha dato. Le nostre scelte:

RegistriamoNon registriamo
identificativo casuale della sceltal’indirizzo IP in chiaro
momento della sceltalo user agent completo
versione dell’informativa a cui si riferiscedati che permettano di risalire alla persona
esito per categoria
percorso della pagina in cui è stata espressa
un’impronta non reversibile dell’IP

L’identificativo casuale è il punto che regge tutto: non identifica la persona, serve solo a collegare il cookie presente sul dispositivo alla riga nel registro. Se domani qualcuno contesta di non aver acconsentito, il confronto fra i due valori è la verifica — e non richiede di sapere chi fosse.

L’impronta dell’IP è un hash troncato con un sale dedicato: consente due cose legittime — limitare gli abusi sull’endpoint e correlare più record della stessa origine in caso di contestazione — senza permettere di risalire all’indirizzo.

Tre dettagli che si scoprono solo implementando:

  • Il percorso del file di log va fuori dalla cartella dell’applicazione. Se sta dentro, il primo deploy che sovrascrive quella directory azzera l’archivio delle prove. Vale per qualsiasi dato persistente in un’app che si aggiorna sostituendo i file.
  • Un endpoint pubblico di logging senza limiti è un modo per far crescere i log all’infinito. Serve un rate limit, con soglie larghe: una persona esprime la scelta una volta e la cambia raramente.
  • Se l’archivio non è scrivibile, la richiesta non deve fallire. La scelta dell’utente è già stata applicata sul client: far vedere un errore per un problema di scrittura sarebbe il comportamento sbagliato. Va segnalato nei log — è una condizione da correggere, non da ignorare.

I requisiti del Garante che si sbagliano facilmente

Le linee guida del Garante sui cookie del 10 giugno 2021 sono precise su alcuni punti che in un banner scritto in casa è facile mancare:

  • Nessun dark pattern. “Accetta” e “Rifiuta” devono avere lo stesso peso visivo e stare al medesimo livello. Il rifiuto nascosto in un secondo passaggio, o reso graficamente meno evidente, è precisamente ciò che l’autorità contesta.
  • Nessun consenso da scroll o da navigazione continuata. Chi scorre la pagina non ha acconsentito.
  • Revoca sempre disponibile, quindi un elemento persistente su tutte le pagine — non un link sepolto in fondo alla cookie policy.
  • Non riproporre il banner prima di sei mesi, salvo cambi delle condizioni. La nostra scelta si conserva 180 giorni.

Su quest’ultimo punto abbiamo aggiunto una cosa che le CMP gestiscono e che va replicata: lo schema di consenso è versionato. Se cambiano le categorie o le finalità, incrementare la versione fa ricomparire il banner a tutti — perché il consenso raccolto sulle vecchie finalità non copre le nuove. Senza quel meccanismo, un giorno si aggiunge uno script e si continua a considerare valido un consenso che non lo è.

Nota tecnica sul comportamento di GA4: resta caricato anche prima della scelta, ma con Consent Mode v2 in stato negato per impostazione predefinita, che invia soltanto segnali anonimi senza cookie. È lo stesso schema che usava la CMP precedente. Le categorie pubblicitarie restano negate in ogni caso, perché il sito non ospita advertising.

Il vincolo da verificare prima di tutto il resto

C’è una condizione che va controllata all’inizio della valutazione, perché rende la scelta reversibile solo a un costo.

Per pubblicare annunci Google o usare AdSense nello Spazio economico europeo, Google richiede una CMP certificata da Google. Non è un requisito tecnico né normativo: è una policy del fornitore, e non si aggira scrivendo codice migliore. L’elenco delle CMP certificate lo pubblica Google, e una soluzione sviluppata internamente non vi entra per il solo fatto di essere conforme al GDPR.

La conseguenza pratica: se fate advertising Google, o pensate di farlo, la sostituzione della CMP non è sul tavolo — o meglio, lo è al prezzo di rinunciare a quel canale. È la prima domanda da farsi, non l’ultima: chi investe in Google Ads e cambia CMP per risparmiare un canone scopre il vincolo nel momento peggiore, cioè quando la campagna viene bloccata.

Quando invece è la scelta giusta

Riassumendo il criterio, senza vendere nulla: la sostituzione ha senso quando pochi vendor richiedono consenso, l’informativa è già contenuto proprio, non c’è advertising Google in gioco e c’è chi mantiene il codice. In quel quadrante si ottiene un banner che non fa nessuna richiesta a domini esterni, un cookie di prima parte, un controllo completo su testi e comportamento, e nessuna dipendenza da un servizio terzo per una funzione che è in mezzo fra l’utente e ogni pagina del sito.

Fuori da quel quadrante, la risposta onesta è che una CMP commerciale fa il suo lavoro e costa meno del vostro tempo.


Stato delle informazioni: aggiornate al 14 agosto 2026. I riferimenti sono le linee guida del Garante sui cookie e altri strumenti di tracciamento del 10 giugno 2021 e l’art. 7 del GDPR sulla dimostrabilità del consenso. Questo articolo descrive scelte progettuali fatte su un caso concreto — il nostro — e non è una consulenza legale: la valutazione va fatta con chi assiste l’azienda sulla privacy.

Se state ragionando sulla stessa decisione, o se avete un’applicazione in cui il consenso va gestito insieme ad altre logiche, è il tipo di lavoro che facciamo nei progetti web application e backend e API. E se il tema è il tracciamento in senso più ampio, la novità di quest’anno sono le linee guida sul tracking pixel nelle email, con scadenza a fine ottobre: scriveteci se vi serve una mano su entrambi.

Prodotti e servizi SynSphere correlati

Dal catalogo SynSphere, quello che c'entra con questo articolo.