Case study tecnico | Sicurezza & indipendenza

Un’architettura di consenso costruita per i nostri progetti, per la sicurezza e la sovranità dei dati

Per le nostre applicazioni web abbiamo sviluppato noi stessi la gestione dei consensi, invece di affidarla a una piattaforma esterna. Funzione, design e comportamento li decidiamo noi; consensi e registri restano sulla nostra infrastruttura – senza script di terzi nel percorso di caricamento e senza canoni ricorrenti.

Progetto di riferimento

Interfaccia

Banner e impostazioni nel design del progetto

Motore di consenso

Stato, versionamento, registro, filtraggio

Sorgente dati

JSON, API o CMS – intercambiabile

Tre livelli distinti: al centro il motore che governa il funzionamento, sotto la sorgente dati intercambiabile, sopra l'interfaccia che appartiene al singolo progetto.

Dati del progetto

Tipo: Case study tecnico
Modulo: @woop-technology/consent
Progetti di riferimento: Woop Art
Questo sito web
Stato: In uso | in sviluppo continuo
Integrazione: React | Next.js App Router
Distribuzione: Registro pacchetti privato

Aree principali

Architettura di consenso
Sovranità dei dati
Google Consent Mode v2
Registro dei cookie
consensi versionati
filtraggio degli script
sorgenti dati intercambiabili
multilinguismo
interfacce specifiche per progetto
registrazione lato server

Punto di partenza

Perché abbiamo sviluppato il nostro consent management

Le applicazioni web integrano spesso servizi esterni come analytics, mappe, video o prenotazioni di appuntamenti. Ne derivano flussi di dati aggiuntivi – e due domande: a quali condizioni questi servizi possono essere caricati, e cosa succede ai dati una volta che hanno lasciato il nostro server.

La risposta ovvia sarebbe una piattaforma di consenso esterna. Per noi avrebbe portato tre cose che non volevamo: un’altra fattura mensile, un sistema di consenso che entra nell’applicazione solo fin dove lo prevede il fornitore – e i dati di consenso dei nostri visitatori su server altrui.

Per questo abbiamo sviluppato il nostro consent management: come parte integrante della nostra architettura applicativa, riutilizzabile e adattabile – e costruito in modo che i dati restino esclusivamente sulla nostra infrastruttura.

La soluzione doveva

01Gestire consensi e valori di memorizzazione in modo centralizzato, senza fornitore esterno
02Attivare i servizi in base al consenso
03Elaborare consensi e registri esclusivamente sulla nostra infrastruttura
04Supportare lingue, fonti di dati e interfacce diverse
05Essere riutilizzabile, senza canoni aggiuntivi al mese o per progetto

Ne è nato un motore di consenso autonomo, oggi impiegato come modulo tecnico comune nei nostri progetti.

Indipendenza & sicurezza

Tre cose che non diamo in mano ad altri

Una piattaforma di consenso esterna aggiunge un fornitore: script propri, configurazione propria, server propri e un canone ricorrente. Il nostro motore gira invece insieme all’applicazione, all’interno della stessa infrastruttura e con gli stessi strumenti.

In concreto si riassume in tre punti.

Costi: Nessuna licenza per dominio, per visualizzazione di pagina o al mese. I costi nascono una volta nello sviluppo e poi nella manutenzione.È sostenibile perché lo stesso componente gira in più progetti.
Controllo: Funzione, base dati, design e comportamento li definiamo noi – fin dentro il codice applicativo, che può interrogare direttamente lo stato del consenso.Nulla finisce dove finisce l’offerta di un fornitore.
Dati: Configurazione, consensi e registri si trovano sui nostri server. Nessun terzo memorizza, elabora o vede le decisioni dei visitatori.

La funzione di consenso non richiede una CMP esterna

La configurazione del consenso e il motore centrale fanno parte dell'applicazione stessa. Per il sistema di consenso non è quindi necessario alcun fornitore CMP esterno.

Questo significa

nessuno script CMP aggiuntivo
nessuna chiamata di rete esterna per la funzione di consenso stessa
nessuna interfaccia di consenso di terze parti
nessuna dipendenza di piattaforma aggiuntiva solo per la gestione dei consensi

