在高并发数字化实验场景下，增长团队与产品研发团队经常在相同的页面、结账漏斗或关键转化路径上并行开展多项 A/B 测试。如果同一位访客同时命中两项或多项实验，便会引发交互效应（Interaction Effects）：团队无法辨别核心指标的提升究竟源自哪一个方案，动态流量变动还可能诱发样本比例失衡（Sample Ratio Mismatch, SRM）。
在 Optimizely 中，解决该问题的核心手段是配置互斥实验组（Exclusion Groups）。互斥实验组作为一个共享流量容器，将多个重合实验聚合在一起，并通过统一的确定性分流种子对受众流量进行科学切分。被分配至实验 A 的用户，绝不会在同一互斥组内被分流至实验 B。
何时应当使用互斥实验组（何时应避免使用）
互斥分流能够保障统计数据的严谨性，但它伴随直接的业务代价：流量稀释。将有限的受众样本切分给多个独立测试，会导致单一实验获得的样本量成倍缩减，进而显著拉长达到统计显著性所需的时间周期。
实验团队应依据业务场景权衡取舍：
| 业务场景 | 建议策略 | 决策考量 |
|---|---|---|
| 直接视觉与交互冲突（例如同页面争抢顶部 Banner、弹窗改版） | 强制配置互斥实验组 | 避免页面排版错乱与用户体验冲突。 |
| 高相关度核心转化漏斗（例如购物车改版与结账物流计算改版并行） | 强制配置互斥实验组 | 杜绝上游变量对下游漏斗指标产生隐性交互污染。 |
| 底层核心算法变更（例如搜索召回模型与推荐排序算法同时改版） | 强制配置互斥实验组 | 避免算法重叠造成响应逻辑冲突与延迟指标失真。 |
| 物理位置独立的页面区域（例如顶部导航菜单改版与页脚合规文案改版） | 并行运行（无需互斥） | 用户行为交互效应极低；保留完整流量并保障实验推进速度。 |
| 主动评估组合协同效应（例如探索文案与主按钮颜色是否存在协同促进） | 采用多变量实验（MVT）替代 | 全因子 MVT 能够在统计学上量化交互作用，而非人为屏蔽它。 |
Optimizely 互斥分流的底层运作机制
默认情况下，Optimizely 对各个实验进行独立分流计算。针对每个实验，Optimizely 会将用户唯一标识（User ID 或 Bucketing ID）与实验 ID（Experiment ID）拼接，通过确定性哈希算法（MurmurHash3）映射至 0 到 9,999 共计 10,000 个流量分桶中。
由于各个独立实验的哈希入参不同，同一用户很可能同时落入多个正在运行的实验的分流区间内。
当实验被纳入**互斥实验组（Exclusion Group）**时，Optimizely 会调整其分桶逻辑：
- 共享分流种子：哈希函数首先将用户标识与互斥组 ID 进行哈希计算。
- 确定性流量切分：10,000 个分桶会严格按照互斥组内设定的比例分配给各个成员实验。
- 强隔离机制：若用户落入实验 A 占据的分桶区间，该用户仅对实验 A 具备参试资格，系统在互斥组内将直接跳过对实验 B 或实验 C 的评估。
决策评估优先级（Evaluation Order）
在 Optimizely Feature Experimentation 与 Web Experimentation 中，分流决策遵循严格的短路执行顺序：
- 规则状态检查：校验 Flag 规则或实验是否处于运行状态。
- 强制变体（Forced Variations）：优先级最高（用于 QA 与内部测试）。
- 白名单用户（User Allowlisting）：显式指定用户 ID 映射。
- 用户画像服务（User Profile Service, UPS）：从存储中调取历史会话中的固定分配结果。
- 受众定向（Audience Targeting）：评估用户属性是否符合受众规则。
- 互斥实验组评估（Exclusion Group Evaluation）：确认该用户是否已分配给组内其他实验；若已分配，则直接排除。
- 流量分配与变体哈希（Traffic Allocation）：根据实验内设定的比例，将用户分配至具体变体（例如 A 组或 B 组）。
操作指南：Optimizely Web Experimentation 客户端配置
适用于前端或边缘层运行的 Web 改版实验团队：
1. 创建互斥组
- 登录 Optimizely Web Experimentation 控制台，进入 Experiments 页面。
- 点击 Exclusion Groups 标签页。（注：若已开通 Optimizely Personalization，请前往 Optimizations > Exclusion Groups）。
- 点击 Create New Exclusion Group 按钮。
- 输入清晰易辨的组名称（Name）与可选的描述（Description）（例如
Checkout_Funnel_Q2_Exclusion）。
2. 关联实验并分配流量比例
- 勾选需要加入该互斥组的草稿状态实验。
- 设定各实验在互斥组总流量中的分配占比：
- 例如两个测试可以各设 50%；
- 也可以保留对照保留组（如实验 1 分配 40%、实验 2 分配 40%、保留未分配流量 20%）。
- 点击 Create Exclusion Group 保存生效。
3. 校验触发条件与页面匹配
确保纳入同一互斥组的所有实验，其页面 URL 匹配规则、激活触发器或受众条件具有合理重合度，避免流量分配失衡。
操作指南：Optimizely Feature Experimentation 服务端配置
适用于后端、移动应用及全栈架构工程团队：
1. 在 Flags 控制台中创建互斥组
- 打开 Flags 导航栏，切换至 Exclusion Groups 标签页。
- 点击 Create New Exclusion Group。
- 填写组名称与描述信息。
- 选择生效的目标环境（Environment）（如
Production或Staging，互斥组与环境强绑定）。 - 点击 Create Exclusion Group 完成创建。
2. 将 Flag 实验规则挂载至互斥组
- 返回 Flags 列表，进入包含目标实验规则的功能标识（Feature Flag）。
- 选择对应环境，点击进入具体的 Experiment Rule。
- 在 Configure Rule 配置区域中，找到下拉选项："Add this experiment to the following exclusion group"。
- 从下拉菜单中选择此前建立的互斥组。
- 输入该实验在互斥组内部占用的流量百分比。
- 点击 Save Experiment 保存。
- 对所有需要互斥的平行实验规则重复上述关联步骤。
3. 通过 REST API 进行自动化配置
对于推行自动化发布流程的工程团队，可直接通过 Optimizely REST API 进行编排：
- 创建互斥组：调用
POST /v2/groups，传入参数{"name": "Cart_Redesign_Group", "environment_key": "production"}； - 更新互斥规则：调用
PATCH /v2/groups/{group_id}，通过rule_id将实验规则绑定至组中； - 巡检组状态：调用
GET /v2/groups批量查询各环境的互斥配置。
4. SDK 零代码改动接入
互斥组逻辑完全由规则集（Datafile）定义并由 SDK 内存引擎自动执行。业务代码调用 client.decide(user_key, flag_key) 时，SDK 会在本地毫秒级完成互斥剔除与分桶计算，无需额外编写协同调度逻辑。
实验治理的四大关键准则
为避免数据污染、统计偏差和不可解释的指标异动，实验团队必须严格遵守以下四项治理规范：
1. 组内实验必须统一步调同步上线
严禁今天启动实验 1，下周再向同一互斥组中塞入实验 2。如果已有访客在单一实验运行期间被打上了组分桶标签，后续追加新实验会打乱哈希边界，导致老用户发生跳变或破坏新样本的随机分布。
2. 严禁在实验运行期间动态增删组成员
互斥组内只要有任何一个实验处于运行状态：
- 切勿向组中追加新实验；
- 切勿从中移除正在运行的实验。 运行中变更会导致流量分桶重新计算，直接触发样本比例失衡（SRM）警报，致使统计结果彻底作废。若某一实验需提前终止，应暂停其规则而非直接拆解互斥组。
3. 保持互斥组成员受众定向的一致性
如果实验 A 面向全部桌面端用户，而实验 B 仅定向移动端用户，将二者置于同一互斥组会产生大量流量浪费。由于分桶先在组级完成，被抽中分流给实验 B 的桌面端访客将直接退出，导致实验 A 错失宝贵的桌面端样本容量。
4. 警惕用户画像服务（UPS）的优先级穿透
在配置了 User Profile Service（UPS）以保障跨会话变体固化的全栈架构中，UPS 查找位于互斥组评估之前执行。如果用户在挂载互斥组之前曾命中过独立运行的历史变体，UPS 会强制返回该旧记录，进而穿透互斥限制。在此类场景下，可搭配 OptimizelyDecideOption.IGNORE_USER_PROFILE_SERVICE 选项确保隔离洁净度。