Optimizely Web Experimentation Cookie同意集成指南：2026年GDPR下的A/B测试
Optimizely在同意讨论中占据着奇特的位置。理性的人看到实验工具可能认为这是低风险类别——测试关注的是哪种按钮颜色获得更多点击，而不是访客是谁。然而，在GDPR建立、EDPB自2023年以来积极执行的框架下，现实是：每当平台写入持久标识符并将实验变体与之绑定时，该实验就涉及与分析或营销完全相同的处理类别。Optimizely Web Experimentation SDK正是这样做的：对持久标识符进行哈希处理以将访客分配给变体，将分配写入第一方Cookie以使访客在整个会话中看到相同变体，并发出与该标识符关联的展示和转化事件。这些步骤中的每一步都会触发同意要求。好消息是，Optimizely在实验类别中拥有最周全的同意集成之一：专用的同意属性和仅在匿名模式下运行的能力。挑战在于真正地使用它们。
Optimizely Web Experimentation为何需要同意
Optimizely的默认初始化在页面首次渲染时执行多项操作：在optimizelyEndUserId键下设置包含持久访客标识符的第一方Cookie；针对活跃实验评估访客；将变体分配写入optimizelyOptOut键下的第二个Cookie；向logx.optimizely.com触发决策事件；并将变体更改应用于渲染页面。如果运营商连接了分析集成——Google Analytics 4、Adobe Analytics、Amplitude、Mixpanel、Heap或Optimizely Data Platform——SDK还会向分析层触发变体展示事件，将变体与访客更广泛的分析档案关联。
这些活动中的每一项都会触发独立的同意要求。访客标识符的持久性是ePrivacy指令Article 5(3)下的存储和访问操作，在EEA、UK以及采用相同标准的所有司法管辖区需要事先、自愿、具体、知情且明确的同意。在会话中将实验变体分配与该标识符绑定是GDPR下的个人数据处理，因为标识符、IP地址和变体展示的组合足以识别个人并表征其与实验项目的互动。跨工具传播变体数据——例如Optimizely将变体传递给Google Analytics——为链条添加了分析关卡。EDPB 2023年指南明确指出，涉及持久识别的实验受与分析相同的同意规则约束。CNIL是在这一点上最高声的监管机构，但并非唯一。
Optimizely在同意前写入的内容——需要抑制的内容
标准Optimizely代码片段将JavaScript SDK直接安装在页面head中并在加载时立即初始化。这是有据可查的快速入门方式，也是最常见的合规失败原因。SDK在Cookie横幅渲染之前执行：optimizelyEndUserId Cookie在毫秒内写入，变体分配完成，决策事件触发——无论访客之后如何决定。每个评估过此模式的欧洲监管机构都得出了相同结论：同意前设置的Cookie是违法的；同意前捕获的变体分配是违法处理；发布者承担责任。
合规集成必须阻止Optimizely在相关同意类别被授予之前向Cookie写入持久标识符并触发决策事件。Optimizely为此支持两种模式。第一种是专用同意属性：在SDK初始化前将OPTIMIZELY_OPT_OUT=true作为查询字符串传递或设置optimizely.opt_out Cookie，将SDK置于退出模式——不写入标识符，不触发事件。第二种是SDK配置中支持的仅匿名模式：SDK以无会话模式运行，仅基于会话本地标识符分配变体，无需跨访问的持久识别。匿名模式允许实验项目在渲染决策的正当利益基础上运行，同时将持久识别推迟到同意授予为止。
Optimizely写入的Cookie和存储
Optimizely Web Experimentation SDK在初始化时写入以下标识符——这些都是非必要的，需要同意：optimizelyEndUserId，具有多年到期时间的持久访客标识符；跟踪退出状态的optimizelyOptOut标记；用于跨子域名实验的optimizelyDomainTestCookie；以及如果运营商启用了跨域名识别，还有附加命名空间Cookie。同意撤回必须同时执行Cookie到期以及通过optimizely.push({ type: 'user', attributes: { opt_out: true } })将SDK设置为退出模式，停止进一步的事件收集。
将Optimizely映射到同意框架
Optimizely本身不实施IAB TCF或IAB Global Privacy Platform——它是第一方实验平台，而非广告技术供应商。但它公开了原生退出API，通过Optimizely Data Platform支持有据可查的Consent Mode集成，并通过OPTIMIZELY_OPT_OUT属性尊重发布者的CMP。通过监管审查的模式将每个Optimizely功能视为与特定CMP信号关联的独立关卡。
- 匿名实验可以在会话本地标识符的正当利益基础上运行。这适合不需要跨访问持久识别、不向下游分析传播的渲染决策。此模式与严格必要或功能类别关联。
- 具有稳定标识符的持久实验与分析目的关联。TCF术语中，这映射到目的8与目的1的组合。在Consent Mode中映射到analytics_storage。
- 跨工具集成（传播到Google Analytics、Amplitude或Optimizely Data Platform的变体展示事件）从接收工具继承分析关卡，如果该工具的关卡未被授予则不应触发。
- 构建在实验之上的个性化和基于受众的定向在从实验测量转向用户级定向时触发营销关卡。
有效的集成模式
参考部署有四个部分：发布实时同意更改事件的CMP；在启用退出或激活匿名模式的情况下初始化Optimizely SDK的延迟引导；在分析关卡打开时将SDK从退出切换到持久识别的同意监听器；以及将SDK返回退出模式、通过document.cookie使optimizely Cookie到期、并将撤回传播到下游分析集成的撤回路径。
采用延迟引导的Web实现
在Web端，最简洁的模式是在SDK初始化前设置window.optimizelyOptOut = true后加载Optimizely代码片段。订阅CMP同意更改事件。当分析类别转为true时，调用window.optimizely.push({ type: 'user', attributes: { opt_out: false } })并让SDK正常初始化。当关卡被撤回时，将退出属性恢复为true，使optimizelyEndUserId Cookie到期，并通过各自的同意API将更改传播到集成的分析平台。
通过Decision Service进行服务端实验
Optimizely还通过Decision Service API支持服务端实验。服务端决策不豁免于同意——法律依据跟随数据。但服务端执行允许发布者完全控制传播哪些标识符。有效模式是在分析关卡关闭时向Decision Service传递临时会话标识符，仅在关卡打开时切换到持久标识符。Decision Service返回的变体分配仍可应用于渲染页面——变化的是它们是否与稳定的访客记录关联。
验证集成和审计追踪
验证步骤是监管机构检查的内容，也是发布者在实验工具中最常跳过的内容。正确集成的Optimizely部署必须依次通过四项测试。第一，显示横幅但未做选择的干净浏览器会话应显示除SDK文件获取外零流量到logx.optimizely.com，以及document.cookie中零个optimizely Cookie。第二，拒绝分析必须保持该状态：无持久标识符，无决策事件，无与稳定记录关联的变体分配。第三，接受分析应产生预期的optimizelyEndUserId Cookie和决策事件流量，并正确应用变体分配。第四，同意撤回应立即停止进一步决策事件，使Cookie到期，并向下游分析集成传播退出。
EDPB 2023年Cookie横幅指南和2026年更新工作组优先事项下的审计追踪期望是：发布者能够证明访客在展示时对Optimizely项目中特定实验展示提供了有效同意。标准模式是通过SDK属性API在Optimizely访客配置文件中将同意版本和时间戳设置为自定义属性，以便每次展示都可追溯到特定的同意日志条目。正确受控的部署与用于同意前渲染决策的匿名模式以及向下游传播的撤回路径相结合，将Optimizely从隐藏的实验层负债转变为发布者产品和增长堆栈中可防御的部分。