I servizi soggetti a consenso restano distinti e vengono caricati solo quando il consenso necessario è presente.

Meno codice di terzi, meno superficie d’attacco

Uno script di consenso esterno viene eseguito con gli stessi diritti della pagina e viene caricato da un server di terzi. Ogni versione distribuita dal fornitore diventa così parte del sito senza poter essere verificata nel dettaglio.

Con fornitori affermati questo di norma non è un problema. Preferiamo comunque conoscere il codice che gira sulle nostre pagine: il nostro motore è versionato, verificato e distribuito come il resto del codice dell’applicazione.

L’endpoint di registrazione

accetta solo richieste provenienti dall’origine del sito
verifica che ogni richiesta contenga campi completi e ammessi
tronca l’indirizzo IP prima di salvarlo
si trova su un percorso fisso per il quale il firewall a monte può tenere regole proprie

Consensi e registri si trovano sui nostri server

Nella gestione dei consensi non è coinvolto nessun altro fornitore. La decisione di un visitatore ha effetto nell’applicazione e viene registrata sullo stesso server su cui gira l’applicazione – dove vengono elaborati anche gli altri dati del progetto. Vale per ogni progetto che utilizza il motore: le decisioni vengono registrate localmente nel container della rispettiva applicazione.

Quali altri servizi esterni utilizzi un progetto concreto e quali dati vengano trasmessi in tale ambito viene definito e documentato separatamente, progetto per progetto.

Architettura

Tre livelli separati per logica, dati e presentazione

Il sistema di consenso separa la logica funzionale centrale dai dati specifici del progetto e dall'interfaccia visibile.

La stessa base tecnica può così essere impiegata in applicazioni diverse, senza dover reimplementare stato del consenso, versionamento o filtraggio degli script per ogni progetto.

Il modulo include un’interfaccia standard che il progetto personalizza o sostituisce del tutto. Così lo stesso motore gira su una piattaforma d’arte e su un sito aziendale, sebbene le due interfacce differiscano nel design.

Motore di consenso: Il motore centrale svolge le funzioni che restano uguali nei diversi progetti:
stato del consenso
verifica della versione
registro dei cookie
filtraggio degli script
soluzioni a due clic
revoca
pulizia dei valori di archiviazione dichiarati
Google Consent Mode v2
La logica funzionale comune viene mantenuta centralmente e messa a disposizione come modulo riutilizzabile.
Sorgente dati: Il motore riceve le informazioni specifiche del progetto tramite un'interfaccia definita. Tra queste, ad esempio:
versione del consenso
categorie e servizi
cookie e altri valori di archiviazione
testi per lingua
configurazioni degli script
L’implementazione fornita legge file JSON nel progetto. Un CMS headless o un’API propria si collega implementando la stessa interfaccia – il motore non ne risente.
Interfaccia: Banner e finestra delle impostazioni vengono progettati per il singolo progetto. L'interfaccia riceve dal motore centrale i dati necessari e un insieme definito di azioni.L'aspetto visivo può così essere adattato a ogni progetto senza dover modificare la logica di consenso sottostante.

Tutto sulla nostra infrastruttura.

0Fornitori esterni

0Script CMP esterni

Progetto di riferimento | Woop Art

3Categorie di consenso

4Servizi

7Cookie

2Lingue

Progetto di riferimento | Questo sito web

3Categorie di consenso

4Servizi

7Cookie

5Lingue

I valori sotto i progetti di riferimento si riferiscono alla rispettiva configurazione. Categorie, servizi e cookie sono liberamente configurabili.

Un modulo comune invece di soluzioni isolate per progetto

Il motore di consenso viene fornito come package proprio tramite il registro di pacchetti privato di Woop Technology. Versioni e modifiche sono gestite centralmente; ogni progetto integra la versione di cui ha bisogno e adotta gli aggiornamenti secondo i propri tempi – progetti diversi possono quindi usare versioni diverse contemporaneamente.

Ogni nuovo progetto aggiunge quattro ambiti:

