Guida all'integrazione del consenso di Cloudflare Zaraz: gestione dei tag lato server all'edge per il 2026
Cloudflare Zaraz è diverso dalla maggior parte dei prodotti di gestione dei tag che lo hanno preceduto. La premessa è strutturale piuttosto che incrementale: invece di caricare JavaScript di Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight e di ogni altro fornitore nel browser del visitatore, Zaraz esegue quelle integrazioni all'interno di Cloudflare Workers in esecuzione all'edge, davanti all'origin dell'editore. Il browser vede un unico piccolo runtime Zaraz; gli strumenti dei fornitori vengono eseguiti lato server. Questa scelta architetturale ha conseguenze a cascata per il consenso. La superficie dei cookie si riduce drasticamente perché la maggior parte dei cookie dei fornitori non viene mai impostata. La superficie di fingerprinting si riduce perché la maggior parte del JavaScript dei fornitori non viene mai eseguita nel contesto del browser. E il punto di applicazione del consenso si sposta da un banner JavaScript che controlla un insieme di tag <script> a una decisione lato server che determina quali integrazioni Zaraz vengono attivate e quale payload ricevono. L'editore che collega correttamente Zaraz a un CMP ottiene una superficie di conformità più ridotta, pagine più veloci e una traccia di audit più chiara. L'editore che tratta Zaraz come un Google Tag Manager più veloce e salta il collegamento al consenso si ritrova con un'esposizione normativa più difficile da individuare perché gran parte dell'attività è invisibile agli audit standard basati su browser.
Cosa fa realmente Zaraz all'edge
Zaraz è un tag manager lato server che viene eseguito all'interno di Cloudflare Workers. Quando un visitatore carica una pagina, l'HTML dell'editore include un piccolo script di inizializzazione Zaraz — in genere pochi kilobyte — che raccoglie un payload di eventi strutturato dal browser (pageview, clic, evento personalizzato) e lo invia via POST a un endpoint Cloudflare nel dominio dell'editore. Il Worker riceve quel payload ed esegue gli strumenti Zaraz configurati su di esso: un'integrazione Google Analytics 4 invia un hit al Measurement Protocol, un'integrazione Meta Pixel invia un evento Conversions API, un'integrazione Mixpanel invia una chiamata HTTP API. Il JavaScript di terze parti del fornitore non viene mai caricato nel browser, i cookie del fornitore non vengono impostati affatto o vengono scritti attraverso il dominio first-party di Cloudflare tramite il Worker, e il fornitore riceve solo i dati che la configurazione Zaraz dell'editore trasmette esplicitamente.
Questa è la proposta di valore architetturale. È anche il motivo per cui il quadro del consenso è diverso da qualsiasi tag manager lato client. Con una configurazione tradizionale la domanda sul consenso è se il JavaScript del fornitore viene caricato o meno. Con Zaraz, il JavaScript non viene mai caricato in nessun caso — la domanda diventa se il payload lato server viene inviato o soppresso, e se il payload contiene gli identificatori di cui il fornitore ha bisogno per tracciare l'utente. Entrambe le domande hanno risposte ben definite nella Zaraz Consent API; il compito dell'editore è mapparle correttamente.
La Zaraz Consent API e come differisce dai CMP lato client
Zaraz viene fornito con un modulo di consenso integrato — Zaraz Consent Tools — che mantiene uno stato di consenso per visitatore e controlla quali strumenti configurati vengono attivati. Lo stato viene esposto attraverso una piccola API JavaScript: zaraz.consent.set({ analytics: true, marketing: false }) per registrare la scelta di un utente, zaraz.consent.get('analytics') per leggerla, zaraz.consent.getAll() per la mappa completa, zaraz.consent.modal() per aprire l'UI del consenso, e listener di eventi su zaraz.consent.onModalShown ed eventi correlati per comportamenti UI personalizzati. Ogni strumento Zaraz nel dashboard è configurato con uno o più ID di finalità, e il Worker esegue uno strumento solo quando le finalità pertinenti sono concesse nello stato di consenso del visitatore.
La scelta di integrazione riguarda se utilizzare il modal di consenso integrato di Zaraz o collegare Zaraz a un CMP esterno. Il modal integrato è il percorso più semplice: abilitare Consent Tools, definire le finalità, configurare ogni strumento con la finalità corretta e distribuire. Il percorso CMP esterno è la scelta giusta per le organizzazioni che già adottano Cookiebot, OneTrust, Usercentrics o un CMP personalizzato — Zaraz opera allora a valle del CMP, con il CMP che chiama zaraz.consent.set() mentre l'utente naviga nel banner. Entrambi i percorsi convergono nello stesso punto di applicazione: il Worker controlla lo stato del consenso prima dell'esecuzione di ogni strumento, e gli strumenti le cui finalità non sono concesse semplicemente non vengono eseguiti.
Supporto IAB TCF e regimi regionali
Zaraz ha aggiunto il supporto IAB TCF v2 nel 2023 e ha seguito l'evoluzione del framework da allora. Per gli editori che operano nel EEA e nel UK nell'ambito di partnership pubblicitarie basate su TCF, l'integrazione traduce automaticamente la stringa di consenso TCF in stato di finalità Zaraz quando l'editore aderisce. Per le regioni non-TCF, l'editore mappa direttamente le finalità personalizzate — tipicamente analytics, marketing, personalization, functional — agli strumenti Zaraz pertinenti. Lo stesso Worker applica entrambe, il che significa che una singola configurazione Zaraz può servire sia un visitatore del EEA attraverso TCF sia un visitatore californiano attraverso un gate di finalità marketing personalizzato senza due pipeline parallele.
Perché Zaraz cambia il quadro GDPR e ePrivacy
La posizione giuridica ai sensi del GDPR, di ePrivacy e del CCPA non è esentata dall'esecuzione lato server — la base giuridica segue i dati, non il trasporto — ma la superficie di conformità pratica cambia. Tre cambiamenti sono rilevanti.
- La superficie dei cookie si riduce. La maggior parte dei cookie dei fornitori non viene mai scritta perché il JavaScript del fornitore non viene mai eseguito nel browser. I cookie rimanenti sono tipicamente l'identificatore di sessione proprio di Zaraz e gli eventuali identificatori first-party che l'editore ha deliberatamente propagato. La superficie di cookie non essenziali che il banner deve controllare è quindi drasticamente più piccola — a volte solo uno o due cookie rispetto alla dozzina e più che uno stack lato client tipico produce.
- La disclosure sul trasferimento a terzi cambia. Poiché il Worker invia dati ai fornitori tramite chiamate server-to-server, il percorso dei dati dal browser del visitatore va all'edge di Cloudflare e da lì ai fornitori configurati. L'informativa sulla privacy deve riflettere questo — Cloudflare è un responsabile del trattamento e ogni strumento Zaraz è un destinatario a valle — ma la disclosure è per molti aspetti più chiara rispetto al percorso lato client equivalente perché l'editore ha pieno controllo su ciò che viene trasmesso.
- La traccia di audit è più centralizzata. Poiché ogni evento del fornitore passa attraverso il Worker, l'editore ha un unico punto in cui lo stato del consenso, il payload dell'evento e il destinatario a valle possono essere registrati. I regolatori che si aspettano un log di consenso interrogabile hanno una risposta più chiara con Zaraz che con una moltitudine di tag lato client.
Il pattern di integrazione che funziona
Il deployment di riferimento ha quattro componenti mobili. Il primo è l'inizializzazione Zaraz nella pagina, caricata dal dominio dell'editore tramite il proxy di Cloudflare. Il secondo è il modal Consent Tools integrato oppure un CMP esterno che chiama zaraz.consent.set() mentre l'utente effettua scelte. Il terzo è la configurazione del dashboard Zaraz che mappa ogni strumento alle finalità corrette — strumenti di analisi alla finalità analytics, strumenti pubblicitari alla finalità marketing, strumenti di session-replay a una finalità functional o research più restrittiva, e qualsiasi strumento dipendente da trasferimenti a terzi alla finalità cross-border-transfer se l'informativa sulla privacy dell'editore la espone come scelta separata. Il quarto è un log lato server — Cloudflare Analytics, Logpush verso il data lake dell'editore, o un Worker personalizzato che scrive le decisioni di consenso in un archivio interrogabile — in modo che il registro del consenso possa essere prodotto su richiesta del regolatore.
La fase di validazione è la stessa sequenza di quattro verifiche che si applica a qualsiasi integrazione di consenso, ma con una particolarità specifica di Zaraz. Una sessione browser pulita con il banner mostrato ma nessuna scelta effettuata dovrebbe produrre zero richieste dal browser del visitatore verso qualsiasi dominio del fornitore e zero cookie non essenziali — entrambi più facili da confermare con Zaraz che con uno stack lato client perché l'assenza di richieste di terze parti è il comportamento predefinito piuttosto che un'eccezione configurata. Una visita con rifiuto dovrebbe mantenere quello stato. Una visita con accettazione dovrebbe produrre i POST all'endpoint Zaraz che trasportano solo gli eventi a cui l'utente ha acconsentito, e i log del Worker dovrebbero mostrare le esecuzioni degli strumenti a valle. Una revoca dovrebbe immediatamente interrompere ulteriori esecuzioni degli strumenti del Worker, far scadere i cookie impostati da Zaraz e attivare i segnali di cancellazione o opt-out appropriati verso i fornitori a valle configurati.
Dove Zaraz richiede ancora una gestione attenta
Zaraz non è una soluzione di consenso-per-architettura che elimina la necessità di ragionare. Tre aree richiedono una gestione deliberata. Gli embed click-to-load — YouTube, Twitter, Instagram, video TikTok — richiedono ancora lo stesso pattern di placeholder che usa qualsiasi deployment consent-first, perché Zaraz attualmente non fa proxy degli iframe video incorporati. Gli identificatori lato client che l'editore sceglie di impostare nel browser per finalità first-party — un ID utente autenticato, un token di sessione, un bucket per test A/B — rimangono sul lato dell'editore del confine del consenso e necessitano di una propria logica di gating. E l'informativa sulla privacy deve descrivere accuratamente il modello di trasferimento lato server, incluso il ruolo di Cloudflare come responsabile del trattamento e la collocazione geografica dei Workers che gestiscono i dati, perché l'edge di Cloudflare opera in più regioni e il traffico del visitatore potrebbe essere elaborato in una regione che non è la sua. Con questi aspetti gestiti, un deployment Zaraz nel 2026 si trasforma da prodotto di gestione dei tag in una delle architetture di consenso più pulite che un editore possa gestire: superficie dei cookie ridotta, meno richieste di terze parti, applicazione centralizzata e una traccia di audit che un regolatore può effettivamente leggere.