1 背景

谷歌（Google）以数据驱动著称，几乎所有可能影响用户体验的改动，无论是 UI 界面调整还是背后算法变更，都要通过在线实验（A/B 测试）来验证。实验的目标是更好地评估新方案的效果，从而加速产品迭代。传统的单层实验系统中，每个请求最多只能属于一个实验。谷歌早期采用Cookie Mod和随机流量分流的单层方案：首先按 Cookie 模划分流量给某些实验，其余流量再做随机分配。这种设计虽然实现简单易用，但存在两个严重的问题：

• 前端代码（上游服务）先行“抢占”流量后，下游服务很可能流量匮乏，导致实验流量饥饿和偏差。
• 更重要的是，这样的单层体系无法支撑大量并发实验，难以满足谷歌数据驱动的需求。

随着迭代需求激增，单一实验平台的可并行实验数量成为瓶颈：如果同时只能运行很少实验，就无法支撑快速的创新节奏。因此，谷歌需要一个架构来支持“更多、更好、更快”的实验。

---

💡 A/B 测试

A/B 测试是一种数据驱动的在线实验方法，用于评估产品改动（如界面、功能或算法）对用户行为或业务指标的影响。通过将用户随机分配为两组：实验组（使用新方案）和控制组（保持现状），对比两组在关键指标上的差异，判断新方案是否有效。其核心优势是通过随机化控制干扰因素，使因果推断更可靠。

实验设计需遵循以下原则：

• 随机分配：确保用户特征在两组中均衡分布，避免系统性偏差；
• 一致分流：同一用户始终进入相同分组，保持实验稳定性；
• 样本量充足：便于检测小幅度变化，提高统计显著性。

常见的评估指标包括：

类型	示例	用途说明
用户行为	点击率（CTR）、转化率（CVR）、跳出率	衡量改动是否改善用户互动与留存
商业指标	收入、下单率、ARPU	直接与业务增长挂钩，是决策重点
系统性能	加载时间、错误率、耗时	反映改动对系统稳定性与响应效率的影响
长期价值	留存率、生命周期价值（LTV）	评估改动对用户长期使用的积极或负面影响

不同实验目标对应不同核心指标。以推荐算法为例，可能关注点击率、推荐命中率、长时间停留等；而注册流程优化则更看重转化率、漏斗流失率等。

此外，为防止“指标漂移”或过度追求短期提升，谷歌等公司还会设定一组保底指标（guardrail metrics），确保实验不会在某些维度上造成退化（如用户满意度或系统稳定性下降）。

为解决单层架构的局限性，谷歌提出了重叠实验基础设施。这一创新架构的核心思想是：将系统参数划分到不同层(Layer)，并允许一个用户请求同时参与多个不同层的实验。与传统的单实验（每请求仅一个实验）不同，每个请求可同时参加多个实验，但每个实验只能修改其对应层的参数。这样，系统可在不同维度上“交叉”运行实验，而不互相干扰。

2 三个核心概念

重叠实验架构的基础由三个核心概念组成：

1. 域(Domain)：对请求流量的分段(Segmentation)，定义了一组实验的运行范围
2. 层(Layer)：系统参数的逻辑子集，每层包含互不重叠的参数组
3. 实验(Experiment)：在特定域内的特定层上，对一部分流量给予替代参数值的尝试

域和层是可嵌套的：域中包含多个层，层中可以包含实验，也可进一步嵌套域。默认域包含所有流量、所有参数。我们可以在默认域内设计多种结构：例如将参数简单划分为三个层，则每个请求最多参加3个实验，各层互不重叠。

或者先将流量分到两个域：一个非重叠域（流量分配到此域的请求最多参与一个实验，可以改变任意参数），另一个重叠域（流量分配到此域的请求可分别进入多个层的实验，每层实验仅修改该层参数）。

下图示意了一个简单的域/层结构示例。整个系统由一个默认域包含所有流量，然后分为两个主要的子域：

左侧的非重叠域占据40%的流量，其特点是每个请求最多只能参与一个实验，但这个实验可以修改系统中的任意参数。这个域中包含三个独立实验（X、Y、Z），每个占10%流量，剩余70%为控制组。右侧的重叠域占据60%的流量，其特点是请求可以同时参与多个不同层的实验。这个域被划分为三个功能层：UI层、算法层和特性层，每层管理不同的参数集。每层都有自己的实验组和控制组，且流量分配各不相同：UI层的实验A占25%，算法层的实验B占30%，特性层的实验C占20%。

