Cloudflare Zaraz 同意集成指南：2026年边缘服务器端标签管理
Cloudflare Zaraz 与此前大多数标签管理产品有着本质区别。其核心理念是结构性变革而非渐进式改良：Zaraz 不再将 Google Analytics、Meta Pixel、Hotjar、Mixpanel、LinkedIn Insight 等第三方 JavaScript 加载到访客浏览器，而是在 Cloudflare Workers 中于边缘节点执行这些集成，位于发布商源站之前。浏览器只看到一个轻量的 Zaraz 运行时，供应商工具则在服务器端运行。这一架构选择对同意管理产生了深远影响：由于大多数供应商 Cookie 从未被设置，Cookie 暴露面大幅缩小；由于大多数供应商 JavaScript 从不在浏览器中执行，指纹识别暴露面也随之缩小。同意执行点从拦截一堆 <script> 标签的 JavaScript 横幅，转变为决定哪些 Zaraz 集成触发及其接收何种数据的服务器端判断。正确将 Zaraz 接入 CMP 的发布商将获得更小的合规面、更快的页面和更清晰的审计追踪；而将 Zaraz 视为更快的 Google Tag Manager 并跳过同意接入的发布商，则会面临难以察觉的合规风险——因为大量活动对基于浏览器的标准审计工具不可见。
Zaraz 在边缘的实际工作方式
Zaraz 是运行在 Cloudflare Workers 内部的服务器端标签管理器。访客加载页面时，发布商的 HTML 包含一个轻量的 Zaraz 初始化脚本（通常只有几千字节），该脚本从浏览器收集结构化事件数据（页面浏览、点击、自定义事件），并通过 POST 请求发送到发布商自有域名的 Cloudflare 端点。Worker 接收该数据并运行已配置的 Zaraz 工具：Google Analytics 4 集成发送 Measurement Protocol 请求，Meta Pixel 集成发送 Conversions API 事件，Mixpanel 集成发送 HTTP API 调用。供应商的第三方 JavaScript 从不在浏览器中加载，供应商 Cookie 要么完全不设置，要么通过 Worker 经由 Cloudflare 一方域名写入，供应商仅接收发布商 Zaraz 配置明确转发的数据。
这是其架构价值所在，也是其同意管理图景与任何客户端标签管理器不同的原因。在传统方案中，同意问题是供应商 JavaScript 是否加载。在 Zaraz 中，JavaScript 无论如何都不会在浏览器中加载——问题转变为服务器端数据是否发送或抑制，以及数据是否包含供应商追踪用户所需的标识符。Zaraz Consent API 对这两个问题都有明确的答案；发布商的任务是正确映射它们。
Zaraz Consent API 与客户端 CMP 的区别
Zaraz 内置同意模块——Zaraz Consent Tools——维护每位访客的同意状态，并控制哪些已配置工具触发。该状态通过简洁的 JavaScript API 暴露：zaraz.consent.set({ analytics: true, marketing: false }) 记录用户选择，zaraz.consent.get('analytics') 读取单项，zaraz.consent.getAll() 获取完整映射，zaraz.consent.modal() 打开同意 UI，以及 zaraz.consent.onModalShown 等事件监听器用于自定义 UI 行为。仪表板中每个 Zaraz 工具配置一个或多个用途 ID，Worker 仅在访客同意状态中对应用途已授权时才执行该工具。
集成选择在于使用 Zaraz 内置同意弹窗还是将 Zaraz 绑定到外部 CMP。内置弹窗是最简单的路径：启用 Consent Tools，定义用途，为每个工具配置正确用途，即可上线。对于已标准化使用 Cookiebot、OneTrust、Usercentrics 或自定义 CMP 的组织，外部 CMP 路径是正确选择——Zaraz 在 CMP 下游运行，CMP 在用户操作横幅时调用 zaraz.consent.set()。两条路径最终到达同一执行点：Worker 在每个工具执行前检查同意状态，未获授权用途的工具简单地不运行。
IAB TCF 支持与地区合规框架
Zaraz 于2023年添加了 IAB TCF v2 支持，此后持续跟进框架更新。对于在 EEA 和 UK 基于 TCF 广告合作运营的发布商，启用后集成会自动将 TCF 同意字符串转换为 Zaraz 用途状态。对于非 TCF 地区，发布商直接将自定义用途——通常为 analytics、marketing、personalization、functional——映射到相关 Zaraz 工具。同一个 Worker 同时执行两者，这意味着单一 Zaraz 配置可同时服务通过 TCF 的 EEA 访客和通过自定义营销用途门控的加州访客，无需两条并行流水线。
Zaraz 如何改变 GDPR 和 ePrivacy 合规面貌
在 GDPR、ePrivacy 和 CCPA 框架下，服务器端执行并不豁免法律义务——法律依据跟随数据而非传输方式——但实际合规面发生了变化。三项转变至关重要。
- Cookie 暴露面缩小。大多数供应商 Cookie 从未被写入，因为供应商 JavaScript 从不在浏览器中运行。剩余 Cookie 通常仅为 Zaraz 自身的会话标识符和发布商有意传播的一方标识符。横幅必须拦截的非必要 Cookie 暴露面因此大幅缩小——有时仅需一两个 Cookie，而典型客户端方案可能产生十余个。
- 第三方数据转移披露更清晰。由于 Worker 通过服务器间调用向供应商发送数据，数据路径是从访客浏览器到 Cloudflare 边缘，再到已配置的供应商。隐私声明必须反映这一点——Cloudflare 是数据处理者，每个 Zaraz 工具是下游接收方——但与等效客户端路径相比，披露内容在许多方面更为清晰，因为发布商完全掌控转发内容。
- 审计追踪更集中。由于所有供应商事件都经过 Worker，发布商在单一节点即可记录同意状态、事件数据和下游接收方。相比客户端标签的分散状态，使用 Zaraz 能为监管机构提供更清晰的可查询同意日志。
有效的集成模式
参考部署包含四个组成部分。第一是页面中的 Zaraz 初始化脚本，通过 Cloudflare 代理从发布商域名加载。第二是内置 Consent Tools 弹窗或在用户操作时调用 zaraz.consent.set() 的外部 CMP。第三是 Zaraz 仪表板配置，将每个工具映射到正确用途——分析工具映射到 analytics 用途，广告工具映射到 marketing 用途，会话回放工具映射到更严格的 functional 或研究用途，任何依赖跨境传输的工具映射到跨境传输用途（若发布商隐私声明将其作为独立选项）。第四是服务器端日志——Cloudflare Analytics、Logpush 到发布商数据湖，或将同意决策写入可查询存储的自定义 Worker——以便在监管机构要求时提供同意记录。
验证步骤是适用于任何同意集成的四步检查流程，但有 Zaraz 特有的变化。在显示横幅但尚未做出选择的干净浏览器会话中，访客浏览器应向任何供应商域名发出零请求，且无非必要 Cookie——这两点在 Zaraz 中比客户端方案更易确认，因为缺少第三方请求是默认状态而非配置的例外。拒绝访问应保持该状态。接受访问应产生仅携带用户已同意事件的 Zaraz 端点 POST 请求，Worker 日志应显示下游工具触发。撤回同意应立即停止后续 Worker 工具执行，使 Zaraz 设置的 Cookie 过期，并向已配置的下游供应商触发适当的删除或退出信号。
Zaraz 仍需谨慎处理的领域
Zaraz 并非消除思考需求的“架构即同意”方案。三个领域需要刻意处理。点击加载嵌入内容——YouTube、Twitter、Instagram、TikTok 视频——仍需与任何同意优先部署相同的占位符模式，因为 Zaraz 目前不代理嵌入视频 iframe。发布商选择在浏览器中为一方目的设置的客户端标识符——登录用户 ID、会话令牌、A/B 测试分桶——仍在发布商侧同意边界内，需要自己的门控逻辑。隐私声明必须准确描述服务器端传输模型，包括 Cloudflare 作为数据处理者的角色以及处理数据的 Workers 的地理位置，因为 Cloudflare 边缘在多个地区运行，访客流量可能在非其所在地区处理。处理好这些问题后，2026年的 Zaraz 部署将从标签管理产品升华为发布商可运行的最清晰同意架构之一：更小的 Cookie 暴露面、更少的第三方请求、集中化的执行，以及监管机构真正能读懂的审计追踪。