01Dati: Categorie, servizi, valori di archiviazione e testi.
02Persistenza: Dove vengono archiviati i registri delle decisioni di consenso.
03Integrazioni: Analytics e altri servizi soggetti a consenso.
04Design: Interfaccia predefinita oppure componenti di banner e impostazioni su misura.

Stato del consenso, versionamento, registro, filtraggio degli script e revoca provengono dal modulo comune. I miglioramenti al motore possono essere trasferiti in più progetti tramite aggiornamenti versionati.

Cosa porta il motore, cosa decide il progetto

01Motoreconsenso per categoria, versionamento, revoca, pulizia dei cookie, gating degli script, Google Consent Mode v2
02Progettofonte dei dati (JSON, API o CMS headless), lingue, interfaccia (UI standard o componenti propri), integrazioni (hook, soluzioni a due clic)
03Persistenzacookie di consenso nel browser, registrazione lato server, indirizzi IP troncati
04Stack & gestioneReact, TypeScript, Next.js App Router, dependency injection, registro di pacchetti privato, input verificati

Che cosa salva un consenso nel browser

Impostazioni di consensoDemo

Tecnicamente necessarioSempre attivo

AnalyticsNon consentito

MarketingNon consentito

Attivate o disattivate una categoria. Il terminale mostra ciò che il motore scrive nel cookie.

Browser | Cookie

// _wt_ci_consent// Non ancora impostato – non c'è alcuna decisione. Analytics e marketing non vengono caricati.{
  "consentId": "00000000-0000-4000-8000-000000000000",
  "version": "1.2.0",
  "acceptedAt": "2026-09-23T00:00:00.000Z",
  "acceptedPurposes": {
    "essential": true,
    "analytics": false,
    "marketing": false
  }
}

Rappresentazione semplificata: qui ogni modifica vale subito, nella finestra reale solo al salvataggio – e ogni salvataggio viene registrato lato server. Campi e versione corrispondono al motore di questo sito. Verificato il 21 settembre 2026 in un ambiente di test: l'integrazione analytics testata viene caricata solo dopo il relativo consenso.

Due clic prima che un servizio esterno venga caricato

Non ogni consenso appartiene al banner. Per i servizi incorporati come la prenotazione di appuntamenti, il motore lo richiede là dove il visitatore vuole effettivamente usare il servizio.

Primo clic: avviso e nuova etichetta. Un clic accanto chiude l'avviso senza che Google sia stato caricato.

Registrazione della homepage di questo sito. Verificato il 23 settembre 2026: al caricamento della pagina e dopo il primo clic nessuna richiesta raggiunge un server esterno; tutte le richieste a Google seguono il secondo clic.

01
Primo clic: l'avviso
Il pulsante indica quale fornitore verrebbe caricato e quali dati verrebbero trasmessi. La sua etichetta diventa «Carica Google Calendar».
02
Secondo clic: il caricamento
Solo ora vengono inclusi script e foglio di stile del fornitore e si apre la prenotazione. Fino a quel momento nessuna richiesta raggiunge Google.
03
Senza passare dal banner
Il visitatore non deve abilitare alcuna categoria nelle impostazioni di consenso. La decisione avviene sul servizio stesso, solo per quel servizio.

I componenti necessari si trovano nello stesso package del motore: pronti per Google Calendar e Calendly, e disponibili per altri servizi tramite un componente di base comune.

L'ID di consenso è a portata di clic

Ogni decisione viene registrata sul server, ma si ritrova in modo univoco solo tramite il suo ID di consenso. Un componente dedicato mette questo ID a portata di mano dei visitatori.

L'ID si trova nel cookie di consenso, dove nessuno lo vede senza strumenti per sviluppatori. Eppure è l'unica via univoca verso la voce sul server, perché l'indirizzo IP viene salvato solo in forma troncata.

Il componente mostra l'ID e lo copia con un clic. In caso di domanda, reclamo o richiesta di accesso, i visitatori lo inviano direttamente e la voce si trova senza domande di chiarimento – con ora, versione e scelta.

