Guía de integración de consentimiento de Cloudflare Zaraz: Gestión de etiquetas del lado del servidor en el edge para 2026
Cloudflare Zaraz es diferente de la mayoría de los productos de gestión de etiquetas que aparecieron antes. La premisa es estructural en lugar de incremental: en vez de cargar Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight y el JavaScript de cada otro proveedor en el navegador del visitante, Zaraz ejecuta estas integraciones dentro de Cloudflare Workers que se ejecutan en el edge, frente al origen del editor. El navegador ve un único y pequeño Zaraz runtime; las herramientas del proveedor se ejecutan del lado del servidor. Esta elección arquitectónica tiene consecuencias acumulativas para el consentimiento. La superficie de cookies se reduce drásticamente porque la mayoría de las cookies del proveedor nunca se establecen en primer lugar. La superficie de huella digital se reduce porque la mayoría del JavaScript del proveedor nunca se ejecuta en el contexto del navegador. Y el punto de aplicación del consentimiento se desplaza de un banner JavaScript que bloquea un conjunto de etiquetas <script> hacia una decisión del lado del servidor que determina qué integraciones de Zaraz se activan y qué payload reciben. El editor que conecta correctamente Zaraz con un CMP acaba con una superficie de cumplimiento más pequeña, páginas más rápidas y un rastro de auditoría más claro. El editor que trata Zaraz como un Google Tag Manager más rápido y omite la conexión del consentimiento acaba con una exposición regulatoria que es más difícil de detectar porque gran parte de la actividad es invisible para las auditorías estándar basadas en navegadores.
Qué hace realmente Zaraz en el edge
Zaraz es un gestor de etiquetas del lado del servidor que se ejecuta dentro de Cloudflare Workers. Cuando un visitante carga una página, el HTML del editor incluye un pequeño script de inicialización de Zaraz — típicamente unos pocos kilobytes — que recopila un payload de evento estructurado del navegador (vista de página, clic, evento personalizado) y lo envía mediante POST a un endpoint de Cloudflare en el dominio propio del editor. El Worker recibe ese payload y ejecuta las herramientas de Zaraz configuradas: una integración de Google Analytics 4 envía un hit de Measurement Protocol, una integración de Meta Pixel envía un evento de Conversions API, una integración de Mixpanel envía una llamada a la HTTP API. El JavaScript de terceros del proveedor nunca se carga en el navegador, las cookies del proveedor o bien no se establecen en absoluto o se escriben a través del dominio de primera parte de Cloudflare mediante el Worker, y el proveedor solo recibe los datos que la configuración de Zaraz del editor reenvía explícitamente.
Esa es la propuesta de valor arquitectónica. También es por eso que el panorama del consentimiento es diferente al de cualquier gestor de etiquetas del lado del cliente. Con una configuración tradicional, la pregunta sobre el consentimiento es si el JavaScript del proveedor se carga o no. Con Zaraz, el JavaScript nunca se carga en ningún caso — la pregunta pasa a ser si el payload del lado del servidor se envía o se suprime, y si el payload contiene los identificadores que el proveedor necesita para rastrear al usuario. Ambas preguntas tienen respuestas bien definidas en la Zaraz Consent API; el trabajo del editor es mapearlas correctamente.
La Zaraz Consent API y cómo difiere de los CMPs del lado del cliente
Zaraz incluye un módulo de consentimiento integrado — Zaraz Consent Tools — que mantiene un estado de consentimiento por visitante y controla qué herramientas configuradas se activan. El estado se expone a través de una pequeña JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) para registrar la elección de un usuario, zaraz.consent.get('analytics') para leerla, zaraz.consent.getAll() para el mapa completo, zaraz.consent.modal() para abrir la UI de consentimiento, y escuchadores de eventos en zaraz.consent.onModalShown y eventos relacionados para comportamiento personalizado de la UI. Cada herramienta de Zaraz en el panel de control se configura con uno o más ID de propósito, y el Worker solo ejecuta una herramienta cuando los propósitos relevantes han sido otorgados en el estado de consentimiento del visitante.
La elección de integración consiste en decidir si se usa el modal de consentimiento integrado de Zaraz o se conecta Zaraz a un CMP externo. El modal integrado es el camino más sencillo: habilitar Consent Tools, definir los propósitos, configurar cada herramienta con el propósito correcto y publicar. El camino del CMP externo es la elección correcta para organizaciones que ya estandarizan en Cookiebot, OneTrust, Usercentrics o un CMP personalizado — Zaraz opera entonces aguas abajo del CMP, con el CMP llamando a zaraz.consent.set() mientras el usuario avanza por el banner. Ambos caminos llegan al mismo punto de aplicación: el Worker comprueba el estado de consentimiento antes de que se ejecute cada herramienta, y las herramientas cuyos propósitos no han sido otorgados simplemente no se ejecutan.
Soporte de IAB TCF y los regímenes regionales
Zaraz añadió soporte de IAB TCF v2 en 2023 y ha seguido el marco desde entonces. Para los editores que operan en el EEA y el Reino Unido bajo asociaciones publicitarias basadas en TCF, la integración traduce automáticamente la cadena de consentimiento TCF al estado de propósito de Zaraz cuando el editor opta por participar. Para las regiones sin TCF, el editor mapea propósitos personalizados — típicamente analytics, marketing, personalization, functional — directamente a las herramientas de Zaraz relevantes. El mismo Worker aplica ambos, lo que significa que una sola configuración de Zaraz puede atender a un visitante del EEA a través de TCF y a un visitante californiano a través de una puerta de propósito de marketing personalizada sin dos pipelines paralelas.
Por qué Zaraz cambia el panorama del GDPR y ePrivacy
La postura legal bajo el GDPR, ePrivacy y la CCPA no queda exenta por la ejecución del lado del servidor — la base legal sigue los datos, no el transporte — pero la superficie práctica de cumplimiento cambia. Tres cambios importan.
- La superficie de cookies se reduce. La mayoría de las cookies del proveedor nunca se escriben porque el JavaScript del proveedor nunca se ejecuta en el navegador. Las cookies que permanecen son típicamente el propio identificador de sesión de Zaraz y cualquier identificador de primera parte que el editor haya propagado deliberadamente. La superficie de cookies no esenciales que el banner debe controlar es, por tanto, dramáticamente más pequeña — a veces solo una o dos cookies frente a la docena o más que produce una pila típica del lado del cliente.
- La divulgación de transferencias a terceros cambia. Dado que el Worker envía datos a los proveedores mediante llamadas de servidor a servidor, la ruta de datos desde el navegador del visitante va al edge de Cloudflare y desde allí a los proveedores configurados. El aviso de privacidad debe reflejar esto — Cloudflare es un procesador y cada herramienta de Zaraz es un receptor aguas abajo — pero la divulgación es en muchos aspectos más clara que la ruta equivalente del lado del cliente porque el editor tiene control total sobre lo que se reenvía.
- El rastro de auditoría es más centralizado. Dado que cada evento del proveedor pasa a través del Worker, el editor tiene un único punto en el que pueden registrarse el estado de consentimiento, el payload del evento y el receptor aguas abajo. Los reguladores que esperan un registro de consentimiento consultable tienen una respuesta más clara con Zaraz que con una dispersión de etiquetas del lado del cliente.
El patrón de integración que funciona
El despliegue de referencia tiene cuatro partes móviles. La primera es la inicialización de Zaraz en la página, cargada desde el dominio del editor a través del proxy de Cloudflare. La segunda es el modal integrado de Consent Tools o un CMP externo que llama a zaraz.consent.set() mientras el usuario toma decisiones. La tercera es la configuración del panel de Zaraz que mapea cada herramienta a los propósitos correctos — herramientas de análisis al propósito de análisis, herramientas publicitarias al propósito de marketing, herramientas de repetición de sesión a un propósito funcional o de investigación más estricto, y cualquier herramienta dependiente de transferencia a terceros al propósito de transferencia transfronteriza si el aviso de privacidad del editor lo expone como una elección separada. La cuarta es un registro del lado del servidor — ya sea Cloudflare Analytics, Logpush a un data lake del editor, o un Worker personalizado que escribe las decisiones de consentimiento en un almacén consultable — para que el registro de consentimiento pueda presentarse a petición del regulador.
El paso de validación es la misma secuencia de cuatro verificaciones que se aplica a cualquier integración de consentimiento pero con un giro específico de Zaraz. Una sesión de navegador limpia con el banner mostrado pero sin elección realizada debe producir cero solicitudes desde el navegador del visitante a cualquier dominio del proveedor y cero cookies no esenciales — ambas más fáciles de confirmar con Zaraz que con una pila del lado del cliente porque la ausencia de solicitudes de terceros es el valor predeterminado en lugar de una excepción configurada. Una visita de rechazo debe mantener ese estado. Una visita de aceptación debe producir los POST al endpoint de Zaraz que llevan solo los eventos para los que el usuario ha dado consentimiento, y los registros del Worker deben mostrar las activaciones de herramientas aguas abajo. Una retirada debe detener inmediatamente las ejecuciones adicionales de herramientas del Worker, hacer caducar las cookies establecidas por Zaraz y activar las señales de eliminación o exclusión voluntaria adecuadas a los proveedores configurados aguas abajo.
Dónde Zaraz todavía requiere un manejo cuidadoso
Zaraz no es una solución de consentimiento por arquitectura que elimina la necesidad de pensar. Tres áreas requieren un manejo deliberado. Las incrustaciones de clic para cargar — YouTube, Twitter, Instagram, vídeo de TikTok — todavía necesitan el mismo patrón de marcador de posición que usa cualquier despliegue que prioriza el consentimiento, porque Zaraz actualmente no proxy-iza iframes de vídeo incrustados. Los identificadores del lado del cliente que el editor elige establecer en el navegador para propósitos de primera parte — un ID de usuario conectado, un token de sesión, un bucket de prueba A/B — permanecen en el lado del editor del límite de consentimiento y necesitan su propia lógica de control. Y el aviso de privacidad debe describir con precisión el modelo de transferencia del lado del servidor, incluyendo el papel de Cloudflare como procesador y la ubicación geográfica de los Workers que manejan los datos, porque el edge de Cloudflare se ejecuta en múltiples regiones y el tráfico del visitante puede procesarse en una región que no es la suya. Con todo esto manejado, un despliegue de Zaraz en 2026 se transforma de un producto de gestión de etiquetas en una de las arquitecturas de consentimiento más limpias que puede ejecutar un editor: superficie de cookies más pequeña, menos solicitudes de terceros, aplicación centralizada y un rastro de auditoría que un regulador puede leer de verdad.