下图中展示了更复杂的嵌套关系：算法层内嵌套了搜索算法子域，包含排序和推荐两个并行实验；个性化层内部嵌套了用户细分子域，再进一步细分为新用户域和老用户域，实现精细化实验控制。通过这种多级嵌套方式，对参数的不同组合划分和流量层次划分可以灵活配置，大大提升并行实验的灵活性和效率（下图示意了一个复杂的域/层嵌套结构示例）。

3 Launch层：特性发布的专用机制

除了常规的实验层外，谷歌还引入了"Launch层"(发布层)的概念，专门用于新特性的渐进式发布。Launch 层总是在默认域中（即覆盖全量流量），与“普通”层使用不同的参数划分方式。在 Launch 层中，实验指定的是参数的新默认值：如果在其他层没有覆盖这些参数，实验中的默认值生效；如果已有层覆盖，则继续沿用普通层的值。

Launch层为特性发布提供了强大的控制机制，使产品团队能够：

• 逐步放量新特性，确保平稳过渡
• 测试不同特性版本间的交互影响
• 在同一个实验框架内统一管理特性发布和常规实验
• 在发现问题时快速回滚，通过调整 Launch 层的参数分配

4 流量分发策略和条件筛选

实验中如何决定每个请求进入哪些实验？这依赖于流量分发类型（Diversion）和条件筛选。

4.1 四种流量分发类型

谷歌的实验平台支持四种主要的流量分发（Diversion）方式，按优先级依次为：

• 用户 ID 分发（User ID Mod）：使用用户登录 ID 做 Hash 切分流量。
• Cookie 分发（Cookie Mod）：使用浏览器 Cookie 做 Hash 切分流量。
• Cookie+日期分发（Cookie-Day Mod）：对 Cookie 结合日期做 Hash，使得同一用户在不同日期可能进入不同实验。这种方式适合短期测试或需要日常变化的场景。
• 随机分发（Random）：对请求做全局随机采样，不保证同一用户的一致性。适用于无需用户连续体验的后端服务测试。

这些分发方式依次按顺序应用：先尝试 User ID 分发，其次是 Cookie 分发，之后是 Cookie+日期，最后才是随机。一旦请求被某种分发方式选中并匹配到一个实验，就不再参加后续的分发。这样确保了测试的一致性（同一用户/Cookie 会持续进入同一类型实验），但也会导致例如 1% 的随机流量实验实际上接收的请求远少于 1% 的 Cookie 实验。

4.2 条件筛选机制

在流量分发的基础上，谷歌的实验平台还支持通过各种条件进一步筛选流量：

条件筛选**（如国家、语言、浏览器、机房等）**可应用于所有类型的流量分发之上。例如，针对“仅对日本用户”做实验时，可在 Cookie 分流后添加“日本”条件，以避免与英文实验冲突。筛选条件还可以用于灰度发布：如仅在特定机房做金丝雀测试，观察新代码稳定性。

5 工具链与监控体系

重叠实验基础设施依赖完善的工具链和监控流程来保障可靠性。

1. 首先，所有实验配置都以数据文件形式管理，可由非工程师（如产品经理）编辑，数据文件通过自动化校验工具进行检查，验证语法、ID 唯一性、参数所属层是否一致、所请求的流量量级是否可用、实验设计是否合规（如是否包含控制组）等。
2. 其次，配置更新无需重新部署代码，而是通过自动化部署系统将验证通过的配置分发至线上环境，包括流量分配、参数激活、触发器设置和日志配置等。
3. 最后，使用实时监控系统跟踪实验指标（如点击率 CTR 等）。实验者可为关键指标设置期望范围，监控系统实时计算度量值，如果超出预期范围则自动告警。这样可以让实验者在实验跑出异常时立即干预，例如暂停实验或修正参数，从而尽量避免流量浪费或线上问题。

6 实验设计原则

在重叠实验框架下，为确保获得高可信度和高质量的实验结果，需要遵循以下几项核心设计原则：