Il componente si trova nella dichiarazione sulla protezione dei dati del sito in questione e da lì porta anche direttamente alle impostazioni di consenso.

Stato del consenso: Non impostato

Il vostro ID di consenso attuale

Questo ID unico viene memorizzato localmente nel vostro browser e in forma pseudonimizzata sul nostro server per dimostrare la vostra scelta in materia di privacy. Per domande o reclami sul vostro consenso, vi preghiamo di inviarci questo ID – ci permette di trovare in modo univoco la relativa prova.

Nessuna scelta effettuata

Il componente è già pronto nel package di consenso. Come il banner e la finestra delle impostazioni, si può progettare liberamente: il funzionamento resta nel package, l'aspetto lo decide il progetto – qui quello di questo sito.

Dati, lingue e interfaccia

La logica di consenso non è legata a una determinata sorgente dati

Il motore di consenso non legge i dati da sé, ma tramite un'interfaccia definita. Da dove provengono lo decide l'implementazione di questa interfaccia – il motore resta lo stesso.

Predefinito: file nel progetto: L'implementazione fornita legge file JSON versionati, distribuiti insieme al codice sorgente. La configurazione non richiede alcuna chiamata di rete.
CMS redazionale: Se l'interfaccia viene implementata per un CMS headless, la redazione vi gestisce testi, servizi e cookie – senza modificare il motore.
Sistema proprio via API: Allo stesso modo si può collegare un CMS proprio o un servizio centrale tramite la sua API – ad esempio per gestire insieme i dati di consenso di più applicazioni.

Definizione tecnica e traduzioni restano separate

Nomi dei cookie, identificativi, categorie e durate di conservazione vengono definiti una sola volta. I testi del banner e della finestra delle impostazioni sono invece disponibili in ogni lingua; il visitatore li vede nella lingua che ha scelto:

denominazioni e descrizioni delle categorie
informazioni sui servizi e finalità dei cookie
informazioni sui trasferimenti di dati
testi del banner e pulsanti
etichette per screen reader

Una logica comune, interfacce diverse

Il motore offre un'interfaccia predefinita che può essere sostituita in tutto o in parte da componenti specifici del progetto.

Un progetto può

adottare banner e finestra delle impostazioni senza modifiche
realizzare graficamente solo il banner
sostituire solo la finestra delle impostazioni
realizzare entrambe le interfacce su misura

Stato del consenso, versionamento e revoca restano gestiti centralmente.

Guardate il caso studio Woop Art

Banner di consenso nel design del progetto di riferimento — Il banner si integra graficamente nel sito.

Finestra delle impostazioni con le categorie di consenso — Categorie, servizi e cookie dichiarati vengono presentati con dati e azioni del motore centrale.

Evidenza ed esercizio

Registrazione lato server delle decisioni

Ogni consenso e ogni modifica successiva generano un record sul server, oltre allo stato nel browser. Questa registrazione è parte integrante del processo, non un'opzione.

Dove finisce il record lo decide, anche qui, l'implementazione dell'interfaccia: per impostazione predefinita l'applicazione lo salva come file sul proprio server. Allo stesso modo può trasmetterlo tramite un'API a un altro servizio che lo gestisce, ad esempio in un database.

Vengono registrati tra l'altro

ID del consenso
versione della configurazione
selezione effettuata
momento
user agent
indirizzo IP abbreviato

Gli indirizzi IPv4 vengono abbreviati dopo il secondo blocco, gli indirizzi IPv6 dopo il terzo segmento. Le voci in arrivo vengono verificate; le richieste incomplete o non ammesse vengono respinte.

La registrazione sostiene la tracciabilità delle decisioni, ma non costituisce un'archiviazione a prova di revisione.

Un errore di registrazione non blocca l'applicazione

La decisione del visitatore ha effetto anzitutto nello stato di consenso dell'applicazione. Se il salvataggio lato server fallisce, il sito resta utilizzabile.

L'errore viene registrato lato server, anziché esporre dettagli tecnici nel browser. La funzionalità del sistema di consenso non dipende quindi dalla disponibilità costante della registrazione.

Dal clic alla voce di registro

consent-flow demo

