Guia de Integração de Consentimento do Cloudflare Zaraz: Gestão de Tags no Lado do Servidor na Borda para 2026
O Cloudflare Zaraz é diferente da maioria dos produtos de gestão de tags que vieram antes dele. A premissa é estrutural em vez de incremental: em vez de carregar o JavaScript do Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight e de todos os outros fornecedores no navegador do visitante, o Zaraz executa essas integrações dentro do Cloudflare Workers que correm na borda, à frente da origem do editor. O navegador vê um único pequeno tempo de execução do Zaraz; as ferramentas do fornecedor correm no lado do servidor. Essa escolha arquitetónica tem consequências compostas para o consentimento. A superfície de cookies encolhe dramaticamente porque a maioria dos cookies dos fornecedores nunca é definida logo de início. A superfície de fingerprinting encolhe porque a maior parte do JavaScript dos fornecedores nunca é executado no contexto do navegador. E o ponto de aplicação do consentimento move-se de um banner JavaScript que controla uma pilha de tags <script> para uma decisão no lado do servidor que determina quais as integrações do Zaraz que são ativadas e que carga recebem. O editor que liga corretamente o Zaraz a um CMP acaba com uma superfície de conformidade menor, páginas mais rápidas e um rasto de auditoria mais claro. O editor que trata o Zaraz como um Google Tag Manager mais rápido e ignora a ligação do consentimento acaba com uma exposição regulatória que é mais difícil de detetar porque muito da atividade é invisível para auditorias padrão baseadas em navegador.
O que o Zaraz realmente faz na borda
O Zaraz é um gestor de tags no lado do servidor que executa dentro do Cloudflare Workers. Quando um visitante carrega uma página, o HTML do editor inclui um pequeno script de inicialização do Zaraz — tipicamente alguns kilobytes — que recolhe um payload de evento estruturado do navegador (pageview, clique, evento personalizado) e faz POST para um endpoint do Cloudflare no próprio domínio do editor. O Worker recebe esse payload e executa as ferramentas Zaraz configuradas contra ele: uma integração Google Analytics 4 envia um hit do Measurement Protocol, uma integração Meta Pixel envia um evento da Conversions API, uma integração Mixpanel envia uma chamada HTTP API. O JavaScript de terceiros do fornecedor nunca é carregado no navegador, os cookies do fornecedor ou não são definidos de todo ou são escritos através do domínio próprio do Cloudflare via o Worker, e o fornecedor recebe apenas os dados que a configuração Zaraz do editor encaminha explicitamente.
Essa é a proposta de valor arquitetónica. É também a razão pela qual o quadro do consentimento é diferente de qualquer gestor de tags no lado do cliente. Com uma configuração tradicional a questão do consentimento é se o JavaScript do fornecedor é carregado ou não. Com o Zaraz, o JavaScript nunca é carregado em nenhum caso — a questão passa a ser se o payload no lado do servidor é enviado ou suprimido, e se o payload contém os identificadores que o fornecedor precisa para rastrear o utilizador. Ambas as questões têm respostas bem definidas na Zaraz Consent API; o trabalho do editor é mapeá-las corretamente.
A Zaraz Consent API e como difere dos CMPs no lado do cliente
O Zaraz é fornecido com um módulo de consentimento integrado — Zaraz Consent Tools — que mantém um estado de consentimento por visitante e controla quais as ferramentas configuradas que são ativadas. O estado é exposto através de uma pequena JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) para registar a escolha de um utilizador, zaraz.consent.get('analytics') para a ler, zaraz.consent.getAll() para o mapa completo, zaraz.consent.modal() para abrir a UI de consentimento, e event listeners em zaraz.consent.onModalShown e eventos relacionados para comportamento de UI personalizado. Cada ferramenta Zaraz no painel é configurada com um ou mais IDs de propósito, e o Worker só executa uma ferramenta quando os propósitos relevantes são concedidos no estado de consentimento do visitante.
A escolha de integração é usar o modal de consentimento integrado do Zaraz ou ligar o Zaraz a um CMP externo. O modal integrado é o caminho mais simples: ative o Consent Tools, defina os propósitos, configure cada ferramenta com o propósito certo e faça o deploy. O caminho do CMP externo é a escolha certa para organizações que já estandardizam em Cookiebot, OneTrust, Usercentrics ou um CMP personalizado — o Zaraz então opera a jusante do CMP, com o CMP a chamar zaraz.consent.set() à medida que o utilizador se move pelo banner. Ambos os caminhos chegam ao mesmo ponto de aplicação: o Worker verifica o estado de consentimento antes de cada execução de ferramenta, e ferramentas cujos propósitos não são concedidos simplesmente não correm.
Suporte IAB TCF e os regimes regionais
O Zaraz adicionou suporte IAB TCF v2 em 2023 e tem acompanhado o framework desde então. Para editores a operar na EEA e no UK sob parcerias publicitárias baseadas em TCF, a integração traduz automaticamente a string de consentimento TCF para o estado de propósito do Zaraz quando o editor opta por isso. Para regiões não TCF, o editor mapeia propósitos personalizados — tipicamente analytics, marketing, personalization, functional — diretamente para as ferramentas Zaraz relevantes. O mesmo Worker aplica ambos, o que significa que uma única configuração Zaraz pode servir tanto um visitante da EEA através do TCF como um visitante californiano através de um portão de propósito de marketing personalizado sem dois pipelines paralelos.
Por que o Zaraz muda o quadro do GDPR e ePrivacy
A posição legal ao abrigo do GDPR, ePrivacy e da CCPA não é isenta pela execução no lado do servidor — a base legal segue os dados, não o transporte — mas a superfície de conformidade prática muda. Três mudanças são relevantes.
- A superfície de cookies encolhe. A maioria dos cookies dos fornecedores nunca é escrita porque o JavaScript do fornecedor nunca corre no navegador. Os cookies que permanecem são tipicamente o próprio identificador de sessão do Zaraz e quaisquer identificadores de primeira parte que o editor propagou deliberadamente. A superfície de cookies não essenciais que o banner deve controlar é portanto dramaticamente menor — por vezes apenas um ou dois cookies versus a dúzia ou mais que uma pilha típica no lado do cliente produz.
- A divulgação de transferência para terceiros muda. Como o Worker está a enviar dados para os fornecedores através de chamadas servidor a servidor, o caminho dos dados do navegador do visitante é para a borda do Cloudflare e daí para os fornecedores configurados. A política de privacidade deve refletir isso — o Cloudflare é um subcontratante e cada ferramenta Zaraz é um destinatário a jusante — mas a divulgação é de muitas formas mais limpa do que o caminho equivalente no lado do cliente porque o editor tem controlo total sobre o que é encaminhado.
- O rasto de auditoria é mais centralizado. Como cada evento do fornecedor passa pelo Worker, o editor tem um único ponto onde o estado de consentimento, o payload do evento e o destinatário a jusante podem ser registados. Os reguladores que esperam um registo de consentimento consultável têm uma resposta mais clara com o Zaraz do que com uma dispersão de tags no lado do cliente.
O padrão de integração que funciona
O deployment de referência tem quatro partes móveis. A primeira é a inicialização do Zaraz na página, carregada a partir do domínio do editor através do proxy do Cloudflare. A segunda é ou o modal Consent Tools integrado ou um CMP externo que chama zaraz.consent.set() à medida que o utilizador faz escolhas. A terceira é a configuração do painel do Zaraz que mapeia cada ferramenta para os propósitos certos — ferramentas de análise para o propósito de análise, ferramentas publicitárias para o propósito de marketing, ferramentas de reprodução de sessão para um propósito funcional ou de investigação mais estrito, e qualquer ferramenta dependente de transferência transfronteiriça para o propósito de transferência transfronteiriça se a política de privacidade do editor o expõe como uma escolha separada. A quarta é um registo no lado do servidor — ou o Cloudflare Analytics, o Logpush para um data lake do editor, ou um Worker personalizado que escreve decisões de consentimento para um armazenamento consultável — para que o registo de consentimento possa ser produzido a pedido do regulador.
O passo de validação é a mesma sequência de quatro verificações que se aplica a qualquer integração de consentimento mas com uma peculiaridade específica do Zaraz. Uma sessão de navegador limpa com o banner mostrado mas sem escolha feita deve produzir zero pedidos do navegador do visitante para qualquer domínio de fornecedor e zero cookies não essenciais — ambos são mais fáceis de confirmar com o Zaraz do que com uma pilha no lado do cliente porque a ausência de pedidos de terceiros é o padrão em vez de uma exceção configurada. Uma visita de rejeição deve manter esse estado. Uma visita de aceitação deve produzir os POSTs do endpoint do Zaraz que transportam apenas os eventos para os quais o utilizador deu consentimento, e os registos do Worker devem mostrar as ativações das ferramentas a jusante. Uma retirada deve imediatamente parar quaisquer execuções de ferramentas do Worker, expirar quaisquer cookies definidos pelo Zaraz, e acionar os sinais de eliminação ou opt-out apropriados para os fornecedores a jusante configurados.
Onde o Zaraz ainda requer tratamento cuidadoso
O Zaraz não é uma solução de consentimento por arquitetura que remove a necessidade de pensar. Três áreas requerem tratamento deliberado. Embeds de clicar para carregar — vídeo YouTube, Twitter, Instagram, TikTok — ainda precisam do mesmo padrão de placeholder que qualquer deployment com consentimento em primeiro lugar usa, porque o Zaraz atualmente não faz proxy de iframes de vídeo incorporados. Identificadores no lado do cliente que o editor escolhe definir no navegador para fins de primeira parte — um ID de utilizador com sessão iniciada, um token de sessão, um bucket de teste A/B — permanecem do lado do editor da fronteira do consentimento e precisam da sua própria lógica de controlo. E a política de privacidade deve descrever com precisão o modelo de transferência no lado do servidor, incluindo o papel do Cloudflare como subcontratante e a localização geográfica dos Workers que tratam os dados, porque a borda do Cloudflare opera em múltiplas regiões e o tráfego do visitante pode ser processado numa região que não é a sua. Com essas questões tratadas, um deployment do Zaraz em 2026 transforma-se de um produto de gestão de tags numa das arquiteturas de consentimento mais limpas que um editor pode correr: superfície de cookies menor, menos pedidos de terceiros, aplicação centralizada e um rasto de auditoria que um regulador pode realmente ler.