Guía de integración do consentimento de Cloudflare Zaraz: xestión de etiquetas no lado do servidor no extremo para 2026
Cloudflare Zaraz é diferente da maioría dos produtos de xestión de etiquetas que existiron antes del. A premisa é estrutural máis que incremental: en lugar de cargar Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight e o JavaScript de cada outro provedor no navegador do visitante, Zaraz executa esas integracións dentro de Cloudflare Workers no extremo, diante do servidor de orixe do editor. O navegador ve un único pequeno tempo de execución de Zaraz; as ferramentas dos provedores execútanse no lado do servidor. Esa elección arquitectónica ten consecuencias acumuladas para o consentimento. A superficie de cookies redúcese drasticamente porque a maioría das cookies dos provedores nunca se establecen. A superficie de fingerprinting redúcese porque a maioría dos JavaScript dos provedores nunca se executan no contexto do navegador. E o punto de aplicación do consentimento pasa dun banner de JavaScript que controla un conxunto de etiquetas <script> cara a unha decisión no lado do servidor que determina que integracións de Zaraz se activan e que carga reciben. O editor que conecta correctamente Zaraz a un CMP obtén unha superficie de cumprimento máis pequena, páxinas máis rápidas e un rexistro de auditoría máis claro. O editor que trata Zaraz como un Google Tag Manager máis rápido e omite o cableado do consentimento fica exposto a un risco regulatorio máis difícil de detectar porque gran parte da actividade é invisible para as auditorías estándar baseadas no navegador.
O que Zaraz fai realmente no extremo
Zaraz é un xestor de etiquetas no lado do servidor que se executa dentro de Cloudflare Workers. Cando un visitante carga unha páxina, o HTML do editor inclúe un pequeno script de inicialización de Zaraz — normalmente uns poucos kilobytes — que recolle unha carga útil de evento estruturado do navegador (vista de páxina, clic, evento personalizado) e envíao mediante POST a un endpoint de Cloudflare no propio dominio do editor. O Worker recibe esa carga útil e executa as ferramentas de Zaraz configuradas contra ela: unha integración de Google Analytics 4 envía un hit do Measurement Protocol, unha integración de Meta Pixel envía un evento da Conversions API, unha integración de Mixpanel envía unha chamada á HTTP API. O JavaScript de terceiros do provedor nunca se carga no navegador, as cookies do provedor ou nunca se establecen ou escríbense a través do dominio de primeira parte de Cloudflare a través do Worker, e o provedor só recibe os datos que a configuración de Zaraz do editor transmite explicitamente.
Esa é a proposta de valor arquitectónica. É tamén por iso que o panorama do consentimento é diferente do de calquera xestor de etiquetas no lado do cliente. Cunha configuración tradicional, a pregunta do consentimento é se o JavaScript do provedor se carga ou non. Con Zaraz, o JavaScript nunca se carga en ningún dos casos — a pregunta convértese en se a carga útil no lado do servidor se envía ou se suprime, e se a carga útil contén os identificadores que o provedor necesita para rastrexar o usuario. Ambas as preguntas teñen respostas ben definidas na Zaraz Consent API; o traballo do editor é mapeaas correctamente.
A Zaraz Consent API e en que se diferenza dos CMP no lado do cliente
Zaraz inclúe un módulo de consentimento integrado — Zaraz Consent Tools — que mantén un estado de consentimento por visitante e controla que ferramentas configuradas se activan. O estado expóñese a través dunha pequena API de JavaScript: zaraz.consent.set({ analytics: true, marketing: false }) para rexistrar a elección dun usuario, zaraz.consent.get('analytics') para lela, zaraz.consent.getAll() para o mapa completo, zaraz.consent.modal() para abrir a interface de consentimento e oíntes de eventos en zaraz.consent.onModalShown e eventos relacionados para o comportamento da interface personalizada. Cada ferramenta de Zaraz no panel configúrase cun ou máis identificadores de propósito, e o Worker só executa unha ferramenta cando os propósitos relevantes están concedidos no estado de consentimento do visitante.
A elección de integración é se usar a modal de consentimento integrada de Zaraz ou vincular Zaraz a un CMP externo. A modal integrada é o camiño máis sinxelo: activar Consent Tools, definir os propósitos, configurar cada ferramenta co propósito correcto e lanzar. O camiño do CMP externo é a elección correcta para as organizacións que xa estandardizan en Cookiebot, OneTrust, Usercentrics ou un CMP personalizado — Zaraz opera entón a continuación do CMP, co CMP chamando a zaraz.consent.set() mentres o usuario se move polo banner. Ambos os camiños chegan ao mesmo punto de aplicación: o Worker comproba o estado de consentimento antes de que cada ferramenta se execute, e as ferramentas cuxos propósitos non están concedidos simplemente non se executan.
Soporte de IAB TCF e réximes rexionais
Zaraz engadiu o soporte de IAB TCF v2 en 2023 e seguiu o marco desde entón. Para os editores que operan na EEA e no Reino Unido baixo asociacións publicitarias baseadas en TCF, a integración traduce automaticamente a cadea de consentimento TCF ao estado de propósito de Zaraz cando o editor opta. Para rexións non TCF, o editor mapea propósitos personalizados — normalmente analytics, marketing, personalization, functional — directamente ás ferramentas de Zaraz relevantes. O mesmo Worker aplica ambos, o que significa que unha única configuración de Zaraz pode servir tanto a un visitante da EEA a través de TCF como a un visitante californiano a través dunha porta de propósito de marketing personalizado sen dúas canalizacións paralelas.
Por que Zaraz cambia o panorama do GDPR e ePrivacy
A postura xurídica baixo o GDPR, ePrivacy e o CCPA non está exenta pola execución no lado do servidor — a base xurídica segue os datos, non o transporte — pero a superficie práctica de cumprimento cambia. Tres cambios importan.
- A superficie de cookies redúcese. A maioría das cookies dos provedores nunca se escriben porque o JavaScript do provedor nunca se executa no navegador. As cookies que quedan son normalmente o propio identificador de sesión de Zaraz e calquera identificador de primeira parte que o editor propagou deliberadamente. A superficie de cookies non esenciais que o banner debe controlar é polo tanto drasticamente máis pequena — ás veces só unha ou dúas cookies fronte á ducia ou máis que unha pila típica no lado do cliente produce.
- A divulgación da transferencia de terceiros cambia. Porque o Worker envía datos aos provedores mediante chamadas de servidor a servidor, a ruta dos datos desde o navegador do visitante vai ao extremo de Cloudflare e desde alí aos provedores configurados. O aviso de privacidade debe reflectir isto — Cloudflare é un procesador e cada ferramenta de Zaraz é un receptor augas abaixo — pero a divulgación é en moitos sentidos máis limpa que a ruta equivalente no lado do cliente porque o editor ten control total sobre o que se transmite.
- O rexistro de auditoría está máis centralizado. Porque cada evento do provedor pasa polo Worker, o editor ten un único punto no que o estado de consentimento, a carga útil do evento e o receptor augas abaixo poden rexistrarse. Os reguladores que esperan un rexistro de consentimento consultable teñen unha resposta máis clara con Zaraz que cunha proliferación de etiquetas no lado do cliente.
O patrón de integración que funciona
O despregamento de referencia ten catro partes móbiles. A primeira é a inicialización de Zaraz na páxina, cargada desde o dominio do editor a través do proxy de Cloudflare. A segunda é a modal de Consent Tools integrada ou un CMP externo que chama a zaraz.consent.set() mentres o usuario fai eleccións. A terceira é a configuración do panel de Zaraz que mapea cada ferramenta aos propósitos correctos — ferramentas de análise ao propósito de análise, ferramentas de publicidade ao propósito de marketing, ferramentas de repetición de sesión a un propósito funcional ou de investigación máis estrito, e calquera ferramenta dependente de transferencia a terceiros ao propósito de transferencia transfronteiriza se o aviso de privacidade do editor o expón como unha elección separada. A cuarta é un rexistro no lado do servidor — Cloudflare Analytics, Logpush a un lago de datos do editor ou un Worker personalizado que escribe as decisións de consentimento nun almacenamento consultable — para que o rexistro de consentimento poida producirse ante a solicitude do regulador.
O paso de validación é a mesma secuencia de catro verificacións que se aplica a calquera integración de consentimento pero cun matiz específico de Zaraz. Unha sesión de navegador limpa co banner mostrado pero sen elección feita debería producir cero solicitudes desde o navegador do visitante a calquera dominio de provedor e cero cookies non esenciais — ambas son máis fáciles de confirmar con Zaraz que cunha pila no lado do cliente porque a ausencia de solicitudes de terceiros é o comportamento predeterminado en lugar dunha excepción configurada. Unha visita de rexeite debería manter ese estado. Unha visita de aceptación debería producir os POST do endpoint de Zaraz que levan só os eventos aos que o usuario consentiu, e os rexistros do Worker deberían mostrar os disparos das ferramentas augas abaixo. A retirada debería deter inmediatamente as execucións posteriores das ferramentas do Worker, facer caducar as cookies establecidas por Zaraz e activar os sinais de eliminación ou exclusión apropiados para os provedores augas abaixo configurados.
Onde Zaraz aínda require un tratamento coidadoso
Zaraz non é unha solución de consentimento por arquitectura que elimina a necesidade de reflexionar. Tres áreas requiren tratamento deliberado. As integracións de clic para cargar — YouTube, Twitter, Instagram, vídeo de TikTok — seguen necesitando o mesmo patrón de marcador de posición que usa calquera despregamento consent-first, porque Zaraz actualmente non fai proxy dos iframes de vídeo integrado. Os identificadores no lado do cliente que o editor elixe establecer no navegador para fins de primeira parte — un ID de usuario con sesión iniciada, un token de sesión, un bucket de proba A/B — permanecen no lado do editor do límite de consentimento e necesitan a súa propia lóxica de porta. E o aviso de privacidade debe describir con precisión o modelo de transferencia no lado do servidor, incluíndo o papel de Cloudflare como procesador e a localización xeográfica dos Workers que xestionan os datos, porque o extremo de Cloudflare funciona en múltiples rexións e o tráfico do visitante pode procesarse nunha rexión que non é a súa. Con eses aspectos tratados, un despregamento de Zaraz en 2026 transfórmase dun produto de xestión de etiquetas nunha das arquitecturas de consentimento máis limpas que un editor pode executar: superficie de cookies máis pequena, menos solicitudes de terceiros, aplicación centralizada e un rexistro de auditoría que un regulador pode realmente ler.