• 并非所有被分流到实验中的请求都会实际触发实验逻辑。例如，某个关于天气信息的实验可能只在用户搜索特定地点或与天气相关的查询时才会触发显示逻辑，这部分真正触发实验条件的请求就构成了该实验的"触发集"。

  为获得准确的实验评估，系统需同时记录两种情况的日志：

  • 事实情形（Factual）：在实验组中记录实际触发了实验逻辑的请求
  • 反事实情形（Counter-factual）：在对照组中记录那些满足触发条件但因为在对照组而未应用实验逻辑的请求

  有了这两个日志，才能准确计算实验真实影响，并避免将未触发的请求稀释掉指标变化。通过分析触发集效果，可提升统计效率（同样的流量下因为效果更明显而更容易检测出差异）。

• 高质量的实验设计应包含实验前后的观察窗口：

  • 预观察期（Pre-period）：在正式实验前设置一段时间窗口，此时已完成流量分组，但尚未应用实验逻辑变更，所有组别仍保持原有行为。
  • 后观察期（Post-period）：实验结束后，继续保持一段时间的分组记录，但所有组别均恢复到原始行为。

  预观察期帮助确认所分配的实验流量与控制组具有可比性，可有效检测潜在的实验偏差（如机器人流量、爬虫干扰或其他异常流量分布）。后观察期则用于检测实验结束后的用户行为变化，特别是学习效应或延续效应是否存在。这两种观察期在基于用户ID或Cookie的实验中尤为重要，已成为谷歌实验设计的标准实践。

• 共享控制组：在传统实验中，每个实验需要独立分配控制组和实验组流量。而在重叠架构下，同一层内的多个实验可以共享一个统一的、规模较大的控制组。每个层内只需设置一个大型控制实验，即可同时作为该层多个具体实验的对照。只要共享控制组的规模远大于单个实验组，其统计效力可提升至相当于双倍独立样本，甚至更高。此机制可显著降低了每个实验所需的流量量级，提升了整体流量利用效率。

• 由于不同实验可以并行进行，重叠设置允许一个层内建立共享的超大控制组。例如，在每个层里只需要一个大的控制实验，就可服务于多个具体实验的对照。只要共享控制组远大于单个实验组，其统计效力相当于双倍独立样本乃至更高，从而显著降低每个实验所需的流量规模。从统计学角度看，控制组共享使重叠架构在同等流量条件下获得更高的统计检验效力，是实现"更多、更好、更快"实验目标的关键策略之一。

除了以上特定机制外，每个实验还必须满足以下基本要求：

• 明确假设：清晰定义实验假设和预期效果
• 适当的分流策略：根据实验性质选择合适的流量分发类型
• 合理的分析指标：预先确定主要指标和次要指标
• 统计工具支持：确保分析工具能自动计算置信区间、执行A/A测试等统计验证

7 培训

技术平台之外，谷歌也通过制度和培训确保实验质量。

其一是实验委员会（Experiment Council）：实验发起者在投放实验前需填写一份检查表，由一个跨团队工程师小组审查。检查表内容包括：

• 基本的实验特性（比如，实验测试什么？它们的假设是什么？）
• 实验的建立（比如，要修改哪些参数，每个实验或实验集合分别要测试的是什么？在哪一层？）
• 实验的流量分配和触发条件（比如，使用什么分配类型和什么分配条件，在多大比例的流量触发实验）
• 实验分析（比如，关注哪个指标？实验者要检测的指标敏感度是什么？）
• 实验规模和时间跨度（即保证，给定一定的流量，实验是有足够的统计量来检测指标敏感度）
• 实验设计（比如，是否要用预时期和后时期来保证，是否反事实日志正确被记录等等）

对于新手来说，这是学习实验设计的过程；对经验者则是快速自查，有问题可提前解决。所有审核过程都有记录，新人可参考已有案例，专家也能借此及时传播最新最佳实践。

其二是数据解读会议：实验结束后，团队会将结果带到一个开放的讨论会，由各领域专家（基础设施、日志、指标、统计分析等）共同参与。会议目标是：

1. 确认结果正确（有时实现细节出错或数据异常需要排查）
2. 挖掘全面洞见（补充指标、不同切片分析等）
3. 评估是否上线（在综合业务视角和数据结果后达成一致）。

这种复盘机制不仅能纠偏，还让经验丰富的同事将知识传递给新人，不断提高全员的实验素养。

参考与推荐

美团点评效果广告实验配置平台的设计与实现

美团—如何提供一个可信的AB测试解决方案

谷歌是如何高效做AB实验的

Athena-贝壳流量实验平台设计与实践

Overlapping Experiment Infrastructure: More, Better, Faster Experimentation 原文

Overlapping Experiment Infrastructure: More, Better, Faster Experimentation 中文翻译