Da quando costruisco siti con l’intelligenza artificiale ho smesso di considerare inevitabile una cosa che per anni ho dato per scontata: pagare un servizio esterno per mostrare un cookie banner. Se oggi posso progettare e scrivere un intero sito su misura, perché la parte che governa il consenso dovrebbe essere per forza una scatola nera uguale su migliaia di domini?
La risposta breve è che non deve esserlo. Una gestione del consenso custom può essere più leggera, più coerente con il progetto e perfino più rigorosa di una configurazione standard di iubenda o Cookiebot. Ma c’è una seconda metà della risposta, meno comoda: con l’AI è crollato il costo di scrivere il codice, non quello di assumersene la responsabilità. Il codice si genera in un pomeriggio; capire cosa parte davvero, documentarlo, testarlo e mantenerlo corretto resta un lavoro.
La domanda non è più soltanto «quale CMP compro?». È diventata: «questo sito ha davvero bisogno di una piattaforma generalista, oppure può governare meglio il consenso conoscendo esattamente ciò che fa?»
Prima distinzione: la CMP non è il banner
Nel linguaggio quotidiano chiamiamo CMP la finestra con i pulsanti Accetta, Rifiuta e Personalizza. Quella finestra è soltanto l’interfaccia. Sotto devono esistere almeno altre tre cose: uno stato che ricordi la scelta, un meccanismo che impedisca ai trattamenti opzionali di partire prima del consenso e una modalità per aggiornare o revocare la decisione.
Poi ci sono protocolli che risolvono problemi diversi. Il Consent Mode di Google comunica ai tag Google se determinate forme di archiviazione e trattamento sono consentite. Il Transparency & Consent Framework di IAB Europe serve invece a trasmettere scelte e basi giuridiche lungo una filiera pubblicitaria composta da molti vendor. Un banner può implementare Consent Mode senza usare il TCF; può essere esteticamente perfetto e non bloccare nulla; può bloccare tutto e non conservare una prova adeguata della scelta.
È qui che l’approccio custom diventa interessante: obbliga a smontare la parola “CMP” nei comportamenti reali. Non si installa un badge di conformità. Si decide, voce per voce, che cosa può succedere prima e dopo ogni scelta.
Il caso di questo sito: una CMP grande quanto il problema
Quando ho ricostruito Marketing in Bocconi come sito custom, ho trovato una situazione molto più semplice del pannello di una CMP generalista. Il sito non ospita pubblicità e non fa profilazione. Usa Google Analytics per una sola finalità statistica e conserva i commenti storici su Disqus, che viene caricato soltanto quando il lettore decide di aprirli.
La soluzione è quindi scritta direttamente nel progetto. Prima che possa partire qualsiasi tag, nel <head> i segnali del Consent Mode v2 vengono impostati su denied. Se non esiste una scelta precedente, Google Tag Manager e Google Analytics non vengono nemmeno scaricati: è l’implementazione che Google definisce basic consent mode. Quando l’utente accetta le statistiche, lo stato viene aggiornato e GTM può caricarsi. I segnali pubblicitari restano sempre negati, perché su questo sito non esiste una finalità pubblicitaria da accettare.
La scelta viene salvata localmente con versione e data di aggiornamento. Dal footer si può riaprire il pannello in ogni momento; in caso di revoca lo stato cambia e i cookie analytics conosciuti vengono rimossi. Una rete di sicurezza impedisce inoltre il caricamento accidentale di domini pubblicitari eliminati durante la migrazione dal vecchio WordPress.
Non è una soluzione universalmente migliore. È migliore per questo perimetro, perché rappresenta senza finzioni quello che il sito fa: una finalità opzionale, due decisioni comprensibili, nessuna lista ornamentale di cento partner. Anche l’assenza di dieci interruttori è una forma di granularità, quando esiste davvero una sola finalità da scegliere.
Dove il custom può essere superiore
Il primo vantaggio non è il prezzo, ma la corrispondenza tra interfaccia e architettura. Il banner può usare lo stesso linguaggio del sito, essere accessibile, non cambiare layout e presentare solo opzioni reali. Il codice può partire nel punto esatto della pagina in cui serve, senza attendere una libreria remota. E soprattutto la regola di consenso può vivere accanto al tag che controlla: quando uno sviluppatore aggiunge un nuovo servizio, deve dichiarare anche quale consenso lo abilita.
Su un sito piccolo e stabile questo riduce dipendenze, richieste di rete e possibilità di configurazioni contraddittorie. Permette anche test automatici molto concreti: aprire la pagina come nuovo visitatore, verificare che nessuna richiesta opzionale parta, rifiutare, accettare, revocare e confrontare il traffico di rete atteso.
Il vantaggio però esiste solo se il perimetro è realmente conosciuto. Una scansione manuale fatta una volta e dimenticata non basta. Il sito custom deve avere un inventario dei servizi, controlli in fase di rilascio e una persona responsabile delle modifiche. Senza questo, la semplicità diventa soltanto invisibilità del rischio.
Le condizioni non negoziabili
Le Linee guida del Garante sui cookie e gli altri strumenti di tracciamento non prescrivono il nome del fornitore. Prescrivono il risultato: prima della scelta devono restare attivi soltanto gli strumenti tecnici; il consenso deve derivare da un’azione consapevole; silenzio, caselle preselezionate e semplice scrolling non bastano. Le finalità devono essere comprensibili e le opzioni granulari devono partire dal diniego.
Anche il design è sostanza. Proseguire senza accettare deve essere facile quanto accettare, e il Garante richiama comandi con pari dimensioni, enfasi e colori. La scelta negativa non può essere nascosta in un secondo livello. La revoca deve essere disponibile in modo semplice da ogni pagina, mentre l’informativa deve spiegare finalità, soggetti, durate e conseguenze.
Infine serve accountability: poter dimostrare che cosa l’utente ha scelto e quale versione dell’informativa stava vedendo. Per un sito anonimo e con poche finalità, una registrazione locale ben progettata può essere parte della prova insieme alla documentazione tecnica; in ecosistemi con account, CRM, più dispositivi o molti soggetti, il requisito porta facilmente verso un registro centralizzato. È uno dei punti in cui il “fatto in casa” smette di essere piccolo.
Questo articolo è un’analisi tecnica ed editoriale, non un parere legale. La validità di una soluzione dipende dai trattamenti effettivi, dalle giurisdizioni coinvolte e da come viene implementata.
Advertising: Google permette il custom, ma non in ogni scenario
Qui nasce buona parte della confusione. Per chi usa Google Ads come advertiser, Google contempla esplicitamente un banner costruito in proprio. La sua documentazione spiega come impostare gli stati predefiniti e aggiornarli attraverso la Consent API, compresi ad_storage, ad_user_data, ad_personalization e analytics_storage. La EU User Consent Policy richiede scelte valide, segnali coerenti, registrazione del consenso e istruzioni chiare per la revoca; non obbliga gli advertiser a scegliere un partner commerciale specifico.
Questo rende possibile una CMP custom adatta anche a campagne efficaci. Ma “possibile” non significa “basta mettere quattro valori nella dataLayer”. Se il banner viene distribuito tramite Google Tag Manager, l’ordine è essenziale: Google raccomanda un template che usi le API di consenso di GTM e applichi il default prima dei tag, non un Custom HTML lanciato quando la pagina ha già cominciato a misurare. Ogni tag di terze parti senza controlli integrati deve avere condizioni esplicite.
Il limite cambia per chi monetizza come publisher. Per servire annunci personalizzati con AdSense, Ad Manager o AdMob agli utenti dello Spazio economico europeo, del Regno Unito o della Svizzera, Google richiede una CMP certificata e integrata con il TCF. In quel contesto un banner custom non registrato non è un’alternativa equivalente.
È possibile costruire una CMP privata dentro il TCF, ma significa entrare nel framework. IAB Europe richiede registrazione, quota annuale, validazione prima dell’assegnazione dell’ID e successivi controlli. Non si tratta più di scrivere un componente per un sito: si diventa responsabili di un nodo interoperabile della filiera pubblicitaria, che cambia versione e regole nel tempo.
Il server-side non è un tunnel sotto il consenso
Il tracciamento server-side può essere il passo successivo giusto. Un server container consente di ricevere un flusso first-party, eliminare o trasformare campi, controllare le destinazioni e ridurre il codice eseguito nel browser. È un miglioramento di architettura e governance, non un modo per rendere invisibile il trattamento.
Nella propria guida al Consent Mode con Tag Manager server-side, Google mantiene infatti il banner sul web container: la scelta viene raccolta nel browser, trasmessa nella richiesta e rispettata dai tag sul server. Se il segnale si perde, il server non diventa automaticamente autorizzato. Anzi, spostando il trattamento lontano dagli strumenti visibili del browser, aumenta la necessità di documentarlo e verificarlo.
Il tema è particolarmente attuale: Google dichiara che da agosto 2026 inizierà a introdurre nell’area europea soluzioni pubblicitarie di misurazione e personalizzazione basate anche sugli indirizzi IP. È un motivo in più per evitare la scorciatoia mentale “niente cookie uguale niente consenso” e descrivere ciò che viene davvero inviato.
Dove iubenda e Cookiebot restano difficili da battere
Una critica intelligente alle CMP commerciali deve riconoscere il lavoro che acquistiamo. Nella propria documentazione, iubenda offre blocco preventivo, memorizzazione delle preferenze, documenti collegati e gestione geografica. Cookiebot dichiara scansione automatica di cookie e tracker, dichiarazioni aggiornate, geotargeting e un registro centralizzato dei consensi.
Sono pagine dei fornitori, quindi descrivono funzionalità e non certificano da sole la conformità di ogni installazione. Tuttavia quelle funzioni hanno un valore reale quando esistono decine di siti, molte lingue, team che pubblicano tag senza passare dagli sviluppatori, vendor programmatici o leggi diverse da applicare per area geografica. In questi casi replicare tutto in casa può costare molto più del canone.
La soluzione più matura può essere ibrida: mantenere nel codice l’enforcement e i test, ma usare un servizio per inventario, registro o interoperabilità TCF. Il contrario — delegare il banner e non controllare cosa succede davvero — è invece il peggiore dei due mondi.
Custom, SaaS o ibrida?
| Scenario | Scelta più sensata | Perché |
|---|---|---|
| Un sito, pochi tag, una giurisdizione | Custom | Il perimetro è verificabile e l’interfaccia può rappresentarlo con precisione. |
| Google Ads su un sito proprietario | Custom o ibrida | Consent Mode è implementabile direttamente, purché segnali e tag siano testati. |
| Molti domini, lingue e team | SaaS o ibrida | Scanner, registro e aggiornamenti riducono lavoro operativo e deriva. |
| Publisher con advertising personalizzato Google | CMP certificata | È un requisito della piattaforma per le aree interessate. |
| Programmatic e molti vendor TCF | SaaS o CMP privata validata | L’interoperabilità diventa parte centrale del problema. |
Forse non stiamo comprando conformità, ma manutenzione
La conclusione provocatoria non è che iubenda e Cookiebot non servano più. È che non dovremmo comprarli per riflesso, come se l’abbonamento trasferisse la responsabilità dal titolare al widget. In un progetto semplice, una CMP scritta insieme al sito può essere più chiara, più controllabile e più rispettosa dell’utente. In un ecosistema complesso, la stessa scelta può diventare presunzione tecnica.
Questa possibilità nasce da un cambiamento più grande: con l’AI anche una piccola organizzazione può costruire software aderente ai propri processi invece di adattare ogni processo a un prodotto standard. È lo stesso principio del laboratorio VEDA Academy Il tuo sito online in un fine settimana, attualmente in completamento: partire da ciò che il sito deve fare, costruirlo e misurarlo senza delegare le decisioni allo strumento.
Resta allora una discussione che vale la pena aprire:
- È più rischioso scrivere una CMP custom o installarne una standard che nessuno nel team ha mai verificato?
- Qual è il punto in cui numero di vendor, paesi e finalità rende irresponsabile continuare in casa?
- Chi dovrebbe possedere davvero il consenso: il reparto legale, il marketing o chi scrive e distribuisce il codice?
La mia posizione è questa: custom non significa artigianale, significa esplicito. Se non possiamo spiegare e testare ogni scelta, non abbiamo costruito una CMP migliore. Abbiamo soltanto costruito un altro banner.
Commenti
I commenti storici sono conservati su Disqus. Caricandoli accetti il trasferimento di dati a Disqus.