01 Impostazioni caricate02 Scelta ricevuta03 Stato del consenso aggiornato04 Decisione registrata✓Processo completato

Rappresentazione schematica – non un output dei registri effettivi del sistema.

01
La scelta nel banner
Il visitatore decide per ogni categoria quali servizi consentire. I valori di archiviazione necessari restano attivi.
02
L'applicazione nel codice
Il motore salva la scelta, aggiorna Google Consent Mode e abilita i servizi consentiti.
03
La registrazione lato server
La decisione viene registrata con versione e momento.

Inquadramento

Perché una soluzione propria era per noi la scelta naturale

L'obiettivo era evitare fin dall'inizio dipendenze e costi ricorrenti. Se ci siamo riusciti in modo rapido e affidabile, è grazie a ciò che avevamo già a disposizione.

Competenza in protezione dei dati e consenso: Come si combinano consensi, Google Consent Mode e obblighi di informazione verso i visitatori fa parte del nostro lavoro quotidiano sulle applicazioni web.
Applicazioni proprie invece di un sistema a blocchi: I nostri progetti sono applicazioni web autonome. Il consenso ha quindi potuto essere costruito come parte dell'applicazione, invece di essere aggiunto dall'esterno.
Infrastruttura propria: Gestiamo noi stessi hosting, deployment e firewall. Conservare i registri sui nostri server non ha quindi richiesto un nuovo servizio, ma solo un endpoint in più nell'applicazione esistente.
Moduli condivisi: Tramite il nostro registro di pacchetti privato, i nostri progetti condividono già altri moduli. Il motore di consenso è uno di questi ed è disponibile per ogni nuovo progetto.

Il motore di consenso non è stato quindi un grande cantiere, ma l'estensione di ciò che esisteva già.

Il consenso può essere integrato direttamente nell'applicazione

Lo stato centrale del consenso è disponibile anche per il codice applicativo.

Un componente può così verificare ad esempio

Analytics è autorizzato?
Un video incorporato può essere caricato?
Serve un consenso prima di una mappa esterna?
La decisione memorizzata è ancora valida per la versione di consenso attuale?

Il consenso non resta quindi limitato a banner e finestra delle impostazioni, ma può essere integrato direttamente nel flusso di un'applicazione.

Controllo totale significa responsabilità totale

Senza un fornitore non c'è nemmeno chi aggiorna gli elenchi dei cookie, recepisce le modifiche a Google Consent Mode o adegua i testi a un nuovo quadro normativo. Questo lavoro spetta a noi – nell'ambito della manutenzione che svolgiamo comunque per le nostre applicazioni – oppure al cliente, quando testi e informazioni vengono gestiti tramite un CMS collegato.

Risultato

Una base propria per il consenso, senza fornitori di mezzo

Oggi il motore di consenso è in uso in diverse applicazioni web – senza fornitore esterno, senza licenza ricorrente e con consensi e registri sulla nostra infrastruttura. Le funzioni centrali vengono mantenute una sola volta, mentre dati, integrazioni, lingue e interfaccia restano specifici di ogni progetto.

Indipendenza: Nessun fornitore, nessuna licenza, nessuno script di terzi nel percorso di caricamento.
Sovranità dei dati: Configurazione, consensi e registri si trovano sulla nostra infrastruttura.
Consenso prima dei servizi soggetti: Le relative integrazioni vengono caricate solo dopo il consenso necessario.
Decisioni versionate: I consensi memorizzati sono legati allo stato corrispondente della configurazione.
Logica di consenso centrale: Stato, versionamento, registro, filtraggio degli script e revoca vengono gestiti insieme.
Riutilizzabile e flessibile: Fonti di dati, lingue e interfacce per progetto; miglioramenti del motore tramite aggiornamenti versionati.

Volete decidere voi dove finiscono i dati dei vostri visitatori?

Nel primo colloquio chiariamo quali servizi del vostro sito trasmettono dati a terzi, dove hanno senso alternative a basso consumo di dati e come consensi e registri possano restare là dove gira la vostra applicazione.

Prenotate un primo colloquio

Inviate una richiesta