Guia d'integració de consentiment de Cloudflare Zaraz: Gestió de tags al costat del servidor a l'edge per al 2026
Cloudflare Zaraz és diferent de la majoria de productes de gestió de tags que van aparèixer abans. La premissa és estructural, no incremental: en lloc de carregar Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight i el JavaScript de cada altre proveïdor al navegador del visitant, Zaraz executa aquestes integracions dins de Cloudflare Workers que s'executen a l'edge, davant de l'origen de l'editor. El navegador veu un sol petit runtime de Zaraz; les eines del proveïdor s'executen al costat del servidor. Aquesta elecció arquitectònica té conseqüències acumulatives per al consentiment. La superfície de galetes es redueix dràsticament perquè la majoria de galetes del proveïdor mai s'estableixen. La superfície de «fingerprinting» es redueix perquè la majoria de JavaScript del proveïdor mai s'executa en el context del navegador. I el punt d'aplicació del consentiment es desplaça d'un bàner JavaScript que bloqueja un conjunt d'etiquetes <script> cap a una decisió del costat del servidor que determina quines integracions de Zaraz s'activen i quin payload reben. L'editor que connecta Zaraz a un CMP correctament obté una superfície de compliment més petita, pàgines més ràpides i un rastre d'auditoria més clar. L'editor que tracta Zaraz com un Google Tag Manager més ràpid i omet la connexió del consentiment acaba amb una exposició regulatòria que és més difícil de detectar perquè gran part de l'activitat és invisible per a les auditories estàndard basades en navegadors.
Què fa realment Zaraz a l'edge
Zaraz és un gestor de tags del costat del servidor que s'executa dins de Cloudflare Workers. Quan un visitant carrega una pàgina, l'HTML de l'editor inclou un petit script d'inicialització de Zaraz — normalment uns pocs kilobytes — que recull un payload d'event estructurat del navegador (visualització de pàgina, clic, event personalitzat) i el fa POST a un endpoint de Cloudflare al domini propi de l'editor. El Worker rep aquest payload i executa les eines de Zaraz configurades contra ell: una integració de Google Analytics 4 envia un hit de Measurement Protocol, una integració de Meta Pixel envia un event de Conversions API, una integració de Mixpanel envia una crida d'HTTP API. El JavaScript de tercers del proveïdor mai es carrega al navegador, les galetes del proveïdor o bé no s'estableixen en absolut o s'escriuen a través del domini de primera part de Cloudflare via el Worker, i el proveïdor només rep les dades que la configuració de Zaraz de l'editor reenvía explícitament.
Aquesta és la proposta de valor arquitectònica. Per això el panorama del consentiment és diferent de qualsevol gestor de tags del costat del client. Amb una configuració tradicional, la pregunta sobre el consentiment és si el JavaScript del proveïdor es carrega o no. Amb Zaraz, el JavaScript mai es carrega en cap cas — la pregunta es converteix en si s'envia o se suprimeix el payload del costat del servidor, i si el payload conté els identificadors que el proveïdor necessita per rastrejar l'usuari. Ambdues preguntes tenen respostes ben definides al Zaraz Consent API; la feina de l'editor és mapear-les correctament.
El Zaraz Consent API i com es diferencia dels CMPs del costat del client
Zaraz inclou un mòdul de consentiment integrat — Zaraz Consent Tools — que manté un estat de consentiment per visitant i controla quines eines configurades s'activen. L'estat s'exposa a través d'un petit JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) per registrar l'elecció d'un usuari, zaraz.consent.get('analytics') per llegir-la, zaraz.consent.getAll() per al mapa complet, zaraz.consent.modal() per obrir la UI de consentiment, i listeners d'events a zaraz.consent.onModalShown i events relacionats per a comportament personalitzat de la UI. Cada eina de Zaraz al tauler de control es configura amb un o més ID de propòsit, i el Worker només executa una eina quan els propòsits rellevants es concedeixen a l'estat de consentiment del visitant.
L'elecció d'integració és si s'utilitza el modal de consentiment integrat de Zaraz o es connecta Zaraz a un CMP extern. El modal integrat és el camí més senzill: habiliteu Consent Tools, definiu els propòsits, configureu cada eina amb el propòsit correcte i publiqueu. El camí del CMP extern és l'elecció correcta per a organitzacions que ja estandarditzen en Cookiebot, OneTrust, Usercentrics o un CMP personalitzat — Zaraz opera llavors downstream del CMP, amb el CMP cridant zaraz.consent.set() mentre l'usuari avança pel bàner. Tots dos camins arriben al mateix punt d'aplicació: el Worker comprova l'estat de consentiment abans que s'executi cada eina, i les eines els propòsits de les quals no es concedeixen simplement no s'executen.
Suport d'IAB TCF i els règims regionals
Zaraz va afegir suport d'IAB TCF v2 el 2023 i ha seguit el marc des de llavors. Per als editors que operen a l'EEA i al Regne Unit sota associacions publicitàries basades en TCF, la integració tradueix la cadena de consentiment TCF a l'estat de propòsit de Zaraz automàticament quan l'editor hi opta. Per a les regions no TCF, l'editor mapeja propòsits personalitzats — normalment analytics, marketing, personalization, functional — directament a les eines de Zaraz rellevants. El mateix Worker aplica tots dos, la qual cosa significa que una sola configuració de Zaraz pot servir un visitant de l'EEA a través de TCF i un visitant californià a través d'una porta de propòsit de màrqueting personalitzada sense dos pipelines paral·lels.
Per què Zaraz canvia el panorama del GDPR i ePrivacy
La postura legal sota GDPR, ePrivacy i CCPA no queda exempta per l'execució del costat del servidor — la base legal segueix les dades, no el transport — però la superfície pràctica de compliment canvia. Tres canvis importants.
- La superfície de galetes es redueix. La majoria de galetes de proveïdors mai s'escriuen perquè el JavaScript del proveïdor mai s'executa al navegador. Les galetes que queden solen ser el propi identificador de sessió de Zaraz i qualsevol identificador de primera part que l'editor hagi propagat deliberadament. La superfície de galetes no essencials que el bàner ha de controlar és, per tant, dràsticament més petita — de vegades només una o dues galetes enfront de la dotzena o més que produeix una pila típica del costat del client.
- La divulgació de transferències a tercers canvia. Com que el Worker envia dades als proveïdors mitjançant crides de servidor a servidor, el camí de les dades del navegador del visitant és cap a l'edge de Cloudflare i des d'allà als proveïdors configurats. L'avís de privacitat ha de reflectir això — Cloudflare és un processador i cada eina de Zaraz és un destinatari downstream — però la divulgació és en molts aspectes més clara que el camí equivalent del costat del client perquè l'editor té control total sobre el que es reenvia.
- El rastre d'auditoria és més centralitzat. Com que cada event de proveïdor passa a través del Worker, l'editor té un punt únic en el qual es poden registrar l'estat de consentiment, el payload de l'event i el destinatari downstream. Els reguladors que esperen un registre de consentiment consultable tenen una resposta més clara amb Zaraz que amb una dispersió d'etiquetes del costat del client.
El patró d'integració que funciona
El desplegament de referència té quatre parts mòbils. La primera és la inicialització de Zaraz a la pàgina, carregada des del domini de l'editor a través del proxy de Cloudflare. La segona és el modal integrat de Consent Tools o un CMP extern que crida zaraz.consent.set() mentre l'usuari fa les seves eleccions. La tercera és la configuració del tauler de Zaraz que mapeja cada eina als propòsits correctes — les eines d'analítica al propòsit d'analítica, les eines publicitàries al propòsit de màrqueting, les eines de «session replay» a un propòsit funcional o de recerca més estricte, i qualsevol eina depenent de transferència a tercers al propòsit de transferència transfronterera si l'avís de privacitat de l'editor ho exposa com a elecció separada. La quarta és un registre del costat del servidor — ja sigui Cloudflare Analytics, Logpush a un llac de dades de l'editor, o un Worker personalitzat que escriu les decisions de consentiment en un magatzem consultable — per tal que el registre de consentiment es pugui presentar a petició del regulador.
El pas de validació és la mateixa seqüència de quatre comprovacions que s'aplica a qualsevol integració de consentiment però amb un gir específic de Zaraz. Una sessió de navegador neta amb el bàner mostrat però sense elecció feta hauria de produir zero sol·licituds del navegador del visitant a qualsevol domini de proveïdor i zero galetes no essencials — ambdues coses més fàcils de confirmar amb Zaraz que amb una pila del costat del client perquè l'absència de sol·licituds de tercers és la configuració predeterminada, no una excepció configurada. Una visita de rebuig hauria de mantenir aquest estat. Una visita d'acceptació hauria de produir els POST d'endpoint de Zaraz que només contenen els events per als quals l'usuari ha donat consentiment, i els registres del Worker haurien de mostrar les activacions d'eines downstream. Una retirada hauria d'aturar immediatament les execucions d'eines del Worker, fer caducar les galetes establertes per Zaraz i activar els senyals adequats d'eliminació o exclusió als proveïdors downstream configurats.
On Zaraz encara requereix una gestió acurada
Zaraz no és una solució de consentiment per arquitectura que elimina la necessitat de pensar. Tres àrees requereixen una gestió deliberada. Les incrustacions de «click-to-load» — YouTube, Twitter, Instagram, vídeo TikTok — encara necessiten el mateix patró de marcador de posició que utilitza qualsevol desplegament que prioritzi el consentiment, perquè Zaraz no proxifica actualment iframes de vídeo incrustats. Els identificadors del costat del client que l'editor tria establir al navegador per a propòsits de primera part — un ID d'usuari connectat, un token de sessió, un paquet de proves A/B — romanen al costat de l'editor del límit del consentiment i necessiten la seva pròpia lògica de control. I l'avís de privacitat ha de descriure amb precisió el model de transferència del costat del servidor, incloent el paper de Cloudflare com a processador i la ubicació geogràfica dels Workers que gestionen les dades, perquè l'edge de Cloudflare s'executa en múltiples regions i el trànsit del visitant pot ser processat en una regió que no és la seva. Amb tot això gestionat, un desplegament de Zaraz el 2026 es converteix d'un producte de gestió de tags en una de les arquitectures de consentiment més netes que pot executar un editor: superfície de galetes més petita, menys sol·licituds de tercers, aplicació centralitzada i un rastre d'auditoria que un regulador pot llegir de veritat.