# AB 测试平台全网竞品与方案调研

> **版本**：2026 年 10 月深度版  
> **范围**：全球 40+ 商业厂商、14 个开源项目、7 类玩家；中国 15+ 互联网公司公开实践；实验平台 6 大核心模块  
> **方法**：L0 基线 + 25 路深度研究 + 2 路交叉验证 + 7 个分册合成  
> **适用读者**：CEO/产品负责人、技术架构师、数据/实验平台负责人

---

## 阅读指南

- 只想快速决策：读 **第 0 章**、**第 9 章**、**第 10 章**。
- 做产品选型：读 **第 2、3 章** 与 **第 9 章** 的对比矩阵。
- 做技术方案：读 **第 6、7 章** 与 **第 10 章** 的参考架构。
- 做中国本土平台：读 **第 4 章** 与 **第 5 章**。

> 信息可信度：A 级=官方文档/源码/论文/公告；B 级=工程博客/权威媒体/可复现评测；C 级=招聘 JD/二手转述。关键处均标注来源；无法核实的写「待核实」，不编造。

---

## 目录

- [0. 执行摘要](#0-执行摘要)
- [1. 研究设计、方法与市场地图](#1-研究设计方法与市场地图)
- [第 2 章 商业平台（上）：Web 实验与优化套件](#第-2-章-商业平台上web-实验与优化套件)
- [2.1 赛道地图与产品谱系](#21-赛道地图与产品谱系)
- [2.2 Optimizely 深度拆解](#22-optimizely-深度拆解)
- [2.3 VWO 深度拆解](#23-vwo-深度拆解)
- [2.4 AB Tasty / Kameleoon / Convert / SiteSpect](#24-ab-tasty--kameleoon--convert--sitespect)
- [2.5 Adobe Target / Dynamic Yield / Monetate / Sitecore](#25-adobe-target--dynamic-yield--monetate--sitecore)
- [2.6 六平台能力对比矩阵](#26-六平台能力对比矩阵)
- [2.7 Web 优化套件的共性局限](#27-web-优化套件的共性局限)
- [2.8 对我们的启示](#28-对我们的启示)
- [第 3 章 商业平台（下）：现代实验平台、Flag 路线与采购](#第-3-章-商业平台下现代实验平台flag-路线与采购)
- [3.1 现代实验平台的四条路线](#31-现代实验平台的四条路线)
- [3.2 Statsig：把 Flag、实验、分析焊在一套曝光上](#32-statsig把-flag实验分析焊在一套曝光上)
- [3.3 Eppo：卖的不是 UI，是 assignment 语义](#33-eppo卖的不是-ui是-assignment-语义)
- [3.4 GrowthBook 云版：把「可拥有」做成价格优势](#34-growthbook-云版把可拥有做成价格优势)
- [3.5 Amplitude Experiment：分析套件的延伸，而非统计引擎](#35-amplitude-experiment分析套件的延伸而非统计引擎)
- [3.6 Flag 路线：LaunchDarkly、Split、Flagsmith、ConfigCat、Unleash](#36-flag-路线launchdarklysplitflagsmithconfigcatunleash)
- [3.7 云厂商与停服教训：他们卖的是交付，不是推断](#37-云厂商与停服教训他们卖的是交付不是推断)
- [3.8 定价、TCO 与采购 scorecard](#38-定价tco-与采购-scorecard)
- [3.9 对我们的启示](#39-对我们的启示)
- [第 4 章 中国互联网公司实验平台](#第-4-章-中国互联网公司实验平台)
- [4.1 中国实验平台全景](#41-中国实验平台全景)
- [4.2 字节跳动](#42-字节跳动)
- [4.3 阿里巴巴](#43-阿里巴巴)
- [4.4 腾讯](#44-腾讯)
- [4.5 美团 / 滴滴 / 百度](#45-美团--滴滴--百度)
- [4.6 快手 / 小红书 / B站 / 京东 / 网易 / 拼多多 / 携程 / 知乎](#46-快手--小红书--b站--京东--网易--拼多多--携程--知乎)
- [4.7 横向对比：组织、架构、统计、场景](#47-横向对比组织架构统计场景)
- [4.8 对中国企业的启示与信息缺口](#48-对中国企业的启示与信息缺口)
- [第 5 章 开源方案与自建](#第-5-章-开源方案与自建)
- [5.1 开源生态地图](#51-开源生态地图)
- [5.2 GrowthBook：开源世界里最接近「完整答案」的那一个](#52-growthbook开源世界里最接近完整答案的那一个)
- [5.3 PostHog：把实验做成 Flag 的一个视图](#53-posthog把实验做成-flag-的一个视图)
- [5.4 Unleash / Flagsmith / Flipt / Flagr / OpenFeature：交付层的五个样本](#54-unleash--flagsmith--flipt--flagr--openfeature交付层的五个样本)
- [5.5 FeatureProbe / ABRouter / Superposition / 其他：三种抽象，三种教训](#55-featureprobe--abrouter--superposition--其他三种抽象三种教训)
- [5.6 能力对比矩阵](#56-能力对比矩阵)
- [5.7 自建 TCO 与二次开发风险](#57-自建-tco-与二次开发风险)
- [5.8 三套推荐方案](#58-三套推荐方案)
- [第 6 章 核心技术模块（上）：实验设计、分桶与统计](#第-6-章-核心技术模块上实验设计分桶与统计)
- [6.1 实验设计的决策树](#61-实验设计的决策树)
- [6.2 随机化单元与实验类型](#62-随机化单元与实验类型)
- [6.3 正交分层、互斥与 Holdout](#63-正交分层互斥与-holdout)
- [6.4 Switchback / Cluster / Interleaving / MAB](#64-switchback--cluster--interleaving--mab)
- [6.5 分桶与哈希工程](#65-分桶与哈希工程)
- [6.6 统计引擎：频率派](#66-统计引擎频率派)
- [6.7 CUPED 与方差缩减](#67-cuped-与方差缩减)
- [6.8 序贯检验与贝叶斯](#68-序贯检验与贝叶斯)
- [6.9 多重比较、SRM、功效](#69-多重比较srm功效)
- [6.10 常见统计陷阱](#610-常见统计陷阱)
- [6.11 对我们的启示](#611-对我们的启示)
- [第 7 章 核心技术模块（下）：指标、架构、组织](#第-7-章-核心技术模块下指标架构组织)
- [7.1 指标体系与 OEC](#71-指标体系与-oec)
- [7.2 曝光、归因与数据链路](#72-曝光归因与数据链路)
- [7.3 实时、批处理与 warehouse-native](#73-实时批处理与-warehouse-native)
- [7.4 参考架构：控制面、数据面、分析面](#74-参考架构控制面数据面分析面)
- [7.5 分流服务与配置下发](#75-分流服务与配置下发)
- [7.6 SDK 与 OpenFeature](#76-sdk-与-openfeature)
- [7.7 多租户、权限、审批、审计](#77-多租户权限审批审计)
- [7.8 规模、可用性与可观测性](#78-规模可用性与可观测性)
- [7.9 组织、流程与合规](#79-组织流程与合规)
- [7.10 模块级 build vs buy](#710-模块级-build-vs-buy)
- [第 8 章 全球案例、学术与趋势](#第-8-章-全球案例学术与趋势)
- [8.1 海外大厂案例地图：十三家公司，一张约束地图](#81-海外大厂案例地图十三家公司一张约束地图)
- [8.2 Netflix / Airbnb / Booking.com：三种「规模化」](#82-netflix--airbnb--bookingcom三种规模化)
- [8.3 Microsoft / Google / Meta / LinkedIn：四个瓶颈，四种答案](#83-microsoft--google--meta--linkedin四个瓶颈四种答案)
- [8.4 Uber / Spotify / Etsy / DoorDash / Instacart / Amazon：实验设计跟着业务结构走](#84-uber--spotify--etsy--doordash--instacart--amazon实验设计跟着业务结构走)
- [8.5 中国大厂公开资料与学术脉络：五条路线，三种加码](#85-中国大厂公开资料与学术脉络五条路线三种加码)
- [8.6 学术基础与标准：学术解决「对不对」，平台解决「用不用得起来」](#86-学术基础与标准学术解决对不对平台解决用不用得起来)
- [8.7 2026–2028 趋势判断：从「实验工具」到「决策层」](#87-20262028-趋势判断从实验工具到决策层)
- [8.8 推荐阅读与启示](#88-推荐阅读与启示)
- [9. 综合对比与选型建议](#9-综合对比与选型建议)
- [10. 参考架构与落地路线图](#10-参考架构与落地路线图)

---

## 0. 执行摘要

### 0.1 一句话结论

**A/B 测试平台已经从「页面优化工具」演化为「产品决策的基础设施」。** 2023-2026 年的停服与并购证明：只做可视化编辑器的产品会被替代，只做 Feature Flag 的产品会被统计层卡住，只做统计的产品会被数据架构卡住。真正稀缺的能力不是「能开实验」，而是**可信的统计、统一的指标口径、低延迟的分流、以及能约束组织的治理机制**。

### 0.2 十个核心判断

**判断一：市场没有全能冠军，选型必须先画「缺口图」。**  
市场至少分成七类玩家：Web 优化套件、企业个性化套件、Feature Flag/交付、现代实验平台、云厂商/边缘原生、开源自建、中国大厂自建/对外输出。每类只覆盖「决策/分流/指标/统计/治理」中的几层。拿一张功能清单横向打勾，是最容易选错的起点。

**判断二：2023-2026 的关键词是「整合」，而且被收购不等于更安全。**  
Harness 宣布收购 Split（2024-05-29 宣布、06-11 交割）、Datadog 收购 Eppo（2025-05）、OpenAI 以 11 亿美元收购 Statsig（2025-09），随后 Statsig 的产品与客户在 2026-05 转给 Amplitude；VWO 与 AB Tasty 在 2026-09 统一为 Wingify；SiteSpect 并入 Monetate。停服侧，Google Optimize（2023-09-30）与 AWS CloudWatch Evidently（2025-10-17）退出。**收购方要的往往是团队与内部能力，不一定是继续经营这个 SaaS。** 选型必须评估数据导出、SDK 替换与「控制权变更」条款。

**判断三：统计引擎的差异不在「方法名」，而在默认参数与产品化程度。**  
几乎每家都宣称支持频率派、贝叶斯、序贯、CUPED；真正拉开差距的是：默认用哪种方法、是否允许 peeking、多重比较怎么校正、比率/分位数指标怎么算、SRM 能否自动定位、护栏指标是否内置、结果是否可解释。**「支持 CUPED」不等于「CUPED 实现正确」，更不等于「业务方看得懂」。**

**判断四：Warehouse-native 是 2023-2026 最重要的架构分化。**  
Eppo、GrowthBook 把指标计算下推到客户数仓，解决「数据不出域、口径统一、不重复建管道」三个问题；Statsig 等自建事件管道，强调实时与开箱即用。前者适合数据成熟、指标复杂的公司，后者适合追求上线速度、实时性强的团队。**没有数仓口径的公司，上 warehouse-native 是空中楼阁。**

**判断五：Flag 与 Experiment 在融合，但「发布安全」与「因果推断」仍是两种产品。**  
Harness FME、Statsig、Eppo、GrowthBook 把 Flag 与实验放在同一套 SDK/曝光上；LaunchDarkly 转向「Guarded Releases」（按护栏指标自动回滚），但它同时有独立的实验统计引擎（默认频率派，支持贝叶斯/序贯/CUPED/SRM），只是产品定位仍偏发布安全；Cloudflare Flagship 则只做 Flag、不做统计。**融合是产品趋势，不是行业标准。** 组织上应「同一数据模型、不同权限与流程」，不要把发布事故和实验结论绑在一起。

**判断六：中国大厂的强项是「规模 + 业务耦合」，但公开资料严重不足。**  
字节（内部 Libra / 对外火山引擎 DataTester）、阿里（淘天/阿里妈妈/阿里云多条线）、腾讯（业务自建为主）、美团/滴滴/百度（交易与双边市场实验）都有成熟实践，但公开的架构、统计方法、实验数量远少于海外。**对外产品与内部平台不能划等号**；很多能力只存在于演讲和招聘 JD 中，报告已逐条标注「待核实」。

**判断七：开源已能覆盖 60-70% 的标准需求，但「最后一公里」仍要自建。**  
GrowthBook 覆盖实验编排、频率派/贝叶斯、CUPED、SRM、warehouse-native；PostHog 强在「分析 + 实验 + 回放」一体；Unleash/Flagsmith 强在 Flag。但**实验治理、超大规模分流、跨端一致性、实时指标、中国私有化**仍需自建。GitHub star 严重误导：PostHog 40k star 来自产品分析，FeatureProbe 1.6k star 但已停更两年。

**判断八：自建的真实成本不是服务器，而是「统计 + 指标 + 组织」。**  
一个 6-10 人的平台团队，3 年人力成本通常在 1900-3300 万人民币（按 80 万/人年）；开源自建（3 人 + 0.5 SRE）约 1350-2000 万，但需要接受统计与治理的二次开发。**省钱的不是「不用买软件」，而是「不重复造轮子」。**

**判断九：采购的核心不是买功能，而是买「可信度 + 退出能力」。**  
实验平台的资产是实验元数据（定义、分层、Holdout、曝光、指标口径、历史结论），不是 UI。合同必须写入：数据导出范围、迁移支持期、控制权变更终止权、SLA（分流 p99、可用性、配置下发延迟）、按曝光/实验计价而非纯 MAU。**不能带走的实验记录，等于没有。**

**判断十：AI 让实验对象从 UI 变成模型，但方法论还没跟上。**  
2025-2026 年厂商都在讲「AI 实验」：LLM Trace/Evals、prompt/模型版本对比、Agent 行为评估。已落地的是「用 AI 辅助写假设/生成变体/解释结果」；真正的新统计问题是「非确定性输出、会话/请求级随机化、延迟与成本护栏、LLM-as-judge 偏差」。**目前多数是厂商叙事，缺少公开的方法论与可复现基准。**

### 0.3 给三类读者的建议

**给 CEO/产品负责人：**
- 不要把「实验数量」当 KPI，把「有决策的实验占比」和「实验周期」当 KPI。
- 先选一个业务做 90 天试点，用真实指标验证「可信度」，再谈全公司推广。
- 预算按「3 年 TCO」算，不要按第一年 license 算；自建的人力成本通常是软件费的 3-5 倍。

**给技术架构师：**
- 决策面与度量面解耦；SDK 用 OpenFeature 抽象；曝光落数仓；统计引擎可替换。
- 分流服务必须无状态、确定性、可离线求值、fail-open；p99 < 20ms 是底线。
- 不要把统计逻辑写进业务代码；不要把实验配置和发布配置混在一个权限体系里。

**给实验平台负责人：**
- 先建「曝光 + 指标 + SRM + AA test」四件套，再建可视化编辑器和 MAB。
- 实验治理（分层、互斥、Holdout、审批、冻结）是平台的核心资产，不要外包。
- 每季度做一次「实验结论复核」，公开失败案例；信任是平台最贵的资产。

### 0.4 推荐路线（针对 DAU 千万级、已有数仓的公司）

| 阶段 | 时间 | 做什么 | 不做什么 |
|---|---|---|---|
| MVP | 0-90 天 | 服务端 SDK、单层分流、曝光管道、频率派 + SRM、10-20 个实验 | 可视化编辑器、MAB、CUPED |
| 规模化 | 90-180 天 | 多端 SDK、正交分层、互斥、Holdout、CUPED、warehouse-native、RBAC/审批 | 实时指标、AI 实验 |
| 智能化 | 180-365 天 | 实时链路、Switchback/Interleaving/MAB、CATE、AI/LLM 实验、私有化 | 纯自研统计引擎（除非有统计团队） |

**最务实的组合**：自建分流与治理 + 采购/复用 warehouse-native 统计（GrowthBook/Eppo by Datadog）+ OpenFeature 解耦 SDK。3 年 TCO 通常在 1000-2000 万人民币，比纯自研低 50% 以上，比纯 SaaS 更可控。

### 0.5 本报告的局限

- 厂商架构与统计实现多为商业机密，本报告只能核实「官方是否宣称 + 文档是否给方法」，不能替代真实数据复现。
- 价格极不透明，报告中的 TCO 是量级估算，不是报价。
- 中国公司公开资料滞后，平台名称、上线时间、实验数量多有「待核实」标注。
- 市场在快速整合，建议每 6 个月复核一次厂商状态与合同条款。

---

## 1. 研究设计、方法与市场地图

### 1.1 我们到底在回答什么问题

这不是一份「A/B 测试工具排行榜」。排行榜只能回答「谁的功能多」，却回答不了三个更关键的问题：

1. **买什么**：当公司已经有埋点、数仓、Feature Flag 和发布系统时，实验平台应该买哪一层，还是自己补哪一层？
2. **怎么建**：如果自建，哪些模块是真正的难点，哪些只是工作量？为什么很多团队「三个月上线，三年不敢用」？
3. **怎么用**：为什么同样一套平台，字节、Airbnb、Booking.com 能跑出每年数万个实验，而多数公司一年只跑几十个、且一半结论不可信？

因此，本报告把「竞品调研」拆成五层：**市场与产品 → 中国实践 → 开源方案 → 核心技术模块 → 组织与案例**，最后回到「自建 / 采购 / 开源自建」的决策。

### 1.2 研究方法：25 路并发 + 三层校验

本次调研采用「分治 + 交叉验证」的方式：

| 层级 | 工作 | 产出 |
|---|---|---|
| L0 基线 | 市场大事记、厂商清单、开源活跃度 | 统一事实底座 |
| 深度研究 | 25 个并发研究任务：商业平台、中国大厂、开源、技术模块、案例 | 25 份原始调研 |
| 交叉验证 | 对高风险论断逐条核验；补齐覆盖缺口 | 事实修正与增补 |
| 分册合成 | 7 位分册主编重新组织、交叉对比 | 7 个主题分册 |
| 终稿 | 执行摘要、选型矩阵、参考架构、路线图 | 本报告 |

信息可信度分为三级：

- **A 级**：官方文档、官方博客、GitHub 源码/Release、同行评审论文、上市公司公告。
- **B 级**：厂商工程博客、QCon/ArchSummit 演讲、权威媒体（Reuters、Bloomberg 等）、可复现的第三方评测。
- **C 级**：招聘 JD、二手转述、社区讨论、无法追溯的「据说」。

报告中凡涉及「某平台支持 CUPED」「某公司实验数量」这类关键能力，优先使用 A 级来源；只有 C 级来源的，会明确标注「待核实」。

**研究局限**（必须先说清楚）：

1. 实验平台的核心架构通常是商业机密。厂商公开的是「能力清单」，不是「实现细节」；中国大厂的公开资料尤其滞后，很多平台名称、上线时间来自演讲或招聘信息，无法逐一核实。
2. 价格极不透明。多数企业级产品「需询价」，公开起价往往只覆盖最小套餐，不能外推到大客户实际成交价。
3. 统计能力很难从外部验证。厂商都说自己「支持 CUPED / 序贯 / 贝叶斯」，但实现质量、默认参数、边界处理差异很大；本报告只能核实「官方是否宣称 + 文档是否给出方法说明」，不能替代真实数据上的复现。
4. 市场在快速整合。2023-2026 年发生了多起停服与收购，任何「厂商清单」都有保质期；本报告以 **2026 年 10 月** 为基准，并标注信息日期。

### 1.3 市场地图：七类玩家，而不是一个赛道

把「A/B 测试」当成一个赛道，是选型时最常见的认知错误。实际上至少有七类玩家，它们的能力边界、计价方式、适用规模完全不同。

| 类别 | 代表产品 | 核心能力 | 主要短板 | 典型买家 |
|---|---|---|---|---|
| **Web 实验/优化套件** | Optimizely、VWO、AB Tasty、Kameleoon、Convert、SiteSpect | 可视化编辑、页面级 A/B、个性化、部分服务端实验 | 统计深度参差；移动端/后端实验弱；按流量计价贵 | 增长/市场团队、电商、媒体 |
| **企业个性化套件** | Adobe Target、Dynamic Yield、Monetate、Sitecore Personalize | 受众/CDP、实时个性化、推荐、Auto-Target/Auto-Allocate | 实施重、依赖专业服务、实验治理弱 | 大型零售、航空、金融 |
| **Feature Flag / 交付平台** | LaunchDarkly、Harness Split、Flagsmith、ConfigCat、Unleash | Flag 生命周期、渐进发布、目标人群、审计、SDK | 统计深度参差：LaunchDarkly 完整，Unleash/Flagsmith/ConfigCat 基本没有 | 研发/平台团队、SaaS |
| **现代实验平台** | Statsig、Eppo、GrowthBook、Amplitude Experiment | Flag + 实验 + 指标 + 统计一体化；warehouse-native | 数据接入有门槛；大客户定制成本高 | 中大型互联网、SaaS |
| **云厂商/边缘原生** | Firebase A/B Testing、AWS AppConfig、Cloudflare Flagship、Azure App Configuration | 与云/边缘/移动端深度集成、低延迟、按用量计费 | 实验统计与治理弱；锁定云厂商 | 云原生团队、移动 App |
| **开源自建** | GrowthBook、PostHog、Unleash、Flagsmith、FeatureProbe、Superposition | 可私有化、可二次开发、成本可控 | 统计/治理需自建；运维与升级成本 | 有平台团队、数据合规要求高 |
| **中国大厂自建/对外输出** | 火山引擎 DataTester、阿里/腾讯/美团内部平台 | 超大规模、与中国业务/数仓深度耦合、私有化 | 外部资料少；对外产品与内部平台能力不等价 | 国内中大型企业 |

这张表最重要的含义是：**「实验平台」不是一个单体产品，而是「Flag 交付 + 分流 + 指标 + 统计 + 治理」的组合。** 不同厂商只覆盖其中几层，选型时必须先画出自己的缺口，而不是对着功能清单打勾。

### 1.4 2023-2026：五条结构性变化

#### 变化一：从「页面优化」走向「全栈实验 + Flag」

Google Optimize 在 2023 年 9 月 30 日停服，象征着一个时代的结束：以「可视化改页面」为核心的轻量 A/B 工具，正在被「服务端实验 + Feature Flag + 全链路指标」取代。Optimizely、VWO、AB Tasty 都在补 Feature Flag、服务端 SDK 和个性化；LaunchDarkly、Split 则从 Flag 反向补实验。两条产品线正在中间汇合。

#### 变化二：从「自建事件管道」走向「warehouse-native」

Eppo、GrowthBook 主推「数据留在你的数仓，平台只做指标定义、SQL 生成和统计计算」。这解决了三个痛点：数据不出域、指标口径统一、不必再维护一套埋点/事件管道。代价是数据延迟（通常 T+1 或小时级）、对数仓性能与建模质量高度依赖。Statsig 则坚持自建事件管道，强调实时性和开箱即用。两条路线没有绝对优劣，取决于团队的数据成熟度。

#### 变化三：统计方法从「唯 p 值」走向「序贯 + 贝叶斯 + 决策」

传统频率派在「可以 peeking」这件事上非常脆弱：连续看结果会显著抬高假阳性。于是厂商分化为三派：

- **序贯检验派**：Optimizely Stats Engine、Statsig、Eppo、GrowthBook 等提供 always-valid 或 group sequential 方法，允许在实验过程中安全地查看和决策。
- **贝叶斯派**：VWO SmartStats（默认贝叶斯、可切频率派）、PostHog、部分 GrowthBook 配置，用可信区间和「优于对照的概率」替代 p 值，更贴近业务决策。
- **混合派**：默认频率派，提供贝叶斯/序贯作为可选项，让客户按场景选择。

方法本身不是护城河，**默认参数、指标类型支持、多重比较处理、SRM 检测和解释成本**才是。

#### 变化四：从「实验平台」走向「发布 + 实验 + 治理」一体化

Feature Flag 原本是研发的发布工具，实验平台原本是增长的分析工具。现在两者在融合：LaunchDarkly 做 Experimentation，Split 被 Harness 收购后并入「Feature Management & Experimentation」，Statsig/GrowthBook/Eppo 从一开始就把 Flag 和实验放在同一个数据模型里。融合的好处是「同一套分流、同一套曝光、同一套指标」；风险是「发布事故」和「实验结论」耦合，权限与流程必须重新设计。

#### 变化五：整合、停服与「退出成本」

2024-05-29，Harness 宣布收购 Split（2024-06-11 交割）；2025 年 5 月，Datadog 收购 Eppo；2025 年 9 月 2 日，OpenAI 以 11 亿美元收购 Statsig，并任命其 CEO 为应用 CTO（[Reuters](https://www.reuters.com/legal/transactional/openai-acquire-product-testing-startup-statsig-appoints-cto-applications-2025-09-02/)、[Bloomberg](https://www.bloomberg.com/news/articles/2025-09-02/openai-to-buy-product-testing-startup-statsig-for-1-1-billion)）；2026 年 5 月，Statsig 的产品与客户又转由 Amplitude 接手。与此同时，VWO 与 AB Tasty 在 2026 年 9 月统一为 Wingify，SiteSpect 被 Monetate 收购，Oracle Maxymiser 进入日落。停服侧，Google Optimize 于 2023 年 9 月 30 日终止，AWS CloudWatch Evidently 于 2025 年 10 月 17 日终止；AWS 在 2026 年 6 月用 AppConfig 补上实验编排，但仍不提供统计推断。

这些事件都在提醒买家：**实验平台不是一次性采购，而是一段 3-5 年的技术关系。** 选型时必须评估供应商的存续能力、数据导出能力、SDK 替换成本，以及「如果明天停服，我的实验记录和 Flag 能不能带走」。更反直觉的一点是：**被巨头收购不等于更安全**——Statsig 被 OpenAI 收购仅 8 个月，产品与客户就被转手给 Amplitude；收购方要的往往是团队与内部能力，不一定是继续经营这个 SaaS。

### 1.5 市场规模：没有可信的「统一数字」，只有可推演的量级

公开市场报告对「A/B testing software market」的口径差异极大：有的只算 Web 优化，有的把 Feature Flag、产品分析、CDP 都算进去，导致规模从十几亿美元到上百亿美元不等。本报告不引用单一「权威数字」，而是给出一个自下而上的量级推演，供预算讨论使用：

- 全球员工数 200 人以上、有独立产品/增长团队、具备基本埋点能力的公司，保守估计 5-10 万家。
- 其中愿意为实验平台付费（而非纯自建/开源）的比例，按 10%-20% 估算，约 0.5-2 万家。
- 年客单价从中小客户的 1-3 万美元到大型企业的 20-100 万美元不等，中位数按 5 万美元估算。
- 对应可服务市场规模约 **25-100 亿美元/年**，这是一个「大但高度分散」的市场。

这个推演只用于判断量级，不应作为投资或采购依据。真正的预算是「自建 3 年 TCO」与「SaaS 3 年报价」的比较，见第 3 章与第 9 章。

> **本章结论**：市场不缺工具，缺的是「可信的实验基础设施」。选型的第一性问题不是「谁功能多」，而是「我的数据在哪、我的决策链路是什么、我愿意为可信度付多少钱」。

---

## 第 2 章 商业平台（上）：Web 实验与优化套件

> 本章拆解 Optimizely、VWO、AB Tasty、Kameleoon、Convert、SiteSpect，以及 Adobe Target、Dynamic Yield、Monetate、Sitecore 等 Web 优化/个性化套件。

## 2.1 赛道地图与产品谱系

这批产品常被塞进同一张「A/B 测试工具」对比表，但血缘并不相同。至少有三条基因：**页面活动**（Optimizely Web、VWO、AB Tasty、Convert、Monetate Maestro）以「新建 campaign、改页面、定受众」为入口；**企业个性化**（Adobe Target、Dynamic Yield、Sitecore Personalize）以「这个人该看什么」为入口；**交付基础设施**（SiteSpect 的反向代理、Optimizely Performance Edge、Kameleoon 的边缘套件）以「请求在哪里被改写或求值」为入口。基因决定产品形态、买单人和计价锚点，也决定了它们很难互相替代。

| 活法 | 代表 | 核心资产 | 典型买单人 | 2026 状态 |
|---|---|---|---|---|
| 营销活动套件 | VWO、AB Tasty、Convert | 编辑器、模板、活动日历 | 增长/市场/电商 | 合并、涨价、独立者收缩 |
| DXP 模块 | Optimizely、Adobe Target、Sitecore Personalize | 与 CMS/CDP/分析捆绑 | CMO/CDO、IT | 被并入更大平台 |
| 统计垂直平台 | Kameleoon | 统计透明度、边缘交付 | 数据成熟的中大型企业 | 独立，靠 AI 建实验 |
| 网络层基础设施 | SiteSpect/Forte | 反向代理、合规部署 | 金融/医疗/大型集团 | 被 Monetate 吸收 |

2024–2026 年不是扩张期，而是整合期。2023-09-30 Google Optimize 硬停服 [来源](https://support.google.com/analytics/answer/12979939?hl=en)；2024-05-31 Oracle Maxymiser 停服 [来源](https://monetate.com/resource/how-does-the-sunsetting-of-oracle-maxymiser-impact-cx-and-personalization/)；2024-05-29 Harness 宣布收购 Split，2024-06-11 完成交割 [来源](https://www.harness.io/press-and-news/harness-completes-acquisition-of-split-software)；2025-06-30 Monetate 收购 SiteSpect [来源](https://www.businesswire.com/news/home/20250630514541/en/Monetate-Acquires-SiteSpect-to-Deliver-AI-Native-Personalization-and-Testing-at-Enterprise-Scale)；2026-01-20 VWO 与 AB Tasty 宣布合并 [来源](https://wingify.com/news/vwo-and-ab-tasty-unite-as-wingify/)，2026-09-16 统一为 Wingify [来源](https://en.yna.co.kr/view/RPR20260916007800353?section=press-release/index)；2026-07-30 Monetate 再收购 Simon AI [来源](https://www.tmcnet.com/usubmit/2026/07/30/10422711.htm)；2026-10 Sitecore 把 CDP、Personalize、Search 合并进 SitecoreAI [来源](https://www.sitecore.com/resources/insights/artificial-intelligence/cms-and-conversion-optimization)。五年之内，几乎每一家「独立 Web 套件」都换了归属，或被并入更大的 DXP、支付、私募组合。

| 产品 | 技术血统与归属 | 2026 年的真实身份 | 对采购的含义 |
|---|---|---|---|
| Optimizely | 2020-10-21 Episerver 完成收购，Insight Partners 持有 [来源](https://www.optimizely.com/company/press/episerver-completes-acquisition-of-optimizely) | DXP + Opal AI，实验是模块 | 买的是营销操作系统，不是单点实验 |
| VWO | 独立起家，2025 年 Everstone 多数股权，2026 并入 Wingify | 合并中的易用型套件 | 合同主体、续费与路线图要重签 |
| AB Tasty | 2014 年巴黎起家，Flagship 并入 | Wingify 旗下欧洲品牌套件 | 与 VWO 产品高度重叠 |
| Kameleoon | 独立 | 统计严谨的垂直实验平台 | 少数仍可长期独立的选项 |
| Convert | 独立 | 公开定价的中小客户工具 | 价格透明，但治理与统计有缺口 |
| SiteSpect | 反向代理起家，2025 年被 Monetate 收购 | Monetate Forte 的网络层底座 | 品牌弱化，买的是 Forte 而非 SiteSpect |
| Adobe Target | Adobe Experience Cloud | 企业实验 + 个性化引擎 | 最接近平台，但绑定 Adobe 栈 |
| Dynamic Yield | McDonald's 2019，Mastercard 2022 | Mastercard 的客户经营产品线 | 产品在售，路线服从支付生态 |
| Monetate | Kibo 2019，2022 剥离 [来源](https://www.centrelanepartners.com/2022/10/28/kibo-spins-out-personalization-business-under-the-monetate-brand/)，连续并购 | 实验 + 个性化 + CDP 拼图 | 整合期，能力变全但路线不稳 |
| Sitecore Personalize | 2021 收购 Boxever 而来 [来源](https://www.sitecore.com/company/newsroom/press-releases/2021/03/sitecore-acquires-boxever-and-four51) | 并入 SitecoreAI Conversion Optimization | 双轨期，迁移规则待核实 |
| Oracle Maxymiser | 2015 年被 Oracle 收购 [来源](https://www.dbta.com/Editorial/News-Flashes/Oracle-Snaps-Up-Customer-Experience-Optimization-Specialist-to-Expand-Marketing-Cloud-106113.aspx) | 2024-05-31 已停服 | 2026 年不应出现在任何 RFP |

这张谱系图对采购有三个含义。**合同主体比功能清单重要**：VWO/AB Tasty 已归 Wingify，SiteSpect 已归 Monetate，签约前要确认续费、涨价、停服、迁移由哪个法人负责。**计费锚点决定你能买到什么**：营销套件按 MTU 卖给市场部，DXP 按模块卖给 CIO/CMO，网络层按部署卖给基础设施团队。**实验模块没有独立生存权**：Maxymiser 不是输给 A/B 工具，而是输给 Oracle 的营销云战略；套件收缩时，实验能力会被优先牺牲。

## 2.2 Optimizely 深度拆解

Optimizely 是这批产品里唯一同时拥有「营销入口」和「工程入口」的，但这不是一个产品，而是两条产品线：Web Experimentation 与 Feature Experimentation。2020-10-21 Episerver 完成收购，2021 年合并品牌，此后把 CMS、Commerce、ODP、Experimentation 打包为 Optimizely One；2024-09-30 收购仓库原生分析公司 NetSpring [来源](https://www.optimizely.com/company/press/optimizely-acquires-netspring)，2025-05-07 推出基于 Gemini 的 Opal [来源](https://www.optimizely.com/de/company/press/opal-workforce)，2026-06-22 发布新品牌。控制权没有变化——Episerver 是 Insight Partners 2018 年以 11.6 亿美元买下的私有组合公司，2024–2026 年未发现所有权变更的一手证据，所以「Optimizely 又被卖了」的说法不成立。

**产品与交付。** Web 端提供可视化/代码编辑、A/B/n、MVT、Split URL；Feature 端提供服务端 SDK（Java、.NET、Node、Python、Ruby、Go、PHP、Swift、Kotlin、React 等）、Flag、远程配置、渐进发布；另有 Personalization/Recommendations 与 ODP。互斥组可跨 Web 与 Feature 划分流量，保证一个访客最多进组内一个实验 [来源](https://certification.optimizely.com/docs/guides/experimentation/configure-mutual-exclusion/)；提供 native global/local holdouts；Stats Accelerator 用多臂老虎机（UCB 家族）动态调流量，报表用绝对提升 pp，服务端需 sticky bucketing。交付有三套形态：标准 snippet、Performance Edge、服务端 SDK。标准 snippet 的完整配置可达 50–200KB，存在闪烁窗口；Performance Edge 把决策搬到 CDN 边缘，用同一套 MurmurHash3 分桶，向 HTML 注入小于 5KB 的 micro-snippet，只含命中变体代码，在 HTML 到达浏览器前「烘焙」好，实现 zero-flicker [来源](https://certification.optimizely.com/docs/concepts/experimentation/performance-edge/)。代价是 Performance Edge 并非默认、要改 CDN、能力有边界；三种交付形态并存，但不是同一套轻量 SDK。

**统计。** 官方名 Stats Engine，默认是频率派序贯检验，不是贝叶斯引擎。它计算 100 个连续置信区间，结果页显著性取其中最保守值，置信区间取交集，因此比 t 检验更保守、更不容易「先显著后反转」[来源](https://certification.optimizely.com/docs/concepts/experimentation/stats-engine-deep-dive/)；提供 always-valid p 值、FDR 控制、多变异 Bonferroni、贝叶斯解释层。CUPED 用回归做协方差调整，默认读实验前两周同指标历史，只支持数值指标，不适用转化率，支持 Snowflake/BigQuery/Databricks 仓库原生 [来源](https://support.optimizely.com/hc/en-us/articles/33424529987597-CUPED-Controlled-experiment-Using-Pre-Experiment-Data)。SRM 用 SSRM 持续检查，但只覆盖手动分流、未开 Stats Accelerator、运行不超过 45 天、至少 1,000 访客的 A/B [来源](https://support.optimizely.com/hc/en-us/articles/13409080412173-Optimizely-s-automatic-sample-ratio-mismatch-detection)；Guardrail alerts 可对收入、结账、注册、留存设阈值。

这里要标注一个「存在不同说法」：二手资料常把 Optimizely 说成「贝叶斯统计平台」。准确说法是——Stats Engine 默认序贯频率派；Feature Experimentation 可以在 Stats Configuration 里选 Bayesian，替代默认的 Sequential，也可以选固定 horizon 频率派 [来源](https://support.optimizely.com/hc/en-us/articles/42734792850061-Configure-a-Bayesian-A-B-test)。把「可选贝叶斯」写成「默认贝叶斯」，会让选型时的统计假设完全错位。

**商业与判断。** Optimizely 不公开套餐价，按模块/流量/部署年度报价 [来源](https://www.optimizely.com/plans/)；第三方 Vendr 样本显示年合同额中位数约 8.1 万美元，实验类在 500 万 MTU 以下常见 5–8 万美元/年（第三方样本，非官方报价）[来源](https://www.vendr.com/marketplace/optimizely)。优势是统计完整、双端完整、PE 零闪烁；限制是贵、面宽、Stats Engine 保守、PE 非默认、snippet 大、指标仍以 Optimizely 为中心。适合已有 Optimizely 生态、要市场与产品实验统一入口的企业，不适合预算敏感、纯服务端、要求指标定义在数仓的组织。

Optimizely 真正值得学的不是「功能多」，而是两件事：**同一套分桶、三种交付**，以及**把统计不确定性产品化**（100 个区间、always-valid p、FDR、护栏告警都是可解释的产品表达）。但 DXP 的买单人决定了它的优先级：实验要为 CMS/Commerce 导流，而不是反过来。这个结构性约束，后面 2.7 会展开。

## 2.3 VWO 深度拆解

VWO 的历史标签是「便宜、好用、上手快」，这个标签在 2025–2026 年已经失效。2025 年 Everstone 收购多数股权（第三方报道约 2 亿美元，官方未披露金额）；2026-01-20 与 AB Tasty 宣布合并；2026-09-16 统一为 Wingify，官方口径年收入超过 1.05 亿美元、4,000+ 客户、700+ 员工、11 个办公室，客户含 L'Oréal、LVMH、Decathlon、Puma、Forbes、Motorola、AXA、De Beers [来源](https://wingify.com/news/vwo-and-ab-tasty-unite-as-wingify/)。合并前 VWO 称 3,000+ 品牌、AB Tasty 称 1,000+ 品牌，与「4,000+」存在不同说法（有重复计算与口径差异），采购时应以合同主体和续费责任为准。

**产品与套餐。** 模块包括 Web Experimentation & Rollout（A/B/n、Split URL、MVT、Rollout、SPA、QA Assistant）、Feature Management/Feature Experimentation（Flag、渐进发布、服务端 SDK、Holdout Groups [来源](https://help.wingify.com/hc/en-us/articles/58766108516889-Configure-Holdout-Groups-in-Feature-Experimentation)）、Personalization/Predictive Data、Commerce（搜索、推荐、Merchandising）、Analytics/Engagement。套餐分层很硬：Growth 才含 MAB 与 Rollout，Enterprise 才有 Mutually Exclusive Groups、Approval Workflow、SSO、Self Hosting [来源](https://wingify.com/pricing/)。架构以异步 SmartCode 为主，支持 SPA 与元素隐藏/延迟渲染，但 anti-flicker 细节不如 Kameleoon 透明；服务端由 FME SDK 承担，覆盖 Java、PHP、Python、.NET、Ruby、Go、Android、Flutter、React Native；数据层是 Wingify Data360/Data Platform，事件、属性、受众、指标都在平台内定义 [来源](https://help.wingify.com/hc/en-us/articles/58831743266969-About-Wingify-Data360)，没有 Optimizely Performance Edge 式独立边缘产品。

**统计。** SmartStats 在 2024-12-03 升级为「Bayesian powered sequential testing engine」[来源](https://wingify.com/blog/new-stats-engine-and-enhanced-wingify-reports/)：贝叶斯默认，启动前可切频率派、启动后不能改；序贯解决 peeking，多变异用 Bonferroni；提供 Fixed Horizon（预计算样本、只判一次）与 Dynamic（无固定样本、持续检查）两种模式；引入 ROPE 做实践等价，用于提前停掉差变体；Pro 含 SRM Detection 与 Guardrail Metrics；官方称用精确分布而非正态近似，小样本更准 [来源](https://help.wingify.com/hc/en-us/articles/59066074450841-What-is-the-Math-Behind-SmartStats)。官方文档未见 CUPED 支持（待核实），这是相对 Optimizely/Kameleoon 的短板。

这里还有第二个「存在不同说法」：说「VWO 是贝叶斯」必须带版本/账户前提。2026 年新版 Data Platform 另有「upgraded statistical engine」，SmartStats 只覆盖非 Data Platform 账户与迁移前 campaign。也就是说，同一个客户在不同账户、不同迁移阶段，可能跑在两套统计引擎上；采购 POC 时应要求厂商明确「这个账户默认用哪套、能否切换、历史结果是否可比」[来源](https://help.wingify.com/hc/en-us/articles/58838252139545-Achieve-Accurate-Campaign-Results-with-SmartStats-Configuration)。

**商业与判断。** 2026-10 官网 Growth/Pro/Enterprise 三档全部只给「Schedule a Demo」，不再公开美元起价 [来源](https://wingify.com/pricing/)；功能按套餐锁定，Pro 才有 Guardrail/SRM/MVT/Cross Domain，Enterprise 才有互斥组/SSO/自托管。历史「VWO 便宜」的标签正在失效，合并后价格体系如何并轨待核实。

VWO 值得抄的是把 ROPE、Fixed vs Dynamic、CTW 做成业务能选的开关，比只给 p 值更接近决策；但「启动后锁方法」和「CUPED 缺失」会让成熟团队不够用。合并后的产品重叠意味着 12–18 个月内会有一次路线取舍，采购要写清退出与迁移条款。

## 2.4 AB Tasty / Kameleoon / Convert / SiteSpect

这四家代表四种「活法」：AB Tasty 是合并中的欧洲品牌套件，Kameleoon 是统计最透明的独立垂直平台，Convert 是公开定价的中小客户工具，SiteSpect 是网络层基础设施。它们正好覆盖「决策发生在哪里」的四个位置：同步 tag、异步脚本 + CSS 隐藏、tracking script + body hiding、反向代理。

**AB Tasty：用首屏性能换无闪烁。** 2014 年成立于巴黎，强项是电商、零售、旅游、金融的品牌客户；合并前称 1,000+ 品牌（L'Oréal、Samsonite、USA Today、Ganni），官方称监控 15,000+ 活跃 campaign [来源](https://docs.abtasty.com/web-experimentation-and-personalization/campaign-creation-and-dashboard/types-of-campaigns)。模块覆盖 Web 实验（A/B、Multipage、MVT、Split/Redirect、A/A）、个性化（Emotions AI、AdaptiveCX）、Commerce（推荐/搜索）、Feature（原 Flagship）与治理（1V1T、审批、SSO）。未见独立 global holdout，以 control + 1V1T 控制污染（待核实）。

架构核心是**同步 tag**：官方建议放 `<head>` 同步加载，确保变体在渲染前应用；异步虽不阻塞，但可能先看到原版 [来源](https://docs.abtasty.com/account/tag-integration/understand-ab-tasty-tag-implementation-methods/choose-between-synchronous-and-asynchronous-methods)。这是「用首屏性能换无闪烁」，同步 tag 拉长关键路径，高流量站点必须评估 Core Web Vitals。SPA 用 MutationObserver 在两次渲染间应用修改，SSR 在 hydration 后再应用；服务端 SDK 覆盖主流语言与移动端，支持 Decision API、panic mode、渐进发布、1V1T [来源](https://docs.abtasty.com/server-side/sdks/sdk-overview)；无独立边缘网络。统计以贝叶斯为主、频率派可选；贝叶斯报表展示 Chance to Win 与置信区间，频率派把 CTW 换成 p 值 [来源](https://docs.abtasty.com/reporting-and-performances/reporting/frequentist-analysis-mode)；序贯用于 Sequential Testing Alerts，但只在检测到「输家」时建议停止，不提前宣布赢家，灵敏度 High/Balanced/Low 对应约 5%/3%/1% 误报 [来源](https://docs.abtasty.com/help-center/faq/faq-sequential-testing-alerts)；SRM 用 S-SRM（频率派 p 值、阈值 0.01、Early Adopters，需联系 CSM）[来源](https://docs.abtasty.com/reporting-and-performances/reporting/sample-ratio-mismatch)。未见 CUPED、系统化 FDR/Bonferroni、独立护栏指标（待核实）。设计取向是「业务友好优先」：CTW 好解释，序贯只止损；代价是想用序贯加速赢家上线做不到，想做方差缩减也没有。

AB Tasty 适合品牌营销团队、欧洲本地服务、需要「实验 + 个性化 + 推荐」一体化的客户；不适合性能敏感高流量站点、需要序贯赢家决策、CUPED/仓库原生或只想买纯实验的公司。合并后与 VWO 的产品重叠是最大不确定性。

**Kameleoon：把统计取舍讲清楚。** 定位 AI-powered experimentation & personalization，客户以中大型企业为主，强项在电商、媒体、旅游、医疗、金融；官方称 1,000+ 品牌，Samsung 是 PBX 案例客户。模块覆盖 Web 实验（可视化/代码编辑、A/B/n、MVT、SPA、PBX）、Feature（Flag、渐进发布、Holdout、跨设备）、个性化（AI Predictive Targeting）、推荐/搜索与治理（跨端互斥组、Holdout、Health Checks、生产审批）。未见经典 MAB；AI Predictive Targeting 是「按转化 likelihood 定向」，不是流量动态分配（待核实）。

架构是六者中最透明的：异步 snippet 从 Cloudflare CDN 加载，单文件 Brotli 压缩约 29KB；初始注入 blocking CSS rule 隐藏内容，脚本加载后移除，默认超时 750ms，超时可选「禁用本页/禁用本次访问/带闪烁继续」，官方称正常网络超时约 2–3%，SLA 超过 99.99% [来源](https://docs.kameleoon.com/developer-docs/web-experimentation/technical-concepts/flicker-management-and-performance)。服务端 SDK 覆盖 Java、C#、PHP、Node、Ruby、Python、Go 与 Android、iOS、Flutter、React/React Native；官方称 zero-latency SDK，分桶本地完成，性能影响小于 1ms。边缘 starter kit 覆盖 Cloudflare Workers（2024-10）、Akamai EdgeWorkers（2024-12）、AWS Lambda@Edge（2024-07）、Fastly、Vercel，另有 Nginx 模块与 OpenFeature provider。这是六者中最完整的「客户端 + 服务端 + 边缘 + 自托管」矩阵。

统计支持三种方法并给出取舍：固定样本频率派（功效最大、但 rigid）、贝叶斯（可融先验、先验错会带偏）、序贯（可随时看/提前停、置信区间任意时点有效，但功效较低、效应估计精度较差）；官方建议序贯做早期止损、固定样本做最终验证 [来源](https://docs.kameleoon.com/user-manual/experiment-analytics/statistical-methods/choosing-the-right-statistical-method-for-ab-testing)。支持多重比较校正、CUPED（用实验前数据做协方差调整，建议与固定样本结合）、Winsorization（极端值缩尾）。Health Checks 含 SRM、Overlapping Exposure、Conversion Tracking、Visitor Tracking；启动后 24 小时每小时跑，之后每天跑 [来源](https://docs.kameleoon.com/user-manual/experiment-analytics/analyze-results/results-page-tabs/health-menu)。Web/Feature 都支持 Holdout；互斥组支持 Web 内、Feature 内及跨客户端/服务端。未见独立 guardrail 产品（待核实），Health Checks 偏数据质量而非业务护栏。

Kameleoon 的优势是统计最完整、交付矩阵最全、对工程最友好；限制是品牌/生态比 Optimizely/VWO 小、无仓库原生指标层、价格不透明、自托管/边缘需工程投入、PBX 生成质量需人工审核、护栏产品化弱。PBX 2025-06 beta、2025-09-25 GA，官方称建实验时间最多减少 97%、前 1,000 个实验平均回收期小于 3 个月（官方宣称，未经独立验证）[来源](https://www.einpresswire.com/article_print/852526197/kameleoon-launches-vibe-experimentation-with-prompt-based-testing)。

**Convert：把价格做成产品。** 定位高性价比、隐私友好、无套件捆绑的 CRO/实验平台，客户以中小企业、代理、Shopify/DTC 商家为主；策略是「免费迁移 VWO」+ 公开定价 + 不限实验数，承接 VWO 涨价/合并后的价格敏感客户。模块包括 A/B、Split URL、Multipage、MVT（Pro）、Full Stack & Flags（Pro）、Personalization、MAB（Pro）、Sequential（Pro）、Holdout、Mutual Exclusion、Visual Editor、Heatmaps、SRM Check、MCP Server。

架构以客户端 tracking script 为主，Body Hiding 隐藏页面直到变体应用以降低闪烁；SPA 通过 URL/选择器监听支持。服务端两条路径：① Cookie hand-off——后端/边缘先决定变体，写 `_conv_sptest` 短生命周期 cookie，客户端 script 读取并上报；② Full Stack SDK——完全服务端分桶/上报，支持 PHP、Node、Python、Ruby、Java、Android、iOS 等 [来源](https://support.convert.com/hc/en-us/articles/360015870371-server-side-testing-)。没有自建边缘网络；CDN 边缘逻辑可通过 cookie hand-off 实现，但需客户自己写。

统计三种方法齐全：频率派（固定样本、p 值、置信区间、t/卡方、可配置阈值、多重比较校正控制 FDR）、贝叶斯（后验、Credible Interval、Probability to be Best，默认无信息先验、可连续监控）、序贯（AGILE 框架，可中期有效停止）[来源](https://support.convert.com/hc/en-us/articles/statistical-models-in-convertcoms-ab-testing-platform)。未见 CUPED、独立 guardrail 产品（待核实）。定价（2026-10-18）：Growth 100K tested users/月，年付 299 美元/月（3,588 美元/年），月付 399 美元，含 A/B、Split URL、MCP Server、Deploys、SRM Check、Heatmaps、Signals；Pro 100K/月，年付 420 美元/月（5,040 美元/年），月付 599 美元，含 MVT、Multipage、Full Stack、MAB、Sequential、SSO；Enterprise 12M/年，Price on Request；全部 15 天免费试用，价格不含税 [来源](https://www.convert.com/pricing/)。

Convert 的价格透明是最大差异化，299 美元/月的锚点比企业套件低 1–2 个数量级；但治理、仓库原生、CUPED、服务端/边缘能力都弱，适合中小团队/代理/落地页实验，不适合大型企业统一平台。

**SiteSpect：把实验做成网络项目。** 定位企业级、无标签、网络层实验/个性化平台，面向大型企业，尤其是医疗、金融、保险等受监管行业，以及有私有云/本地部署要求的集团。核心卖点是 reverse proxy：流量经过 SiteSpect 集群，HTML/CSS/JS/API 响应在到达浏览器前被改写，不需要客户端 snippet，天然无闪烁、对页面性能影响小 [来源](https://doc.sitespect.com/knowledge/sitespect-implementation)。2025-06-30 被 Monetate 收购后，官方强调其私有云/本地部署、HIPAA/PCI 合规经验；2026 年 sitespect.com 已指向 Monetate 的 Maestro 与 Forte，品牌弱化 [来源](https://monetate.com/)。这里存在不同说法：有资料称 2025-06-30 完成交割，公开稿用「Acquires」但未单独披露交割日，采购应以合同主体为准。

模块包括 A/B（客户端/服务端 campaign、Visual Editor、Factors/MVT、Triggers、Audiences）、个性化、推荐、server-side Flag、Omnichannel/Mobile（待核实）；单租户/私有云/本地、SSO、审计、PCI/HIPAA；无现代互斥组/分层（待核实），以 control 为主，未见 global holdout。未见经典 MAB。

部署不是「加一行 JS」，而是「改网络」：客户交前端 URL、后端 origin、SSL 证书、端口；SiteSpect 建集群、配站点、部署健康检查；客户把 DNS 或 CDN 指向 SiteSpect；SiteSpect 终止 SSL、转发请求、改写响应，页面源码与 JSON 是主要改写对象。官方称配置通常 3–5 小时、最快 3 天上线；DNS 切换建议提前 24 小时把 TTL 降到 300 秒。代价是必须动 DNS/CDN/证书，涉及网络、安全、运维多团队；代理是全局故障点；WebSocket、HTTP/2/3、流式响应兼容性需逐项验证。SPA 支持比想象中好：首个 HTML 响应注入 `ssdomvar.js`、`core.js` 等库，用 MutationObserver 监听 DOM，框架无关，客户端与服务端变体可在同一 campaign 混用 [来源](https://doc.sitespect.com/knowledge/sitespect-and-single-page-applications)。

统计是六者中最传统：频率派假设检验，用 two-tailed t-test 比较变体与对照，计算 z-score、p 值、置信区间；报表展示 90%/95%/99% 置信条，置信图用 80% 区间辅助；没有 always-valid p 值/alpha spending/序贯校正，没有贝叶斯、没有 CUPED、没有自动 SRM 检测 [来源](https://doc.sitespect.com/knowledge/sitespect-statistics)。定价不公开，按企业 license + 流量/部署 + 服务报价；典型合同六位数美元/年（推断，官方未披露），TCO 还要加证书、CDN 规则、运维人力、灾备。

SiteSpect 是「基础设施」，不是「营销工具」；买它等于买一个网络项目。它适合受监管、私有化、需要改写 API 响应的场景，不适合想要轻量接入、快速迭代、现代统计的团队。

| 交付位置 | 代表 | 防闪烁 | 首屏代价 | 部署门槛 | 适用 |
|---|---|---|---|---|---|
| 同步 tag（head） | AB Tasty | 强 | 高（阻塞关键路径） | 低 | 品牌站点、欧洲合规 |
| 异步脚本 + CSS 隐藏 | Kameleoon、VWO、Convert | 中—强 | 中（隐藏超时/闪烁兜底） | 低 | 大多数 Web |
| CDN 边缘注入 | Optimizely Performance Edge | 强 | 低 | 中（改 CDN） | 高流量、已有 CDN |
| 反向代理 | SiteSpect/Forte | 最强（架构级） | 低 | 极高（DNS/证书/网关） | 受监管、私有化 |

「防闪烁」不是功能开关，而是部署位置的结果；任何厂商说「零闪烁」都要问「在哪一层实现、代价是什么、失败时怎么办」。

## 2.5 Adobe Target / Dynamic Yield / Monetate / Sitecore

这四家常被归为「企业个性化套件」。严格说，只有 Adobe Target 以实验为核心能力；另外三家的第一性问题都是「这一屏该给谁看什么」，实验只是投放模式之一。它们共享同一套架构：受众/画像 → 决策/分配 → 内容下发 → 曝光回收 → 模型训练。差别在「决策在哪、模型多复杂、统计承诺是什么」。

**Adobe Target：用能力分层换延迟。** 它是 Adobe Experience Cloud 里的实验与个性化引擎，覆盖 Web、App、邮件、IoT 与服务端体验 [来源](https://experienceleague.adobe.com/en/docs/target/using/activities/activities)。分 Standard 与 Premium：Premium 只增加 Automated Personalization、Auto-Target、Recommendations、Recommendations as an Offer、Enterprise User Permissions；Auto-Allocate 属于 Standard，不是 Premium，这是生态里最贵的误解 [来源](https://www.miaprova.com/blog/two-customers-asked-us-the-same-question-inside-of-a-week-what-exactly-do-we-get-if-we-move-from-adobe-target-standard-to-premium/)。

手动 A/B 用 Welch's t-test、固定 horizon，不自动做 B vs C 比较。Auto-Allocate 是 bandit：80% 智能分配、20% 随机探索；冷启动每个经验至少 1,000 访客、50 转化；每小时更新，选「当前最优」和「Bernstein 95% 区间上界最高的挑战者」；区间不重叠时打 winner badge，官方称误报率约 5%、赢家真实响应不比最优差超过 1%（相对）[来源](https://experienceleague.adobe.com/en/docs/target/using/activities/auto-allocate/automated-traffic-allocation)。代价是只有新访客重分配、回访者保持原体验、启动后不能切回手动。Auto-Target/AP 用 Random Forest + ε-greedy：每个 experience/offer 一个模型，先在随机流量上训练并用 AUC 验证，24 小时重训，无法区分个体时回退 Thompson；控制组 ≥10%，单个 experience 每日至少 1,000 访客 + 50 转化、整体 7,000 + 350，会话内预测不变 [来源](https://experienceleague.adobe.com/en/docs/target/using/activities/auto-target/auto-target-to-optimize)[来源](https://experienceleague.adobe.com/en/docs/target/using/activities/automated-personalization/algo-random-forest)。XT 是规则不是实验，MVT 是全因子，推荐是 Premium 模块。

架构三层：SDK 回源（at.js/AEP Web SDK → Delivery API，能力最全）；On-device decisioning 把 A/B 与 XT 编译成 rule artifact，缓存到 Akamai CDN [来源](https://experienceleague.adobe.com/en/docs/target-dev/developer/server-side/on-device-decisioning/overview)；2026 年 CDN-based delivery 可跑 Akamai EdgeWorkers、Lambda@Edge [来源](https://www.miaprova.com/blog/adobe-target-had-a-quietly-big-year-at-summit/)。但边缘只支持 Form-based Composer 的 A/B 与 XT、手动分流，不支持 Visitor Profile/Network/Mobile/Traffic Source/Experience Cloud Audiences，artifact 传播最长 20 分钟，也不支持 Auto-Allocate、Auto-Target、AP、MVT、推荐。结论：**Adobe 的「零延迟」与「ML 个性化」不可兼得**，边缘只能承载规则可序列化的实验，用模型必须回源，这是要写进 SLA 的硬约束。

价格不公开，按产品选项、数字资产量、全渠道方式定制 [来源](https://business.adobe.com/products/target/pricing.html)；第三方估算议价后 7.2–24 万美元/年，首年 7.9–30 万美元+（第三方，非官方）[来源](https://kirro.io/adobe-target-ab-testing)。限制：非仓库原生；手动 A/B 无序贯/CUPED/多重比较校正；Auto-* 只优化单一目标；每活动最多 50 个「受众×位置」、每体验 350 个 offer、300 个选择器、单 offer 75KB；北京 RDC 只覆盖 Analytics AppMeasurement，不覆盖 Target，决策与事件只能走海外，且无私有化版本 [来源](https://experienceleague.adobe.com/zh-hant/docs/core-services/interface/data-collection/rdc?lang=zh-Hant)。启示是「按决策延迟做能力分级」，Standard/Premium 的切分说明实验卖「测量」、个性化卖「模型」。

**Dynamic Yield：承认自己不做因果推断。** McDonald's 2019-03 收购 [来源](https://www.cnbc.com/amp/2019/03/25/mcdonalds-announces-acquisition-to-personalize-the-drive-thru.html)，Mastercard 2022-04 完成收购 [来源](https://newsroom.mastercard.com/news/europe/de-de/newsroom/pressemitteilungen/de-de/2022/april/mastercard-starkt-mit-abschluss-der-ubernahme-von-dynamic-yield-seine-services-zur-kundenbindung/)；2026-10 dynamicyield.com 已 301 到 mastercard.com，品牌写作「Mastercard Dynamic Yield」，产品结构变成 Experience OS、Experience OS Agents、Shopping Muse、Experience APIs、Experience Search [来源](https://www.mastercard.com/us/en/business/consumer-acquisition-and-engagement/personalization/dynamic-yield.html)。这不是停服，而是被收编为支付公司的客户经营产品线；产品仍在售、仍在迭代，但路线图服从 Mastercard 的金融与商户生态。

能力以 campaign/experience 为核心：横幅、弹窗、推荐位、搜索、邮件/短信/推送；实验只有 A/B allocation、Dynamic Allocation（MAB）、推荐与 Experience API。没有 Adobe 式「每访客一个模型」的公开叙事，MVT 未见文档（待核实）；强项是内容/商品/促销的实时个性化，不是产品策略实验。

Dynamic Allocation：初始均分；用主指标计算每个变体的 Probability to be Best，表现好的逐步加流；至少每小时重算并重新分配；探索/利用比例 10/90，10% 随机（hidden control），90% 给当前最优；编辑变体不会重置算法，新增变体先按 1/n 给流量，被编辑的变体最初几小时按 1/n 重新评估 [来源](https://support.dynamicyield.com/hc/en-us/articles/360034513414-Dynamic-Allocation)。官方明确说它「less focus on statistical significance and more focus on optimization and speed」。P(best) 不是 p 值，不能回答「带来多少增量」，只能回答「现在该多给谁流量」。

架构是 JS tag + Choose API + 移动 SDK，服务端可用 Experience API [来源](https://dy.dev/docs/choose)。含推荐的 Choose 调用 95% 情况 10–140ms，不含推荐 10–30ms；默认限流每个 section 每分钟 22,000 次。它是为「页面同步渲染」设计的。Vendr 合同中位数约 10.1 万美元/年，区间 6.26 万–10.94 万美元/年（2025 页面数据，第三方）[来源](https://www.vendr.com/marketplace/dynamic-yield)。限制是 SaaS 为主、无公开私有化、实验治理无公开文档、被 Mastercard 收编后路线确定性下降、中国大陆无常驻区域。它适合促销/推荐位，不适合产品实验；拿它做因果结论，是用错了工具。

**Monetate：并购拼图与「自动上线」。** 2019 年 Kibo 收购；2022-10-28 Kibo 把个性化业务剥离为独立公司，沿用 Monetate 品牌，由 Centre Lane Partners 与 GarMark Partners 支持 [来源](https://www.centrelanepartners.com/2022/10/28/kibo-spins-out-personalization-business-under-the-monetate-brand/)；2025-06-30 收购 SiteSpect；2026-04（页面只标 Apr 16，年份推断）推出 Forte [来源](https://monetate.com/resource/monetate-introduces-forte/)；2026-07-30 收购 Simon AI [来源](https://www.tmcnet.com/usubmit/2026/07/30/10422711.htm)。2026 年的 Monetate 是「Maestro 实验套件 + Forte 网络层实验 + Simon AI CDP + 推荐/搜索」的组合体。整合期既是机会（能力变全），也是风险（路线图与团队稳定性）。

Maestro 是实验套件：客户端/API 驱动的 A/B、A/B/n、MVT、feature experimentation、dynamic testing；Forte 是面向受监管、登录态、结账链路的「安全实验」，把客户端、服务端与 flag 统一，底层沿用 SiteSpect 的混合架构 [来源](https://monetate.com/maestro/)，可部署在云、私有网络或本地。Monetate 是这几家里唯一公开承诺 on-prem/私有网络部署的，但 Forte 是反向代理方案，不是轻量 SDK。

架构有两种接入：JavaScript API + Monetate tag（同步 tag 阻塞加载，保证无闪烁但可能增加加载时间；异步 tag 不阻塞，但可能闪烁）；Engine API（一次调用同时完成三件事——传上下文、取当前上下文应触发的 actions、回传事件/指标）[来源](https://docs.monetate.com/docs/implementation-overview)。这个「三合一」是为了降延迟，但也意味着曝光、决策、指标回收耦合在同一个请求里，排查问题和离线归因会更依赖厂商日志。

统计上，Auto-Promotion 容易被误认为 bandit，实际是显著性达标后的自动上线：控制组阈值 >0、体验里不能有 split；活动跑够天数、目标指标正向 lift 显著、且没有任何指标负向 lift 超过置信度；然后复制为「无控制组的全量实验」、暂停原活动、激活新活动 [来源](https://docs.monetate.com/docs/enable-auto-promotion-for-experiences)。它优化「赢家上线速度」，不是「在线学习中的流量分配」；真正的在线学习在 Automated Personalization 里，但算法细节没有公开 [来源](https://docs.monetate.com/docs/create-an-automated-personalization-experience)。定价不公开，需询价；从产品组合与企业级服务看，客单价不会低于 Adobe Target 的量级。限制是客户端 tag 的闪烁/性能取舍、统计文档弱于 Adobe/Sitecore、连续并购带来产品重叠、中国大陆无常驻区域。它的价值在「受监管行业的私有化/网络层实验」，不是「更好的 A/B 工具」。

**Sitecore Personalize：决策层很强，统计层够用。** 2026-10 Sitecore 把 CDP、Personalize、Search 合并进 SitecoreAI，统一为「Conversion Optimization」，强调「single license and shared context」[来源](https://www.sitecore.com/resources/insights/artificial-intelligence/cms-and-conversion-optimization)；官方定义是「SitecoreAI 的实验层」[来源](https://www.sitecore.com/platform/conversion-optimization)。但 Personalize 没有立刻消失：文档仍在更新，独立 Personalize 仍在售，FAQ 仍讨论 standalone 与 XM + Personalize 的买法 [来源](https://developers.sitecore.com/learn/faq/xm-personalize/personalize-cdp)。本文判断 2026 下半年是「双轨期」——新客户被引导到 SitecoreAI，老客户继续用 Personalize，迁移与折算规则待核实。

实验分三类：Web experiment（模板/表单做页面变体）、Interactive experiment（开发者全栈实验，后端返回 JSON，前端渲染，适合 App/SPA/服务端）、Triggered experiment（FreeMarker 生成内容，推给 ESP 或短信/推送，做站外触发）[来源](https://doc.sitecore.com/personalize/en/users/sitecore-personalize/introduction-to-experiments-in-sitecore-personalize/introduction-to-experiments-in-sitecore-personalize.html)。

决策层是差异化：基于 DMN 标准，业务人员可用规则建模，同一个 decision model 可复用到不同渠道；支持 decision model、decision table、programmable decision、analytical model、knowledge source、data system，跑在 Lambda 架构（批 + 流）上 [来源](https://doc.sitecore.com/personalize/en/users/sitecore-personalize/introduction-to-decisioning-in-sitecore-personalize.html)。这比 Adobe 的「受众 + 体验」表达力更强，适合「下一步最佳动作」这类复杂决策。

统计有 Classic 与 Optimized 双引擎：Classic 固定假设、跑到统计显著；Optimized 是多臂老虎机，官方建议用于周末闪购这类时间窗有限的场景。Optimized 用 Thompson sampling；每个变体保留至少 1% 流量做持续探索；后验按 `Beta(p, q+1)` 计算（p 为转化数，q 为曝光数）；用 Monte Carlo 抽样 N 次，统计每个变体「成为最高」的次数，除以 N 得到新权重 [来源](https://doc.sitecore.com/personalize/en/users/sitecore-personalize/introduction-to-experiments-in-sitecore-personalize/running-an-experiment-with-optimized-testing/understanding-multi-armed-bandit-calculations.html)。这里有一个细节：文档写的是 `Beta(p, q+1)`，而工程上常见的 Beta-Bernoulli 后验是 `Beta(1+conv, 1+fail)`；两者在 q 很大时接近，小样本阶段不同。本文按官方文档原样引用，具体实现待核实——读厂商统计文档不能只看结论，要看他把哪个量当参数。Sitecore 还主动提示：4 个变体 + 1 个控制组时，实际误报率约 18%，建议 Bonferroni 校正。这是少见的「自曝其短」。

Personalize 自带轻量 CDP：能识别用户、建画像、跨有限会话保存状态，但不能访问客户画像、不能分群、不能导出数据，要用完整 CDP 才能解锁 [来源](https://developers.sitecore.com/learn/faq/xm-personalize/personalize-cdp)。企业已有 CDP/数仓时，这部分是重复建设；只做站内实时个性化 + 实验，轻量版够用。部署是 SaaS，客户端 Boxever.js，服务端 full-stack API，没有 Adobe 式设备端 artifact，也没有 Forte 的私有化叙事。

成本与生命周期是更大的风险。Sitecore 不公开 Personalize 单价；第三方数据显示 Sitecore 整体首年总成本：中小型 7.5 万–25 万美元，中大型 25 万–75 万美元+，大型超过 100 万美元/年，实施费可能等于或超过年授权费 [来源](https://www.vendr.com/marketplace/sitecore)。XP 10.0/10.1 的 Extended Support 在 2026-12-31 结束，之后进入 Sustaining，安全补丁「任何价格都买不到」；XM Cloud 不包含 xDB 的分析与个性化，迁移必须单独购买 CDP + Personalize [来源](https://clonepartner.com/blog/sitecore-xp-end-of-support-2026-the-version-by-version-guide)。中国方面，Sitecore 没有大陆 region，XM Cloud 没有可备案的托管资源；Personalize 的数据落在境外，构成 PIPL 下的跨境传输 [来源](https://www.21cloudbox.com/support/sitecore-xm-cloud-china.html)。

Sitecore 的 DMN 决策层最有表达力，但实验统计是「够用」而非「领先」，且被 DXP 生命周期绑架。它适合已有 Sitecore 栈、需要决策编排的客户；不适合无 Sitecore 栈、需要完整 CDP 但不加购、或要求仓库原生的团队。

**Oracle Maxymiser：一个已经消失的参照系。** 2015-09 Oracle 收购 Maxymiser，并入 Oracle Marketing Cloud；当时称每月优化超过 200 亿次客户体验。据 Monetate 的迁移说明，Oracle 在 2023 年宣布停服、生效日 2024-05-31；Oracle 官方公告本次未能直接核验（官网 403），该日期按第三方资料引用 [来源](https://monetate.com/resource/how-does-the-sunsetting-of-oracle-maxymiser-impact-cx-and-personalization/)。2026-10-18 复核：原产品页 404/301，Gartner 产品名改为「Oracle Maxymiser (Legacy)」[来源](https://www.gartner.com/reviews/product/oracle-maxymiser-legacy)，PeerSpot 标注「EOL」[来源](https://origin.peerspot.com/products/comparisons/monetate-intelligent-personalization-engine_vs_oracle-maxymiser-eol)。三条教训：实验模块会随套件战略被砍；停服时没有「等效替代」，Oracle 其他工具可以替代部分功能，但不包括 A/B 测试；迁移成本被低估，配置、受众规则、历史报表都要重建，而公告到生效日只有约一年。合同里必须写「停服/剥离时的数据导出、配置迁移、过渡期支持」。

## 2.6 六平台能力对比矩阵

先看六家 Web 套件。符号：● 原生支持；◐ 部分支持/需加购/待核实；○ 弱或无；— 不适用。

| 维度 | Optimizely | VWO | AB Tasty | Kameleoon | Convert | SiteSpect |
|---|---|---|---|---|---|---|
| 定位 | DXP 中的实验模块 | 易用型套件，合并后上探企业 | 欧洲品牌型实验+个性化+推荐 | 统计严谨的 AI 实验平台 | 公开定价的中小客户 CRO | 网络层企业级实验 |
| 典型客户 | 中大型企业、DXP 买家 | SMB→中大型 | 中大型品牌/零售/旅游 | 中大型企业、数据成熟 | SMB、代理、DTC | 大型企业、受监管 |
| 可视化编辑 | ● | ● | ● | ● | ● | ◐ |
| 服务端/Flag | ●/● | ●/● | ●/●（原 Flagship） | ●/● | ◐/◐（Pro） | ●/◐ |
| 个性化/推荐 | ●/◐ | ●/● | ●/● | ●/● | ◐/○ | ●/◐ |
| 互斥/分层 | 互斥组，无正交分层 | Enterprise 互斥组 | 1V1T/优先级，无分层 | 互斥组（跨端），无分层 | 互斥实验，无分层 | 未见 |
| Holdout | ●（global/local） | ●（FME） | ◐ 未见独立产品 | ●（Web/Feature） | ◐ 有条目，待核实 | ○ 以 control 为主 |
| 防闪烁 | Snippet/PE 边缘，PE 零闪烁 | 异步 SmartCode，待核实 | 同步 tag/SSR 锁定 | 异步+CSS 隐藏+750ms | Tracking script+Body Hiding | 反向代理，架构级 |
| 公开定价 | 询价；第三方中位约 8.1 万美元/年 | 询价（原低价） | 询价 | 询价 | 299 美元/月起 | 询价（企业级） |
| 2026 状态 | 在售，DXP+AI | 在售，合并为 Wingify | 在售，并入 Wingify | 在售，独立 | 在售，独立 | 被 Monetate 收购，品牌弱化 |

再看统计与治理。这张表最重要的不是「谁有勾」，而是「默认是什么、可选是什么、限制在哪」。

| 维度 | Optimizely | VWO | AB Tasty | Kameleoon | Convert | SiteSpect |
|---|---|---|---|---|---|---|
| 默认统计 | 频率派序贯 | 贝叶斯 | 贝叶斯 | 三选一 | 三选一 | 频率派 t 检验 |
| 可选方法 | 贝叶斯（Feature Exp.）、固定 horizon | 频率派（启动前） | 频率派 | 固定/贝叶斯/序贯 | 固定/贝叶斯/序贯 | — |
| 序贯 | ● always-valid | ● Dynamic | ◐ 仅止损告警 | ● | ● AGILE | ○ |
| CUPED | ● 仅数值指标 | ○ 未见 | ○ 未见 | ● | ○ 未见 | ○ |
| 多重比较 | FDR+Bonferroni | Bonferroni | ◐ 待核实 | ● | FDR | ◐ 待核实 |
| SRM | ● SSRM（有条件） | ● Pro | ◐ S-SRM（需 CSM） | ● Health Checks | ● SRM Check | ○ |
| 护栏 | ● Guardrail alerts | ● Pro | ◐ 弱 | ◐ 弱 | ◐ 弱 | ○ |
| 指标层 | ODP、GA4、Adobe、仓库可读 | Data360、GA4、Adobe、CDP | GA4、Adobe、Segment、推荐数据 | GA4、Adobe、数仓、OpenFeature | GA4、Adobe、Segment、GTM | GA4、Adobe、WATTS/API |

企业个性化四家的对照已在 2.5 展开，这里不再重复一张表；关键差异可以压成一句：Adobe Target 的实验最完整但绑定 Adobe 栈，Dynamic Yield 的 P(best) 只服务促销，Monetate 的 Forte 是唯一公开的私有化路径，Sitecore 的 DMN 决策层最强但统计只算「够用」。

读这张矩阵，可以提炼两个结论。

第一，**基础能力已经商品化，差异在统计、治理与交付架构**。可视化编辑、A/B/n、基础报表六家都能做；真正拉开差距的是 CUPED、序贯、SRM、护栏、互斥组、holdout、边缘/网络层交付。把「编辑器好不好用」放在第一权重，是把商品化能力当成了差异化能力。

第二，**统计标签必须写四列：默认方法、可选方法、仅某模块、不支持指标**。VWO 贝叶斯默认可切频率派，但新 Data Platform 另有引擎；Optimizely 默认序贯、Feature Experimentation 可选贝叶斯；AB Tasty 的序贯只用来止损；SiteSpect 只有 t 检验。CUPED 在 Optimizely 只支持数值指标、不适用转化率。不问清这些边界，POC 会得出错误结论。

治理则是套餐函数：互斥组、holdout、SSO、审批、自托管几乎都被锁在 Enterprise。这不是技术限制，而是价格歧视；自建时不要复制这套逻辑，否则团队会用影子工具绕开。

## 2.7 Web 优化套件的共性局限

把六家放在一起看，会发现短板高度相似。这不是巧合，而是「卖给营销团队、按流量计费、靠套件 upsell」这套商业模式的必然结果。

**一，指标层是套件自己的，不是企业的。** 套件把指标定义、事件收集、报表都放在平台内，形成数据孤岛。Optimizely 在 2026 年补齐了仓库原生——CUPED 可以跑在 Snowflake/BigQuery/Databricks 上——但这仍是「仓库可读」，不是「指标定义在仓库」：指标口径、归因逻辑、报表语义依然由 Optimizely 定义。真正的仓库原生是把 metric definition 放在 dbt/MetricFlow，平台只负责分配、曝光、统计查询。差别在规模化时会变成「同一指标在 GA4、平台、数仓三个口径」的治理灾难，也让自定义方差缩减、异质效应、长期 holdout 分析变得困难。对 PE 持有的厂商，这不是技术难题，而是组织难题：把指标定义权交给客户数仓，会削弱平台内报表的价值与粘性。

**二，统计是差异点，但不是可审计的科学。** 六家的默认方法各不相同，CTW、P(best)、置信区间的话术也不统一。AB Tasty 的序贯只用于「检测输家」，不能提前宣布赢家；VWO、AB Tasty、Convert、SiteSpect 都没有公开的 CUPED；多重比较和 FDR 有的做、有的不做；SRM 常常是付费功能或人工检查；护栏指标只有 Optimizely 和 VWO 做得比较产品化。后果是：实验数量上来后，误判率不可控；「显著」被当成「有效」；业务方记住的是「CTW 95%」，而不是「效应量、置信区间、护栏是否被击穿」。CTW 本身没有错，错在把它当成上线后赚钱的概率——它是给定模型与先验下的后验概率，还依赖指标口径、样本代表性、无 SRM、无 novelty effect。

**三，治理被切成套餐，规模化时最贵。** 互斥组、holdout、SSO、审批、自托管几乎都在最贵套餐；中端工具没有完整的 RBAC、审计、实验台账。试点时十个人、五个实验，感觉不到问题；一旦扩到十个团队、每年数百实验，就会出现「谁都能改线上」「实验互相污染」「历史结果查不到」的混乱。更糟的是，团队会绕开平台，用 Feature Flag、前端脚本、甚至手工灰度做「影子实验」，平台的指标与治理彻底失效。

**四，交付架构有物理约束，没有免费午餐。** 浏览器 snippet 会闪烁；同步 tag 不闪烁但损害 Core Web Vitals；异步 + CSS 隐藏有超时和闪烁兜底；反向代理能架构级消除闪烁，但要把 DNS、证书、CDN、网关全部交出去；边缘决策只能承载规则可序列化的实验，ML 个性化必须回源。Adobe 自己就承认 On-device/CDN 不支持 Auto-Target、AP、MVT、推荐；SiteSpect 的「零闪烁」是用「改网络」换来的。任何「零闪烁」的宣传，都要追问实现层、首屏代价、失败模式。

**五，实验设计原语缺失。** 六家都没有正交分层、factorial design、switchback、cluster randomization、interleaving 的公开原语；互斥组只是「不重叠」，不是「正交」；MVT 是全因子组合，不是带交互效应建模的 factorial design。这意味着它们只能覆盖营销页面、内容、文案、推荐位等场景，做不了推荐/搜索/定价/社交网络/双边市场等复杂实验。对 DAU 千万级的公司，主战场恰恰在后一类。

**六，供应商生命周期风险。** Maxymiser 停服、SiteSpect 被吸收、VWO/AB Tasty 合并、Dynamic Yield 被收编、Sitecore 改名，都说明「实验模块没有独立生存权」。退出成本不是「能不能导出 CSV」，而是「历史实验还能不能复现」：有没有 assignment 级曝光日志、当时的 metric 定义、config version、salt、统计方法参数。只给聚合报表、不给 assignment 级数据的厂商，停服时你拿到的只是一张结果表，无法复核。合同要写通知期、数据导出格式、迁移协助、价格保护、数据删除证明；优先选给过无停机迁移方案的厂商，避开「硬停服 + 无继任」的产品。

这六条局限的根因，是商业模式而不是技术能力。套件卖给营销团队，按 MTU/流量计费，靠 CMS/个性化/推荐 upsell；因此优先做编辑器、模板、活动运营，而不是分桶、指标治理、统计审计。理解这一点，就不会指望「买一个套件」解决平台问题。

## 2.8 对我们的启示

对 DAU 千万级、研发数百人的公司，结论不是「买哪家」，而是「哪一层买、哪一层必须自己掌握」。可以把实验平台拆成六层，分别决定买、建、还是不买。

| 层 | 建议 | 理由 |
|---|---|---|
| 可视化编辑/活动运营 | 买或轻自建 | 长尾需求，自建 ROI 低；但要能导出活动配置 |
| 分桶/曝光/Flag | 自建 | 核心资产；统一哈希、salt、config version；不能被供应商锁定 |
| 指标/统计 | 自建 + 仓库原生 | 口径与可审计性；CUPED/序贯/SRM/护栏必须自己掌握 |
| 治理/审批/审计 | 自建 | 组织流程，不能外包；多租户/权限/实验台账 |
| 个性化/推荐 | 买 | 内容/商品生态，非实验核心；与实验平台解耦 |
| 网络层/私有化 | 仅受监管场景买 Forte | 部署重；不如自建反向代理/网关层 |

**第一，把 Web 套件定位为「营销实验卫星」，不是核心平台。** 核心平台服务推荐、搜索、增长、商业化等服务端场景；套件服务落地页、内容、活动。两者共用分桶与指标，但不共用工作流：营销要模板、审批、素材；产品要 SDK、Flag、分层、holdout。用 campaign 工具承载全公司实验，最后一定是「营销嫌统计复杂、产品嫌编辑器没用」。

**第二，一套分桶、多种交付。** Optimizely 的 MurmurHash3 + Performance Edge、Kameleoon 的边缘 kit、SiteSpect 的反向代理，说明「同一套 assignment API，多种交付形态」可行。自建应把分桶、配置、曝光做成独立服务，snippet、SDK、边缘 worker 都调同一套 API；不要在三个地方各写一套哈希。曝光日志至少带 `experiment_id`、`variant`、`unit_id`、`assignment_time`、`config_version`、`salt`、`surface`。

**第三，统计引擎要可解释、可审计。** 默认序贯/always-valid，提供固定样本模式；CUPED 支持数值指标 + 仓库前两周数据；SRM 自动检测；FDR/Bonferroni；护栏指标；比率指标用 delta method；双视图——默认业务语言，一键下钻到频率派/序贯原始输出，并强制显示 SRM/护栏状态。Optimizely 的 100 个区间、VWO 的 ROPE、Kameleoon 的三方法取舍都可借鉴，但不要只给一个 CTW。

**第四，指标层必须仓库原生。** 指标定义放 dbt/MetricFlow，平台只做分配、曝光、统计查询；否则会变成「第三个口径」。Optimizely 的 CUPED on warehouse 是「仓库可读」，不是「指标定义在仓库」；真正的仓库原生要能版本化、血缘化、复用。

**第五，治理要产品化，内部不要按套餐 gate。** 互斥组、正交分层、holdout、Health Checks、审批、审计、实验台账是规模化刚需。把「谁负责口径、谁审批、谁解释统计」写进 RACI。Kameleoon 的 Health Checks、Optimizely 的 SSRM/Guardrail alerts 值得借鉴，但不要做成「只有管理员能用」。

**第六，采购按「退出成本」而不是「功能清单」决策。** 合同主体、路线图、assignment 级数据导出、OpenFeature/私有化、价格保护、12 个月通知期、迁移协助、数据删除，缺一不可。POC 用 3G、低端安卓、SPA 首屏实测「原版可见时长」与 CWV；要求厂商给出序贯/贝叶斯的假设、alpha 分配、多重比较校正、CUPED 窗口。Split→Harness FME 的无停机迁移是正面例子 [来源](https://developer.harness.io/docs/feature-management-experimentation/split-to-harness/migrate-from-split-to-harness/how-it-works)；Optimize 硬停服、Maxymiser 无等效替代是反面教材。

**第七，AI 用来降本，不用来替代判断。** 用 AI 生成变体、配定向、写报告，把「建实验」成本降下来；但显著性判断、护栏取舍、上线决策必须由人负责。PBX 称减少 97% 建实验时间，即使成立，也只是把瓶颈从「建实验」转移到「评审与决策」。

**可以买编辑器，不能买走分桶权、指标定义权和结论解释权。** 实验平台不是买一个 UI，而是建一套「分桶—曝光—指标—统计—治理」的公共基础设施；Web 套件是补充，不是主干。放对位置能服务好营销团队，放错位置就是第三个口径、第二个影子平台和下一个停服风险。

---

## 第 3 章 商业平台（下）：现代实验平台、Flag 路线与采购

> 本章拆解 Statsig、Eppo、GrowthBook、Amplitude Experiment，以及 LaunchDarkly/Split/Flagsmith 的 Flag 路线；最后给出定价、TCO 与采购 scorecard。

## 3.1 现代实验平台的四条路线

把 Statsig、Eppo、GrowthBook、Amplitude Experiment 放进同一张功能表逐项打勾，会得出一个错误结论：它们越来越像。四家都有 Flag、Holdout、CUPED、Bandit，2026 年又都在补 AI 与 MCP。但**功能是追赶变量，架构是约束变量**。真正的分野是三个结构选择：数据面放在哪里、Flag 与实验耦合多深、统计默认值是什么。

| 路线 | 代表 | 卖的是什么 | 数据在哪算 | 统计默认/强项 | 计费锚点 | 典型买家 |
|---|---|---|---|---|---|---|
| 一体化产品开发平台 | Statsig | 一套系统：事件、Flag、实验、分析 | 厂商管道 + 可选客户仓 | t/序贯/贝叶斯并列 | 计量事件 | 产品、工程、数据共用 |
| 仓原生统计层 | Eppo | 统计契约与 assignment 语义 | 客户数仓，聚合回传 | 频率派序贯 + CUPED++ | MTU/询价 | 数据科学与实验负责人 |
| 可拥有的基础设施 | GrowthBook | 可自建、可审计的软件 | 客户数仓 | 默认贝叶斯 | 席位 + 托管仓事件 | 工程与数据团队 |
| 分析套件的延伸 | Amplitude Experiment | 分析平台里的实验模块 | Amplitude 自有管道 | 默认序贯 mSPRT | 事件量 + 活跃实验数 | 已用 Amplitude 的团队 |

四条路线在 2024–2026 年都补 Flag、仓原生、AI，但收敛的是菜单不是约束；只看功能覆盖，会把架构差异误判成版本差异。

更清楚的拆法是三层：**控制面**（实验/Flag 定义、审批、下发）、**分配与曝光面**（SDK 求值、曝光日志）、**推断面**（指标、统计、护栏）。每家公司只把其中两层做成产品，第三层留给客户。Statsig 三层全包；Eppo 包控制面与推断面，分配靠客户 SDK、数据靠客户仓；GrowthBook 卖软件，三层都可自建；Amplitude 包控制面与推断面，但数据必须在 Amplitude 的事件模型里；ConfigCat/Unleash 只做前两层，推断完全外置。**控制面和分配面可以拼，推断面依赖的指标语义却没人统一**——谁定义“活跃”、谁定义“转化窗口”、谁负责曝光去重，决定了实验结论能不能对账。

统计默认值的差异，比功能清单更能预测使用体验。把“支持贝叶斯”写进选型表没有意义，必须写成四列：默认、可选、仅某模块可用、不支持的指标。

| 平台 | 默认 | 可选 | 序贯实现 | CUPED | 多重比较 |
|---|---|---|---|---|---|
| Statsig | 工具箱并列（t/序贯/贝叶斯） | Switchback、MAB | 官方未宣称唯一默认 | CUPED；CURE 仅 WHN | 支持 |
| Eppo | 频率派序贯 | 固定 horizon、贝叶斯 | time-uniform confidence sequence | CUPED++ | preferential Bonferroni |
| GrowthBook | **贝叶斯** | 频率派 | ASCS（仅频率派） | CUPEDps | Holm/BH（仅频率派） |
| Amplitude | **序贯** | 贝叶斯 | mSPRT | 有，细节待核实 | Bonferroni（频率派） |
| LaunchDarkly | **频率派** | 贝叶斯、序贯 | 自研 | 支持，不兼容百分位 | Bonferroni/BH |
| Harness FME | 频率派 | 无贝叶斯 | mSPRT | 公开文档未见 | MCC |
| Flagsmith | 贝叶斯 | 无 | 无 | 无 | 未见 |

默认值决定评审会的语言：GrowthBook 用户说“Chance to Win 96%”，Eppo 用户说“置信区间下界为正”，Amplitude 用户说“序贯检验已显著”。这些句子听起来等价，实际对应不同的错误率控制。**默认值还决定平台吸引谁**：贝叶斯让产品经理敢点开报表，频率派让数据科学家敢签字。

五个变量决定成败：**数据面位置**（厂商管道是“增长税”，客户数仓是“工程税”）；**默认统计**（贝叶斯不控假阳，频率派不直观，序贯区间更宽）；**耦合度**（Statsig 换供应商要换 SDK/曝光/历史，ConfigCat 只给 Variation ID）；**实时性**（配置生效与结果刷新要分开，止损能力=配置回滚、护栏检测、数据新鲜度三者最小值）；**供应商所有权**（三年内 Optimize、Evidently 停服，Split、Statsig、Eppo 易主）。最后一条是 2026 年新增的一等变量。

## 3.2 Statsig：把 Flag、实验、分析焊在一套曝光上

Statsig 2021 年 2 月成立，起点是“给每个工程与产品团队一套数据工具”，后来扩成实验、Flag、产品分析、Session Replay 的一体化平台 [来源](https://statsig.com/blog/openai-acquisition)。它最值得抄的不是功能数量，而是**同一个 gate 可以先 1% 放量，再直接转为实验，曝光口径不变**。Flag 与实验共用同一套分流与曝光日志，比“Flag 厂商 + 实验厂商”拼装方案少了一次对账。Flag 侧有 Gates、Dynamic Config、Segments、Release Pipelines；实验侧覆盖 A/B/n、Layers、Holdouts、MAB、Switchback [来源](https://docs.statsig.com/experiments/overview)。很多公司的实验流量要从发布系统里“借”，借一次就要重新埋点；Statsig 把这件事产品化了。

Holdout 的工程细节尤其成熟：建议 1%–2% 用户长期（3–6 个月）不看新功能，用**等量非 holdout 用户**做对照，而不是拿剩下 99% 全体比；支持 global/selected、1%–50%，可单独设 salt [来源](https://docs.statsig.com/experiments/holdouts-introduction)。“等量对照 + 独立 salt + layer 默认值隔离”，多数自建平台只做第一件。

统计栈分四层：检验框架（t、序贯、贝叶斯、Switchback、MAB）、方差缩减（CUPED；WHN 还有 CURE）、诊断（SRM、SDK check、crossover）、异质效应（Differential Impact Detection）[来源](https://docs.statsig.com/statsig-warehouse-native/features/statistics)。CURE 把国家、平台、tenure、模型打分等协变量放进回归，用 modified lasso 选特征，官方称相对 CUPED 再缩短 10%–20% 周期、新用户实验 10%–40%；但 **CURE 仅 WHN 有** [来源](https://statsig.com/blog/announcing-cure) [来源](https://docs.statsig.com/statsig-warehouse-native/native-vs-cloud)。SRM 用卡方，并给出 p 值与绝对偏差双阈值：p<0.001 且偏差≥0.1% 才红灯 [来源](https://docs.statsig.com/experiments/monitor)。这很实用——大样本下 0.02% 的偏差也会“显著”，只报 p 值会让平台天天告警。Differential Impact Detection 用 Welch t 比较“某分段内的处理效应”与“其余分段”，在 Day 1、Day 3、目标时长扫描；它是**分段筛查**，不是因果森林意义上的 CATE。

护栏方面，Guardrail Metric Alerts 在 WHN 按客户管道节奏触发，Cloud 依赖 Pulse；Pulse 通常“上线次日”才可用，本质是天级批处理。要求小时级止损，两种形态都要额外做实时链路 [来源](https://docs.statsig.com/experiments/monitor)。

Statsig 同时卖两种形态。Cloud 自己收事件、算指标，上手快；WHN 让客户在 Snowflake、BigQuery、Databricks、Redshift、Athena 里建 assignment/metric source，Statsig 生成 SQL 在客户仓里跑，只取聚合结果 [来源](https://docs.statsig.com/statsig-warehouse-native/features/experiment-options)。官方对比表很直白：Cloud 独有自动建指标、用户记账指标、自动 A/A；WHN 独有 View SQL、Source ID mapping、按需 reload；CURE 仅 WHN [来源](https://docs.statsig.com/statsig-warehouse-native/native-vs-cloud)。WHN 不是 Cloud 的皮肤：**Cloud 强在开箱即用与实时摄入，WHN 强在口径与可审计，但把查询成本与延迟转给客户数仓**。

2025-09-02，OpenAI 宣布收购 Statsig，官方称已签最终协议、交易待监管批准；据 Bloomberg/CNBC 报道对价约 11 亿美元、全股票，官方新闻稿未披露金额 [来源](https://statsig.com/blog/openai-acquisition) [来源](https://www.reuters.com/legal/transactional/openai-acquire-product-testing-startup-statsig-appoints-cto-applications-2025-09-02/)。创始人 Vijaye Raji 出任 OpenAI 应用 CTO，团队留在 OpenAI。2026-05-05，Amplitude 接手品牌与客户，继续维护 Cloud 与 WHN [来源](https://amplitude.com/blog/amplitude-and-statsig-partnership)；交易结构未披露，Statsig 博客编者注写“收购”，Amplitude 官方博客写“品牌与客户转入”，**存在不同说法**，合同主体以书面为准。2026-06-17 进入 Phase 1，约 50 人团队维护，计划 Q3 打通数据层 [来源](https://statsig.com/blog/statsig-amplitude-phase-1)；2026-10 仍在发 MCP v3，“停更”不成立，但**路线图由 Amplitude 决定**。

公开价：Developer 免费 2M events/月、50k replays；Pro $150/月含 5M events、100k replays，超额 $0.05/1K events；Enterprise 询价 [来源](https://statsig.com/pricing)。计费口径是 metered events，曝光、logged event、摄入指标、自定义指标都算，Flag/Config check 不算。粗算：1,000 万 DAU、每人每天 2 次曝光，月曝光约 6 亿条，扣除 500 万免费额度后约 **2.98 万美元/月**（595,000 × $0.05），还未计指标与日志事件（**推断，仅作量级参考**）。这就是“事件计费是规模化隐形税”的来源。

**判断**：Statsig 最适合没有强数仓约束、想用一套系统快速铺开实验文化的 product-led 团队；也适合已有数仓、愿意用 WHN 换口径一致性的公司。不适合要求秒级止损、或对数据出境与供应商锁定极度敏感的场景。合同必须写控制权变更条款——八个月两次易主，足以说明“被巨头收购”不等于“产品更安全”。

## 3.3 Eppo：卖的不是 UI，是 assignment 语义

Eppo 不建自己的事件管道，而是让客户在数仓里定义 assignment、fact、metric，Eppo 生成 SQL 在客户仓里跑，只把聚合结果拉回自己的 Postgres 做展示 [来源](https://docs.geteppo.com/reference/architecture-and-security/)。很多厂商都说自己“warehouse-native”，差别在**谁定义 assignment**。Eppo 把 assignment 做成一等公民：客户要在 SQL 里定义“谁在什么时间被分到哪个变体”，Eppo 才能把曝光、指标、实验配置 join 起来。这不是 UI 功能，而是语义契约。

控制面是另一条链路：实验/Flag 规则存在 Eppo Postgres，推送到 **Fastly CDN**；客户端 SDK 从 CDN 拉规则集，或拉预计算好的 flag 值（由 Edge Function 求值）；曝光通过 SDK callback 写回客户数仓，再由数仓侧跑分析 [来源](https://docs.geteppo.com/reference/architecture-and-security/)。关键是**控制面低延迟、数据面高延迟**：配置变更秒级生效，结果刷新要等 SQL 跑完。Eppo 不承诺实时分析，这是取舍。

统计严谨度体现在四个细节。**CUPED++**：对每个变体分别做 ridge regression，协变量包括实验前 30 天（默认）的指标历史，以及 assignment properties（≤100 个取值）；用 post-hoc stratification 替代实时分层，官方称能达到与分层抽样相同的方差缩减，却不需要在分流时做工程改造；覆盖 standard、ratio、funnel 指标，**percentile 不做 CUPED**，filtered/explore 也不做 [来源](https://docs.geteppo.com/statistics/cuped/)。**Preferential Bonferroni**：同时校正 metrics 与 variants，主指标获得更高权重，增加次要指标不会显著牺牲主指标功效；贝叶斯不提供该校正 [来源](https://docs.geteppo.com/statistics/multiple-testing/)。**Guardrail cutoff** 是“下行阈值”，不是普通指标：置信区间下界跌破阈值但尚未显著为负时黄色警告，显著为负时红色；带 cutoff 的指标设为主指标时可做非劣效检验 [来源](https://docs.geteppo.com/data-management/organizing-metrics/guardrails)。**Global Lift**：实验只覆盖部分人群时，用实验内效应、覆盖率、treatment 比例反推全量上线对全局指标的提升，并给出 Coverage [来源](https://docs.geteppo.com/statistics/global-lift/)。

Eppo 没有因果森林/meta-learner 意义上的 CATE；Interaction Detection 用卡方检验 assignment dependence、ANOVA 检验 effect interaction，p<0.01 才告警，这是**实验与实验之间**的干扰，不是人群异质效应 [来源](https://docs.geteppo.com/statistics/interaction-detection/)。

Eppo 2024-08-20 完成 2,800 万美元 B 轮；2025-05-05 被 Datadog 收购，品牌变为“Eppo by Datadog”，官方称继续服务存量与新增客户 [来源](https://www.datadoghq.com/about/latest-news/press-releases/datadog-acquires-eppo-to-expand-its-ai/)。第三方传对价约 2.2 亿美元，官方与 TechCrunch 均未披露，**待核实**。一个细节：Eppo 的 CUPED 文档写“percentile 的 CUPED 在 Datadog Experiments 中支持”，而 Eppo 自己不支持——能力正向 Datadog 迁移。

**判断**：Eppo 是四家里统计严谨度最高一档，适合已有 Snowflake/BigQuery/Databricks/Redshift、数据团队能写 assignment/fact SQL、把“实验可信度”放在第一位的公司。限制同样明显：强依赖数仓建模、分析是批式、没有公开价格与免费层、Switchback 仍是 closed beta、被收购后独立品牌存在不确定性。它不适合没有数仓、想要市场团队自助做 Web 实验、或要求实时自动止损的团队。

## 3.4 GrowthBook 云版：把「可拥有」做成价格优势

GrowthBook 的定位是 MIT 开源的模块化平台：Feature Flags、Experiment Analysis、Product Analytics 可分开用，也可一起用；云版托管在 AWS，自建版可跑在 Kubernetes，甚至 air-gapped 环境 [来源](https://docs.growthbook.io/overview)。官方称 3,000+ 家公司使用，GitHub 上 8,506 stars、884 forks、154 contributors、最近提交 2026-10-16 [来源](https://github.com/growthbook/growthbook)。它的差异化是**可拥有、可审计、便宜**：核心开源，企业功能另授权；云版按席位计价，BYO warehouse 时实验与 Flag 流量不限量。但“开源”不等于“免费”：`enterprise/` 目录走 GrowthBook Enterprise License，Holdouts、Contextual Bandits、post-stratification、审批、SCIM 都在企业版 [来源](https://github.com/growthbook/growthbook/blob/main/LICENSE)。这条边界必须写清楚，否则 POC 时“什么都有”，上线后“什么都要加钱”。

统计上，官方明确“默认贝叶斯”，理由是大多数客户觉得概率陈述更直观；频率派引擎做两样本 t 检验，可叠加 CUPED 与序贯 [来源](https://docs.growthbook.io/statistics/overview)。贝叶斯默认用无信息先验，可开启 proper prior，默认 Normal(0, 0.3)，即约 68% 的效应落在 ±30%、95% 落在 ±60%，把小样本结果向 0 收缩；输出 Chance to Win、Relative Uplift、Absolute Change、Scaled Impact。这个先验不是“偷偷影响结果”，而是把“小样本容易出极端值”显式化；代价是产品经理容易把“Chance to Win 95%”读成“95% 概率赚钱”。

序贯只支持频率派，实现是 **Asymptotic Confidence Sequences**（Waudby-Smith et al., 2023），不是 mSPRT；有一个调参 N*（默认 5,000），设成“你通常做决策时的样本量”时置信区间最窄；序贯区间整体比固定样本区间宽，这是允许任意 peeking 的代价 [来源](https://docs.growthbook.io/statistics/sequential)。把 GrowthBook 的序贯说成 mSPRT 是常见的事实错误。

CUPEDps 是 CUPED + post-stratification：CUPED 用实验前 14 天（默认，可调）的同指标数据做回归调整；post-stratification 用预计算维度（如国家）做分层，企业版功能；官方称在合适条件下等价于多拿 20%+ 流量 [来源](https://docs.growthbook.io/statistics/cuped)。多重比较提供 Holm-Bonferroni（控 FWER）与 Benjamini-Hochberg（控 FDR），仅频率派；SRM 默认 p<0.001，另有 Multiple Exposures、Pre-exposure Bias、Minimum Data 等健康检查。

公开价格（2026-10-18）：Starter 免费（3 用户/1 项目/无限实验，Managed Warehouse 1M events）；Pro **$40/seat/月**（30 用户/3 项目、2M events、MAB、Safe Rollout）；Enterprise 含 SSO/SCIM、审批、Holdouts、Contextual Bandits、99.99% SLA；Self-Hosted 开源免费、企业版另授权 [来源](https://www.growthbook.io/pricing)。官网另设 CDN Requests 1M/月（Pro 2M，超出 $10/M）、Bandwidth 5GB/月（Pro 20GB，超出 $1/GB）——“BYO warehouse 不限量”不等于分发成本为零。

**判断**：GrowthBook 的最大价值有两层：作为产品，它用 MIT 核心 + 低价云版把“实验平台”的价格打下来；作为参考实现，它把“控制面薄、数据面厚”的架构写成了可读的代码。很多自建团队的第一版，实际上是在复刻它的 Fact Table/Metric 分层。限制也清楚：自建要自己运维、升级、扩容；高级能力锁在企业版；默认贝叶斯需要培训；没有自有事件管道，实验分析强依赖数仓建模；融资额官方未披露，长期独立性待观察。官网专门做了从 Statsig 迁移的落地页，这是厂商叙事，但说明市场存在供应商稳定性焦虑 [来源](https://www.growthbook.io/blog/how-to-migrate-from-statsig-to-growthbook)。适合有数仓、要数据主权、能接受“自己运维或买云版”、预算敏感的公司。

## 3.5 Amplitude Experiment：分析套件的延伸，而非统计引擎

Amplitude Experiment 是 Amplitude 数字分析平台里的实验与 Feature Flag 模块，与 Product Analytics、Session Replay、Guides & Surveys 打包售卖。它的差异化不是统计，而是**与产品分析同源**：实验的曝光、转化、留存、路径都在同一个事件模型里，产品经理不需要等数据团队建仓就能看结果。

这个优势在“实验民主化”上很真实：市场团队可用可视化编辑器改页面，产品经理可直接看漏斗。但同源也是天花板：指标口径受 Amplitude 事件模型约束，原始数据不在客户数仓，复杂的比率、分位数、自定义归因窗口都要在 Amplitude 框架内表达。容易误解的是“Warehouse-native Amplitude（WNA）”：官方明确写它是 **legacy feature，不向新客户开放**，只支持 Snowflake 直连 [来源](https://amplitude.com/docs/data/warehouse-native/overview)，不能当 Experiment 的仓原生后端。

Amplitude 的默认是序贯检验，官方 FAQ 明确实现是 **mSPRT**，允许随时看结果而不膨胀假阳性；固定 horizon 的 t 检验在 peeking 下会把 5% 的 α 膨胀到 30–50% [来源](https://amplitude.com/docs/faq/sequential-testing)。这个数字是它默认序贯的最好理由。

贝叶斯模式使用无信息先验（二项指标 Beta(1,1)，连续指标无信息正态先验）；输出 Chance to Beat Control、Credible Interval、Chance to Be Best；最小数据要求是二项指标每变体 25 个转化 + 100 个曝光，数值指标每变体 100 个曝光；贝叶斯模式**不支持 CUPED、不支持自定义先验、关闭 Bonferroni**，改用 expected loss 控制 [来源](https://amplitude.com/docs/feature-experiment/experiment-theory/bayesian-statistics)。CUPED 在官方指南里被称为可用 14 天实验前数据，但产品文档只在贝叶斯页提到“贝叶斯不支持 CUPED”，没有给出配置细节与适用指标；**CUPED 在频率派/序贯引擎上的具体开关、覆盖率待核实**，POC 时必须现场演示。SRM 使用序贯版卡方检验，α=0.01；多重比较频率派用 Bonferroni，贝叶斯不用；护栏可以设为主指标，但 MAB 不允许用护栏当主指标 [来源](https://amplitude.com/docs/feature-experiment/troubleshooting/sample-ratio-mismatch)。

分流实现写得很清楚：`murmur3_x86_32("bucketing_salt/bucketing_value")`；先做 allocation bucketing（hash % 100 < allocation%），再做 variant bucketing（`floor(hash/100)` 映射到按权重划分的区间）；bucketing salt 在创建时随机生成，改 salt 会重新随机化用户 [来源](https://amplitude.com/docs/feature-experiment/implementation)。这套做法与行业主流一致，关键是 **salt 的生命周期管理**：改 salt、改 targeting、开关 sticky bucketing 都可能造成 variant jumping 与 SRM。SDK 支持客户端与服务端；本地求值把配置缓存在内存，官方性能是 Node.js 0.025ms、Go 0.098ms、JVM 0.007ms，冷启动 0.7–6ms [来源](https://amplitude.com/docs/feature-experiment/local-evaluation)；代价是不支持 ID resolution、用户 enrichment、sticky bucketing，这些只在远程求值里有。曝光语义尤其要小心：客户端 SDK 访问变体时自动打曝光；**服务端本地求值只自动打 assignment event，曝光要单独打**，分析时用 assignment 当曝光 [来源](https://amplitude.com/docs/feature-experiment/local-evaluation)。把“求值”当“曝光”，会把没真正看到功能的用户算进处理组，直接稀释效应。

定价（2026-10-18）：Free 2M events/月、无限 Flag、1 个 active experiment，Feature A/B/n 与 MAB/Holdout/互斥不可用；Plus $0 起，1 个 active experiment；Growth 按事件计费，基础 2 个 active experiments，MAB/Holdout/互斥/分层都是 add-on；Enterprise 同基础，含 RBAC、数据访问控制、50k Replay [来源](https://amplitude.com/pricing)。**实验能力按 active experiment 数量分层，高级类型是 add-on**——实验密度高的团队，账单远高于“2M events 免费”的直觉。

2026-05-05 起，Amplitude 同时运营 Experiment 与 Statsig，定位为“AI 产品开发的 validation stack”：Amplitude 做行为分析，Statsig 做实验与发布验证 [来源](https://amplitude.com/blog/amplitude-and-statsig-partnership)。Experiment 可能长期扮演“中端/分析内嵌实验”，Statsig 承担“专业平台”角色；两条线如何划界，采购时必须问清。

**判断**：适合已用 Amplitude、实验以产品/增长/Web 为主、需要产品经理自助的公司。不适合已有强数仓、要求指标口径与仓一致、或需要 CUPED/序贯/多重校正全套统计能力的团队。

## 3.6 Flag 路线：LaunchDarkly、Split、Flagsmith、ConfigCat、Unleash

Flag 平台的核心对象是 `flag → variation → targeting rule → rollout`，回答“这个请求应该走哪条代码路径”，优化爆炸半径与可逆性；实验平台的核心对象是 `hypothesis → experiment → metric → analysis`，回答“这条路径相对对照产生了多少因果效应”，优化偏差与方差。Flag 要求同一用户在多次请求中稳定命中同一 variation；实验还额外要求**曝光只在真正进入处理时记录一次**。按“随机化、曝光、指标、推断、治理”五件事拆，五家不在一个档位上。

| 平台 | 归属/许可（2026-10） | 实验档位 | 统计 | 曝光 | 计费锚点 | 公开起价 |
|---|---|---|---|---|---|---|
| LaunchDarkly | 独立 | L3：完整统计 + 仓原生 | 贝叶斯/频率派/序贯/CUPED/MCC/SRM | SDK 事件 | 服务连接 + client MAU | $0；$10/连接 + $8.33/1K MAU |
| Harness FME | Harness 旗下 | L3：完整频率派 + 仓原生 | Welch t / mSPRT / MCC / SRM | impressions | 模块/席位（询价） | 需询价 |
| Flagsmith | 独立，BSD-3 | L2：内嵌贝叶斯 Beta | 仅贝叶斯 | 部分 SDK 事件 | 请求数 + 席位 | 年付 $40，月付 $45 |
| ConfigCat | 独立 | L1：只做 assignment 导出 | 无 | Variation ID | config 下载量 | $110/月（25M 下载） |
| Unleash | 独立，AGPLv3 | L1：impression + impact metrics | 无 | impression data | 席位 | OSS 免费；$75/seat |

> L3 = 独立统计引擎 + 实验治理；L2 = 有内嵌统计但方法与治理有限；L1 = 只做分配/曝光，推断外置。这是能力匹配度，不是产品好坏。

**LaunchDarkly** 已把自己重新定义为“software and AI agents 的 runtime control platform”。2026-08-06 官方新闻稿称 ARR 超过 2 亿美元、同比增长逾 25%，每天支撑超过 50 万亿次 flag evaluation [来源](https://leaderpost.com/press-releases/globe-newswire/launchdarkly-surpasses-200-million-in-arr-as-demand-for-runtime-control-accelerates/)。实验统计是五家里最完整的：Bayesian、Frequentist fixed-horizon、Frequentist sequential 三种模式，默认频率派；CUPED 按 Deng et al. (2013) 的 ANCOVA/CUPED 处理，不兼容百分位；多重比较有 Bonferroni 与 BH；SRM 内置；还有 stratified sampling [来源](https://launchdarkly.com/docs/guides/statistical-methodology/choosing) [来源](https://launchdarkly.com/docs/guides/statistical-methodology/cuped)。官方还明确警告：**贝叶斯不控制假阳性率**，大量 A/A 测试也可能出现高“胜率”。这句话值得所有把“Chance to Win”当决策依据的团队贴在墙上。

仓原生是它 2025–2026 的关键补强：2025 年支持 Snowflake，2026-06-25 扩到 BigQuery、Databricks、Redshift；Data Export 把曝光同步进仓，指标在仓内计算，只把聚合、去标识结果回传展示 [来源](https://launchdarkly.com/blog/warehouse-native-experimentation-comes-to-bigquery-databricks-and-redshift/)。注意：**原始数据不出仓，不等于分析完全在仓内完成**——统计与报告仍由 LaunchDarkly 侧完成。

架构数字很漂亮：SSE 流式下发、100+ POP、初始化 25ms、变更 200ms 内到达，SDK 内存缓存、断网可求值；配置下发延迟 SLO 为 Developer <300ms、Foundation <200ms、Enterprise <150ms [来源](https://launchdarkly.com/how-it-works/platform-architecture/)。但 2025-10-20 的 AWS us-east-1 故障说明“流式 + 多区域”不是银弹：内部降载变更切到冷缓存旧路由，SDK 重试风暴，服务端 streaming 全球约 99% 连接错误，事件摄取还发生了数据丢失 [来源](https://launchdarkly.com/blog/what-happened-what-we-learned-and-how-were-improving/)。**配置可以靠本地缓存继续服务，但实验数据丢了就是丢了**；合同要写清 failover、事件补发与数据丢失补偿。

定价按“连接数 × 客户端 MAU”：Developer 免费、无限 seats/flag、100K experimentation MAU、1K client MAU；Foundation 按量，$10/服务连接/月 + $8.33/1K client-side MAU/月（年付）；Enterprise 询价；Guardian（release monitoring、guardrail metrics、自动回滚）单独定价 [来源](https://launchdarkly.com/pricing/)。对 1,000 万 DAU、客户端全量接入、200 个服务端实例的公司，粗算 10M × $8.33/1K ≈ **$83.3K/月**，加 200 × $10 = **$85.3K/月**（约 $1M/年），还没算 Guardian。

**Harness FME（原 Split）**：2024-05-29 宣布收购、2024-06-11 交割，随后更名 Harness FME [来源](https://www.harness.io/press-and-news/harness-completes-acquisition-of-split-software)。有资料写“2024-07”，与官方交割日不符，**存在不同说法，以官方新闻稿为准**。截至 2026-10，官网出现“Runtime Configuration”品牌层，但文档仍用 FME，是否正式改名**待核实**。统计是纯频率派：固定 horizon 用 Welch's t-test，序贯用 **mSPRT**，官方明确不提供贝叶斯；默认每组至少 355 个独立观测才开始算显著性（固定 horizon 最低 10、序贯最低 100），内置 review period 与 SRM [来源](https://developer.harness.io/feature-management-experimentation/use-fme/experimentation/key-concepts/fixed-horizon)。MCC 有独立文档；护栏自动测量；CUPED 在公开统计文档中未检索到，写“不支持”不严谨，写“公开文档未提供，需书面确认”更准确。架构上每天服务 **500 亿次** flag evaluation，双层 CDN 全球 **<200ms** 下发 [来源](https://developer.harness.io/docs/feature-management-experimentation/sdks-and-infrastructure/)。互斥实验靠父子 flag 拼装，官方明确代价是“每个实验分到的流量变少、跑得更久”。商业风险：并进 DevOps 后 roadmap 受 CI/CD 影响；品牌更名频繁；Harness 还保留一套更老的 Feature Flags 产品，**同一厂商两套 flag 并存**，买前必须确认买的是哪套；FME 定价需询价。

**Flagsmith** 的核心卖点是“真开源”：核心 flag、远程配置、targeting rules 用 **BSD-3-Clause**，可自托管、fork、商用；GitHub 约 6,597 stars [来源](https://github.com/Flagsmith/flagsmith)。实验能力截至 2026-10 仍是 **Beta**：多变量 flag 分流，SDK 采集 exposure 与 conversion，事件进托管仓或客户 ClickHouse/Databricks；结果页给 lift、95% credible interval、win probability [来源](https://docs.flagsmith.com/experimentation)。细节说明成熟度：结果最多每 5 分钟刷新；样本少于 50 identities 时不给结论；SRM 警告会提示“不要据此行动”；只有 Bayesian；事件采集只覆盖部分 SDK。

价格上有一个抓取冲突：一处记录 Start-Up $250/月、Scale-Up $300/月，另一处记录 Start-Up $40/月、Scale-Up $250/月。核对 2026-10-18 官网后确认，**这是年付/月付两栏**：年付 $40/$250，月付 $45/$300；额外成员 $60/月（年付 $50），超量 $7/100K requests [来源](https://www.flagsmith.com/pricing)。两份记录各取一栏，**存在不同说法但可解释**。

**ConfigCat** 只做 feature flag + remote config，不碰实验统计。它给每个被服务过的值生成 **Variation ID**，让客户端随事件发给 Amplitude、GA、Mixpanel、Segment，由外部工具分析 [来源](https://configcat.com/docs/advanced/variation-id-for-analytics)。这是“assignment 在 flag 平台，inference 在分析平台”的典型分工：灵活、便宜，但实验元数据、曝光去重、SRM、指标口径全要自己管。SDK 从 CDN 下载 config JSON 并缓存，默认 polling 60 秒；SLA 99%–99.99%。价格按下载量：Pro $110/月含 25M、Enterprise $900 含 1B、Dedicated $4,500 含 6B+，seats/MAU 不限 [来源](https://configcat.com/pricing/)。200 个服务端实例每 60 秒拉一次，月约 864 万次下载，Pro 就够；客户端每次冷启动都拉一次，下载量会随 DAU 线性上涨。

**Unleash** 是挪威的开源 flag 平台，主打 flag 生命周期、治理、渐进发布。GitHub 约 13.9k stars；2026-06-02 从 Apache 2.0 切到 **AGPLv3**（v8.0.0 起）；2026-03-04 完成 3,500 万美元 B 轮 [来源](https://www.getunleash.io/blog/unleash-moving-to-agplv3) [来源](https://www.getunleash.io/blog/series-b)。它的 A/B 指南很坦率：用 experiment flag + gradual rollout + strategy variants 分流，用 impression data 接转化结果，判断哪个 variant 更好依赖你自己的分析。**Impact metrics** 支持 counter/gauge/histogram，用途是画图与 release safeguards，属于“发布安全”而非“因果推断”。

**判断**：Flagsmith 适合轻量实验 + 自托管，ConfigCat 适合纯配置 + 外部统计，Unleash 适合强治理 + 仓内统计。三家的共同点是：**不要指望它们替你回答“哪个版本更好”**。

计费锚点会反向决定架构。1,000 万 DAU、200 个服务端实例的粗算：LaunchDarkly 约 **$85.3K/月**（client MAU + 连接），Flagsmith 约 **$15K/月**（300M 请求），ConfigCat **$110/月**（config 下载），Unleash 200 × $75 = **$15K/月**（席位），FME 需询价。按 client MAU 计费就把求值放服务端/边缘；按请求计费就必须本地缓存与 Edge；按下载计费就控制实例数与轮询；按席位计费就约束后台账号数。**没有一家按 flag 数量或 context 数量直接计费**，真正被计价的是连接、请求、席位、下载这些运行规模量。

“Flag + 数仓”适合：已有成熟数仓与指标治理；发布/灰度远多于实验；高 DAU、客户端全量接入；需要 cluster randomization、switchback、interleaving、分位数等非标准方法；原始数据不能出仓。不适合：PM 自助实验；需要开箱即用的序贯/贝叶斯/护栏；数据工程弱（曝光不完整、身份拼接不稳定）；实验量大且需要互斥层、holdout、评审；需要供应商 SLA。

推荐混合架构：**Flag 控制面（买或开源自托管）+ 自建 exposure schema + 数仓指标层 + 仓内统计 + 自建治理**。关键设计：assignment 与 exposure 分离；exposure 表作为事实表（`experiment_id, variant, unit_id, timestamp, surface, sdk_version`，按 `unit_id + experiment_id` 去重）；统计在仓内（CUPED 用实验前 28 天预指标，序贯用 group sequential 或 mSPRT，SRM 用卡方/时序检查）；高 DAU 优先 server-side local eval + Edge。

```mermaid
flowchart LR
  A[业务代码 / OpenFeature SDK] --> B[Flag 控制面]
  B -->|assignment| A
  B -->|exposure 事件| C[曝光采集层]
  A -->|业务事件| C
  C --> D[数仓明细层]
  D --> E[指标语义层 dbt/Spark]
  E --> F[统计引擎 CUPED/序贯/贝叶斯]
  F --> G[实验报告 / 护栏 / 复盘]
  B --> H[审批 / 审计 / 变更]
```

隐藏成本有五处：**曝光管道**（旧 SDK、事件去重、`identify` 时序都会制造 SRM）；**身份拼接**（匿名 ID → 登录 ID 不稳定，会让同一用户在不同 variant 间漂移）；**指标治理**（同一个“转化率”在埋点、数仓、BI 三个口径）；**回填与重算**；**双份合同**。组织上把“发布控制”与“实验推断”分开：一个团队负责 flag/rollout/审批，一个团队负责指标/统计/评审。把“flag 清理率”纳入平台 KPI。

## 3.7 云厂商与停服教训：他们卖的是交付，不是推断

**Google** 官方帮助页写得很直接：**Optimize 和 Optimize 360 自 2023-09-30 起不再可用，当天仍在运行的实验和个性化全部结束**；理由是 Optimize“没有客户所需和要求的许多实验功能”，因此把投入转向第三方集成 [来源](https://support.google.com/analytics/answer/12979939)。这是超大规模厂商对通用实验平台的投入产出判断：功能长尾极长。

停服后，Google 的实验能力被拆成三层：**Firebase A/B Testing**（移动 App，Remote Config 参数 + GA4 指标 + 频率派检验）、**GA4**（测量层，把变体写成 audience/维度）、**第三方**（Optimizely/VWO/AB Tasty 补 Web 实验）。Firebase 的边界很清楚：分流单元是 App 安装实例，不是业务账号；2023-10-23 起新实验用频率派单侧检验、显著水平 0.05、每天刷新；上限是同时 24 个实验、项目内 300 个、单实验 8 个变体、最长 90 天；没有文档化的 CUPED、序贯、SRM、多重比较 [来源](https://firebase.google.com/docs/ab-testing/ab-concepts)。它是“移动端够用版”，不是 Optimize 替代品。

**AWS** 官方博客 2024-10-17 宣布 CloudWatch Evidently 将于 **2025-10-17** 停止支持，期间只提供关键安全补丁、不再接受 limit increase，建议迁 AppConfig [来源](https://aws.amazon.com/blogs/mt/support-for-amazon-cloudwatch-evidently-ending-soon/)。有第三方 GitHub issue 写“2025-10-16 停服”，与官方差一天，**存在不同说法，以官方为准**。Evidently 停服时，AppConfig 只有 flag/segment，编排和推断都要自己做；2026-06，AWS What's New 上线 **AppConfig experimentation**，2026-09-30 官方博客给出完整架构 [来源](https://aws.amazon.com/blogs/devops/running-production-experiments-with-aws-appconfig-experimentation/)。它做“实验编排 + 分流 + 曝光日志”：控制面定义 hypothesis/audience/control/treatment，Agent 本地按 Entity-Id 返回固定 treatment，首次分配往 stderr 写 assignment 日志，再经 CloudWatch Logs → Firehose → S3 → Athena 进数仓。**它不做统计推断**：官方让你在自己的统计工具里跑 two-proportion z-test。

这套架构有几个具体的坑，官方自己都点了出来：**0% 曝光验证不了 assignment 管道**（override 不产生记录，必须拉到 1%）；**曝光不能中途降低**（只能 stop 后重起更低的 run）；**AppConfig 是 Regional 的**；**实验小时计费从 start 到 stop**（三个并发就是三倍）。第三方实测约 $0.90/小时，非官方定价页确认，**待核实**。

这段历史很重要：AWS 把独立实验产品砍掉，把实验降级为配置服务的一个 feature；一年后又以“AppConfig experimentation”把编排能力加回来。产品形态从“独立平台”变成“配置服务 + 按实验小时计费”。这也是最值得自建平台借鉴的取舍：把“实验定义、分流、曝光日志”产品化，把“指标口径与统计推断”留给数仓和方法团队。

**Microsoft** 的 ExP 留在内部（2018 年论文称每年超过一万个实验，由 portal、execution、log processing、analysis 四部分组成），对外只有 **Azure App Configuration** 的 Switch/Rollout/Experiment 与 Metric Scorecard（preview）——有显著性面板，没有 CUPED、序贯、SRM、多重比较；吞吐 Standard 300 RPS、Premium 450 RPS，高 QPS 必须本地缓存。**Cloudflare Flagship** 是边缘 flag：Durable Objects + KV + isolate，变更最多 30 秒全球生效，没有实验统计、holdout、分层、互斥 [来源](https://blog.cloudflare.com/flagship/)。它们负责“让用户看到哪个版本”，不负责“判断哪个版本更好”。

**中国云厂商**的实验能力，基本是“内部平台外溢”或“场景化能力”，不是横向 SaaS。火山引擎 DataTester 是字节内部 Libra 的对外产品，2012 年引入 A/B、2016 年产品化、2021 年对外开放；中原银行项目中标 **96 万元/27 个月**，神策报价 85 万，另一家 139 万 [来源](https://www.volcengine.com/product/DataTester) [来源](https://www.365trade.com.cn/jfwzb/775230.jhtml)。阿里云 PAI A/B 只面向 LLM/搜索推广的模型服务，功能免费、算力另计，限四地域 [来源](https://www.alibabacloud.com/help/zh/pai/a-b-experiment/)。腾讯云公开目录未见独立通用 A/B SKU（**待核实**）。京东科技 ABTest 3.0 服务南航数科，中标 **256 万元（含税）** [来源](http://www.gdebidding.com/nhpbgs/199863.jhtml)。这些报价说明：**国内私有化的真实价格带是“百万级”**；对 3,000 万 MAU 按 2–3 倍上浮，3 年许可 + 实施 250–600 万是合理预期，但加上基础设施与人力，总 TCO 约 910–1,680 万（见 3.8 节）。

五条停服教训。**第一，独立实验产品在云厂商内部缺乏 P&L 与预算优先级**：Optimize、Evidently 都不是“技术做不出来”，而是“在巨头的产品组合里排不上号”。**第二，收购后“人、产品、品牌”可以分离**：Statsig 团队留在 OpenAI，产品/品牌/客户转给 Amplitude；Split 品牌退出，SDK 与客户迁到 Harness FME。评估风险要分别问：团队、产品、数据导出。**第三，免费层最先被砍**：Optimize 的免费 Web 实验、Evidently 的免费额度都是获客工具。**第四，技术债决定寿命**：Optimize 的 DOM 操作、闪烁、SPA 兼容差；Evidently 的尴尬在于“往上不如专业平台，往下又比纯 flag 重”。**第五，云厂商回归的是“编排 + 曝光”，不是“推断”**：AppConfig 不计算结果，Azure Metric Scorecard 只给“显著/不显著”面板，Firebase 只有基础频率派检验。

退出成本分四层：**数据层**（曝光明细、指标定义、实验配置、审计日志，难度中）、**代码层**（SDK API、flag key、targeting 规则，难度高）、**统计层**（salt/哈希兼容、历史复现，难度高）、**组织层**（流程、权限、培训，难度低-中）。最贵的是代码层与统计层，也最容易被采购文档忽略。

## 3.8 定价、TCO 与采购 scorecard

实验平台的报价单看似五花八门，拆开只有七种计量单位：MAU/MTU、曝光量、事件量、实验数、席位、域名/数字资产、SDK 请求。它们分别把增长风险分配给流量、实验密度、埋点、实验文化、组织扩张、多端多品牌和轮询架构；**计量单位决定谁承担增长风险**，锚点与价值曲线越不匹配，越应谈“封顶价”而非“单价”（推断）。

三种隐性税：**实验密度税**——按实验数计费，50 实验/月比 10 实验/月贵 5 倍，但平台边际成本几乎为零，等于对实验文化征税；GrowthBook 与 Convert 都标注 unlimited experiments。**曝光税**——按 impressions 计价会把“实验覆盖多少流量”变成成本项，团队本能缩小流量，损害统计功效（样本越小，MDE 越大），这是最坏的激励错位：**为了省钱而做不出显著结果**。**席位税**——按 seat 计费会让平台变成“数据团队的专属工具”，产品经理、运营不敢开账号；GrowthBook Pro 的 $40/seat 在 30 人以内尚可，超过 30 人就要转 Enterprise。

2026 年 10 月公开价格：

| 厂商 | 计价锚点 | 免费层 | 公开起价（官方，除非注明） | 信息日期 |
|---|---|---|---|---|
| GrowthBook | seat + 托管仓事件 | 3 用户/1 项目/无限实验 | Pro **$40/seat/月**；托管仓 1M/2M 事件，超出 $0.03/1K；CDN 超出 $10/M | 2026-10-18 |
| LaunchDarkly | client MAU + 服务连接 | $0：无限 seat、100K 实验 MAU、1K client MAU、5 连接 | **$10/连接/月 + $8.33/1K client MAU/月**（年付） | 2026-10-18 |
| Statsig | 计量事件 | 2M events、50K replays | Pro **$150/月**含 5M events，超出 **$0.05/1K** | 2026-09-17 |
| Flagsmith | API 请求 + seat | 50K 请求/月、1 成员 | 年付 **$40**、月付 **$45**（Start-Up，1M 请求） | 2026-10-18 |
| ConfigCat | config 下载 | 5M 下载、10 flags | Pro **$110/月**（25M 下载） | 2026-10-18 |
| Unleash | seat | OSS 自托管免费 | Cloud PAYG **$75/seat/月**（53M API 请求） | 2026-10-18 |
| Amplitude | 事件量 + active experiments | 2M events、1 active experiment | Plus **$0 起**；Growth/Enterprise 询价 | 2026-10-18 |
| Eppo | MTU + flag（询价） | 无公开 | **无公开价**，需询价 | 2026-10-18 |
| 火山引擎 DataTester | 项目/私有化 | 试用 | 需询价；银行项目中标 **96 万元/27 个月** | 2025-12-18 |
| 京东科技 ABTest | 私有化项目 | — | 南航数科项目中标 **256 万元（含税）** | 2026-07-20 |

> Eppo、Harness FME、Optimizely、Adobe Target 均为询价制，第三方估算不写成官方报价。

三年 TCO 假设：3,000 万 MAU / 1,000 万 DAU、50 实验/月（3 年 1,800 个）、单实验覆盖 20% MAU、月曝光 3 亿次、月事件 18 亿条、工程师 80 万/人年、汇率 7.1。以下为**本报告测算（推断）**，误差 ±50%。

| 方案 | 3 年订阅/许可 | 3 年基础设施 | 3 年人力 | 一次性投入 | **3 年合计** | 单位实验成本 |
|---|---|---|---|---|---|---|
| A. 商业 SaaS（外资，按 MAU/事件） | 1,300–3,800 万 | 含在订阅 | 120–240 万 | 100–300 万 | **1,520–4,340 万** | 0.85–2.4 万 |
| B. 商业私有化（国产） | 250–600 万 | 300–600 万 | 360–480 万 | 含在许可 | **910–1,680 万** | 0.5–0.95 万 |
| C. 开源自建（GrowthBook/FeatureProbe + 数仓） | 0–150 万（企业版） | 450–900 万 | 840 万（3 人 + 0.5 SRE） | 60–120 万 | **1,350–2,010 万** | 0.75–1.1 万 |
| D. 纯自研 | 0 | 450–900 万 | 1,440–2,440 万 | 含在人力 | **1,890–3,340 万** | 1.05–1.85 万 |

三个反直觉结论：**私有化最便宜**——国产厂商把研发成本摊到多个客户，license + 实施 + 三年维保可压到 250–600 万，而自建 3 个工程师三年就是 840 万，人比 license 贵。**“开源免费”是幻觉**——GrowthBook 企业目录走商业许可，Unleash 是 AGPL-3.0，FeatureProbe 已停更两年；许可证免费，3 人三年 840 万是实打实的。**SaaS 不一定贵，但不可预测**——按 MAU 计价在 30M 规模挂牌约 $300 万/年，5 折 $150 万/年，三年约 3,200 万；只有“不打算养团队”时它才比自研便宜。

敏感性：流量翻倍，SaaS +80%–100%，其余 +10%–20%；实验数翻倍，按 MAU 计费的 SaaS 边际成本≈0，按事件计费约 +100%，私有化 +5%–10%，开源/自研 +15%–25%；人力 +30%，自研 +30%，开源 +25%，私有化 +5%，SaaS≈0。**边际实验成本才是实验文化的真正约束**：要把实验密度从 50/月提到 150/月，只有 flat fee 或自建两条路。

常见的 9 维权重是：统计可信度 20、功能匹配 15、规模与延迟 15、数据安全 12、合规 8、集成 10、总成本 10、供应商稳定性 5、迁移成本 5。方向对，但**供应商稳定性只给 5 分，而 2023–2026 年三个主流产品消失或易主（Optimize、Evidently、Split），两个被收购/合并（Statsig、VWO+AB Tasty）**。把稳定性压到 5 分，等于假设“大厂不会停服”，而这恰好被证伪。

本章建议改成两级：**先过资格门槛，再加权打分**。

| 层级 | 项目 | 判定方式 |
|---|---|---|
| 门槛 1 | 能导出曝光级明细（不是只有聚合报表） | 合同附件 + POC 实测 |
| 门槛 2 | 有 SRM 检测/告警 | 注入 2% 分流偏差，看是否报警 |
| 门槛 3 | 数据区域/私有化可行 | 合规问卷 + 部署架构图 |
| 门槛 4 | SLA ≥99.9%，有按分钟赔付条款 | 合同 |
| 门槛 5 | 能说明哈希/salt，且合同价格封顶 | 白皮书 + POC + 报价单 |
| 加权 | 统计可信度 25、数据架构 15、规模与延迟 15、治理 10、集成 10、总成本 10、供应商稳定性 10、迁移 5 | 1–5 分加权 |

把统计从 20 提到 25，是因为“回放测试”能证伪；把稳定性从 5 提到 10，是因为基率摆在那里；把“数据架构”单列 15 分，是因为仓原生与非仓原生在 TCO 上是两种物种。任何门槛不过，整体否决，不进入加权。

**统计回放**是唯一能证伪“统计强”的方法：用你提供的 3 个历史实验——1 个 A/A、1 个有 SRM、1 个已知效应量——比较四项：A/A 是否报告“无显著差异”；SRM 是否被标记；已知效应量是否落在置信区间内；换指标口径（如“下单”换“支付”），结论是否稳定。A/A 要样本量足够、运行完整；SRM 可人工注入 2% 偏差，但要在测试环境做；已知效应最好来自全量上线验证过的实验。

合同四件事必须写死：**曝光级明细导出**（`user_id/device_id/experiment_key/variant/timestamp/context/exposure_id`，Parquet/CSV + REST API，终止后至少保留 90 天）；**迁移协助**（免费 80–160 人时，含双跑支持）；**三年价格封顶**（涨幅 ≤5%/年，超量单价封顶）；**停服过渡**（不少于 12 个月，或源码托管 escrow）。再加两条：控制权变更时可无罚终止；SLA 99.95%、按分钟赔付、公开状态页。

迁移最容易出事的是 salt。典型实现是 `hash(salt + unit_id) % 100`，**salt 或哈希一变，同一个用户会被重新分配**：运行中的实验“中途换组”，效应量被污染；已结束实验复现对不上；holdout 组被打破。可行路径按风险从低到高：**冻结法**（只迁已结束实验和已下线 flag，运行中的在原平台跑完，最安全但拖 4–8 周）；**变体钉住**（新 SDK 把老平台 variant 作为 context 传入，新平台只记录+分析，不分配）；**同盐同算法**（要求自定义 salt 与相同哈希如 MurmurHash3，做 1% 流量对比，多数厂商不承诺，需 POC）；**双跑对照**（新旧 SDK 同时求值，不一致率 <0.1% 才切流，成本最高，可用于核心实验）。

中国市场有四道硬约束。**数据出境**：《促进和规范数据跨境流动规定》（2024-03-22 施行）把出境分成安全评估、标准合同/认证、豁免三档 [来源](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm)；3,000 万 MAU 的平台累计出境个人信息必然超过“100 万人”这一档，原则上需申报安全评估。外资 SaaS 在中国区几乎不可用——不是“贵”，是“合规路径走不通”。可行解只有：私有化/专属云部署在境内；或仓原生且**控制面也在境内**；或只让聚合指标出境（工程上很难保证）。**等保 2.0 三级**：实验平台处理用户标识、行为数据、能改变线上行为，通常按三级建设；SaaS 多租户很难提供“独立边界 + 独立审计 + 独立测评”，这是金融/央国企偏好私有化的直接原因。**信创**：国产 CPU/OS/数据库/国密算法；SDK 要有 ARM64 构建，SQL 方言要适配（窗口函数、JSON、UDF 是重灾区）。**私有化交付**：需要离线镜像、Helm Chart、License 绑定、升级窗口、维保、驻场；升级最容易被低估——每次都要在客户环境做回归，版本落后 2–3 个季度是常态。

## 3.9 对我们的启示

对 DAU 千万级、已有埋点/数仓、多端产品、数百研发的委托方，结论不是“选一家平台”，而是把平台拆成五个模块，分别决定买、建、复用。

| 模块 | 建议 | 理由 | 近期动作 |
|---|---|---|---|
| Flag/控制面 | **买或开源自托管** | 多语言 SDK、边缘、审批、审计、SLA 的工程复杂度高 | 在 LaunchDarkly、Unleash、ConfigCat 中按计费与治理选型；用 OpenFeature 抽象求值接口 |
| Assignment/曝光 SDK | **自建薄层** | 曝光明细是核心资产，不能锁在厂商；assignment 与 exposure 必须分离 | 定义 exposure schema、去重键、salt 生命周期；跨端一致性测试 |
| 指标语义层 | **复用数仓，自建语义层** | 公司已有唯一可信口径，平台不应制造第二套指标 | 用 dbt/Spark 建 assignment/fact/metric 三层，平台只读 |
| 统计引擎 | **仓内自建 + 开源参考** | 序贯、CUPED、SRM、多重比较的方法公开，工程可控 | 先做 CUPED + 序贯 + SRM 双阈值 + 护栏非劣效 |
| 实验治理 | **自建** | 分层/正交、互斥、holdout、审批、生命周期是公司特异性能力 | 先做全局 holdout + 互斥层 + 实验冻结，再做评审与归档 |

六条落地建议。**第一，先定“实验单元”与“曝光事实表”**：实验单元（user/device/account/city）与分析单元可以不同，但必须显式声明；曝光表至少含 `experiment_id, variant, unit_id, timestamp, surface, sdk_version`，按 `unit_id + experiment_id` 去重。没有这张表，统计都是沙上建塔。

**第二，统计默认值选“序贯 + CUPED”，贝叶斯作为沟通层**：序贯解决 peeking，CUPED 解决灵敏度；护栏用“非劣效 cutoff”；多重比较按 metrics × variants 校正、主指标加权；SRM 用“p 值 + 绝对偏差”双阈值，避免大样本下微小偏差天天报警。贝叶斯可对外讲“Chance to Win”，内部决策仍要有频率派假阳控制。

**第三，Holdout 与 Layers 要产品化**：至少要有全局 holdout（按 unit 类型）、互斥层、正交层，以及“holdout 用户在所有 gate 上返回 false/默认值”的一致性保证。Statsig 的等量对照、独立 salt、layer 默认值隔离，Eppo 的 mutual exclusion + holdout analysis，都是成熟设计；否则 holdout 会被某个忘记加判断的实验污染。

**第四，计价优先谈“flat fee + 曝光上限 + 价格封顶”**：不要接受纯按曝光/事件的线性计价，否则实验密度越高，账单越不可控。用 12 个月真实流量做 TCO，重点问：曝光算不算 event、指标摄入算不算、超额单价、是否按实验/席位另收、数仓查询谁买单。

**第五，供应商风险写进合同，不要写进“感觉”**：Statsig 八个月两次易主、Eppo 并入 Datadog、Split 品牌退出、Optimize/Evidently 停服，说明“被巨头收购”不等于“产品更安全”。合同至少要有曝光级明细导出、控制权变更终止权、价格保护、迁移协助、停服过渡 12 个月或 escrow、数据删除证明。**实验元数据（实验定义、分层、holdout、曝光日志）比 UI 更重要**，必须可导出、可重放。

**第六，中国区默认私有化/境内控制面，组织上把“发布控制”与“实验推断”分开**：3,000 万 MAU 意味着数据出境安全评估，外资 SaaS 基本出局；国产私有化价格带是百万级（85–256 万中标案例），但要用迁移条款对冲锁定。如果选仓原生，确认“控制面也在境内”，否则“数据不出仓”只是数据面留在境内。组织上，一个团队负责 flag/rollout/审批（偏 SRE/平台工程），一个团队负责指标/统计/评审（偏 DS/数据）；合一容易让 flag 的“快”绑架实验的“准”。把“flag 清理率”“实验复盘率”“SRM 告警处理时长”纳入 KPI。

**一句话：买“变更的确定性”，建“因果的可信度”，复用“指标的唯一定义”。** 三者混在一起买，最后一定会在“指标口径”和“跨业务互斥”两处被卡住；拆开建，才可能用可接受的成本得到既快又准的平台。

## 本章主要来源

1. [Statsig is joining OpenAI（官方）](https://statsig.com/blog/openai-acquisition)
2. [Reuters：OpenAI to acquire Statsig（2025-09-02）](https://www.reuters.com/legal/transactional/openai-acquire-product-testing-startup-statsig-appoints-cto-applications-2025-09-02/)
3. [Amplitude and Statsig（官方，2026-05-05）](https://amplitude.com/blog/amplitude-and-statsig-partnership)
4. [Statsig Phase 1（官方，2026-06-17）](https://statsig.com/blog/statsig-amplitude-phase-1)
5. [Statsig Docs：Statistics（WHN）](https://docs.statsig.com/statsig-warehouse-native/features/statistics)
6. [Statsig Docs：Native vs Cloud](https://docs.statsig.com/statsig-warehouse-native/native-vs-cloud)
7. [Statsig Pricing](https://statsig.com/pricing)
8. [Eppo Docs：CUPED++](https://docs.geteppo.com/statistics/cuped/)
9. [Eppo Docs：Multiple Testing](https://docs.geteppo.com/statistics/multiple-testing/)
10. [Eppo Docs：Architecture & Security](https://docs.geteppo.com/reference/architecture-and-security/)
11. [Datadog acquires Eppo（官方，2025-05-05）](https://www.datadoghq.com/about/latest-news/press-releases/datadog-acquires-eppo-to-expand-its-ai/)
12. [GrowthBook Docs：Statistics Overview](https://docs.growthbook.io/statistics/overview)
13. [GrowthBook Docs：Sequential Testing](https://docs.growthbook.io/statistics/sequential)
14. [GrowthBook Pricing](https://www.growthbook.io/pricing)
15. [GrowthBook GitHub](https://github.com/growthbook/growthbook)
16. [Amplitude Docs：Sequential Testing FAQ](https://amplitude.com/docs/faq/sequential-testing)
17. [Amplitude Docs：Bayesian Statistics](https://amplitude.com/docs/feature-experiment/experiment-theory/bayesian-statistics)
18. [Amplitude Pricing](https://amplitude.com/pricing)
19. [LaunchDarkly Pricing](https://launchdarkly.com/pricing/)
20. [LaunchDarkly Docs：Choosing a statistical methodology](https://launchdarkly.com/docs/guides/statistical-methodology/choosing)
21. [LaunchDarkly：October 20 Service Disruption](https://launchdarkly.com/blog/what-happened-what-we-learned-and-how-were-improving/)
22. [Harness Completes Acquisition of Split（官方）](https://www.harness.io/press-and-news/harness-completes-acquisition-of-split-software)
23. [Harness FME Docs：Fixed Horizon vs Sequential](https://developer.harness.io/feature-management-experimentation/use-fme/experimentation/key-concepts/fixed-horizon)
24. [Flagsmith Pricing](https://www.flagsmith.com/pricing)
25. [ConfigCat Pricing](https://configcat.com/pricing/)
26. [Unleash：Moving to AGPLv3](https://www.getunleash.io/blog/unleash-moving-to-agplv3)
27. [Google Optimize sunset（官方）](https://support.google.com/analytics/answer/12979939)
28. [Firebase A/B Testing concepts](https://firebase.google.com/docs/ab-testing/ab-concepts)
29. [AWS：CloudWatch Evidently ending（官方）](https://aws.amazon.com/blogs/mt/support-for-amazon-cloudwatch-evidently-ending-soon/)
30. [AWS：AppConfig experimentation（官方）](https://aws.amazon.com/blogs/devops/running-production-experiments-with-aws-appconfig-experimentation/)
31. [Azure App Configuration：Feature management](https://learn.microsoft.com/en-us/azure/azure-app-configuration/concept-feature-management)
32. [Cloudflare Flagship（官方）](https://blog.cloudflare.com/flagship/)
33. [火山引擎 DataTester](https://www.volcengine.com/product/DataTester)
34. [中原银行 AB 实验平台中标候选人公示](https://www.365trade.com.cn/jfwzb/775230.jhtml)
35. [南航数科 AB 实验产品采购评标公示](http://www.gdebidding.com/nhpbgs/199863.jhtml)
36. [促进和规范数据跨境流动规定](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm)
37. [OpenFeature](https://openfeature.dev/)

---

## 第 4 章 中国互联网公司实验平台

> 本章覆盖字节、阿里、腾讯、美团、滴滴、百度、快手、小红书、B站、京东、网易、拼多多、携程、知乎等公司的公开实践，并标注信息可信度。

## 4.1 中国实验平台全景

中国实验平台的公开图景有一个反直觉特征：**能力最强的几家公司，对外可见的"产品"反而最少**。字节是唯一把内部平台做成对外商品的公司，但对外文档与内部方法论之间有明显落差；腾讯在 VLDB、KDD 上持续输出工业级方法，腾讯云却找不到通用 A/B 产品页；拼多多至今没有一篇可核实的工程博客。这说明中国大厂的实验能力主要不是以"产品"形态沉淀的，而是以**组织内的基础设施 + 论文/专利/白皮书**三种形态沉淀的。只搜产品名会系统性低估这个市场，只看论文又会系统性高估其产品化程度。

公开可验证的组织形态只有三类，且与公司规模无关，与**事业群的数据边界**强相关。

| 路径 | 代表 | 共同特征 | 主要代价 |
|---|---|---|---|
| 公司级大一统 | 字节（Libra→DataTester）、快手（指标底座） | 一套分流/指标/方法服务全公司，再择机对外 | 平台排期成为业务瓶颈；内外节奏冲突 |
| BG 级联邦 | 腾讯（TAB/X/天秤）、阿里（通天塔/Tesla/AirTrack）、美团（图灵/Wedge/BETA） | 各 BG 自建，BG 内收拢，公司层弱治理 | 口径分裂、重复建设、跨平台流量冲突 |
| 能力嵌入产品 | 百度（统计 AB/AI_REC/峙一）、京东（内部体系+增长实验室） | 不追求独立平台品牌，实验作为分析或云产品的一个模块 | 能力浅、难复用；内外两套系统脱节 |

时间上可分三段。**2012–2016 是引入期**，主题是"能分流、能出报表"：字节 2012 年引入 A/B 体系，淘天通天塔 2015 年诞生，天猫 AirTrack 与阿里妈妈 Tesla 在 2016 年公开，携程 2017 年还在用"设备号取模 100"做机票实验。**2017–2020 是中台化期**，主题是"多业务复用同一批流量"：腾讯 PCG 把骡马、阿拉丁、OAS 收敛为 TAB，滴滴 Apollo 支撑每周数千实验，京东开始搭指标与实验的语义层。**2021–2026 是计算与因果期**：微信在 VLDB 2024 公开 BSI 指标计算，字节公开 ITR 与 DQ，美团连发八篇白皮书，快手把 AB 指标搬到 2000 节点 Doris，小红书公开 PreAA 与反转实验。主题不再是"支持多少实验"，而是"**算得准、算得快、算得对**"。

这条线索解释了一个易被误读的现象：**公开度与公司体量不成正比，而与业务形态强相关**。内容与社交公司愿意讲方法（小红书、快手、B站），因为实验对象是"人"，方法可复用、可外宣；交易型公司愿意讲指标口径（京东、美团），因为痛点在口径；广告型公司愿意讲竞价与归因（阿里妈妈、腾讯广告），因为那是收入命脉；拼多多则完全沉默。**公开度是传播策略，不是能力排名**——这是阅读本章所有材料前必须先建立的校准。

## 4.2 字节跳动

字节是中国唯一完成"内部平台→对外商品"闭环的公司，也是"内外双轨"张力最典型的一家。内部叫 **Libra**，对外叫 **DataTester**，同源不同步。字节 A/B 测试技术负责人韩云飞在 AICon 上海 2025 的讲者简介里给出最完整的时间线："内部名称 Libra，对外产品 DataTester……脱胎于 2012 年引入的 A/B 测试体系，2016 年实现产品化，2021 年通过火山引擎开放给企业客户。"[来源](https://aicon.infoq.cn/2025/shanghai/speaker/9508) 这句话澄清了两个常见混淆：DataTester 的商品史只有五年，不是 2012 年就存在；"十多年"指的是内部实验体系，不是对外版本。

规模数字必须带口径引用。

| 时间 | 累计实验 | 日新增 | 同时运行 | 覆盖业务 |
|---|---|---|---|---|
| 2021-11 | 80 万+ | 1500+ | 1 万+ | 500+ 业务线 |
| 2023-06 | 240 万+ | 4000+ | 5 万+ | 数百 |
| 2025-05 | 340 万+ | 未更新 | 7 万+ | 数百 |

2021-11 到 2023-06 的 19 个月，累计从 80 万到 240 万，月均约 8.4 万；2023-06 到 2025-05 的 23 个月，从 240 万到 340 万，月均约 4.3 万。增速在放缓，但这可能是统计口径变化（去重、只计有效实验），也可能是业务进入存量期，**不能简单读作"平台衰退"**。另有一处**存在不同说法**：BytePlus 英文产品页写"累计 150 万+、日增 2000+、同时 3 万+"[来源](https://docs.byteplus.com/en/docs/DataTester/Learn-about-A-B-Testing-Products-DataTester)，与 2025 年的 340 万/7 万明显冲突，合理推测是国际化版本的历史快照或只统计 BytePlus 侧，不建议对外引用。

真正值得自建方细看的是四个工程取舍。第一是**分流键与统计键分离**：分流服务接收 `decision_id`（只算命中、不上报）、`track_id`（只做上报归因）、`attributes`（只参与过滤）三个参数[来源](https://docs.byteplus.com/en/docs/DataTester/Traffic-Shunt-Agent)。原因是"稳定分流"与"准确统计"对 ID 的要求天然矛盾——分流希望 ID 越稳定越好（设备 ID、ssid），统计希望 ID 能跨端合并（登录 uid）。强制用同一个 ID，用户一登录就可能跳组。代价是 ID 映射表变成关键基础设施，映射错乱会产生"分流在 A、上报在 B"的静默错误。

第二是**双层哈希 + 1000 桶**：`hash(did + ":" + layer_name) mod 1000` 定层，`hash(did + ":" + experiment_name) mod N` 定组，salt 用层名/实验名而非随机数[来源](https://docs.byteplus.com/en/docs/DataTester/Basic-Concept)。方案实现简单、跨语言可复现、不需要中心化分配服务，但换来三个硬约束：最小粒度 0.1%，小流量业务做 1% 实验只有 10 个桶；层名/实验名一旦上线不能改，改名即换桶；正交性是**概率意义上**的，字节自己在 2021 年就承认要靠"大量模拟实验 + 系统监控自检，超过阈值就调整"[来源](https://www.doit.com.cn/p/475545.html)。换句话说，正交不是哈希函数的数学保证，而是一项需要持续运营的监控指标。

第三是**层—域—实验的三级治理**：流量层 → 互斥域组 → 互斥域 → 实验；同域组内不同域互斥，不同域组之间正交，域还能嵌套子域[来源](https://docs.byteplus.com/en/docs/DataTester/Traffic-Layer-and-Mutual-Exclusion-Domain)。配套规则很琐碎——已被实验绑定的层不能再绑新域，运行中的实验不能切到已有实验的域——但本质是**用创建时的约束替代运行时的分布式锁**。第四是**三级缓存 + MQ 广播 + 定时全量兜底**：配置落库同时写消息队列，各节点消费 MQ 更新内存与 Redis，另开协程定期全量刷新防止 MQ 故障。这是明确的"牺牲实时性换可用性"：配置晚生效几分钟没人会死，分流报错会直接影响用户体验；代价是配置非强一致，极端情况下几分钟内读到旧配置。

统计能力是字节最需要克制表述的部分，因为**内部方法论不等于对外产品能力**。对外文档能确认的是频率派报告：p 值、95% 置信区间、MDE、核心指标唯一 + 必看指标强制继承、告警支持"仅显著变化触发"[来源](https://docs.byteplus.com/en/docs/DataTester/How-to-Interpret-the-Experiment-Report)、实验前重随机化（最多 3 个指标或按 cluster）[来源](https://docs.byteplus.com/en/docs/DataTester/Enhanced-Shunt-Uniformity)、MAB 智能调优（最短 30 分钟一轮，冷启动每组 >500 人，仅 Ultimate Edition）[来源](https://docs.byteplus.com/en/docs/DataTester/MAB-Multi-Armed-Bandit-Intelligent-Tuning-Experiment)。内部文章披露的则是另一套：CUPED 之上自研 **ITR**（线性模型、决策树、神经网络分别学习实验前后相关性，再用 stacking 学权重），在一条业务线 10 个指标上均有额外方差缩减，最高接近 20%[来源](https://server.it168.com/a2024/1023/6866/000006866793.shtml)；**Parleiden** 把 Leiden 并行化，数小时可对约 1 亿节点、300 亿条边的社交图完成社区划分；**DQ 估计量**用 MDP 式策略评估替代均值差，论文称在抖音把 MSE 降低 99%[来源](https://arxiv.org/abs/2305.02542)。

这里**存在不同说法**：内部文章说这些方法已落地，对外文档却几乎不提 CUPED/ITR/SRM。合理解释有两种——尚未产品化到对外版本，或产品化了但没写文档。无论哪种，采购方都不能假设"买了 DataTester 就有 CUPED"。同理，公开文档里的"实验诊断工具"只回溯近 3 个月分流请求、给出 8 类未命中原因，那是**分流正确性诊断**，不是 SRM 检验；把两者混为一谈是常见的营销误读。

字节的局限也很具体：0.1% 的最小粒度对小业务不友好；服务端"进组不出组"要业务自己实现 `UserAbInfoHandler`（官方给了 Redis 示例），不实现就会在扩流量时跳组；服务端 SDK 能力不均，匿名分流只有 Java/Go/PHP 支持，互斥域只有 Java/Go 支持；Traffic Shunt Agent 官方定性为"单节点、性能等价于单个服务端 SDK，只建议试用和小流量"；实时性是"当天实时 + 次日起 T-1"的 Lambda 型。这些限制拼起来，画像很清楚：**它是一套为超大规模、多业务、强运营场景打磨的工程系统，不是为统计严谨性打磨的分析系统**。

## 4.3 阿里巴巴

阿里的实验体系不能用"一个平台"描述。公开可验证的至少五套：淘天**通天塔**（AB 分析数仓）、阿里妈妈 **Tesla**（分层分流 lib）、天猫 **AirTrack**（端上实验），加上阿里云面向模型/推荐/搜索的 **PAI ABTest、PAI-Rec、OpenSearch A/B**。它们分属不同法人、不同业务域，**不能拼成一个"阿里实验平台"**——这既高估统一程度，也低估各平台的场景约束。

三套内部系统的分流实现差异大到不像同一家公司：Tesla 是 lib 嵌进广告引擎，`hash % 100 + 1` 得 1–100 桶，用 layerID 作离散因子保证层间正交；AirTrack 是端上 SDK 解析一棵 JSON 条件树，用"设备 ID + 条件名称 + 当前节点深度"哈希到 0–10000 后按区间落子树；通天塔则根本不公开分流层，它是分析平台。Tesla 的 `bucketID` 值得单独说：一次请求可能命中多层多个实验，返回 `100_103` 这样的下划线拼接字符串，日志按 `_` 拆开就能还原每个实验。这个设计极其轻量，但要求所有下游模块透传 bucketID，长链路里很容易丢字段。另一个被低估的设计是"**初始化层**"：每个场景第一层存放要全量生效的参数，实验推全时删掉实验、把参数挪进初始化层，避免实验数无限膨胀。需注意一处**存在不同说法**：部分二手资料把 Tesla 的公开时间记为 2017 年，InfoQ 原文实际发布于 2016-09-19。

通天塔的价值不在分流，而在**把 AB 数据做成公共数仓**：2015 年诞生，连续十年支撑淘天算法 AB 分析，接入搜索、推荐、内容、用增、营销等 100+ 场景，能力分三层——AB 数据公共层（线上分流、分布对齐、通用特征、场景 label）、科学评估层（长周期跟踪）、自助分析层（多维即席 OLAP）[来源](https://developer.aliyun.com/article/1672360)。2025 年的 Fluss 改造把实时 AB 的代价讲得很透：原链路 Flink + 集团 TT + Hologres，曝光作业消费 44 个字段却只用 13 个，行存导致约 70% 的 IO 在为不需要的列付钱；成交归因要"排序 + 双流 Join + 24 小时 State"，单任务 State 高达 100TB，Checkpoint 超时、改作业要从 0 点重刷。换 Fluss 列存 + Delta Join 后，State 减免 95TB，CPU/内存实际使用降低 80%+，资源消耗平均降低 30%；2025 年 618 验证流量峰值千万级、平均延迟 1 秒内。这些是工程师自述、无第三方审计，但组件与改造前后对比是硬细节。

阿里真正领先的是**广告实验的方法论深度**。阿里妈妈 2021 年的数据科学系列把指标分成四类（UV 转化率、人均指标、连续型定量指标、比率指标），并区分"不变量"（两组应相同，用于校验分流/埋点）与"变量"（要观察的效应）——这是护栏指标的雏形：不变量异常，先查 SRM/埋点，而不是看 p 值[来源](https://zhuanlan.zhihu.com/p/390417035)。离线抽样那篇完整给了 CUPED（`Z = X - θY`，`θ = Cov(X,Y)/Var(Y)`）、分层抽样、IPW、PSM 的组合[来源](https://zhuanlan.zhihu.com/p/394253252)。这条方法链的意义是**承认广告主层面的实验往往不是随机对照**：运营活动只对消耗达阈值的客户开放，客户是否使用某产品是自选择，此时不能假装是 A/B。

更关键的是它公开讨论了广告实验的四层特殊性。**竞价**破坏 SUTVA——实验组提高出价会改变竞价环境，影响对照组曝光与成本；**预算**是广告主/计划级共享资源，按用户随机会让 A 组消耗挤占 B 组机会，随机单元必须上移；**归因不等于增量**，归因回答"记给哪个触点"，增量回答"没有这个广告还会不会转化"；**长期效应**有 carryover 与 saturation，7 天结论不能推全年。对应的学术输出是 CausalMTA（KDD 2022，用因果推断消除多触点归因中的用户混杂偏差，再做 Shapley 分配）[来源](https://arxiv.org/abs/2201.00689) 与 CausalMMM（WSDM 2024，显式建模渠道投入的时序衰减与饱和效应）。但必须划清边界：**"用分层/域隔离实验"是公开可验证的，"用 switchback 处理竞价干扰"没有公开证据**，只能标为行业通用做法与推断。

产品化是阿里的短板。PAI ABTest 文档更新于 2026-09-09，仍是**邀测发布、功能免费**，仅北京/上海/杭州/深圳四地域，不支持角色 SSO，只能用 RAM 子账号；底层 EAS、MaxCompute、Hologres 单独计费[来源](https://www.alibabacloud.com/help/zh/pai/a-b-experiment/)。OpenSearch A/B 限制更硬：每组最多 20 个实验、最多 10 个同时在线、流量最小粒度 1%、报表 T+1[来源](https://help.aliyun.com/zh/open-search/industry-algorithm-edition/a-or-b-tests)。而 AHAS 的 Feature Toggle 模块在 2024-01-05 停止新购、2025-03-31 正式停服，官方明确说"目前没有无缝替代产品"[来源](https://help.aliyun.com/en/ahas/product-overview/delisting-announcement-of-function-switch-function-module)。这条比任何功能列表都重要：它说明阿里云在"实验相邻品类"上曾有过独立产品，却在 2024–2025 年主动退场。

一句话总结阿里：它证明了"分析面可以比控制面先成熟"，也证明了"控制面不统一，最后每个 BU 一套 bucketID、一套指标口径"。对自建平台来说，先把实验/指标/分流的元数据模型定下来，比先写 SDK 更重要。

## 4.4 腾讯

腾讯是"能力最强、产品最散"的典型。截至 2026-10-18，腾讯云官网没有一个独立售卖的通用 A/B 实验平台产品页；能公开检索到的是 BG 级中台、海外 SaaS 和若干场景化能力。

| 名称 | 归属 | 定位 | 公开状态 |
|---|---|---|---|
| TAB 实验中台 | PCG | 公司级/PCG 级一站式 A/B | 2022 年文章点名；2026 年仍在招相关岗位 |
| X 实验平台 | WXG | 微信全业务：AB/MAB/BO/Interleaving/客户端/社交/双边 | 2023-10 官方技术文章披露 |
| 天秤实验平台 | CDG | CDG 侧实验平台 | 仅 2022 年点名，细节未公开 |
| ABetterChoice | PCG；海外主体 Proxima Beta | 面向游戏出海的仓库原生 SaaS | 官网/文档可访问，在售状态待核实 |
| 广告拆分对比 | 腾讯广告 | 广告主自助 A/B：创意/定向/出价 | 2019 年上线，页面仍在线 |
| IM Push A/B | 腾讯云 | 推送标题/内容两组等比例 | 文档 2026-04-24 更新 |

最重要的一行是 2022 年腾讯大讲堂的原话："PCG 有 TAB 实验平台，WXG 有 X 实验平台，CDG 有天秤实验平台。在 PCG 内部，早期有骡马、阿拉丁、OAS 等实验平台，现在主要是使用 TAB 实验中台。"[来源](https://cloud.tencent.com.cn/developer/article/2156664) 它揭示的路径是"**先有烟囱、再有中台、BG 内统一、公司层联邦**"，与字节"一个平台服务全公司再对外"完全相反。这里**存在不同说法**：2026 年的招聘 JD 写"支持腾讯一站式的 A/B 实验平台建设"，但"一站式"是 JD 话术，是否覆盖 WXG/IEG，公开材料无法证实。

腾讯的护城河不在实验管理 UI，而在**指标计算**与**干扰推断**。指标计算看微信 2023 年的湖仓改造与 2024 年的 VLDB 论文。公开规模是：有效指标 6 万+、大数据计算资源 19 万+ core、存储 25PB+、OLAP 2 万+ core/5.5PB、Iceberg 增量存储 20PB+[来源](https://cloud.tencent.com.cn/developer/article/2346725)。论文要解决的问题是"数万指标 × 数万策略，每个实验算数百指标，每天数百万 CPU 小时、数百 PB 网络流量"，传统 OLAP 的"扫描—聚合"扛不住。解法分四步：日志统一成曝光/指标/维度三张表（分析单元是指标分母，随机化单元是分流单位，**后者必须不低于前者**）；用与分流无关的哈希把分析单元切 1024 个 segment 并行，再用独立哈希把随机化单元切 1024 个 bucket，每桶算一个指标值，等价于 1024 次独立重复，用于估方差/协方差；把 analysis-unit-id 编码到 segment 内固定位置，指标值用 **Bit-Sliced Index + Roaring Bitmap** 表示，加法/比较变成 bitmap 的 XOR/AND/OR，零值被压缩；scorecard 与 CUPED 用 Spark 预计算，即席下钻用 ClickHouse[来源](https://arxiv.org/abs/2405.08411)。论文抽样 5890 个指标，其中 3979 个值域基数 ≤100，这正是 BSI 成立的前提。

代价同样清楚：BSI 只适合非负数值、固定查询范式；1024 桶对极小流量实验不够稳；Spark 预计算意味着"今天看昨天"；湖仓本身还有元数据与小文件成本——腾讯自己列过 2 万实验 ID、180 万分区、HDFS 8 亿 metadata 上限、Merge Into 写倾斜这些坑。湖仓改造的收益是：20PB 历史数据迁移，计算核时优化 69.4%、节省约 20 万核时/天，存储优化约 100PB，年化降本约 3800 万元，p99 耗时降 70%。这些是官方自述，未见第三方复核，但方向与论文一致。

分流侧最硬的证据是 2019 年申请、2021 年授权的专利 CN110830234B：每个实验有**各自的哈希种子**，对用户标识哈希后归一化映射到全流量区间，每个对照实验按"流量比例 + 起点"划分子区间，流量比例可以随时间变化[来源](https://patents.google.com/patent/CN110830234B/zh)。它解释了一个常被忽略的工程点："按比例分流"不是简单取模，而是"归一化 + 区间命中 + 独立盐值"——独立盐值保证正交，归一化保证均匀，区间起点保证扩量时老用户不跳组。ABetterChoice 把上层结构写得更清楚：Global Domain → Domain → Multi-Layer Domain / Exclusive Layer；多层域共享流量池、层间用独立种子正交，互斥层内每个实验占不同桶段。

统计栈以 ABC 文档为样本：频率派双侧 CI + Delta Method 算相对变化，p 值 α 默认 5%，功效默认 80%；CUPED 默认开启，文档举例"原本 12 天，可能 5 天得出结论"；同时看 3 个以上指标时建议开 FDR；另有贝叶斯后验、SRM + AB Backtrack、HTE[来源](https://docs.abetterchoice.ai/guide/experiments/stats-engine-and-validation)。更前沿的是 CIKM 2024 的 **Soptima**：把序贯检验与"淘汰型 MAB"结合，支持多臂与通用奖励类型，在保持 Type-I/II 错误率与最优臂识别保证的同时动态调流量。作者与腾讯流量调整专利的发明人重合，基本可判断是平台的技术输出，但论文未明写"腾讯生产环境"，只能标"作者关联腾讯，部署范围待核实"。

真正让腾讯区别于其他中国公司的是**干扰推断**。微信是全世界最适合研究网络干扰的场景之一：10 亿+ 用户、数千亿条边，每天数千个实验，其中数百个涉及网络干扰。当一个新功能只在部分用户生效，效果会通过分享、评论、共同好友扩散到对照组，传统 difference-in-means 估的是"部分暴露效应"，不是"全量上线效应"。腾讯的解法不是造完美社交图，而是承认只能拿到**替代网络**：保留过去 28 天有特定社交互动的边，把 10 亿节点、千亿边的图稀疏化，再用 pseudo-inverse 估计 TTE，并在 5000 万+ 用户的真实微信实验中把 pseudo-inverse 与均值差结合，用来**检测**干扰是否存在[来源](https://arxiv.org/abs/2408.04441)。KDD 2025 的后续工作进一步利用用户对之间的二元数据构造 dyadic-robust t 统计量，并给出子采样、实验前分层随机化、实验后用户级+二元级控制变量等工程手段[来源](https://doi.org/10.1145/3711896.3736906)。取舍很清楚：Bernoulli 简单、实验多、流量复用高，但强干扰下偏；Cluster 减偏，但簇内相关放大方差；饱和设计能估溢出，但要专门流量结构。微信选的是"日常 Bernoulli + 事后检测/校正，重点实验用 cluster/双边"，比 Meta 的"cluster + network exposure"更偏低成本、可规模化。

最后一句判断：腾讯不是没有能力，而是**能力被组织边界切碎了**。论文/专利水平不低，但腾讯云找不到通用 A/B SKU——这不是技术问题，是"谁为跨 BG 的统一买单"的组织问题。

## 4.5 美团 / 滴滴 / 百度

把这三家放在一起，不是因为相似，而是因为它们演示了同一条规律：**平台形态由实验单元与干扰结构决定，而不是由技术栈决定**。美团的单元最杂（用户、订单、商家、AOI、城市、骑手），所以必须做配置模型与方法库；滴滴的单元最粗（城市、区域、30 分钟时间片），所以必须做时空设计与干扰建模；百度的单元最轻（设备、流量），所以工具可以做得简单。

**美团**公开的是"图灵（到家履约）+ Wedge（到店广告）+ BETA（分析引擎）"的联邦，没有覆盖全公司的统一平台名。最值得研究的是 BETA 的定位：它把**实验设计、配置、流量分配、数据生产**与**实验分析**解耦，分析引擎只依赖标准化实验数据集（含单元、分组方法、周期、指标元数据）[来源](https://tech.meituan.com/2024/09/09/New-Generation-Analysis-Engine-Driving-Data-Decisions.html)。流水线固定为：数据可靠性验证（同质性、SRM、样本量）→ 预处理（3σ/IQR 异常值）→ 效应估计（差值、DID、回归）→ 方差估计（Delta/Bootstrap/聚类调整 + CUPED）→ P 值 → 报告。治理上有一条极硬的规则：**每种显著性检验方法必须经过 AA 模拟验证才能上线**，分组支持"不同质时系统重分组，最多 5 次"。

几个数字值得记住。CAR（协变量自适应分组）在样本少于 40 时，完全随机的不同质比例可超 6%，CAR 可稳定控制在 5% 以下，官方称至少 10 个样本也能取得有效同质性。CUPED 在合适场景下方差可降约 50%，并针对比率型指标（如人均完成单量 = 订单量/完单用户数）提出二元同系数 CUPED。Switchback 的典型设计是"14 天里随机 7 天实验、7 天对照"，彻底消除同城两组间的空间溢出；配对轮转把城市切成两个相似半城，每天随机一个做实验、另一个做对照，用"半城交界处轻微溢出"换"消除天与天差异"；随机饱和设计则给每簇随机分配不同实验组比例，利用"高饱和簇对对照组溢出更强"识别真实效应与溢出效应。

美团公开的最有价值的不是方法，而是一个反例：**分析单元比分流单元更细、却用错方差公式时，真实无提升的实验被误判"显著有效"的概率接近 50%**。这句话应该贴在每个自建平台的评审室里——它不是统计学的边角问题，而是会直接导致错误上线的工程问题。

**滴滴**的 Apollo 平台公开规模是 6000+ 并行实验/周（2020 年口径），支持在线与离线实验，分组有随机与时间片，分析覆盖基础/率/均值/留存指标，手段含均值检验、VCM、Bootstrap[来源](https://zhuanlan.zhihu.com/p/147203168)。它的特色是分组算法从 CR 到 RR 再到 Adaptive（CAR）的演进：

| 分组方法 | 组间最大差异 | 机制 |
|---|---|---|
| CR（完全随机） | 可达 14% 以上 | 一次哈希取模，小样本不稳定 |
| RR（重随机） | 可控制在 2.7% 以下 | 反复重跑取最优，用算力换质量 |
| Adaptive（CAR） | 95% 情况下 0.8% 以下 | 逐样本分配，兼顾配额与指标分布 |

这组数字来自 1 万司机、7 日 GMV/在线时长/全兼职、每种方法跑 400 次，不能外推，但量级足以说明"交易型平台的小样本分组不能只靠哈希"。代价是 CAR 破坏简单随机性，后续方差估计不能直接套两样本 t 检验；而且**已按 CR 分流完的实验无法重新均衡**——分组算法必须在分流前介入。

滴滴真正的方法论贡献是时空实验。其 AI Lab 参与、2024 年刊于 JRSS-B 的论文给出两种设计：时间交替（实验 14 天，策略每 30 分钟交替）与时空交替（把城市切成 r 个不重叠区域，每区独立随机初始策略，再在时间上交替；论文在 C5 把城市分成 17 个区域，同样 14 天、30 分钟一个时间单元）[来源](https://arxiv.org/abs/2202.10887)。方法论核心是 VCDP：允许潜在结果依赖本区策略历史、状态变量和邻居区策略，把 ATE 分解为直接效应（DE）与间接效应（IE）。论文的洞察很尖锐：双边市场里"策略通过改变司机分布间接影响邻近区"本身就是决策的一部分，只看总体效应，会把"抢了邻居的订单"误判为增长。

**百度**的公开材料最薄，但恰好演示了"能力嵌入产品"的形态。对外有三条线：**峙一**（2018-11-15 上线，官方称每年完成上千个上线评估、累计影响 PV 约 10 亿，可科学抽样、流量在线调整即时生效、按城市/性别/年龄生效）[来源](https://ziyuan.baidu.com/wiki/2727)；**百度统计 AB**（同层互斥、跨层正交，但层数上限 5 个，分流主体只有设备 ID）；**智能云 AI_REC AB**（2024-05 上线，核心指标决策、辅助指标判断其他影响、功效默认 80%、显著性默认 95%，流量计算器"仅供参考"）[来源](https://cloud.baidu.com/doc/AI_REC/s/Flw4scq90)。AI_REC 是这组里少见的公开定价：SaaS 基础套餐按 QPS 包年包月，5–20 QPS 为 1000 元/QPS/月，21–80 超出部分 700 元/QPS/月，官方示例 50 QPS ≈ 4.1 万元/月。

峙一的现状必须打问号：公告页 2026 年仍可访问，但搜索资源平台现行导航已看不到"峙一/功能实验室"入口，也没有停服公告。因此只能写"2018 年上线，2026 年是否仍在售/已下线待核实"，**不能写"已停服"**。百度还有一件专利值得注意：CN115391184B 把 A/B 流量各拆成至少两个子组、交叉配对出至少四对子组，做多次对比检验并做 P 值校正。这说明百度在"小样本、多比较"的统计设计上有积累，只是没有产品化到对外文档里。

## 4.6 快手 / 小红书 / B站 / 京东 / 网易 / 拼多多 / 携程 / 知乎

这一组公司的公开材料呈现出清晰分工：**内容社区讲方法，电商讲口径，实体交易讲分流算法，而拼多多什么都不讲**。

**快手**把实验平台做成了"公司级指标计算底座"。公开材料几乎不讲实验设计 UI，全在讲怎么把 AB 报告算快：分流表 × 指标宽表按 UID 做 Colocate Join，单 Bucket 扫千万级数据先过滤约 95% 无效数据；Local Distinct Grouping Sets 把去重下推本地，代价是约 6 秒 Barrier；分流判定 UDF 从 Java 改 C++ Native 后，模板整体再快约 3 倍。规模是 5 FE + 2000 BE、10 万 CU、12 个逻辑计算组、单日扫描 40TB/千亿行、日均几十万任务，核心指标模板从 21 分钟压到最大 145 倍提速、资源消耗下降 72%[来源](https://www.selectdb.com/blog/1719)。要提醒：145 倍是特定模板、特定优化组合下的最大值，**不是任意查询的普遍提速**；且这套优化成立的前提是"AB 模板长期稳定"，模板不稳定的公司抄不了。快手的分流是"按日志回放实验命中"的离线判定模式，好处是补数/回溯方便、分流逻辑可版本化，代价是分流结果要落表、配置变更后历史表要重算。统计方法几乎未公开。2026 年 8 月的 **A/B Agent** 是更值得关注的信号：分层经验树 + 实验树 + 护栏惩罚效用函数，论文称短视频电商推荐场景五轮演化后购物车 GMV +4.829%、GPM +4.677%、所有护栏为正[来源](https://arxiv.org/abs/2608.04625)。这是论文宣称、单一场景，但它指出下一个瓶颈是"实验解读与下一轮策略生成"，而不是再快 10 倍。

**小红书**是八家里公开方法论最完整的。分流上，实验 SDK 内置在推荐服务里，定期拉配置、本地判定、本地打点，不是每请求调远程服务；代价是配置 staleness 与多版本 SDK 兼容。治理上，它把实验变更当线上变更管理：高峰期变更要审批，灰度支持服务维度与不同机房按比例，变更后用质量指标"打灯"——红灯强制卡点、绿灯自动生效、黄灯人工介入[来源](https://zhuanlan.zhihu.com/p/715370120)。这套机制的意义是**把实验平台接进了发布系统**，这是成熟度的重要标志。

小红书最有价值的分享是对"AA 不齐"的处理与自我警告。朴素做法是跑真实 AA 挑差异小的组，但要等 2–3 天、能试的组数有限；他们做**回溯 AA（PreAA）**，用历史数据多次遍历分流、尝试不同哈希种子，生成多套虚拟分组让实验同学挑最均衡的一套。但分享者明确讲了三个坑：选组会带来样本偏倚（总是挑"好看"的分组，下周指标可能仍"好看"，但那是选择偏差）；PreAA 选组后不能用普通 t 检验，正确的显著性计算非常贵、工程上难落地；"平"太难，指标越多成功率从千分之一降到万分之一。他们的结论是"有了 CUPED 就不需要额外选组"。还有一个非常诚实的数字：留存类指标 LT28（28 天内来访天数）**假阳率一度超过 50%**，消费类指标通常只有 10% 左右，难提升的指标甚至可能接近 70%。

解法不是把单个实验做大，而是"打包结算"：层域模型隔离约 10% 纯净流量，在其中圈垂直打通层，让这批用户吃到每一个推荐策略，另有"推全层"可无视预留流量；父子实验支持二层打包；再用 **LR + Reverse** 保留一小股反转流量，大盘异动时遍历反转实验定位"是谁拖累的"，同时用正向/反向两个观察点是否一致来测算假阳率。代价是流量切碎、单策略样本变少、打包周期长（双月）、策略累积可能把小误判叠成大偏差。数据侧则是千亿日志、每天上千活跃实验、5 分钟 + user_id 粒度的 DWS、P90 < 10 秒、资源为旧实时方案的 36%、实时/离线差异 <1%。

**B站**是"零件齐全、整机不可见"。2023 年 12 月公开的专利给出"层—组—任务"三级模型：预先配置实验层与每层实验组，配置若干 AB 测试任务并记录任务与实验组的关联，把用户分流到实验分组后按关联找目标任务执行。这解决的是多业务复用同一批流量，任务不直接绑流量而绑"层里的组"。GitHub 上确有 `bilibili/abtest` 仓库（Apache-2.0，描述为 C++/Java/Go 的分层实验框架），但创建与最后 push 都是 2019-11-13、约 14 stars、README 只有一行标题[来源](https://github.com/bilibili/abtest)，基本可判定是早期骨架而非生产平台开源。数据底座"北极星"倒是很实：北极星、标签画像、AB 实验人群包都基于 ClickHouse 的 RoaringBitMap，日行为数据数千亿行、日增约 10TB，事件分析平均 2.77 秒、漏斗 0.58 秒、整体平均 3.4 秒；属性字典服务压测支持 50 万 QPS[来源](https://www.bilibili.com/read/cv21106590/)。这意味着 B站实验平台不是孤岛，但上游依赖很重。

**京东**的强项是"实验数据工程"，不是统计创新。京东零售当天在线实验量可达万级，主要矛盾是数据链路生产效率与口径一致性。它把数据要素拆成四块：分流维表（用维表关联事实表而非只靠埋点，且**不能用 Inner Join**，否则破坏两组同质可比）、单实验单算、累计统计（既累计行为也累计进组，因为实验组转化更好会导致次日进组用户因复购差异偏移）、指标继承（事实表、过滤逻辑、聚合方式必须同源）[来源](https://zhuanlan.zhihu.com/p/10465095421)。工程上用"数据编织"把指标平台和实验平台接起来，实验订阅指标后系统自动完成关联、变宽/变高、当天/累计策略分裂、统计量计算，多个实验路由到同一逻辑表时用"实验 ID 列表"把 N 个任务合并成 1 个。公开进展是 **60% 的指标可以通过实验订阅驱动自动计算**，交付效率从周级提升到天级。这个 60% 比"支持多少种实验类型"更有含金量。

京东对外还有过一个"增长实验室"，技术文章把分流讲得很细：uuid + 实验种子 → 强一致哈希 → 取模 100 → 0–99 桶位，1 桶 = 1% 流量；调整版本比例时先识别"比例减少"的版本，从其桶位区间**最右侧**拆出需要让出的桶，再从左到右分配给"比例新增"的版本。文章举的反例很典型：VA=10%、VB=10%、VC=80% 扩到 20/20/60 时，若简单重划，原本在 VB 的 11–20 号桶用户会被挪到 VA，发生跳组[来源](https://testerhome.com/column_channels/38235)。但截至 2026-10-18，京东云产品页 `/cn/products/growth-lab` 已无法访问，站内也没有明确在售页面，因此**既不能断言停服，也不能断言在售**，只能写"公开入口与报价不可得，生命周期待核实"。

**网易**同时公开了电商与内容两套平台，方法互补。严选把 AB 拆成六阶段，解法是"实验前—实验中—实验后"三段式：实验前给最小样本量预估，实验中把分流逻辑从业务代码接管到平台、埋点自动化、指标口径统一，实验后报表自动化并给显著性/置信区间。统计细节很实在：最小样本量用 Z 分布公式，1%→2% 约需 2000+ 样本，1.1%→1.2% 约需 17 万样本；显著性标准是 p<0.05 且功效 ≥80%；分流借鉴 Google 流量模型，同层互斥、跨层正交。业务结果是支撑数千次实验、有效决策比例超 40%、平均周期缩短到 3–7 天[来源](https://zhuanlan.zhihu.com/p/587995471)。云音乐"天秤"则是 SRM 治理的教科书：SRM 归因分五类（分流算法不随机、流量分配不科学、实验前用户状态偏差、策略/漏洞影响留存、日志漏报错报、风控误伤），对比 murmurhash、md5、bkd 后选 murmurhash，把单次分流不均匀概率控制在 5% 以内；推荐等比例分配与等比例扩缩量，因为两组比例相等时指标方差最小；提供天级/小时级样本监控，任一维度卡方检验不通过就高亮告警。统计上还有 Bonferroni（检测次数少时）与 BH（检测次数多时）、CUPED、共享对照组[来源](https://zhuanlan.zhihu.com/p/641222646)。这套材料的价值在于它把很多平台只写在文档里的东西讲到了实现细节和踩坑。

**拼多多**是纯黑箱。截至 2026-10-18，没有找到官方工程博客、技术公众号、大会演讲、产品名、开源项目或可核实的架构与规模数字。唯一能做的推断是：其业务以商品、价格、活动、推荐为核心，实验单元很可能不只用户，还包括商品/店铺/活动，组织风格偏"强运营 + 快速迭代"。但这是从业务形态反推，**没有任何公开材料能证明**。在竞品分析里，拼多多应标为"黑箱"而不是"落后"。

**携程**的材料跨度很大，恰好展示了一代人的演进。2017 年机票 ABT 是"端上拉配置 + 设备号取模 100 + ABCD 做 AA"：App 启动时公共框架拉取所有线上试验号和版本存本地，进入频道触发本地实验号并打 trace 埋点；分流用"设备号 + 试验号 + 随机数"组成 N 位数对 100 取模，按 10:70:10:10 分 ABCD，A 为兜底；AA 设四版，ACD 为旧版、B 为新版，C/D 各为 B 的一半，先比 C/D 再比 B 与 ACD；经验法则是单页面同时在线实验不超过 7 个（Magic Number 7）；分析靠 CR、收益与趋势图，p 值"一年也没怎么用"[来源](https://zhuanlan.zhihu.com/p/25685006)。这段材料今天看很"土"，但真实反映了当时的水平，问题也清楚：随机数参与哈希可能破坏同设备稳定进组、端上拉全量配置有体积与版本兼容隐患、没有 SRM 与 CUPED。

2025 年火车票团队面对的是完全不同的问题：实验单元不是用户，而是酒店商户。酒店数量不超过 100 万，销量/曝光马太效应明显，同地区酒店用户流量交叉严重。直接哈希有三个问题：高单价酒店可能集中到实验组导致 GMV 结论错误；非用户实体数量少，实验期间分组要固定且实验前后要相似；同一用户可能同时看到实验组和对照组商户。解法是三个可插拔模块：分区随机抽样（按类目/价格段交叉分层，层内按指标排序等距分桶）、贪心交换（只在同一交换桶内枚举样本对，计算"最大相对差异"下降量）、图贪心分流（用历史"用户—商户"曝光构建加权图，Louvain 做社区发现，把高频共现商户打包成新分流单位，再对新单位贪心交换，最后还原到原始商户）。实证结果：分流通过率从先验随机的"需重试 200+ 次"提升到图贪心的 90%+，模块度从约 0 提升到约 0.3，UV 交叉率从 60% 降到 40%[来源](https://cloud.tencent.cn/developer/article/2536676)。注意 40% 仍然不低——图算法只是"降低"不是"消除"。

**知乎**的公开材料在数据层：AB2.0 早期基于 ClickHouse 预计算，痛点是预计算资源消耗大、多表 Join 能力有限、已有指标无法复用；新架构让 Hive 只负责进组用户落表与指标加工，通过 Broker/Stream Load 写入 Doris，平台直接对 Doris 做即席查询；表设计用前缀索引、zstd 压缩、Colocate Join、AGG 模型；功能上用 bitmap 做滑动窗口、指标拆解、SQL 合并、缓存加速。效果是查询耗时降低 35%、P99 降幅 60%，进组用户表达百亿级[来源](https://www.sohu.com/a/848315597_121665362)。分流与统计仍然模糊。

八家的公开成熟度可以排一张表，但必须强调：**这是"公开可验证信息"的成熟度，不是能力排名**。

| 公司 | 公开平台名 | 架构公开 | 统计公开 | 规模证据 | 公开成熟度 |
|---|---|---|---|---|---|
| 小红书 | 小红书实验平台 | SDK 分流 + 数据链路详细 | PreAA/CUPED/反转/假阳率 | 千亿日志/千级实验 | ★★★★★ |
| 快手 | 未公开专名 | 指标计算层很详细 | 少 | 2000 节点/10 万核 | ★★★★☆ |
| 京东 | 内部未公开；增长实验室状态待核实 | 数据编织 + 桶位/流量保护 | 统计量计算，缺检验细节 | 万级实验/日 | ★★★★☆ |
| 网易 | 严选平台；云音乐天秤 | 两套都较详细 | p 值/功效/CUPED/多重检验/SRM | 严选数千实验 | ★★★★☆ |
| 携程 | ABT/UBT；统一平台名未公开 | 端上分流 + 图分流 | t 检验/AA/最大相对差异 | 机票每周数十实验 | ★★★☆☆ |
| 知乎 | AB2.0 | 数据层详细 | 少 | 百亿级进组表 | ★★★☆☆ |
| B站 | 未公开 | 分层专利 + 北极星底座 | 少 | 千亿行/日 | ★★☆☆☆ |
| 拼多多 | 未公开 | 无 | 无 | 无 | ★☆☆☆☆ |

这张表最重要的结论不是排名，而是**内容社区与电商的实验平台不是同一套产品改个皮肤**。内容社区的对象是"人"，样本大、哈希分流够用，难点在指标不敏感（留存、时长）与实验间干扰，所以要 CUPED、打包、反转、长期 holdout；电商的对象经常是"商品/商户/酒店"，样本小、特征集中、实体关联强，哈希会不均衡、会流量交叉，难点在预分流、实体打包、口径一致，所以要分层抽样、贪心交换、图社区发现、数据编织。把小红书的"打包 + 反转"直接搬到交易型业务，大概率水土不服。

## 4.7 横向对比：组织、架构、统计、场景

把前面所有材料压到四个维度上，能看到单看任何一家都看不到的规律。

**组织：三种"统一"，多数公司只做到第一种。** 统一可以发生在入口层（一个控制台）、元数据层（一套实验/指标/分流定义）、口径层（指标分子分母与去重逻辑一致）。字节做到了元数据层，所以能内外融合、按 DDD 拆 8 个子域；腾讯停在入口层之下、BG 层之上，TAB/X/天秤各自实现分流、指标、权限，跨平台实验的全局互斥与流量预算很难做；阿里连入口层都没统一；美团最接近"方法统一、入口分散"，BETA 作为方法中心被多平台调用。一个可检验的判断是：**当公司出现第二个实验平台时，真正的分水岭不是"要不要合并"，而是"指标定义归谁"**。指标定义不统一，合并只会得到"统一登录页 + 各自后台"。

**架构：分流求值位置分四类，各有不可替代的场景。** 端上本地求值（字节客户端 SDK、小红书、天猫 AirTrack）解决开屏/弱网/时延，代价是配置 staleness 与多版本兼容；服务端 SDK 本地求值（字节、PAI ABTest、PAI-Rec）解决低延迟与一致性，代价是元数据刷新延迟与"进组不出组"要外部存储；lib 嵌入（阿里妈妈 Tesla）接入简单、不增加运维，代价是升级跟业务发版、跨语言差、故障隔离弱；仓库/离线回表（快手、ABC、京东、知乎）指标口径与分组解耦、补数方便，代价是存储与重算成本。桶数也不统一：Tesla 100、DataTester 1000、AirTrack 10000、微信 1024、PAI-Rec 100、京东 100。**桶数不是越多越好**——它要和最小可实验流量、样本量、计算成本一起定，且一旦定下不能改。

**统计：底座高度收敛，加码方向分叉。** 收敛的是随机化 + 假设检验 + 置信区间 + MDE/功效 + SRM/AA + 多重比较，几乎所有公开平台都有。分叉在方差缩减与干扰处理：

| 能力 | 公开确认在用的公司 | 备注 |
|---|---|---|
| CUPED | 字节（内部）、美团、腾讯、滴滴（论文侧）、网易云音乐、小红书 | 已近事实标准；比率指标需 Delta 或二元 CUPED |
| 模型化方差缩减 | 字节 ITR、快手 CUPAC、美团二元 CUPED | 均缺完整 A/A 校准，应默认关闭后按指标开放 |
| 序贯检验 | 腾讯 Soptima（论文）、ABC（文档）；其余多数未公开 | 中国平台公开度显著低于欧美 |
| 贝叶斯 | 腾讯 ABC（可选）、字节 MAB（贝叶斯优化，非 A/B 推断） | "支持贝叶斯"必须限定模块与默认值 |
| SRM 产品化 | 网易云音乐、腾讯 ABC、美团 | 多数平台只有"命中诊断"，不是 SRM |
| 多重比较 | 网易（Bonferroni/BH）、美团（自动）、百度（专利子组交叉校正） | 公开实现细节的只有网易 |
| 干扰/聚类 | 字节、腾讯、美团、滴滴、快手 | 中国公司在此明显领先欧美公开材料 |

最后一行值得展开：**中国公司对干涉效应的投入，明显高于欧美公开材料**。原因不神秘——微信/抖音是社交网络，美团/滴滴是双边市场，快手是社交+内容，这些业务形态逼着平台处理 SUTVA 失效。字节把干涉分成"直接干涉（社交溢出，低估效应）"与"间接干涉（资源竞争，高估效应）"，分别用社群聚类与 DQ 处理；抖音私信案例中用户级分流的跨组私信占 50%，社群分流后降到 1%；高清视频案例中真实效应 -0.5%，朴素估计 +2.95%，DQ 估计 -0.49%。这些数字比任何"支持聚类分流"的功能描述都更有说服力。

**场景：随机化单元是一张必须提前填的表。** 把六类场景压成矩阵，基本可以作为自建平台的需求输入。

| 场景 | 典型单元 | 主要干扰 | 首选设计 | 常见错误 |
|---|---|---|---|---|
| 内容推荐 | 用户/设备 | 推荐链路层层叠加、策略互相稀释 | 用户级 + CUPED + 打包/反转 | 用单实验 p 值判断低灵敏度指标 |
| 社交 | 用户/社群 | 分享、共同好友、内容扩散 | 社群聚类 + 父子实验 + 事后检测 | 用户级随机后直接外推全量 |
| 双边市场 | 城市/区域/时间片 | 供给重分配、跨区溢出 | switchback / 时空交替 / VCDP | 按用户随机做派单或定价 |
| 交易/履约 | 城市/AOI/站点/订单 | 骑手跨区、库存共享、公平性 | CAR + 半城配对 + 饱和设计 | 分析单元细于分流单元却用 t 检验 |
| 广告竞价 | 广告主/计划/时间片 | 竞价均衡、预算耦合 | 广告主级抽样 + 分层 + PSM/CUPED | 用户级 A/B 做出价实验 |
| 游戏经济 | 服务器/赛季/匹配池 | 交易行、公会、通胀 | cluster / switchback + 长期护栏 | 用户级随机 + 只看 7 日留存 |

这张表也解释了为什么"买一个通用 SaaS"很难满足交易型公司：商业产品的默认假设是"用户级随机 + 独立个体 + 固定 horizon"，而这张表里超过一半的场景不满足这个假设。

## 4.8 对中国企业的启示与信息缺口

把中国经验压缩成可执行的原则，大约是八条。它们不是口号，每一条都对应一个会被踩到的坑。

**第一，先建"实验单元注册表"，再谈分流。** 平台必须能声明：分流单元是什么、分析单元是什么、两者是否一致、不一致时用什么方差（Delta/聚类/Bootstrap）、干扰边界在哪（同城？同商圈？同商家？）。美团"分析单元细于分流单元、假阳性接近 50%"的反例说明，这不是学术问题，而是会直接导致错误上线的工程问题。注册表还应固定"分流键一旦选定，实验中途不能换"。

**第二，身份图是超级 App 的地基。** 一个用户可能从 Feed、搜索、直播间、小程序、Push 五个入口进入同一实验，设备 ID、账号 ID、手机号、OpenID 的映射还不一致。字节的 `decision_id`/`track_id` 分离是这个问题的一个优雅解，但代价是映射服务本身要成为高可用基础设施。对 DAU 千万级的公司，最划算的投资不是"支持更多实验类型"，而是把身份图与单元层级做成平台级元数据。

**第三，指标语义层要先于实验平台。** 微信的 BSI、快手的 Doris 模板、京东的数据编织、美团的 BETA，本质上都在解决同一件事：让"指标口径、聚合层级、方差计算"成为平台能力，而不是每个实验者写 SQL。京东 60% 指标自动计算、网易严选的指标注册、小红书的指标结构化，都是这条路上的里程碑。没有指标语义层，实验报告就是一次性 SQL 的堆叠。

**第四，分流必须是纯函数、可复现、带版本。** `hash(unit_id + experiment_salt + layer_salt) % buckets` 应作为契约，salt 与配置版本一起存档。小红书的 UDF 复算、京东的"uuid + 种子 + 取模 100"都是这个思路。衍生要求是：扩量时只从缩量组/对照组拿桶，绝不碰其他实验组已占用的桶——京东的"流量保护"是低成本高收益的设计，代价是区间碎片化，需要控制单实验调整次数。

**第五，统计门禁要产品化，而不是写进规范。** 具体是四件事：新方法上线前必须跑 AA 模拟验证（美团）；SRM 自动检测并按维度告警（网易云音乐）；多指标/多组自动多重比较修正（美团、网易）；护栏指标默认继承、显著变化才告警（字节"必看指标"）。这四件事的收益远大于"再做一个酷炫的报表页"，因为它们把统计素养的要求从"每个实验者"转移到了"平台默认值"。

**第六，干扰工具箱按业务形态选，不要一律聚类。** 社交网络优先"社群聚类 + 父子实验"；双边市场优先"cluster/switchback + DQ 或 DID"；地理业务优先"区域聚类 + 半城 DID/合成控制"；广告优先"竞争隔离 + 广告主级抽样"。聚类不免费：有效样本变少、簇内相关放大方差、残余溢出仍在。务实顺序是先小流量做"用户级 vs 社群级"父子实验，比较两套估计，差异不显著就继续用户级。

**第七，实时性要分层。** 合理分层是 L0 曝光/分流毫秒级（SDK 本地求值）、L1 核心指标秒–分钟级（Flink/Fluss/Doris 微批）、L2 归因指标小时级（湖流一体、离线回刷）、L3 实验结论天级。淘天通天塔的教训是实时 AB 的瓶颈在"排序 + 双流 Join + 24 小时归因"的 100TB State，不在 SQL 算得慢；快手的教训是千亿行级别的自建平台，真正的工作量在数据库内核与元数据治理，不在实验 UI。中小团队优先"分钟级微批 + 离线回刷"。

**第八，合规要前置到实验设计。** 个保法第 24 条禁止对个人在交易价格等交易条件上实行不合理差别待遇，算法推荐管理规定第 21 条同样禁止价格歧视；个性化定价、差别权益、敏感人群实验应先做 PIPIA 与法务评审，价格实验要留"非不合理差别待遇"证据，推荐实验保留非个性化对照组。合规不只改文案，它会改变随机化单元与识别策略。

另有一条组织经验值得单独写：**平台 KPI 不应只是实验数量，而应是"可信实验占比"与"问题到结论的周期"**。美团的"三方分工"（数科定方法与模板、数仓保指标口径、工程建管道）之所以可复制，是因为它明确了"谁对实验可信度负责"；腾讯的联邦式之所以代价高，是因为每个 BG 都要自己回答这个问题。没有嵌入式数据科学家，平台会退化成"分桶工具"。

信息缺口需要被当成结论的一部分，而不是脚注。

| 缺口 | 具体缺什么 | 影响 | 建议核实方式 |
|---|---|---|---|
| 拼多多 | 平台名、架构、分流、统计、规模，全部 | 无法做有效对标 | 行业访谈、招聘 JD、专利检索 |
| 字节对外统计 | CUPED/ITR、SRM、多重比较、Holdout 是否交付 | 直接影响采购估值与 POC | 厂商演示 + 合同功能清单 |
| 阿里 Tesla/AirTrack | 2016 年后是否改名、是否仍用 lib | 无法判断广告实验当前形态 | 阿里妈妈技术号、专利续期、JD |
| 腾讯天秤/TAB 边界 | 天秤是否仍存在；TAB 是否真"一站式" | 影响对"联邦程度"的判断 | 腾讯招聘 JD、内部技术号 |
| 美团规模 | 实验数量、DAU 覆盖、平台用户数 | 只能判断方法强弱 | 白皮书后续篇目、QCon |
| 百度内部平台 | 平台名、分流、统计方法 | 只能确认"有实践" | 搜索团队论文、专利、校招 JD |
| B站/知乎/携程 | 分流服务、统计引擎、实验规模 | 只看到"零件" | 专利全文、技术号、Doris 案例 |
| 京东增长实验室 | 是否在售/停服/改名 | 对外状态不确定，不能写报价 | 京东云销售确认、页面快照 |
| 快手统计 | 检验类型、CUPED/序贯、SRM | 只能判断"指标计算强" | 后续分享、A/B Agent 论文附录 |

如果要把这些缺口转成一次尽调，最有效的八个问题大概是：CUPED 是默认开启还是可选？比率指标怎么处理？SRM 是自动检测还是只做命中诊断？多重比较用什么方法、什么条件触发？序贯检验的 alpha 如何分配？Holdout 的流量口径与统计方法是什么？私有化与 SaaS 的功能差异清单在哪？分流服务的 SLA 与降级策略是什么？这八个问题，比任何功能对比表都更能区分"有平台"和"有 PPT"。

最后回到一个判断：中国经验里最值得抄的，不是某个架构（BSI、Doris、Fluss 都强依赖各自的业务形态与团队规模），而是**把统计可信度做成产品默认值的制度**——必看指标自动继承、AA 不通过不许上线、SRM 异常自动标红、扩量只动自己的桶。这些设计不炫技，但它们决定了一个实验平台在第三年还能不能被业务信任。

---

**参考来源**

1. [AICon 上海 2025：韩云飞《AI 时代实验平台演进之路》](https://aicon.infoq.cn/2025/shanghai/speaker/9508)
2. [InfoQ：一年 40 万次实验，字节跳动 A/B 测试平台是怎么炼出来的（2021-09-26）](https://www.infoq.cn/article/T7HCVlTeUCSroDRhT1FF)
3. [IT168：抖音集团实验平台的边界拓展（2024-10-23）](https://server.it168.com/a2024/1023/6866/000006866793.shtml)
4. [e-works：火山引擎实验平台微服务架构（2024-07-19）](https://news.e-works.net.cn/category802/news115463.htm)
5. [BytePlus Docs：Basic Concept（双层哈希、1000 桶）](https://docs.byteplus.com/en/docs/DataTester/Basic-Concept)
6. [BytePlus Docs：Traffic Layer and Mutual Exclusion Domain](https://docs.byteplus.com/en/docs/DataTester/Traffic-Layer-and-Mutual-Exclusion-Domain)
7. [BytePlus Docs：Server Side SDK Overall Description](https://docs.byteplus.com/en/docs/DataTester/Server-Side-SDK-Overall-Description)
8. [BytePlus Docs：Enhanced Shunt Uniformity](https://docs.byteplus.com/en/docs/DataTester/Enhanced-Shunt-Uniformity)
9. [BytePlus Docs：MAB Intelligent Tuning Experiment](https://docs.byteplus.com/en/docs/DataTester/MAB-Multi-Armed-Bandit-Intelligent-Tuning-Experiment)
10. [arXiv:2305.02542 Correcting for Interference in Experiments: A Case Study at Douyin](https://arxiv.org/abs/2305.02542)
11. [阿里云开发者社区：淘天 AB 实验分析平台 Fluss 落地实践（2025-07-18）](https://developer.aliyun.com/article/1672360)
12. [InfoQ：阿里妈妈大规模在线分层实验实践（2016-09-19）](https://www.infoq.cn/article/alimama-large-scale-online-hierarchical-experiment)
13. [InfoQ：天猫 App A/B 测试实践（AirTrack）](https://www.infoq.cn/article/tmall-app-ab-test/)
14. [阿里妈妈数据科学系列：在线分流框架下的 AB Test](https://zhuanlan.zhihu.com/p/390417035)
15. [阿里妈妈数据科学系列：离线抽样框架下的 AB Test](https://zhuanlan.zhihu.com/p/394253252)
16. [阿里云 PAI：A/B 实验（ABTest）概述（更新 2026-09-09）](https://www.alibabacloud.com/help/zh/pai/a-b-experiment/)
17. [阿里云 OpenSearch：如何使用 A/B Test 功能](https://help.aliyun.com/zh/open-search/industry-algorithm-edition/a-or-b-tests)
18. [阿里云 AHAS：Feature Toggle 模块停服公告](https://help.aliyun.com/en/ahas/product-overview/delisting-announcement-of-function-switch-function-module)
19. [arXiv:2201.00689 CausalMTA（KDD 2022）](https://arxiv.org/abs/2201.00689)
20. [arXiv:2405.08411 Large-Scale Metric Computation in Online Controlled Experiment Platform（VLDB 2024）](https://arxiv.org/abs/2405.08411)
21. [腾讯云：微信实验平台全面拥抱湖仓时代（2023-10）](https://cloud.tencent.com.cn/developer/article/2346725)
22. [腾讯云：一文详解非标准 AB 实验（2022）](https://cloud.tencent.com.cn/developer/article/2156664)
23. [ABetterChoice：Stats Engine 与样本验证](https://docs.abetterchoice.ai/guide/experiments/stats-engine-and-validation)
24. [arXiv:2408.04441 Causal Inference in Social Platforms Under Approximate Interference Networks](https://arxiv.org/abs/2408.04441)
25. [KDD 2025：Detecting Interference using Dyadic Data in Online Controlled Experiments](https://doi.org/10.1145/3711896.3736906)
26. [专利 CN110830234B：一种用户流量分配方法及装置（腾讯）](https://patents.google.com/patent/CN110830234B/zh)
27. [美团技术团队：可信实验白皮书系列 08（2025-08-22）](https://tech.meituan.com/2025/08/22/meituan-AB-Online-Controlled-Experiment-08.html)
28. [美团技术团队：新一代实验分析引擎（2024-09-09）](https://tech.meituan.com/2024/09/09/New-Generation-Analysis-Engine-Driving-Data-Decisions.html)
29. [美团技术团队：效果广告实验配置平台（Wedge，2019-11-28）](https://tech.meituan.com/2019/11/28/advertising-performance-experiment-configuration-platform.html)
30. [美团《可信实验白皮书》2025 合集 PDF](https://s3plus.meituan.net/ddfile/2025%E5%8F%AF%E4%BF%A1%E5%AE%9E%E9%AA%8C%E7%99%BD%E7%9A%AE%E4%B9%A62025.8.20.pdf)
31. [arXiv:2202.10887 Policy Evaluation for Temporal and/or Spatial Dependent Experiments](https://arxiv.org/abs/2202.10887)
32. [滴滴技术：AB 实验之分组提效（2020）](https://zhuanlan.zhihu.com/p/147203168)
33. [百度智能云：AI_REC AB 实验文档（2024-05）](https://cloud.baidu.com/doc/AI_REC/s/Flw4scq90)
34. [百度搜索资源平台：峙一 AB 实验开放平台上线公告（2018-11-15）](https://ziyuan.baidu.com/wiki/2727)
35. [SelectDB：快手 AB 场景提速 145 倍（2026-07-03）](https://www.selectdb.com/blog/1719)
36. [arXiv:2608.04625 A/B Agent: A Self-Evolving Agent for Strategy Iteration in Industrial A/B Testing](https://arxiv.org/abs/2608.04625)
37. [arXiv:2602.08569 Towards Reliable Social A/B Testing](https://arxiv.org/abs/2602.08569)
38. [小红书：推荐系统迭代 AB 测试架构的高效与稳定性策略（2024-08）](https://zhuanlan.zhihu.com/p/715370120)
39. [ITPUB：小红书 × 云器科技 增量计算 + 实时湖仓（2026-10-16）](https://blog.itpub.net/70048664/viewspace-3184138/)
40. [GitHub：bilibili/abtest（Apache-2.0）](https://github.com/bilibili/abtest)
41. [B站：基于 ClickHouse 的海量用户行为分析应用实践（北极星）](https://www.bilibili.com/read/cv21106590/)
42. [京东零售：数据编织在 AB 实验自动化中的应用与实践](https://zhuanlan.zhihu.com/p/10465095421)
43. [京东云：增长实验室 AB 分流的流量保护功能介绍（2023-11）](https://testerhome.com/column_channels/38235)
44. [网易云音乐：一站式 A/B 实验平台的搭建与落地应用](https://zhuanlan.zhihu.com/p/641222646)
45. [网易严选：A/B 科学实验平台实践（2022-11）](https://zhuanlan.zhihu.com/p/587995471)
46. [携程火车票：非用户端 AB 实验的分流算法（2025-07）](https://cloud.tencent.cn/developer/article/2536676)
47. [携程机票：ABTest 实践（2017）](https://zhuanlan.zhihu.com/p/25685006)
48. [知乎：Apache Doris 在知乎 AB 实验平台的使用实践（2025-01）](https://www.sohu.com/a/848315597_121665362)
49. [百度 AB 测试专利 CN115391184B](https://eureka.patsnap.com/patent/CN115391184B)
50. [《个人信息保护法》（2021-08-20）](http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html)
51. [《互联网信息服务算法推荐管理规定》（2022-03-01 施行）](https://www.gov.cn/zhengce/zhengceku/2022-01/04/content_5666429.htm)

---

## 第 5 章 开源方案与自建

> 本章拆解 GrowthBook、PostHog、Unleash、Flagsmith、Flipt、Flagr、OpenFeature、FeatureProbe、ABRouter、Superposition，并给出自建 TCO 与三套方案。

## 5.1 开源生态地图

一句话概括 2026 年 10 月的开源实验生态：**能把「开关」做好的项目很多，能把「实验」做对的项目很少，能把两者同时做成产品的只有两个半。** GrowthBook 算一个，PostHog 算一个但实验只是副产品，Flagsmith 的实验还停在 Beta——其余项目本质上都是交付层或配置层。

把实验平台拆成四层，供给的拥挤程度立刻显形：

| 能力层 | 核心问题 | 开源供给 | 代表项目 | 成熟度 |
|---|---|---|---|---|
| 交付层 | 这段代码今天对谁生效？ | 极度拥挤 | Unleash、Flipt、Flagr、Flagsmith、FeatureProbe | 高，接近商业产品 |
| 编排层 | 多个实验如何不互相污染？ | 稀疏 | GrowthBook（namespace/filters）、Superposition（100 桶互斥） | 中低，多为近似 |
| 分析层 | 组间差异是否可信？ | 极少 | GrowthBook、PostHog、Flagsmith Beta、FeatureProbe（已冻结） | 低，方法覆盖不全 |
| 治理层 | 谁批、怎么停、怎么复盘？ | 近乎空白 | 各家 Enterprise 目录里的 SSO/审批/审计 | 很低，且几乎都收费 |

统计层为什么长不出来？**一是统计与指标语义强耦合**：比率指标要处理分子分母协方差，留存要处理窗口，分位数连 CUPED 都不适用，这些定义藏在每家公司的数仓里。**二是统计是研究成本而非 CRUD 成本**：方法每两年翻一代，维护者得持续跟论文。**三是买 Flag 的人和买实验结论的人不是同一拨**：前者关心 P99、SDK 覆盖、容灾，后者关心偏差、功效、SRM。

按数据路径，这些项目分四类，「免费」贵在不同科目：

| 数据路径 | 代表 | 事件存在哪 | 能力天花板 | 隐性成本 |
|---|---|---|---|---|
| 自采事件 | PostHog、FeatureProbe、ABRouter | 自己的 ClickHouse / MySQL | 事件量与自建存储运维 | 存储、管道、与数仓口径割裂 |
| 仓库原生 | GrowthBook、Flagsmith（Beta） | 客户数仓 | 数仓成熟度与查询成本 | 扫描费、T+小时延迟、建模人力 |
| 只输出曝光 | Unleash、Flagr、Flipt | 客户 Kafka / 数仓 | 客户自建全部分析 | 统计层从零开始 |
| 配置 / 路由 | Superposition、AB Testing Gateway | 不涉及 | 没有实验语义 | 用错场景的返工 |

截至 2026-10-18 的快照（star 与 release 取当日 GitHub 页面）：

| 项目 | License | Star | 最近 release | 状态判断 |
|---|---|---:|---|---|
| GrowthBook | MIT 核心 + `enterprise/` 商业目录 | 8,506 | 5.1.0（2026-09-22） | 活跃，独立运营 |
| PostHog | MIT 核心 + `ee/` 商业许可 | 40,331 | Cloud 持续发布 | 活跃，自建仅 hobby |
| Unleash | v8 起 AGPLv3，官方镜像 Apache-2.0 | 13,882 | v8.2（2026-09） | 活跃，治理最强 |
| Flagsmith | BSD-3-Clause | 6,597 | v2.286.0（2026-10-15） | 活跃，实验 Beta |
| Flipt | v2 服务端 FCL（存在争议），SDK MIT | 4,920 | v2.14.0（2026-10-15） | 活跃，GitOps 路线 |
| Flagr | Apache-2.0 | 2,610 | 1.2.4（2026-08-20） | 活跃，无商业支持 |
| FeatureProbe | Apache-2.0 | 1,638 | 2.7.0（2023-09-20） | 功能冻结，仅安全修复 |
| Superposition | Apache-2.0 | 438 | v0.118.2（2026-10-13） | 活跃，0.x API |
| ABRouter | GPL-3.0 | 46 | 无 release，2023-05 后停更 | 停更 |
| OpenFeature | Apache-2.0 | 1,273 | 规范持续演进 | CNCF Incubating |
| PlanOut | BSD 系 | 1,681 | 已归档 | 历史标本 |

这张表最容易被误读的是 star 列。PostHog 的 4 万 star 来自「产品分析 + 回放」这个更大的品类；`statsig-server-core` 只有 24 star，因为那只是求值内核；FeatureProbe 1,638 star，却在 2023 年 9 月后没有功能发布。**star 是注意力，不是可维护性**；该看最近 6 个月的 release 节奏、非依赖提交占比、是否有公司实体承担 SLA。

另一条共性是：**Open Core 的付费墙位置高度一致**——高级统计（CUPED、序贯、holdout、bandit）、治理（SSO/SCIM、审批、审计、多组织）、规模（席位、环境数、Flag 数）。这不是巧合，而是「免费给你能跑，收费才敢用」。理解这一点，就不会把「开源」当成「免费获得一个企业级实验平台」。

中国可用性：截至 2026-10，没有发现这些项目在中国大陆有官方云区域。问题不是「能不能装」，而是「能不能合规地长期运行」——内网镜像、ICP 备案、个人信息评估、等保缺一不可。FeatureProbe 中文文档最友好，但已冻结。

## 5.2 GrowthBook：开源世界里最接近「完整答案」的那一个

GrowthBook 成立于 2020 年，官方自称「第一个 warehouse-native、开源的 Feature Flag、实验与产品分析平台」，宣称 3,000+ 家公司使用、累计处理超过 1 万亿次事件查询（[About](https://www.growthbook.io/about)，厂商口径）。它的卖点不是统计最先进，而是**数据不动**：原始曝光与指标留在客户的 Snowflake/BigQuery/Databricks 里，平台只下发配置、生成 SQL、把聚合后的充分统计量拿回来算（[Warehouses](https://docs.growthbook.io/warehouses)）。于是合规成本低、SQL 可审计、指标口径可复用；代价是分析延迟受数仓调度约束，客户必须有人会写 assignment query、fact table 和 metric。

**它到底开源了什么。** 仓库 LICENSE 写明：`packages/back-end/src/enterprise`、`packages/front-end/enterprise`、`packages/shared/src/enterprise` 三个目录走 GrowthBook Enterprise License，其余走 MIT Expat（[LICENSE](https://github.com/growthbook/growthbook/blob/main/LICENSE)）。你可以 fork 核心、内部部署，但不能把 `enterprise/` 当 MIT 用。付费墙的位置很关键：CUPED、Sequential、Holdout、Post-stratification、Pipeline Mode、SSO/SCIM、审批、审计、多组织全要 license（[Pricing](https://www.growthbook.io/pricing)）。**社区版给你的是「能跑实验」，不是「能跑可信的实验」**；如果评审要求 CUPED 降方差、序贯控制 peeking、holdout 衡量长期影响，落地第一天就该按商业版做预算。

**架构：轻控制面，重数仓。** 官方自托管文档写明系统由 Next.js 前端、Express API、Python 统计引擎组成，打包在单个 Docker 镜像里，前端 3000、API 3100，Cookie 要求同根域（[Self-Hosting](https://docs.growthbook.io/self-host)）。元数据库是 **MongoDB**，不是 Postgres——Postgres 在这里只是「被查询的数据源」之一；官方建议三节点副本集，并明确 Cosmos DB 不能替代（[Production](https://docs.growthbook.io/self-host/production)、[FAQ](https://docs.growthbook.io/faq)）。这是中文团队最容易误判的硬约束：若公司标准是「一切上 Postgres」，自托管就要多养一套 Mongo 栈，而改数据模型等于重写。统计计算在独立 Python 包 `gbstats` 里做，生产上可把 Jobs Server 拆出去，用 `EXTERNAL_PYTHON_SERVER_URL` 指向独立实例；代价是单机进程池有上限、`/stats` 端点本身没有内置鉴权。

**分桶协议是它最值得抄的部分。** 「Build Your Own SDK」规范把算法写死了：FNV-1a 32 位哈希；`hashVersion=1` 是 `fnv32a(value + seed) % 1000 / 1000`；`hashVersion=2` 是 `fnv32a(fnv32a(seed + value) + "") % 10000 / 10000`（[Build Your Own SDK](https://docs.growthbook.io/lib/build-your-own)）。v1 存在「并行实验偏差」，v2 用双重哈希修复，官方要求所有 SDK 行为完全一致。**哈希版本是必须进协议的字段**，否则不同语言 SDK 会在同一批用户上算出不同结果，而这种偏差极难在报表上发现。互斥靠 namespace：把 `"__" + namespace` 作为 seed 对用户 ID 做哈希，每个实验在 0–1 的命名空间里占一段 range，不重叠即互斥；官方还有一句实用提醒：**改 split 会让用户换组，改 coverage 不会**。

**统计栈：工业够用，但不是最前沿。** 默认贝叶斯，可在 Organization 或 Project 级切换（[Statistics Overview](https://docs.growthbook.io/statistics/overview)）。贝叶斯默认 improper 先验（方差无穷，等价于不加先验信息），开启 proper prior 后默认 `N(0, 0.3)`，输出 Chance to Win 与 95% credible interval；频率派是双侧 t 检验，自由度用 Welch-Satterthwaite 近似，相对 lift 的方差用 Delta Method（[Statistical Details](https://docs.growthbook.io/statistics/details)）。

CUPED 是标准回归调整：`Y_adj = Ȳ - θ·X̄`，`θ = Cov(Y,X)/Var(X)`，θ 在 control+treatment 池化后计算，默认回看 14 天。差异化在 **CUPEDps = CUPED + post-stratification**：用维度分层，先算层内 lift 再加权汇总，可修正层内实际分流比例与目标比例的偏差（[CUPED](https://docs.growthbook.io/statistics/cuped)）。序贯只支持频率派，实现是 Waudby-Smith 等（2023）的 **Asymptotic Confidence Sequences**，不是 mSPRT；调参量 `N*` 默认 5000，含义是「你通常做决策时的样本量」，越接近真实决策点，置信序列相对固定样本 CI 的膨胀越小（[Sequential](https://docs.growthbook.io/statistics/sequential)）。代价是序贯 CI 一致地更宽，它解决的是 peeking 导致的假阳性膨胀，不是让你更早看到显著。

最值得直接抄的是**实验健康检查产品化**：结果页自动跑六项——SRM（卡方，p<0.001，出现即不可信）、Multiple Exposures、Pre-exposure Bias（频率派 + Bonferroni）、Minimum Data、Variation Id Mismatch、Suspicious Uplift（[Experiment Results](https://docs.growthbook.io/app/experiment-results)）。它把「这个实验能不能信」做成了默认输出，而不是数据科学家的脚本。多重比较只有频率派支持，提供 Holm-Bonferroni（FWER）与 Benjamini-Hochberg（FDR），范围是「一次结果视图里的所有 Goal metrics × variations」，**不包括 Secondary 和 Guardrail**，adjusted p-value 只在 UI/CSV 里、API 不导出（[Multiple Corrections](https://docs.growthbook.io/statistics/multiple-corrections)）。Guardrail 不参与校正是有意取舍：宁可多报警，但不能用校正后的显著性去解释它。

**边界与代价。** 没有原生 Layers，只有 namespace/filters 和 per-experiment seed，互斥靠手工切区间，没有容量仪表盘与冲突检测；几十个实验够用，上千个会变成治理灾难。MongoDB + Agenda + 单机 Python 进程池适合「配置面高并发、分析面中等吞吐」。默认 6 小时刷新、SQL 缓存 60 分钟（[Env](https://docs.growthbook.io/self-host/env)），Event Forwarder 能把曝光入仓做到秒级，但分析仍是批处理。数仓扫描是最容易被低估的 TCO；官方 connector 覆盖 BigQuery、Snowflake、ClickHouse、Trino 等，但没有 MaxCompute、Hive、Doris、StarRocks，只能自研 adapter 或用 Trino/ClickHouse 中转。

判断：**它是最好的「实验分析底座」，不是「实验平台」**。分析层 85 分，编排层 60 分，治理层要付费且仍偏薄。有数仓、实验量 10–100 个/月、有 1–2 名数据同学，它是最现实的起点；DAU 千万、上千并行实验，它应做「统计与报表层」。

## 5.3 PostHog：把实验做成 Flag 的一个视图

PostHog 的路径和 GrowthBook 相反：不是「把实验建在数仓上」，而是「把实验建在自己的事件管道上」。Product Analytics、Session Replay、Feature Flags、Experiments、Data Warehouse、CDP 六个模块共享同一条事件流和同一个 ClickHouse，实验与 Flag 合并计费、不单独收费（[Pricing](https://posthog.com/pricing)）。

**实验在 PostHog 里不是一等公民。** 创建实验时系统默认自动创建一个多元 flag，或挂到已有 flag 上（要求 2–20 个变体）；实验只是给这个 flag 附加「指标 + 曝光口径 + 统计配置」（[Creating an Experiment](https://posthog.com/docs/experiments/creating-an-experiment)）。于是 flag 可以独立存在，实验是它的分析视图；任何人在 flag 页面改比例、改发布条件，都会直接影响运行中的实验；实验的「结束」本质上是把某个变体固化到 flag 上。这与 Optimizely/Statsig 类产品有根本差异——后者有独立的实验对象、分配服务和生命周期。PostHog 用极低的接入成本，换来了治理能力的简化。

**架构上，它是一家把 ClickHouse 用到极致的公司。** 官方拓扑是 Django Web/API + Rust（capture、feature flags、replay）+ Kafka/WarpStream + ClickHouse 分片集群 + Aurora PostgreSQL + Redis/Valkey + S3（[How PostHog Works](https://posthog.com/docs/how-posthog-works)）。事件经 Kafka 表引擎拉取、物化视图写入 Distributed 表，按 `sipHash64(distinct_id)` 分片（[ClickHouse](https://posthog.com/docs/how-posthog-works/clickhouse)）。这对实验有一个重要含义：**按用户 ID 分片，让「查某个用户」是单分片操作，但「按变体聚合所有用户」是全分片扫描**——而实验指标天然是后者。所以它必须用充分统计量聚合、Winsorization、CUPED 回看窗口限制来压查询成本，这是工程折中，不是统计偏好。

2025-09-29，US 区域 flag 服务宕机 1 小时 48 分钟、约 78% 请求返回 504（[Post-mortem](https://github.com/PostHog/post-mortems/blob/main/2025-09-29-flags-is-down.md)）；此前官方披露旧 Django 服务 50 万请求/分钟要 300 个 pod、8,800 美元/月，Rust 重写后降到 90 个 pod、2,800 美元/月、p99 85.4ms。**flag 的可用性就是实验平台的可用性。**

**统计：默认贝叶斯，但默认路径最容易被误读。** 贝叶斯引擎把用户级数据聚合成充分统计量，用无信息先验更新正态后验，输出 chance to win 与 95% credible interval（[Bayesian](https://posthog.com/docs/experiments/statistics-bayesian)）。官方明确：多变体各自独立与对照比较，**不做多重比较校正**；5 个指标出现至少一个假阳性的概率约 23%，10 个约 40%。频率派用 Welch t-test，比率指标用 Delta Method，额外提供基于 Waudby-Smith 2023 的序贯检验（[Frequentist](https://posthog.com/docs/experiments/statistics-frequentist)）。CUPED 只支持 mean 指标和「有序、无数据仓库步骤」的 funnel，ratio、retention、无序 funnel 即使开启也不调整，回看窗口默认 14 天（[CUPED](https://posthog.com/docs/experiments/cuped)）。笔者认为，「贝叶斯默认」更像产品体验选择：无信息先验下 chance to win 与单侧 p 值高度对应，并没有解决 peeking。

**曝光是整个体系最脆弱的一环。** 默认曝光事件是 `$feature_flag_called`，必须带 `$feature_flag` 和 `$feature_flag_response`；只有首次曝光之后的指标事件才计入，转化窗口锚定首次曝光（[Exposures](https://posthog.com/docs/experiments/exposures)）。官方自己列了两个坑：Web SDK 按 identity 跨会话去重，若用户在实验上线前就查过这个 flag，事件已被缓存，上线后不会再发，**老用户可能根本不算曝光**；广告拦截会让 flag 请求到不了 PostHog，官方建议反向代理，称通常能提升 10–30% 采集。再加上配额耗尽时 `/flags` 返回 `quota_limited: true`、SDK 静默回退默认值（[Cutting Costs](https://posthog.com/docs/feature-flags/cutting-costs)），实验会「悄悄停止分流」而不是报错。这比宕机更危险。

**自托管已不是企业选项。** 官方定位是 MIT 下的免费 Docker Compose「hobby」部署，**不支持**、不做 tagged release、不发 CVE，付费功能仅 Cloud；边界是 30 万事件/月、1 千录像、30 万 flag 调用（[Self-host](https://posthog.com/docs/self-host)）。2023-02 宣布停止 Helm 支持（5 月底停止常规更新）、停售自托管 license。对要求数据境内的中国公司，只剩 EU Cloud 或放弃——**硬约束，不是价格问题**。

**成本模型要按三项一起算。** flag 请求前 100 万免费，之后分档降到 $0.00001/次；按官方价累加，1,000 万次/月约 $460，5,000 万次约 $1,460，6 亿次（假设 1,000 万 DAU、每人每天 2 次）约 $6,960（[Pricing](https://posthog.com/pricing)）。事件另计：1,000 万事件/月约 $324，1 亿约 $2,618。隐藏成本有三项：曝光事件本身算一条事件，**一次实验曝光同时消耗 flag 额度和事件额度**；Surveys 会求值项目内所有活跃 flag；本地求值按轮询计费，定义变化的轮询算 10 次请求。再加 Boost $250/月、Scale $750/月、Enterprise $2,000/月的平台包，**实验其实被收了两次甚至三次**。

结论：PostHog 是**从 0 到 1 最快**的产品，也是**千人组织最不合适**的平台。Approvals 只覆盖 flag 变更；SRM 从 100 次曝光起算、只警告不阻断；没有 guardrail 类型、分层/互斥、MAB。这是定位取舍，不是待补功能。

## 5.4 Unleash / Flagsmith / Flipt / Flagr / OpenFeature：交付层的五个样本

这一组代表五种「把求值做对」的哲学，它们的共同短板恰好定义了自建平台的真正工作量。

**Unleash：最像企业级 Flag 控制面。** 13,882 star，客户案例覆盖 Lloyds Banking Group、Mercadona、Wayfair 等（厂商自述）。2026 年最重要的变化是 license：**从 v8（2026-06-09）起主仓库与 npm 包从 Apache 2.0 改为 AGPLv3**，官方 Docker 镜像仍是 Apache-2.0，SDK 保持宽松许可（[v8.0.0 Release](https://github.com/Unleash/unleash/releases/tag/v8.0.0)）。官方明确：修改源码并以网络服务形式对外提供，AGPL 要求开放修改后的源码或购买商业许可。这里有**存在不同说法**：部分资料仍称 Unleash 是 Apache-2.0，那是 v8 之前的版本口径；以 v8 release note 为准，但镜像与 SDK 的许可确实更宽松，法务要按「部署形态 + 是否改源码」分别判断。

架构是「API server + 多语言 SDK + 可选 Edge」：后端 SDK 拉全量配置本地求值，前端 SDK 由 Server/Edge 代求值（[Overview](https://docs.getunleash.io/get-started/unleash-overview)）。分流用归一化 MurmurHash，stickiness 默认 `userId`、缺失回退 `sessionId`，`groupId` 默认是 Flag 名（[Strategies](https://docs.getunleash.io/concepts/activation-strategies)）。隐蔽后果：**同一 `groupId` 的多个 Flag 会相关而非独立分流**，适合多开关联动，不适合正交分层。

实验支持是「有实验 Flag，没有实验结论」：开启 impression data 后 SDK 发曝光，由外部工具归因（[Guide](https://docs.getunleash.io/guides/a-b-testing)）。没有实验对象、样本量、SRM、CUPED、序贯、多重比较；**「unlimited experiments」指 Flag 变体能力，不是统计实验数量**。$75/seat/月，OSS 限 1 项目/2 环境/5,000 Flag，治理全在 Enterprise。它解决发布风险，不解决因果推断。

**Flagsmith：五个项目里唯一把实验做进产品的。** 6,597 star，BSD-3-Clause，最新 v2.286.0（2026-10-15）。2026 年最大的变化是 Experimentation（Beta）：不再只做「multivariate flag + 第三方分析工具」，而是内置仓库连接、指标定义、实验创建、贝叶斯结果页（[Experimentation](https://docs.flagsmith.com/experimentation)）。

链路是：接仓库（Cloud 可用托管仓库，也可 BYO ClickHouse/Databricks；Snowflake/BigQuery 官方写「coming soon」）→ 定义指标（Occurrence、Count、Sum、Mean 四类，区分 goal 与 guardrail）→ 选 multivariate flag、设流量与变体比例 → 跑实验（SDK 记录 exposure 与 conversion，事件默认每 10 秒批量上报，**当前只支持远程求值**）→ 看结果（Lift、95% credible interval、chance to beat control；曝光按 identity 去重取最早；同一 identity 出现多变体则 quarantine 排除；SRM 在至少 100 identities 后检查，阈值千分之一；每个 arm 至少 50 identities、转化指标至少 5 次转化才展示）（[Analyse](https://docs.flagsmith.com/experimentation/analyse-an-experiment)）。统计口径很坦诚：贝叶斯引擎，用 chance to beat control 替代 p 值；明确 **frequentist engine deferred**、**risk/expected loss not currently planned**（[Statistics](https://docs.flagsmith.com/experimentation/statistics)）。

这里有一处**存在不同说法**值得记录：有的资料把 Flagsmith 的实验指标概括为「转化率、计数、均值三类」，官方文档实际是四类（多了 Sum）。架构是 Django 控制面 + 无状态 Edge Proxy，Edge 跑的是 local evaluation mode 的 Python Server SDK，官方基准是 M1 MacBook Pro 上约 2,000 RPS、平均约 7ms（[Edge Proxy](https://docs.flagsmith.com/performance/edge-proxy)）。关键限制是 Edge **不持久化 trait**，每次请求必须带全量 traits。价格：Free 50k requests/月；Start-Up 年付 $40/月（月付 $45），1M requests；Scale-Up 年付 $250/月（月付 $300），5M+ requests，含 SAML/SSO、RBAC、change requests、audit（[Pricing](https://www.flagsmith.com/pricing)）。

**Flipt：Git-native 的「配置即代码」派。** 4,920 star，v2.14.0（2026-10-15），单 Go 二进制，默认无外部依赖，Flag 配置存在 Git 仓库，UI/API 的写操作变成 Git commit，支持 GitHub/GitLab 的 PR 流程，并提供 OFREP 与 OpenFeature provider（[v2 Concepts](https://docs.flipt.io/v2/concepts)）。分流逻辑非常透明：把 `flagKey:entityID` 拼接，做 CRC-32（IEEE），对 1000 取模得到 0–999 的桶，distribution 按百分比占连续区间，**不持久化任何 entity/context/变体结果**。优点是简单、可复现、隐私友好；缺点是 salt 设计固定——`flagKey` 直接参与哈希，没有独立实验 salt/层，多个 Flag 之间无法保证正交，**想改分桶只能改 flagKey 或换 entityID，会破坏稳定性**。它也没有 exposure 概念，Analytics 只收集 Flag Evaluation Count，可写 ClickHouse 或 Prometheus，UI 展示最多 24 小时，而且只统计经过服务端 REST/gRPC 的求值（[Analytics](https://docs.flipt.io/v2/configuration/analytics)）。

License 是这一节最需要标注**存在不同说法**的地方：v2 官方 licensing 页写服务端采用 **Fair Core License（FCL）**，允许读、改、自托管、再分发，但限制「与 Flipt 商业利益竞争」的用途，FCL 在发布两年后转为开源许可，SDK 保持 MIT；而仓库 README 仍显示 GPL-3.0 徽章，第三方事实核查也按 GPL-3.0 记录（[Licensing](https://docs.flipt.io/v2/licensing)）。合理解释是 v1 服务端 GPL-3.0、v2 改 FCL，但徽章与文档不一致，**法务必须按具体版本文档确认**。商业版 Pro $200/月，含最多 10 个实例、SCM 集成、GPG 签名。

**Flagr：极简 Go 微服务，2026 年补上了曝光。** 2,610 star，Apache-2.0，仓库从 `checkr/flagr` 迁移到 `openflagr/flagr`，2026 年仍在发版（1.2.4，2026-08-20），但没有商业版/托管服务，也就没有厂商 SLA。架构按延迟预算拆成三条路径：求值走内存 EvalCache（默认 3 秒轮询 snapshot）、配置走强一致 CRUD、记录走异步 fan-out 到 Kafka/Kinesis/Pub/Sub/Datar；README 给的 benchmark 是约 2k req/s、median 327µs（[README](https://github.com/openflagr/flagr)、[Overview](https://openflagr.github.io/flagr/flagr_overview)）。

分桶用 **Flag ID 字符串做 salt**：先 `crc32.ChecksumIEEE(salt)`，再 update entityID，最后 `% 1000`。这跟 Flipt 的「flagKey:entityID 直接 CRC32」不同：Flagr 改 flagKey 不会重新洗牌，改 flagID 会；Flipt 改 flagKey 会重新洗牌。这个差异在迁移/复制实验时是真实的坑。2026 年补上的曝光 API 很实用：客户端流程是「POST /evaluation → 渲染 → POST /api/v1/exposures」，批量上限 100，exposure 只校验 Flag/variant 存在、**不重跑 segment 约束**，且默认在认证白名单里，官方明确警告「开放接口可被伪造曝光」（[Exposure](https://openflagr.github.io/flagr/flagr_exposure)）。但它也很坦率：**「Flagr doesn't run significance tests」**，join、转化率、显著性、序贯全部交给你的数仓，文档只给「first exposure + 7 天转化窗口」的 SQL 模板（[Pipeline](https://openflagr.github.io/flagr/flagr_eval_exposure_pipeline)）。

**OpenFeature：标准化「怎么问 Flag」，不标准化「怎么证明因果」。** CNCF Incubating（2023-12-19 晋级），核心是 Evaluation API、Provider、Hooks、Events、Tracking（Experimental）、OFREP（[Specification](https://openfeature.dev/specification/)）。官方参考求值引擎 flagd 没有 UI、没有管理控制台、没有持久化层，配置来自文件/HTTP/K8s CRD/gRPC（[flagd](https://flagd.dev/)）。它的价值有三：SDK 解耦（业务代码只依赖 OpenFeature API，底层从 Unleash 换 Flipt 不用改代码）、曝光钩子（Hooks 可在每次求值后采集 flagKey/variant/context/timestamp）、OFREP 降低 provider 数量。但 **Tracking 仍是 Experimental，provider 不支持时 `track` 会 no-op**，不能当可靠曝光通道（[Tracking](https://openfeature.dev/specification/sections/tracking)）。它不解决实验对象、随机化单元、分层/互斥、样本量、SRM、CUPED、显著性、治理——把 OpenFeature 当实验平台，是典型的层次错位。

把五个项目放在一起，**Flag 平台做实验的五个硬缺口**非常清楚：

1. **统计引擎**：除 Flagsmith Beta 外都不提供。工业级要有 t/比例检验、Welch、Delta Method、贝叶斯 credible interval、序贯、多重比较、CUPED、聚类稳健方差、MDE/功效，比率、聚类、多变异、连续监控各有各的坑。
2. **指标语义**：Unleash/Flagsmith/Flagr 的曝光字段只够定位「谁看到哪个变体」，Flipt 干脆没有 exposure；它们都缺少指标目录、OEC/guardrail 定义、比率/分位数指标、跨设备归因、实验污染处理；Unleash 的 impact metrics 是运行指标，不是业务指标。
3. **SRM**：只有 Flagsmith 内置，且 SRM 只是症状不是根因——分流 bug、曝光丢失、重定向、机器人、实验互斥、客户端崩溃都可能触发（[SRM Paper](https://www.kdd.org/kdd2019/accepted-papers/view/diagnosing-sample-ratio-mismatch-in-online-controlled-experiments-a-taxonom)）。
4. **CUPED**：普遍没有。它需要实验前 7–28 天用户级快照、相关协变量、按随机化单元回归、比率再叠 Delta Method、处理缺失/新用户/漂移。
5. **实验治理**：Flag 生命周期 ≠ 实验生命周期。change request/RBAC/Git PR 是变更治理；实验治理要注册表、分层互斥、holdout、评审、决策日志、复盘，没有一家做完整。

还有一个常被忽略的细节：**分流语义。** 随机化单元默认 `userId`，但实验可能需要 device/session/geo/cluster；触发点也不同，Unleash 在 `isEnabled` 时就发 impression，可能早于真正展示，Flagr 明确要求渲染后 POST；Flagsmith 按 identity 取最早曝光并 quarantine 多变体用户，Unleash 每次调用都发、要下游去重。这些不会写进功能表，却直接决定结论可不可信。

## 5.5 FeatureProbe / ABRouter / Superposition / 其他：三种抽象，三种教训

这一组项目的价值不在「用」，在「读」。它们分别把实验对象、配置对象、路由规则三种抽象做到了极致，正好用来校准自研平台的数据模型。

**FeatureProbe：中国团队最完整的一体化开源实验平台，但已按下暂停键。** 1,638 star，Apache-2.0，中文文档优先、Gitee 镜像、微信社区，带有明显的「国内大厂内部平台开源化」印记；官方 README 称已在「一家 5000+ 开发者的公司」使用五年以上、支撑百万用户级产品（公司主体、客户名单、融资均未披露）。项目状态是这份调研里最重要的负面信号：最后一个 release 是 2023-09-20 的 2.7.0，最后一次非依赖变更停在 2024-06-05，2024-08-15 之后基本只有 dependabot；中文 README 直接写「社区活跃度不高，暂停新功能规划和发布，仅安排安全漏洞修复与社区贡献合入」（[README_CN](https://github.com/FeatureProbe/FeatureProbe/blob/main/README_CN.md)）。这不是「停止维护」，而是「功能冻结、安全修复兜底」。另一个观察：2026-10-18 实测 `featureprobe.io` 会 302 跳转到无关的 `beautifulhotels.co`，文档站仍正常，商业托管是否已停止**待核实**，但至少说明 SaaS 入口已不可靠。

它的架构比多数开源 flag 项目完整：React/TS 的 Admin UI、Spring Boot 的 API、Rust 的 Server（SDK 连接、规则判定、事件接收）、多语言 SDK；`docker-compose.yml` 显示配置库与事件库都跑在 MariaDB 上，Server 通过 `FP_REFRESH_SECONDS=3` 每 3 秒从 API 拉规则（[Architecture](https://featureprobe.github.io/FeatureProbe/zh-CN/reference/structure/)）。关键词是「控制面/数据面分离、SDK 本地求值、规则最终一致」。代价是**事件链路没有 Kafka、没有 ClickHouse，直接写 MySQL 再由 Analysis 查 MySQL**；官方集群部署文档只建议「Admin 集群 + Server 集群 + 数据库主从」，多环境是逻辑隔离。这套架构能撑中小规模，面对 DAU 千万、每天上亿条事件时，MySQL 写入与聚合都会成为瓶颈，要上规模必须换事件链路。

分流是「顺序匹配、第一条命中即返回」，百分比推出用 0–10000 的三维数组表示权重；算法是把 `FPUser` 的 key 与开关 salt 拼接（salt 为空时用开关 key）、做 SHA-1、取哈希字节的**后 4 位**转整数、对 10000 取模（[Evaluation Rules](https://featureprobe.github.io/FeatureProbe/zh-CN/reference/evaluation-rules/)）。优点是跨语言极易复现、确定性好、无状态。真正的影响在 salt 策略：**salt 默认等于开关 key**，意味着改 key、复制开关、跨实验复用同一 key 都会改变分流结果，运营侧必须把 key 当不可变契约。

统计面比外界印象中强：官方定义转化/计数/平均/加和四类指标，口径很细（[Metrics](https://featureprobe.github.io/FeatureProbe/zh-CN/reference/metric-explanation/)）——**平均类会把无事件用户丢弃、不计入样本**，加和类则按 0 计入。前者造成组间样本选择偏差，后者把「未曝光」与「真实零」混在一起；报表没有强制提示口径风险。

统计上团队明确选贝叶斯，给出 `P(B>A)`、`E(loss|B)`、`E(uplift|B)`，并称模拟显示同等效果下样本量可省约一半（[博客](https://featureprobe.github.io/FeatureProbe/blog/FeatureProbe%20bayesian/)）。但先验如何选、数值指标用什么似然、是否做多重比较、是否有序贯或 CUPED，文档都没说；「省一半」是模拟宣称，不是独立验证。**它有一个可用的贝叶斯转化率比较器，还不是工业级统计引擎。**

**ABRouter：PHP 生态的轻量工具，GPL 是硬约束。** 46 star，GPL-3.0，Laravel + React + MySQL + Redis + Consul + Traefik。事件只有 incremental（漏斗，按用户去重）与 summarizable（可求和，按日汇总）；官方「决策」文档只说等数据、看 OKR，**没有显著性检验、置信区间或序贯方法**（[Decisions](https://docs.abrouter.com/docs/managing/makingdecisions/)）。内部部署不对外分发时 GPL 不要求开源修改，但做成私有化 appliance 或嵌入对外销售的软件就要提供源码。最后提交 2023-05-18，定价页仍可访问（Team Cloud 1 万活跃用户内免费、超出 $19/月，Premium $99/月）——**「网站在卖」不等于「产品在迭代」**。

**Superposition：不是实验平台，是「上下文配置引擎」。** 438 star，Apache-2.0，Rust + Postgres + Redis，Juspay 开源，源自 Hyperswitch 的配置引擎，解决「配置逻辑焊死在代码里」的问题：Default Config + Dimensions + Context/Overrides，用 CSS 式的「默认值 + 更具体规则胜出」模型管理配置（[Context-aware Config](https://superposition.juspay.io/docs/basic-concepts/context-aware-config/how-all-this-works/)）。它也能做实验，但实验是配置的一种用法：一个 Experiment 有且仅有一个 CONTROL、n 个 EXPERIMENTAL，context 圈定样本，traffic percentage 是「**每个 variant** 分到的流量」，所以总流量 = 百分比 × variant 数（官方特别注明，容易误读）；Experiment Group 用 **100 个桶**做互斥：`hash(identifier, group_id) % 100` 得到桶号，每个桶绑定一个 `(experiment_id, variant_id)`，组内一个用户只会看到一个实验，组外仍可重叠（[Experiment Groups](https://superposition.juspay.io/docs/basic-concepts/experimentation/experiment-groups/)）。

这套机制简单、可解释，但局限很硬：**只有 100 个桶，粒度 1%**，多实验分配容易碎片化；没有正交分层、holdout、sticky bucketing 的显式文档，也没有 SRM/CUPED/序贯的方法说明。它的优势在另一条轴：类型安全（JSON Schema）、审计（`change_reason`）、多租户（Organisation + Workspace，是这批项目里最明确的）、Casbin、OpenFeature provider。**适合多租户配置 + 渐进放量 + 轻量互斥实验，不适合当纯实验分析平台。**

**其他项目。** 微博 AB Testing Gateway 是 nginx 七层灰度路由，`ngx_lua` + 共享字典缓存 + Redis 策略，2018-10 后停更，今天只适合学「边缘分流 + 策略缓存」。PlanOut 是 Facebook 的实验 DSL（WWW 2014），价值在「分配逻辑、salt、namespace、日志结构化」，已归档。`statsig-server-core`（24 star）只是求值内核，不能代表 Statsig 整体能力。

这一组给自研平台的最大教训是：**数据模型比功能清单重要。** FeatureProbe 把「进入实验组」定义为「调用分组函数」，于是同一用户可多次进入、口径要自己兜底；ABRouter 把实验做成「多分支 + 日汇总」，只能看趋势不能推断；Superposition 把实验做成「配置 override」，天然没有曝光与样本概念。三种抽象各自自洽，但只有第一种接近实验平台语义——「照着 UI 抄一遍」不等于「做出一个实验平台」。

## 5.6 能力对比矩阵

把「有没有」换成「到不到」，矩阵才有选型价值。判断口径：● 官方文档可验证的完整能力；◐ 部分支持或有明显边界；○ 官方文档未见。截至 2026-10-18。

| 项目 | 实验对象 | 分层/互斥 | Holdout | 频率派 | 贝叶斯 | 序贯 | CUPED | 多重比较 | SRM | 仓库原生 |
|---|---|---|---|---|---|---|---|---|---|---|
| GrowthBook | ● Flag + 实验 | ◐ namespace/filters，无 Layer | ● Enterprise | ● | ● 默认 | ● 仅频率派 | ● | ● 仅频率派 goal | ● p<0.001 | ● |
| PostHog | ◐ Flag 的分析视图 | ○ | ● | ● | ● 默认 | ● 仅频率派 | ◐ 仅 mean/有序 funnel | ○ | ◐ 100 曝光起警告 | ◐ 自带 CH + 数仓指标 |
| Flagsmith | ● Flag 绑指标 | ○ | ○ | ○ | ● Beta | ○ | ○ | ○ | ◐ ≥100 identity | ◐ BYO CH/Databricks |
| Unleash | ◐ 变体，非对象 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| Flipt | ○ 变体 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| Flagr | ◐ Flag/变体 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| FeatureProbe | ● 开关 + 实验 | ○ | ○ | ○ | ◐ 胜出概率 | ○ | ○ | ○ | ○ | ○ |
| Superposition | ◐ 配置实验 | ◐ 100 桶组内互斥 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |
| ABRouter | ◐ 多分支 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ |

第二张表看工程与许可，它决定「能不能真的用三年」：

| 项目 | 部署复杂度 | 多租户 | 审计 | 商业支持 | 许可对二次开发 | 中国境内自建 |
|---|---|---|---|---|---|---|
| GrowthBook | 中：单镜像 + MongoDB + Proxy | ◐ Enterprise multi-org | ◐ Enterprise | Cloud/Enterprise | 核心友好，企业目录不可用 | 可行，需自建 connector |
| PostHog | 高：Django/Rust/Kafka/CH/PG/Redis | ◐ 组织/项目 | ◐ 付费 | Cloud only | 核心可，`ee/` 不可 | 理论可行，官方不支持 |
| Unleash | 中：API + PG + Edge | ◐ 项目/环境 | ◐ Enterprise | Enterprise | AGPL 有网络服务义务 | 可行 |
| Flagsmith | 中：API + PG + Redis；实验加 Kafka/CH | ◐ 组织/项目/环境 | ◐ 付费 | Enterprise | 最宽松 | 可行 |
| Flipt | 低：单二进制 + Git | ○ 环境/命名空间 | ● Git 历史 | Pro/Enterprise | FCL 非竞争限制 | 可行 |
| Flagr | 低：单二进制 + DB | ○ | ◐ snapshot | 无 | 宽松 | 可行 |
| FeatureProbe | 中：5 组件 + MariaDB | ○ | ◐ 操作记录 | 无 | 宽松，但已冻结 | 最友好（中文/Gitee） |
| Superposition | 低：Rust + PG + Redis | ● Org + Workspace | ● change_reason | 社区 | 宽松 | 可行 |
| ABRouter | 中：Laravel + MySQL + Redis + Consul | ○ | ○ | 无 | GPL 传染 | 可行，但已停更 |

读这两张表，有三个结论。**第一，没有一行全绿**：最接近完整的 GrowthBook 分层只是 ◐、多租户要 Enterprise、数仓适配不含中国组件；PostHog 统计列齐全，但 CUPED 只覆盖 mean/有序 funnel、SRM 只警告、没有多重比较。选型不是找全能冠军，而是找「前三项需求都打 ●、其余可接受」的那个。**第二，「有实验对象」和「有统计」是两件独立的事**：Flagsmith 有对象、有贝叶斯但无频率派；Unleash 有变体、有曝光但无对象；FeatureProbe 有对象、有胜出概率但无 SRM/序贯/CUPED。**第三，治理与 license 强相关**：SSO/SCIM、RBAC、审批、审计、多组织几乎都在商业版，Apache-2.0 项目治理最弱、许可最友好。**治理是 Open Core 最自然的收费点。**

## 5.7 自建 TCO 与二次开发风险

先固定口径，否则数字没有可比性。模型假设：36 个月、3 名工程师、人力 80 万元/人年、DAU 1,000 万、50 个实验/月（约 23 个并发、平均 3 个变体）、平均每用户每天 3 次实验曝光（约 9 亿曝光/月）、指标事件复用现有数仓、服务器按国内公有云目录价并含 3 年预留折扣、汇率 1 USD = 7.2 RMB。这是**模型估算，不是供应商报价**。

| 成本项（万元/3 年） | A 轻量：Flipt/Unleash + 现有 BI | B 标准：GrowthBook 自建 | C 大规模：GrowthBook + 独立 Flag 层 |
|---|---:|---:|---:|
| 服务器/存储 | 90–130 | 130–210 | 300–450 |
| 软件授权 | 0–50 | 100–300 | 150–350 |
| 人力（3 FTE × 3 年） | 720 | 720 | 720 |
| 额外人力 | 60–100 | 0–60 | 120–200 |
| 迁移/集成 | 60–100 | 50–80 | 100–150 |
| 合规/等保 | 30–80 | 30–80 | 50–100 |
| 机会成本 | 150–350 | 100–250 | 250–450 |
| **合计（区间）** | **1,110–1,530** | **1,130–1,700** | **1,690–2,420** |
| 基准值 | 1,320 | 1,390 | 2,055 |
| 现金成本（不含 3 FTE 与机会成本） | 240–460 | 310–730 | 720–1,250 |

三个反直觉的结论。**第一，轻量和标准的总成本几乎一样**：轻量省授权，但多花 1 名数据工程师、多花 3–6 个月补统计层，机会成本更高。**第二，人力占一半**：720 万元是基准线；已有 3 名平台工程师时增量现金只有 350–520 万元。**只算服务器不算人，TCO 会少一半**。**第三，大规模方案的成本主要不在软件**：ClickHouse/Kafka/多业务线治理才是大头。到千万 DAU，「买还是建」不再是 license 比较，而是「谁拥有指标口径与治理」。

与 SaaS 对照：GrowthBook Cloud（100 席位下限）约 630 万元/3 年，Unleash Enterprise + 自建统计层约 870–970 万元，B 标准自建约 1,390 万元，C 大规模约 2,055 万元——SaaS 便宜约 600–800 万元。所以**自建的理由不是「省 license」**，而是四个：数据不能出境、需要深度定制、实验量/席位大到 SaaS 边际成本不可接受、把能力沉淀为组织资产。四个至少占一个；实验量只有每月十几个时，自建的固定成本摊到每个实验上是荒谬的。

这里有一处**存在不同说法**必须标注：部分 TCO 测算把 40 美元/seat/月当作 GrowthBook Enterprise 的授权下限，但官方定价页上 40 美元是 **Pro 档**价格，Enterprise 明确写 Custom、需询价。本文以官方页为准，把 40 美元仅当作「授权下限锚点」，表中的授权区间要按实际报价替换。

**按量计费在千万 DAU 的锚点。** 用 PostHog 公开价做一个独立测算：9 亿曝光/月，若按 flag 请求计费，5,000 万以上档 $0.00001/次，约 $9,000/月；曝光事件同时算事件量，按边际价约 $0.000009，约 $8,100/月；两项合计约 $1.7 万/月，3 年约 440–500 万元，还未含平台包、数仓同步、额外环境。这个数字和 B 方案的自建现金成本（310–730 万元）已在同一量级——**「SaaS 便宜」只在中小规模成立**。（该测算基于公开分档价的线性外推，实际账单会因去重、采样、合同折扣而不同，属推断。）

敏感性方面，四个变量最值得盯：人力单价 60 万/100 万，TCO 约 −180 万/+180 万；实验量翻倍，数仓与存储 +30–50%、授权可能跳档；Enterprise 授权免除或翻倍，∓100～300 万；DAU 500 万/2,000 万，约 −30%/+60% 基础设施与数仓成本。

**二次开发的风险，比 TCO 更容易被低估。** 先看 license 这一张否决票：

| 项目 | 许可结构 | 能否 fork | 主要风险 |
|---|---|---|---|
| GrowthBook | MIT 核心 + `enterprise/` 商业 | 核心可，企业功能不可 | 抄企业目录会侵权；升级冲突 |
| PostHog | MIT 核心 + `ee/` 商业 | 核心可，`ee/` 不可 | 自建只能用免费功能；付费功能无授权 |
| Unleash | v8 起 AGPLv3 + 商业 | 可，但有限制 | 改后通过网络提供服务需开放源码 |
| Flagsmith | BSD-3 核心 + 商业 | 可 | 最宽松；企业功能另授权 |
| Flipt | v2 FCL（争议）/ v1 GPL | 可，但非竞争限制 | 不能做对外售卖的竞品托管 |
| FeatureProbe / Superposition / Flagr | Apache-2.0 | 可 | 冻结/0.x/无支持 |
| ABRouter | GPL-3.0 | 可，但衍生作品需 GPL | 停更 + 传染性 |

Fork 的真实成本不只是改代码：你要维护长期分叉、跟进安全补丁、解决 migration 冲突、重跑 CI、维护文档和 SDK。维持一个活跃项目的 fork，每年至少 1–2 人年，3 年就是 240–480 万元，**接近甚至超过一个 GrowthBook Enterprise 授权**。一个 3 人团队 fork 活跃项目，通常 6–12 个月内失去同步能力，最后变成「事实上的自研」。

升级冲突也各有各的坑：GrowthBook 发布快（5.1.0，2026-09-22），MongoDB schema 与统计引擎都会变；PostHog 自建不提供版本化 release，按 master 持续发布，官方明确不保证兼容；Unleash v8 转 AGPL，老 fork 停在 v7 就拿不到新功能；Flagsmith 发版很密（v2.286.0），实验管道还在 Beta、schema 可能变；Flipt v1→v2 是 major 重写，Git 存储模型变了；FeatureProbe/ABRouter 没有功能升级，也就没有升级冲突，但有「永远不修」的风险。

**统计引擎自研是最贵的坑。** 一个「能用」的引擎至少要有两比例 z-test / Welch t-test、比率指标的 Delta Method、SRM 检查、序贯检验、CUPED/方差缩减、多重比较、分位数指标、聚类/分层稳健方差。MVP 6–12 人月，生产级 2–3 年；还要做 A/A 校准、模拟 false positive rate、与可信实现 backtest、处理延迟数据/口径漂移。**统计引擎自研的期望成本，远高于 GrowthBook Enterprise 的授权费。** 如果一定要自研，建议把统计层做成独立服务，输入是「曝光表 + 指标表」的稳定 schema，输出是估计值/置信区间/诊断；不要嵌进控制面。

迁移成本要按 6–12 人月、双跑 4–8 周预算：SDK/曝光多端接 2–3 人月、指标迁移 2–4 人月（30–100 个指标的分子分母、归因窗口、去重逻辑都要重写）、历史回填 1–2 人月、组织迁移 1–2 人月。合计占 3 年 TCO 的 10–20%；迁移期实验速度下降，这部分机会成本常被漏算。

最后是五个常见误算：只算服务器不算人；把开源版当企业版；忽略数仓扫描成本；忽略迁移（指标口径迁移往往比 SDK 更难）；忽略机会成本（平台延期 6 个月，少跑 300 个实验，比省下的 license 更贵）。

## 5.8 三套推荐方案

先按顺序问四个问题：**数据在不在数仓？实验量多大？有没有 1–2 个能写统计代码的人？能不能接受 6–12 个月建设期？** 数据不在数仓，先建指标层；没人能读懂 CUPED 和 SRM，买再好的引擎也会退化成「看 p 值」；不能接受建设期，就买 SaaS，不要用「开源自建」的名义做一场拖延。

**方案 A：轻量——Flag 层 + 现有 BI + 轻量统计。** 适合研发 <100 人、实验 <10 个/月、没有专职数据团队的组织。Flag 层选 Flipt v2（GitOps、单二进制、零 DB）或 Unleash OSS；曝光/指标复用现有埋点与数仓，用 SQL + Python 做两比例检验/Welch t-test；治理靠 Git/PR 与人工流程。成本：1 名兼职工程师 + 90–130 万元基础设施；按 3 FTE 全成本约 1,110–1,530 万元/3 年。它的价值是「两周跑起第一个实验」，不是「支撑三年」。

**方案 B：标准——GrowthBook Enterprise 自建 + 数仓。** 适合研发 100–1,000 人、实验 10–50 个/月、已有 ClickHouse/BigQuery/Snowflake/Databricks、有 1–2 名数据/统计同学的组织。组成是：GrowthBook 自建（先用 Open Source 做 PoC，再买 Enterprise 解锁 CUPED/序贯/holdout/多组织/SSO/审计）；GrowthBook Proxy 做 Flag 缓存，SDK 本地求值，数仓做指标与曝光；指标层建统一 metric registry；治理上实验评审、审批流、分层/互斥域、holdout。成本：3 FTE + 1,130–1,700 万元/3 年（基准 1,390 万元）；复用现有团队时增量现金 310–730 万元。

为什么不是 PostHog：自建要扛 Kafka/ClickHouse/数十个服务，且付费功能 Cloud-only；GrowthBook 把重活交给数仓，控制面轻得多。为什么不是 Unleash：Flag 层很强，但没有统计引擎，规模化后只能退化成「Flag + 手工分析」。

**方案 C：大规模——GrowthBook 分析层 + 独立 Flag 层 + 薄治理层。** 适合研发 >1,000 人、实验 >50 个/月、多业务线/多端、有独立数仓与平台团队的组织。分析层用 GrowthBook Enterprise（multi-org）+ 数仓，按业务线分组织；Flag 层用 Unleash Edge 或 Flipt 做高并发、低延迟、强容灾下发；治理层自研薄层（实验注册、指标 registry、审批、审计聚合、SDK 网关），**不要把统计引擎重写一遍**。成本：3 FTE + 2 名 SRE + 1,690–2,420 万元/3 年。关键设计是三层解耦：控制面/数据面分离；Flag 求值在 SDK/Edge，分析在数仓；曝光日志是唯一事实源。**这是从「买一个产品」到「建一个能力」的分界线。**

三套方案共享同一套底座，这部分比选型更重要。最小曝光契约建议至少十个字段：

| 字段 | 说明 | 必填 |
|---|---|---|
| `event_id` | 全局唯一，幂等去重 | 是 |
| `experiment_id` | 实验注册表 ID，不是 flag_key | 是 |
| `flag_key` / `flag_version` | Flag 标识与配置快照版本 | 是 |
| `variant` | 变体 key，含 control | 是 |
| `assignment_key` | 随机化单元（user_id/device_id/session_id） | 是 |
| `assignment_unit` | user/device/session/geo/cluster | 是 |
| `exposure_time` | 客户端/服务端曝光时间，带时区 | 是 |
| `context` | 国家、端、版本、新老用户等 | 否 |
| `surface` | 页面/组件/实验位 | 否 |
| `ingest_time` | 服务端接收时间 | 是 |

五条设计原则：**experiment_id 与 flag_key 必须分离**（一个实验可能复用多个 Flag）；**flag_version 必须带**（否则中途改配置，前后曝光无法区分）；**曝光在渲染后发**（前端组件 mount/IntersectionObserver，服务端「响应返回且未降级」）；**去重键用 `(experiment_id, assignment_key)` 取最早曝光**；**SRM 作为发布门禁**（异常直接标记「不可决策」，下钻到端/版本/国家/新老用户/实验位）。这五条不依赖选哪家产品，但决定三年后结论能不能被审计。

落地节奏按「90 天闭环、180 天规模化、12 个月智能化」推进：第 1–2 周定 Flag 选型与 OpenFeature 适配；第 3–6 周建曝光管道与事实表；第 7–10 周上 SRM + 基础检验 + guardrail；第 11–13 周接 CUPED/比率指标，跑 3–5 个真实实验复盘。半年内补分层/互斥、holdout、多重比较、指标 registry；一年内再谈序贯、HTE、自动决策建议。**不要一上来做「全自动 MAB」**：MAB 会改变分流概率，导致经典的固定比例检验失效。

最后是一张「不要选」清单：不要用 PostHog 自建扛 1,000 万 DAU；不要把 FeatureProbe 作为新项目底座；不要选 ABRouter；不要把 OpenFeature 当实验平台（Tracking 仍是 Experimental，`track` 可能 no-op）；不要 fork GrowthBook 把 MongoDB 改成 Postgres（Mongoose model 遍布后端）；不要用 star 数做选型；不要为了省 license 而自建（标准自建比 Cloud 贵约 600–800 万元）。

一句话收束这一章：**开源给了你「不必从零写求值」的起点，但没有给你「不必从零建统计与治理」的捷径。** 真正的分水岭不是选 GrowthBook 还是 Unleash，而是你是否愿意把「曝光契约、指标语义、实验治理」当成三件独立的一等公民来建设——这三件事，没有任何一个开源项目能替你完成。

> **本章主要来源**：[GrowthBook 定价](https://www.growthbook.io/pricing)、[GrowthBook 自托管](https://docs.growthbook.io/self-host)、[GrowthBook 统计总览](https://docs.growthbook.io/statistics/overview)、[GrowthBook CUPED](https://docs.growthbook.io/statistics/cuped)、[GrowthBook 序贯](https://docs.growthbook.io/statistics/sequential)、[GrowthBook SDK 规范](https://docs.growthbook.io/lib/build-your-own)、[PostHog 定价](https://posthog.com/pricing)、[PostHog 曝光](https://posthog.com/docs/experiments/exposures)、[PostHog 贝叶斯](https://posthog.com/docs/experiments/statistics-bayesian)、[PostHog 自托管](https://posthog.com/docs/self-host)、[PostHog ClickHouse 架构](https://posthog.com/docs/how-posthog-works/clickhouse)、[PostHog flag 故障复盘](https://github.com/PostHog/post-mortems/blob/main/2025-09-29-flags-is-down.md)、[Unleash v8 release](https://github.com/Unleash/unleash/releases/tag/v8.0.0)、[Unleash A/B 指南](https://docs.getunleash.io/guides/a-b-testing)、[Unleash 定价](https://www.getunleash.io/pricing)、[Flagsmith 实验分析](https://docs.flagsmith.com/experimentation/analyse-an-experiment)、[Flagsmith 统计口径](https://docs.flagsmith.com/experimentation/statistics)、[Flagsmith Edge Proxy](https://docs.flagsmith.com/performance/edge-proxy)、[Flipt v2 概念](https://docs.flipt.io/v2/concepts)、[Flipt 许可](https://docs.flipt.io/v2/licensing)、[Flagr 曝光](https://openflagr.github.io/flagr/flagr_exposure)、[Flagr 数据管道](https://openflagr.github.io/flagr/flagr_eval_exposure_pipeline)、[OpenFeature 规范](https://openfeature.dev/specification/)、[OpenFeature Tracking](https://openfeature.dev/specification/sections/tracking)、[FeatureProbe 指标口径](https://featureprobe.github.io/FeatureProbe/zh-CN/reference/metric-explanation/)、[FeatureProbe 项目状态](https://github.com/FeatureProbe/FeatureProbe/blob/main/README_CN.md)、[Superposition 实验组](https://superposition.juspay.io/docs/basic-concepts/experimentation/experiment-groups/)、[ABRouter 决策文档](https://docs.abrouter.com/docs/managing/makingdecisions/)、[CUPED 论文（WSDM 2013）](https://www.exp-platform.com/Documents/2013-02-CUPED-ImprovingSensitivityOfControlledExperiments.pdf)、[SRM 论文（KDD 2019）](https://www.kdd.org/kdd2019/accepted-papers/view/diagnosing-sample-ratio-mismatch-in-online-controlled-experiments-a-taxonom)。

---

## 第 6 章 核心技术模块（上）：实验设计、分桶与统计

> 本章回答「实验怎么设计、流量怎么分、统计怎么做」：从随机化单元到 CUPED、序贯、贝叶斯、SRM。

## 6.1 实验设计的决策树

把十种实验类型排成一张菜单，是竞品文档最常见的写法；但真正有用的是菜单背后的约束求解。一个实验设计由四个变量决定：干扰结构、随机化单元、观测方式、时间尺度；类型只是这四个变量的常见组合——cluster 是「有溢出 + 簇单元」，switchback 是「有均衡效应 + 市场×时间」，interleaving 是「排序偏好 + 合并列表」，holdout 是「长期 + 小比例留出」。平台因此不必为每种类型写一套对象，而可以把它们表示为同一套 assignment / exposure / schedule / analysis 配置的不同取值。

A/B 测试的默认假设不是「随机化」，而是 SUTVA（stable unit treatment value assumption）：一个单元的结果只取决于它自己的处理，单元之间没有交互。双边市场、社交网络、内容社区、广告竞价最容易违反它；Airbnb 的定价实验发现，用户级 Bernoulli 随机化下约 **32.60%** 的估计偏差来自干扰，而不是抽样误差 [来源](https://arxiv.org/abs/2004.12489)。所以决策树的第一层不该是「我有多少流量」，而该是「处理一个单元会不会改变另一个单元的结果」。

干扰不是二值变量，而是五种形态。把它们分开，才能解释为什么「同一个 A/B 框架」在某些业务上永远做不出可信结论。

**表 6-1　五类干扰与对应设计**

| 干扰形态 | 机制 | 例子 | 首选设计 | 代价 |
|---|---|---|---|---|
| 溢出 spillover | 处理组行为直接改变对照组结果 | 社交邀请、共享库存、同城司机供给 | Cluster randomization | DEFF 膨胀；簇数少时推断难 |
| 均衡效应 equilibrium | 处理改变市场价格、匹配概率或供给 | 定价、补贴、派单、费率 | Switchback | 有效样本等于切换次数 |
| 共同冲击 common shock | 同一时段所有单元受同一事件影响 | 大促、天气、版本发布 | Switchback + 时间固定效应 | 周期共振、carryover |
| 组成变化 composition | 长期看用户结构、留存或学习行为被改变 | 推荐策略、增长策略、会员权益 | Holdout | 样本小、周期长 |
| 偏好异质 heterogeneity | 排序质量因人、因 query 而异 | 搜索、推荐排序 | Interleaving | 只测偏好，不测业务价值 |

**决策树的四条剪枝规则。** 第一，**先问干扰，再问流量**：有溢出且 cluster 足够，优先 cluster；不够再看市场×时间切换；都不行才考虑准实验或放弃。第二，**再问「要估计还是优化」**：要回答「大多少」必须固定分配；要最小化 regret 才用 MAB；MAB 的自适应分配破坏 i.i.d.，它的定位是优化器，不是测量仪 [来源](https://engineering.atspotify.com/2026/1/why-we-use-separate-tech-stacks-for-personalization-and-experimentation)。第三，**再问「短期还是长期」**：短期赢不等于长期赢，holdout 是叠加层，不是替代品。第四，**排序类先 interleaving、后 A/B**：interleaving 换敏感度，但只测偏好，不能直接当 ship 决策。

走完规则，落地的不是「一个类型名」，而是一组配置：**Assignment**（随机化单元、盐、比例、层/互斥域）、**Exposure**（谁真的被处理、触发条件）、**Schedule**（一次性、时间块、序列、长期 holdout）、**Analysis**（分析单元、方差估计、CUPED、序贯、多重比较、SRM）。同一个 Assignment 可以配不同的 Analysis：cluster 分配既能按 cluster 聚合，也能在用户级回归上用 cluster-robust 方差；同一个 Analysis 可以服务多种设计：Delta method 既算比率指标，也算 cluster 的「分子求和 / 分母去重」。平台把「设计」和「分析」解耦，才能避免类型数量爆炸；反过来，把 switchback 做成一个下拉框、却复用了用户级方差，是这类平台最常见的伪产品化。

## 6.2 随机化单元与实验类型

随机化单元是整份设计里唯一不能事后修补的选择。分析可以换估计器，方差可以换方法，CUPED 可以后补；但「按 session 随机」一旦发生，没有任何统计技巧能把用户级因果效应救回来——同一用户今天在新版、明天在旧版，留存和复购会被系统性稀释。

**表 6-2　九种随机化单元**

| 单元 | 稳定性 | 覆盖 | 主要风险 | 适用 |
|---|---|---|---|---|
| user_id | 高（登录后） | 仅登录用户 | 匿名流量丢失、多端不一致 | 长期指标、账户级功能 |
| account_id | 高 | B2B/组织 | 单元少、同事间干扰 | 席位定价、组织级功能 |
| device / installation ID | 中（重装重置） | 全部设备 | 一人多设备、IDFA/GAID 受限 | 匿名 App、UI |
| cookie | 中（可清除） | Web | 清 cookie 后重抽、跨端不通 | Web 实验 |
| session | 低 | 全部会话 | 同一用户跨会话看到不同版本 | 纯 UI、文案、加载动画 |
| geo / cluster | 高 | 地理/集群 | 单元极少、需 cluster 推断 | marketplace、供给网络 |
| market×time | 由调度决定 | 单市场 | 切换次数决定功效 | 定价、派单、补贴 |
| query | 高（单次） | 搜索/推荐 | 只覆盖排序场景 | Interleaving |
| conversation | 中 | LLM 多轮 | 样本少、组内相关大 | 助手、客服、agent |

**选择原则：随机化单元决定方差的分母，分析单元可以更细但必须折算，曝光单元可以更粗但会稀释。** 三者不必字面相同，但必须显式声明关系。Google 的 cookie 取模实验以 cookie 为随机化单元、query 为分析单元，同一 cookie 的多个 query 不独立，必须用 Delta method 把方差折算到 cookie 级 [来源](https://doi.org/10.1145/1835804.1835810)。反过来，按用户随机却把没曝光的用户算进分母，曝光率 10% 时观测效应大约只剩 10%；但**稀释的前提是曝光与处理独立**，如果某一臂加载更慢、崩溃更多，那是选择偏差，不是稀释。

字节 DataTester 的做法值得单独提：它把 `decision_id`（只算命中）与 `track_id`（只做上报）分开，让匿名期用设备 ID 分流、登录后用 uid 统计时不跳组 [来源](https://docs.byteplus.com/en/docs/DataTester/Learn-about-A-B-Testing-Products-DataTester) [来源](https://aicon.infoq.cn/2025/shanghai/speaker/9508)。这是「随机化单元、分析单元、曝光单元」三者关系的一个工程解：不强行让三个 ID 相等，而是让它们可追溯、可对齐。移动端更复杂，至少还有 installation ID、设备 ID、账号、会话四种单元；UI 实验用 installation ID 够了，权益/钱包必须用账号，跨端体验必须用账号，推送则要用账号或 token，并记录「是否实际送达」，否则打开率会被分母污染。

**三种并行设计。** A/B/n 对 `unit_id` 加盐哈希到 k 个桶，每臂样本约 `16σ²/Δ²`（95% 置信、80% 功效），总样本约 `k×n`，再叠加多重比较校正。Factorial 全析因需要 `2^k` 个格子，总样本 `2^k × n_cell`，交互检验功效远低于主效应；NIST 手册明确说 5 个及以上因素时全析因不再高效 [来源](https://www.itl.nist.gov/div898/handbook/pri/section3/pri333.htm)，DoorDash 用部分析因研究留存，说明「多因素、低成本、可接受别名」是它的边界 [来源](https://arxiv.org/abs/2311.14698)。实施上必须「联合分配」：平台把因素组合作为一个 variant 下发，否则交互效应无法识别。

Crossover 让每个用户做自己的对照：按随机顺序接受两种处理（TC 或 CT），比较同一用户两阶段的差异，消掉用户间的稳定差异。微软的 FORME 论文证明，在相同流量和时长下，crossover 的方差通常不高于并行设计，并提出 re-randomized design 检验 carryover [来源](https://arxiv.org/abs/1501.00450)。它的代价是学习/习惯化会破坏可逆性，两阶段之间需要 washout；序列随机化只平衡顺序，不消除时间趋势。它适合 UI 响应、延迟、推荐点击这类可逆的短期处理，不适合留存、付费、不可逆的功能。

把 6.1 的四变量与本节九种单元组合，十种实验类型可以在一张表里定位；平台的产品化重点不是类型数量，而是**单元注册表 + 分析插件**。建实验时强制声明随机化、分析、曝光三个单元并校验关系，比事后做 SRM 排查便宜得多。美团 BETA 把 CUPED、Delta、Bootstrap、Fisher/Neyman、SRM、MDE 做成方法库，而不是把统计写死在某个实验类型里，也是同一个思路 [来源](https://tech.meituan.com/2025/08/22/meituan-AB-Online-Controlled-Experiment-08.html)。

## 6.3 正交分层、互斥与 Holdout

分层、互斥、holdout 常被并列成三个功能，其实它们管的是三种不同资源：**分层管并行度，互斥管参数冲突，holdout 管长期总量**。三者叠加，才构成一个平台的「流量账本」。

Google 2010 年的重叠实验设施把系统拆成三个概念：domain（域，流量的一份划分）、layer（层，参数的子集）、experiment（在某个流量划分上修改若干参数）。规则是：一个请求每层最多进一个实验；同层实验互斥，不同层用 `layer_id` 作盐、近似正交。分桶写成 `f(cookie, layer_id) % 1000`，而不是 `f(cookie) % 1000`，这是层间独立的关键 [来源](https://doi.org/10.1145/1835804.1835810)。Google 还引入了 launch layer（发布层）：它永远在默认域、拥有全量流量，把实验参数写成「新的默认值」，普通层实验仍可覆盖；这样灰度发布和实验共用一套设施，发布过程本身也可被度量。

**容量账。** 若有 `L` 个层、每层覆盖 `c_l`、实验在本层占 `s`，则样本期望是 `N × c_l × s`；一个用户最多同时进入 `L` 个实验。**分层的本质是用流量换并行度**：层数越多，单实验能拿到的流量越少；一个需要 50% 流量才能检出 1% 效应的实验，在 10 层结构里可能永远拿不到足够样本。

正交性是假设，不是保证。不同盐、不同 `layer_id` 理论上独立，但短 key、相似 key、弱雪崩会让相关性浮现；工程上不能只靠假设，要用 2×2 卡方、Cramér's V，或用两套盐跑 A/A，确认两个层的分组没有关联。

**互斥的两种实现。** 区间互斥让每个实验占一段 `[start, end)`，简单、可计算容量，但不能表达复杂的「部分重叠」约束；过滤器/排除组更灵活，但需要共享状态、顺序敏感，边缘/无状态 SDK 很难做。GrowthBook 用 `filters` 和 `namespace` [来源](https://docs.growthbook.io/lib/build-your-own)，Google 用区间 + 层，Optimizely 用 mutex group，Statsig 用 layer 并锁定运行中的实验 [来源](https://docs.statsig.com/experiments/layers-overview)。两者本质相同：**用确定性的区间划分代替运行时状态**，代价是每实验只能拿 1/k 流量。

**Holdout 是长期对照资产，不是实验类型。** 它留出一小部分用户，在较长时间内看不到一组新功能/新策略，再从非 holdout 用户中抽等规模样本对照，比较累计指标差异。三家头部平台的默认值差异很大：

**表 6-3　三家平台的 holdout 设计**

| 平台 | 默认比例 | 对照构造 | 周期建议 | 关键限制 |
|---|---|---|---|---|
| Statsig | 1%–2% | 从非 holdout 随机抽等规模样本 | 3–6 个月 | holdout 内 gate 返回 false；层内实验返回 layer defaults |
| GrowthBook | 默认 5% | 非 holdout 中取同样 5% 做 measurement | 冻结后再跑 2–4 周 | 不能给带 conversion window 的指标；需 lookback |
| Eppo | 客户在 withheld traffic 内设定 | `status_quo` vs `all_shipped` | 客户定义 | 需把 holdout 作为 experiment 记录，并链接子实验 |

来源：Statsig [来源](https://docs.statsig.com/experiments/holdouts-introduction)；GrowthBook [来源](https://docs.growthbook.io/app/holdouts)；Eppo [来源](https://docs.geteppo.com/experiment-analysis/holdouts/)。

**Holdout 的功效由 holdout 组大小封顶，不由总流量决定。** 1% holdout 在 1000 万 DAU 上是 10 万人；若对照也抽 10 万人，等于每臂 10 万。以 10% 基线转化率为例，80% 功效下这个样本只能检出约 **0.38pp** 的绝对提升（相对 3.8%），检不出 1% 的相对变化——后者需要约 **142 万人/臂**。所以 1% holdout 适合看方向性、大效应，不适合验证精细提升；要检测小效应，要么把 holdout 扩到 5% 以上，要么接受更粗的决策阈值。统计上还有两个难点：holdout 可能被社交、广告的间接接触污染，效应是「直接 + 部分间接」的混合；带 conversion window 的指标需要回看历史，冻结时点与测量窗口必须提前写死。

**表 6-4　三层流量账本**

| 机制 | 资源单位 | 解决什么 | 主要代价 | 失效模式 |
|---|---|---|---|---|
| 分层 | 层内流量 | 多实验并行 | 单实验样本稀释 | 层间相关、层数过多 |
| 互斥 | 互斥域内桶 | 同参数/同界面冲突 | 每实验 1/k 流量 | 运行中换层、容量硬约束 |
| Holdout | 全局保留比例 | 长期累计增量 | 功效、周期 | 太小/太短/污染/漏 gate |

## 6.4 Switchback / Cluster / Interleaving / MAB

当 SUTVA 被违反，标准 A/B 的对照组就不再是对照组。四种设计分别对付四类违反：cluster 对付溢出，switchback 对付均衡效应与共同冲击，interleaving 对付排序偏好的异质性，MAB 对付「多臂、快速反馈、以累计收益为目标」的场景。它们不是四个可以随便替换的「实验类型」，而是四种不同的**兑换关系**。

**表 6-5　四种非标准设计的对照**

| 设计 | 干扰类型 | 随机化单元 | 分析单元 | 有效样本 | 核心假设 | 产品化程度 |
|---|---|---|---|---|---|---|
| Cluster | 溢出 | 城市/卖家/创作者/社群 | cluster 或用户级 + CRVE | 簇数 | 簇内相关、簇间无溢出 | 中（GrowthBook、Airbnb、LinkedIn） |
| Switchback | 均衡、共同冲击 | 市场×时间段 | block | 切换次数 | 非预期、m 阶 carryover、时间平稳 | 低中（Eppo closed Beta） |
| Interleaving | 偏好异质 | query/session | query | 非平局 query 数 | 合并算法与 credit 规则无偏 | 低（多为专用系统） |
| MAB | 无干扰但自适应 | 用户/上下文 | 臂 | 无固定每臂样本 | 平稳、即时反馈、单目标 | 中（部分平台以 bandit 提供） |

**Cluster randomization。** 以 cluster（城市、卖家、创作者、listing 簇、学校、家庭）为单位随机分配，簇内所有单元接受同一版本。分析时在 cluster 层聚合，或在单元层用 cluster-robust 方差；样本量用 `DEFF = 1 + (m - 1) × ρ`，`m` 是簇平均大小，`ρ` 是 ICC。若 `m=100`、`ρ=0.05`，DEFF≈5.95，10 万用户只相当于约 1.7 万独立用户。簇只有十几个时，CRVE 本身不可靠，应改用 wild cluster bootstrap 或 randomization inference。

Airbnb 的定价 meta 实验用观测数据构造 listing 簇，与 Bernoulli 随机化并列比较，发现 Bernoulli 估计中 **32.60%** 来自干扰偏差 [来源](https://arxiv.org/abs/2004.12489)。LinkedIn 用 ego-cluster 随机化 ego 的邻居，约 20 万 ego 需要处理约 1000 万个体；loss rate 会带来保守偏差，作者用 degree 分层控制 [来源](https://arxiv.org/abs/1903.08755)。这说明 cluster 不是「更保守的 A/B」，而是「换一个随机化单位重新定义 estimand」。

**Switchback。** 把一个聚合单元（城市、市场、区域）在时间上切成若干 block，每个 block 随机分配 treatment 或 control；该单元、该时段的所有用户接受同一版本，共享供给、价格均衡、司机/骑手池的干扰被「同一时段的同一市场」吸收。Bojinov、Simchi-Levi、Zhao 把设计形式化：在 carryover 阶数 `m` 下，block 长度、切换次数、carryover 假设必须一起定 [来源](https://arxiv.org/abs/2009.00148)。关键参数是：block 长度大于 carryover 阶数；切换后加 burn-in/burn-out；时间趋势用随机化时点和固定效应处理。

分析单位是 **block（市场×时间段）**，不是用户：先按 block 聚合，再做配对/固定效应回归；标准误 cluster 到市场或 block。**有效样本是切换次数，不是用户数**；把用户级 n 代进功效公式，是这类实验最常见的统计错误。ABAB 固定交替在有周内周期时会和周期共振，更稳的是在 strata 内随机化切换顺序，或随机化 block 长度。Eppo 已把 switchback 做成 closed Beta：environment entity、带时间窗的 assignment 表、burn-in/out，以及 join 诊断 [来源](https://docs.geteppo.com/experiment-analysis/switchbacks/)。

**Interleaving。** 把两个 ranker 的结果合并成一个列表呈现给同一用户，按点击/转化把 credit 分给两个 ranker，再用「用户偏好哪个 ranker」的比例做检验。经典 Team Draft 每个位置抛硬币决定本轮谁选，被选中的 ranker 给出最靠前且未用过的 item；统计单位是 query/session，不是用户，同一列表内竞争消掉了用户间、query 间方差，所以敏感度远高于用户级 A/B。

Airbnb 在 KDD 2025 报告：搜索排序场景下，interleaving 与反事实评估结合，可把敏感度提升到传统 A/B 的**最多 100 倍**（取决于方法与指标）[来源](https://arxiv.org/abs/2508.00751)。但论文另一处写「达到同等统计功效所需流量约为 A/B 的 1/50」，叠加反事实评估后部分指标可达 1/100；二手转述常把两者合并成「100 倍」，**存在不同说法**。选型时要问「在哪个指标、哪种合并算法、什么 query 分布下测得的倍数」，而不是记一个常数。

检验通常从符号检验开始：每个 query 记 A 赢/B 赢/平，在非平局样本上做二项检验（p=0.5）。要检测 55% vs 50% 的偏好差，单侧 0.05、80% 功效约需 **620 个非平局 query**；若平局率 40%，实际要跑约 **1,030 个 query**。更精细的是对 credit 差值做配对 t 检验或 bootstrap，并对长尾 query 加权；ECIR 2023 的 Stat-weight 指出，TD 在均匀 query 上不错，但真实搜索是长尾，少数高频 query 会主导总 credit，按 query 的统计检验结果分配权重更准、更敏感 [来源](https://arxiv.org/abs/2303.10094)。

**MAB。** 在实验过程中根据观测 reward 动态调整各臂流量，把更多流量给当前看起来更好的臂，以最大化累计收益、最小化 regret。常见策略是 Thompson Sampling 和 UCB。它与 A/B 的根本区别是：A/B 的目标是「估计效应」，MAB 的目标是「优化决策 policy」；自适应分配破坏 i.i.d.，朴素 t 检验有偏，需 IPW/DR/Bayesian。Spotify 明确不在实验平台用 MAB，理由是单指标、反馈慢、多目标配置复杂 [来源](https://engineering.atspotify.com/2026/1/why-we-use-separate-tech-stacks-for-personalization-and-experimentation)。

**表 6-6　四种设计的兑换关系**

| 设计 | 换到 | 付出 |
|---|---|---|
| Cluster | 抗溢出、可解释的整组效应 | DEFF 膨胀、簇数少时推断难 |
| Switchback | 吸收均衡效应与共同冲击 | 有效样本=切换次数、周期与 carryover 设计复杂 |
| Interleaving | 敏感度提高 1–2 个数量级 | 外部效度：只测排序偏好，不测收入/留存 |
| MAB | 累计 regret 最小 | 不可估计 ATE、推断复杂、易被干扰误导 |

这张表是本章的第一个结论：**实验设计没有免费午餐，只有「用哪种方差/偏差换哪种决策速度」**。平台的价值不是把四种设计都做成按钮，而是让实验 owner 看清每种选择在兑换什么，并在分析侧强制配套的方差方法。

## 6.5 分桶与哈希工程

分桶的本质，是把「用户身份 + 实验盐 + 算法版本」映射成一个稳定、可复现的伪随机数。多数的分流事故不是哈希不够随机，而是盐、桶数、版本、分流单元和曝光口径在变更中被悄悄破坏。把分桶写成纯函数 `bucket = H(salt ‖ unit) mod N`，它必须同时满足四条不变量：确定性、均匀性、单调性、稳定性；最难的是后两条，因为它们取决于分桶空间如何被切分，而不是哈希函数本身。

1. **确定性**：同样的 `(salt, unit, N, version)` 在任何语言、任何机器、任何时间都得到同一个结果。跨语言一致性比均匀性更难，因为字符串编码、整数位宽、取模语义都可能不同。
2. **均匀性**：大量 unit 落入每个桶的概率近似 `1/N`。有限哈希空间对 `N` 取模必然有微小偏差，关键是偏差要远小于实验要检测的效应。
3. **单调性**：覆盖度从 10% 扩到 20% 时，原来在 10% 里的用户必须全部保留。这条不变量决定「放量」会不会变成「重洗」。
4. **稳定性**：改文案、改定向条件、改指标定义，都不应该改变用户的桶；只有显式修改 salt、权重或算法版本才允许重洗。

四条里最难的是第三、四条，因为它们不是哈希函数本身的性质，而是**分桶空间如何被切分**的性质。很多平台在覆盖度上做对了，在权重上却做不到。

**分桶是一份跨端契约。** 契约字段是 `(hash_algorithm, salt, bucket_count, hash_version, unit_type, encoding, separator, range_rule)`；它至少出现在 SDK 求值、服务端兜底、离线复盘、曝光日志校验四个地方，每多一个位置就多一份「契约漂移」风险。防御只能靠**金标测试向量**：固定几百组 `(salt, unit)`，把期望桶值写进 JSON，所有语言的 CI 跑同一份文件；GrowthBook 有 400+ 条语言无关用例 [来源](https://docs.growthbook.io/lib/build-your-own)。

**哈希选型：不是越强越好。** 分桶不是密码学场景，真正重要的是跨语言可复现、分布均匀、计算便宜、永不回退。SHA-256 的价值在抗碰撞，不在均匀性；MurmurHash3、FNV-1a 在非对抗场景下完全够用。换一个更快的哈希，通常不会改变实验结果，却能把单次求值从几十微秒压到几微秒。

**表 6-7　五种哈希的工程对比**

| 算法 | 输出位宽 | 相对速度 | 典型使用者 | 工程注意点 |
|---|---|---|---|---|
| MurmurHash3 x86_32 | 32 bit | 很快 | Optimizely、Unleash | 有符号整数溢出；不同语言的 32 位实现要统一 |
| SHA-1 | 160 bit（常截断） | 快 | LaunchDarkly | 取前 15 个十六进制字符（60 bit）；大小写要统一 |
| SHA-256 | 256 bit | 中等 | Statsig | 取前 8 字节时注意大小端；不要用字符串比较 |
| FNV-1a 32 | 32 bit | 极快、实现最短 | GrowthBook（v2 双重 FNV） | 雪崩性弱，单次哈希易有偏，必须二次混淆 |
| MD5 | 128 bit | 中等 | 早期自研系统 | 除历史包袱外没有理由继续用 |

GrowthBook 的案例最值得研究：v1 是 `fnv32a(value + seed) % 1000`，官方注释直言「在并行实验时有偏」；v2 改成 `fnv32a(fnv32a(seed + value) + "") % 10000`，用双重哈希改善雪崩性，并把桶数从 1000 提到 10000 [来源](https://docs.growthbook.io/lib/build-your-own)。这段历史说明两件事：FNV 单次哈希对拼接字符串混合不够，二次哈希是廉价补救；**算法升级必须版本化**，否则所有在线实验会在发布瞬间被重洗。

**表 6-8　六家平台的分桶机制（仅列官方文档/源码可确认者）**

| 平台 | 哈希与桶数 | 盐/版本 | 分层与互斥 |
|---|---|---|---|
| GrowthBook | FNV-1a 32，v2 双重哈希，10000 桶（v1 为 1000） | 实验 key 或显式 seed；`hashVersion` 版本化 | namespace + filters；区间不重叠即互斥 |
| LaunchDarkly | SHA-1 前 15 hex（60 bit），权重分母 100000 | flag 自带 salt；rollout 可带独立 seed | segment + rollout；无显式分层 |
| Statsig | SHA-256，实验 10000 / 层 1000 | 每条规则唯一 salt；可复制 salt | layer + holdout |
| Optimizely | MurmurHash3，bucketing ID；桶数未公开（待核实） | experiment ID + bucketing ID | mutex group |
| Eppo | 未公开具体算法，按实验 key 加盐的确定性哈希 | allocation key | allocation + entry point |
| Unleash | 归一化 MurmurHash | 按 flag/环境 | 无分层，靠 strategy 组合 |

这张表最重要的不是参数，而是**公开程度的差异**。GrowthBook、Statsig、LaunchDarkly 的文档或源码足以复刻其分桶；Eppo 只说「deterministic hashing function salted with the experiment key」，没有给位宽和取模方式 [来源](https://docs.geteppo.com/sdks/architecture/overview/)；Optimizely 的文档入口在 2026 年迁移，从 Go SDK 源码可确认 MurmurHash 和 bucketing ID，但桶数未公开 [来源](https://raw.githubusercontent.com/optimizely/go-sdk/refs/tags/v0.1.0/optimizely/decision/experiment_bucketer_service.go)。对标时不能把「文档没写」当「没有」，也不能把「有这个名字」当「实现相同」。

**模运算偏差：桶数必须远小于哈希空间。** 设哈希空间 `H`、桶数 `B`，最大相对偏差约 `B/H`。32 位哈希配 10000 桶，`B/H ≈ 2.3×10⁻⁶`，可以忽略；8 位哈希配 100 桶，偏差高达 50%，绝对不能接受。结论不是「取模一定有偏」，而是「桶数必须远小于哈希空间」；小哈希应改用乘移法或拒绝采样。

**盐的语义：一个实验一个盐。** 盐不是加密，而是去相关。两个实验用同一个盐、同一个 unit、同一个桶数，桶值完全相同，分组高度相关，差异方差被低估、显著性被高估；极端情况下两个实验其实是同一批人。LaunchDarkly 用 `SHA1("{flagKey}.{salt}.{contextValue}")`；Statsig 每条规则生成唯一 salt，复用同一条规则时 50%→0%→50% 会回到同一批人 [来源](https://docs.statsig.com/sdks/how-evaluation-works)；GrowthBook 默认用 experiment key 作 seed；Google 把 layer 编进哈希。

拼接时用 `\x1f` 分隔、长度前缀，避免 `("ab","c")` 与 `("a","bc")` 的歧义；编码统一 UTF-8，ID 统一 trim、lowercase、NFC——Python 的 UTF-8 字节、JS 的 UTF-16 码元、Java 的代理对，都可能让同一字符串产生不同哈希。

**空 ID 的处理，三家平台完全不同。**

**表 6-9　空 unit 的行为差异**

| 平台 | 空 ID 行为 | 后果 |
|---|---|---|
| GrowthBook | `hashValue == ""` 时直接不入组 | 匿名流量不进实验，样本少但干净 |
| Statsig | 空 unitID 仍会被分桶 | 空 ID 全进同一桶，可能静默污染对照组 |
| LaunchDarkly | context value 为空时返回 `0.0` | 永远落在第一个桶 |

来源：GrowthBook [来源](https://docs.growthbook.io/lib/build-your-own)；Statsig [来源](https://docs.statsig.com/sdks/how-evaluation-works)；LaunchDarkly [来源](https://launchdarkly.github.io/ruby-server-sdk/LaunchDarkly/Impl/EvaluatorBucketing.html)。三种行为没有对错，但如果业务侧不 guard，空 ID 会静默地把所有匿名流量塞进对照组或第一桶；平台应把「空 ID 策略」做成显式配置，并在曝光日志里带上 `is_empty_id` 标记。

**桶数与版本：一旦上线就不能悄悄改。** 100 桶只能表达 1% 的粒度，10000 桶可以表达 0.01%；LaunchDarkly 用 100000 作权重分母，GrowthBook v2 和 Statsig 实验用 10000，Statsig 的 layer 用 1000。桶数不是越大越好：卡方拟合优度要求每桶期望频数 ≥5，10000 桶至少需要 5 万样本。工程折中是：**权重用万分比整数存储，桶数固定 10000，永远不改**。要改必须走「双写 + 对比 + 切换」：两套哈希都算但只用旧版结果，写进曝光日志跑 1–2 周，对比桶分布与指标差异，再灰度切换。直接改常量会让所有在线实验瞬间重洗。

**扩量：coverage 可以单调，weights 不行。** 这是分桶工程里最反直觉、也最值得写进规范的一条。GrowthBook 的 `getBucketRanges` 是这样切的：

```
cumulative = 0
for w in weights:
    start = cumulative
    cumulative += w
    ranges.push([start, start + coverage * w])
```

注意 `start` 是**权重累加起点**，不随 coverage 变化；只有区间右端随 coverage 缩放。以 50/50、coverage 0.5 为例，A 是 `[0, 0.25)`，B 是 `[0.5, 0.75)`；coverage 调到 1.0 后，A 是 `[0, 0.5)`，B 是 `[0.5, 1.0)`。原来在 `[0.5,0.75)` 的 B 用户仍是 B，`[0.25,0.5)` 的用户从「未入组」变成 A——**没有任何已入组用户翻转** [来源](https://docs.growthbook.io/lib/build-your-own)。

但这个结论依赖「锚定式」切分：每个变体的起点由权重累加决定，coverage 只拉长右端。如果平台把区间整体连续缩放，扩量仍会移动边界；选型或自研时，必须把切分逻辑写成单元测试，而不是假设「扩量天然安全」。权重一变就不行了：50/50 → 70/30 时，A 的区间从 `[0,0.5)` 变成 `[0,0.7)`，原本在 `[0.5,0.7)` 的 B 用户会翻成 A——在同一个 `[0,1)` 空间里改变占比，必然移动边界。

所以工程规范是：**放量只改 coverage，不改 weights；必须改比例时，上新实验（新 salt）或开 sticky bucketing（把用户→变体映射持久化，配置变更时保持老用户分组）；绝不在实验中途改桶数或哈希版本。** 新实验意味着新 cohort，历史数据不能直接比；sticky 能保住体验，但实际比例会偏离计划值，分析时要按实际曝光比例做 SRM 检查。

**曝光日志与 assignment 分开建模。** 三个事件必须区分：assignment（分桶函数算出了变体，可以在用户还没看到任何东西时发生）、exposure（用户真的有机会看到变体）、metric（曝光后的行为）。三者是 eligible → assigned → exposed → converted 的漏斗，任何一层漏了都会变成 SRM 或稀释。最常见的错误是**把 assignment 当曝光**：只要调用 `getAssignment` 就打点，不管用户有没有进入实验路径；后果是大量「分配了但没看到」的用户被算进分母，效应被稀释。Eppo 的 assignment logger 只在 `get<Type>Assignment` 被调用时触发，建议把调用点放在「代码分叉处」；需要预取时用 Entry Point 在分析侧过滤 [来源](https://docs.geteppo.com/sdks/event-logging/assignment-logging/)。

Google 的论文专门讨论了「触发」：实验可能分配了全部流量，但只有条件满足时才真正展示。只在触发时记录事实，对照组没有对应记录，就无法比较；正确做法是同时记录 factual 和 counterfactual（对照组「本可以被触发」时的行为），分析只在触发集合上进行。这就是 ITT 与 TAT 的取舍：ITT 无偏但稀释，TAT 更接近真实但曝光是事后变量。触发分析的价值在于把「曝光」定义成**分配前就能确定的触发条件**，既聚焦又保持随机性。

曝光表的主键应该是 `(unit_id, experiment_key, config_version)` 的第一次曝光，而不是每次渲染都写一行。重复曝光不只是存储膨胀：如果某一臂页面更慢、重试更多，重复行会更多，指标被系统性高估。Eppo 允许表里有重复行、分析时自动去重；同一个 subject 出现在多个变体里，直接移除 [来源](https://docs.geteppo.com/sdks/event-logging/assignment-logging/)。这条规则应写进所有曝光表 ETL：**一个 unit 在一个实验里只能有一个变体，多变体视为数据错误，不是「取最新」**。

## 6.6 统计引擎：频率派

统计引擎不是「选一个检验」，而是一条五层管线。很多平台把它做成 frequentist / Bayesian / sequential 三选一的下拉框，真正决定结果可信度的是下拉框背后的五层是否对齐。

**表 6-10　统计引擎的五层**

| 层 | 解决什么 | 典型实现 | 常见事故 |
|---|---|---|---|
| 指标语义 | 随机化单元、分析单元、曝光口径、聚合方式 | 用户级均值、比例、比率、分位数；winsorization | 用户随机化却按 session 分析 |
| 估计器 | 点估计与 estimand | 双样本比例 z、Welch t、Delta method、分位数、CUPED | 比率指标当均值算 |
| 方差 | 估计不确定性 | 解析方差、Delta、cluster robust、bootstrap | CUPED 点估计配未调整方差 |
| 有效性 | 结果是否可信 | SRM、A/A、前置期平衡、多重比较、序贯 α | SRM 不拦截、peeking 不校正 |
| 决策 | 是否上线/回滚 | p 值/CI、chance-to-beat、expected loss、guardrail | 把「显著」当「有效」 |

一条设计原则：**估计器、方差和决策规则必须成对出现**。CUPED 的点估计必须配 CUPED 的方差；序贯的 p 值必须配 always-valid 的置信区间；Bayesian 的后验必须配事先约定的决策阈值。平台上最常见的错误不是公式写错，而是把不同层的部件拼在一起。

转化率、留存率这类 0/1 指标，用双样本比例 z 检验。**检验用 pooled 方差，CI 用 unpooled 方差**：检验在原假设 `p_T = p_C` 下构造，CI 不在原假设下构造。数值例：各 5 万人、10% vs 10.5%，`p_pool=0.1025`，`SE=0.001918`，`z=2.607`，双侧 `p=0.0091`——5% 显著、1% 不显著。小样本或极端比例（期望频数 <5）改用 Fisher 或 Beta-Binomial 精确区间。

均值型指标用 Welch t，不假设两组方差相等，自由度用 Welch-Satterthwaite 近似；GrowthBook 官方明确用这套 [来源](https://docs.growthbook.io/statistics/details)。均值型指标的方差通常远大于比例指标：同样 5% 的相对提升，客单价所需样本可能是转化率的几倍到几十倍；这也是收入类指标必须做 CUPED 或 winsorization 的原因。

**Delta method 是比率指标的正确打开方式。** 人均 GMV = GMV / 用户数、CTR = 点击 / 曝光、客单价 = 收入 / 订单数，分子分母都随机，不能把比值当成普通均值。一阶近似是：

```
R = Ȳ / X̄
Var(R) ≈ (1/(n X̄²)) * [ Var(Y) - 2R*Cov(Y,X) + R²*Var(X) ]
```

数值例：10 万用户，人均收入 `Ȳ=50` 元，人均 session `X̄=5`，`R=10` 元/次；`Var(Y)=900`、`Var(X)=4`、`Cov(Y,X)=1.5`。代入得 `Var(R)=0.000508`，`SE(R)=0.02254`；忽略分母随机性会得到 `0.01897`，低估 **15.8%**，t 值高估约 19%。失效场景：分母接近 0 或为负时改用 Fieller 区间或 bootstrap；重尾先 winsorize；分母是「事件」而单元是「用户」时，必须先在用户级聚合再套公式 [来源](https://docs.geteppo.com/statistics/confidence-intervals/statistical-nitty-gritty/)。

分位数指标（P90/P99 延迟、头部用户消费）的 estimand 是 `Δ_ν = Q_T(ν) - Q_C(ν)`。分位数没有闭式方差，工业界用「顺序统计量 + 二项分布」构造 CI；要估 P99 至少需要 `n > 4p/(1-p) ≈ 396` 个样本，P99.9 约需 4,000 个。工程限制：事件级 P50 与用户级 P50 可能差一倍（GrowthBook 例子是 2 与 5）；含零/不含零、capping 都会改变结果；GrowthBook 明确分位数不支持 CUPED 和序贯，Eppo 也把 percentile 排除在 CUPED 外 [来源](https://docs.growthbook.io/statistics/quantile)。

**表 6-11　指标类型与估计器**

| 指标 | 估计器 | 方差 | 不能做什么 |
|---|---|---|---|
| 比例 | 双样本 z（pooled 检验 / unpooled CI） | `p(1-p)(1/n_T+1/n_C)` | 小样本正态近似 |
| 均值 | Welch t | `s_T²/n_T + s_C²/n_C` | 重尾不做处理 |
| 比率 | Delta method | 一阶泰勒，含协方差 | 分母近 0/负 |
| 分位数 | 顺序统计量 + 二项 | 秩 CI | CUPED/序贯 |
| 聚类 | cluster 级或 CRVE | DEFF / sandwich | 少簇不校正 |

整条管线的顺序是：**先 SRM，再估计，再方差缩减，最后决策规则**。顺序反了，后面所有计算都建立在不可信样本上。

## 6.7 CUPED 与方差缩减

CUPED（Controlled-experiment Using Pre-Experiment Data）的核心只有两步：找一个实验前就能观测、且与实验期指标高度相关的协变量 `X`，用回归系数把 `Y` 中可由 `X` 解释的部分扣掉。

```
θ = Cov(Y, X) / Var(X)
Y_cv = Y - θ * (X - X̄)
τ̂ = mean(Y_cv | T) - mean(Y_cv | C)
```

若 `θ` 已知，`Var(Y_cv) = Var(Y)(1 - ρ²)`，其中 `ρ = Corr(Y,X)`。因此方差缩减比例是 `ρ²`，等效流量倍数是 `1/(1-ρ²)`，MDE 缩小 `sqrt(1-ρ²)`。数值：`ρ=0.5` → 方差缩减 25%、等效多 33% 流量、MDE 缩到 86.6%；`ρ=0.7` → 缩减 49%、等效 1.96 倍、MDE 71.4%；`ρ=0.3` → 只缩减 9%、等效 1.10 倍。这就是为什么 CUPED 对高频、强自相关的指标（活跃天数、停留时长、GMV）效果最好，对低频、偶发指标（首次购买、流失）效果有限：不是方法不行，是 `ρ` 上不去。

**表 6-12　CUPED 家族**

| 方法 | 协变量 | 模型 | 适合 | 代价 |
|---|---|---|---|---|
| 经典 CUPED | 同一指标的前置期值 | 线性回归，单个 θ | 高频、自相关指标 | 新用户/无历史指标无效 |
| CUPAC | 前置期指标 + 用户属性/行为 | 任意 ML 模型预测 Y | 非线性、多源协变量 | 训练/推理复杂，过拟合风险 |
| CUPED++ | 多个前置期指标 + assignment properties | 每个变体分别做 ridge，再用预测值调整 | 转化/留存等无前置期类比的指标；新用户 | 计算量大；Eppo 只在高层次结果页用 |
| CURE | 跨指标、跨人群的前置期信息 | 回归/机器学习扩展 | 新用户、非自相关指标 | 需要 warehouse-native 数据 |

**同名不同物。** Statsig Cloud 版自动应用 CUPED，前置期是「每个用户曝光前 7 天」，没有前置期数据的用户用 stratification 分 strata 后组内估计再聚合 [来源](https://docs.statsig.com/experiments/statistical-methods/methodologies/cuped)。GrowthBook 默认 14 天，做 CUPED + post-stratification，并排除分位数、bandit 目标比率、legacy ratio [来源](https://docs.growthbook.io/statistics/cuped)。Eppo 的 CUPED++ 把多指标前置值和 assignment properties（≤100 个取值）放进 ridge，分别对每个变体拟合；计算量大，所以只在 metrics overview 页应用，模型每天更新一次 [来源](https://docs.geteppo.com/statistics/cuped/)。对比平台时不能只问「支不支持 CUPED」，要问协变量、窗口、更新频率、哪些指标被排除。

**数值示例。** 沿用 6.6 的例子：基线 10%、实验组 10.5%、每组 5 万人，`SE=0.1918pp`，`z=2.607`。若 `ρ=0.5`，`SE_cv=0.1661pp`，`z_cv=3.010`，`p≈0.0026`——原本在 1% 水平不显著的结果，CUPED 后变成 1% 显著；等效流量从 10 万降到 7.5 万，MDE 从 0.532pp 降到 0.460pp。这个计算假设 `ρ` 已知且稳定；真实场景中 `ρ` 会随指标、人群、季节变化，上线前应用历史实验回测「方差缩减比例」，而不是看「p 值变小」。

**判断：CUPED 不是免费午餐，是用数据工程换方差。** 你要为每个用户、每个指标维护前置期聚合，保证前置期与实验期口径一致，还要处理新用户、指标变更、数据回填。没有数仓和指标治理的团队，CUPED 的维护成本会超过收益。

## 6.8 序贯检验与贝叶斯

固定样本的 p 值只在一个预先定好的样本量上有效。如果你每天看、看到显著就停，实际假阳性率会远高于 5%。Evan Miller 的经典模拟：A/A 测试、真实转化率 50%、连续监控并在首次显著时停止，假阳性率约 **26.1%**，是名义 5% 的 5 倍多；如果偷看 10 次，想让实际显著性维持在 5%，单次报告的显著性要做到约 1% [来源](https://www.evanmiller.org/how-not-to-run-an-ab-test.html)。Optimizely 的模拟更激进：5,000 访客的 A/A 测试，若每个访客后都看一次，至少一次错误宣布赢家/输家的概率约 **57%**；每 500 人看一次约 26%，每 1,000 人看一次约 20%；用他们的 sequential 方法后降到约 3% [来源](https://www.optimizely.com/field-notes/articles/statistics-for-the-internet-age-the-story-behind-optimizelys-new-stats-engine)。这些数字依赖模拟设定，不能当成 universal constant，但方向是确定的：**peeking 的代价随查看次数和停止规则放大**。

**Alpha spending / group sequential** 预先定好 `K` 个看点，把总 α 按 spending function 分配。Pocock 早期更容易停，O'Brien-Fleming 早期极难停、后期接近 1.96，对最终功效损失最小。两看、`α=0.05`、`t=0.5`：OBF 的 `α*(0.5)=0.00557`，第一次需 `z>2.77`；Pocock 的 `α*(0.5)=0.0310`，第一次需 `z>2.16`。限制是**只能在预定看点看**：计划 3 次、第 4 次偷看并停，α spending 的保证就破了。

**mSPRT 与 confidence sequence** 不预设看点，任意时刻看都有效。mSPRT 把效应量当成先验分布，对每个可能效果计算似然比再混合；Statsig 给出完整 CI 公式，`τ` 是 mixing parameter，CI 始终比固定样本宽。Confidence sequence 用时间均匀的边界：Eppo 默认 Howard 等（2021）的 time-uniform CS，`N_tune=10,000` [来源](https://docs.geteppo.com/statistics/confidence-intervals/analysis-methods/)；GrowthBook 用 Waudby-Smith 等（2023）的 asymptotic CS，`N*=5,000`，并明确 sequential CI 一致地宽于 fixed CI，`N*` 越接近决策样本量损失越小、且必须实验前固定 [来源](https://docs.growthbook.io/statistics/sequential)。Eppo 的 sequential hybrid 运行期用 sequential、结束切回 fixed，CI 约宽 10–15%。

**表 6-13　五种读数方式的取舍**

| 方法 | 允许的查看时点 | 能否早停 | 代价 | 适用 |
|---|---|---|---|---|
| 固定样本 | 只在预定样本量 | 否 | 最大功效 | 计划稳定、样本充足 |
| Group sequential | 只在预定 K 个看点 | 可以 | 少量功效损失；需提前设计 | 临床/高风险、中期分析 |
| mSPRT / always-valid p | 任意时刻 | 可以 | CI 更宽；τ 需调 | 持续监控、早停收益大 |
| Confidence sequence | 任意时刻 | 可以 | CI 更宽；N* 需调 | 同上，工程实现更简单 |
| Bayesian | 任意时刻（模型内） | 可以，但决策规则要校准 | 先验敏感；频率派 error 无保证 | 低样本、决策者要概率读数 |

**贝叶斯：先验、后验与决策规则。** 转化率用 Beta-Binomial：先验 `Beta(α0,β0)`，数据 `s/f`，后验 `Beta(α0+s, β0+f)`。数值：每组 1 万、10% vs 10.5%、均匀先验，`P(p_T>p_C)≈87.9%`，95% 可信区间约 `[-0.34pp,+1.34pp]`，期望损失约 `0.026pp`。「87.9% 概率更好」和「CI 跨 0」不矛盾：CTW 只看方向，期望损失看幅度。

均值型指标用 Normal-Normal 共轭：后验精度是 `1/τ² + 1/σ²`，后验均值是先验与数据的精度加权；把后验均值写成 `Δ_post = Δ̂ - [σ²/(σ²+τ²)](Δ̂ - μ0)`，就能看出「收缩」：数据越吵、先验越强，后验越向 `μ0` 收缩；样本足够大时，先验被数据淹没。决策规则有四种：chance to beat（`P(Δ>0)` ≥ 阈值）、expected loss（`E[max(0,-Δ)]` ≤ 阈值）、credible interval（95% CI 排除 0）、ROPE（`P(|Δ|<δ) < ε`）。常见错误是把「CTW = 95%」当成「有 95% 概率赚 5%」：前者只说明方向，不说明幅度；另一个错误是只看 CTW 不看 expected loss——一个 96% 概率微赚、4% 概率巨亏的变体，CTW 很好看，但期望损失可能不可接受。

先验选择分三档：弱先验/无信息先验（Statsig 默认 `N(0, ∞)`；GrowthBook 开启 proper prior 时默认 `N(0, 0.3²)`）、经验贝叶斯（用历史同类实验的 `AVG(ATE)` 作 `μ0`、`SD(ATE)` 作 `τ`）、强先验（同一功能在别的 segment 做过，但必须做敏感性分析）。Eppo 的官方文档在这里有一个值得警惕的不一致：统计细节页写贝叶斯先验是 `N(0, 0.05²)`，分析方法页又描述为「50% 的实验提升落在 ±21%，95% 落在 ±62%」（约 `σ≈0.31`），两者相差 6 倍，**存在不同说法**；实际生效的先验以租户的 Statistical Analysis Plan 配置为准，上线前应导出一次后验参数做 sanity check。另外，GrowthBook 官方默认 Bayesian、可在 org/project 切换，这与不少二手评测把它写成「频率派平台」不一致，**存在不同说法** [来源](https://docs.growthbook.io/statistics/overview)。

**三种范式不是三个引擎，而是三种决策规则。** 固定样本控制「计划样本量下的错误率」，序贯控制「任意停止下的错误率」，贝叶斯给「给定先验和模型下的后验概率」。同一实验可以有三个读数，但只能有一个预注册的主决策规则；今天看频率派显著就 ship、明天看 CTW 只有 88% 就继续跑、后天看序贯 CI 跨 0 又停，这不是「综合判断」，是用不同模型做多次检验，实际 error rate 无法控制。

## 6.9 多重比较、SRM、功效

同时看 10 个指标、5 个变体对比，就有 50 个检验；即使每个都无效应，至少一个显著的期望个数是 `50×0.05=2.5`。两类错误率要区分：`FWER = P(至少一个假阳性)`，`FDR = E[假阳性数 / 显著结果数]`。三种常用校正：Bonferroni（`p_i ≤ α/m`）、Holm（排序后依次检验 `p_(k) ≤ α/(m-k+1)`，遇到第一个不满足就停止）、BH（找最大的 k 使 `p_(k) ≤ kα/m`，拒绝前 k 个）。

数值例：`m=10`、`α=0.05`，p 值排序为 `0.001, 0.008, 0.012, 0.030, 0.031, 0.045, 0.060, 0.120, 0.300, 0.700`。Bonferroni 阈值 `0.005`，只拒绝第 1 个；Holm 第 1 个 `0.001<0.005` 拒绝，第 2 个 `0.008>0.00556` 停止，只拒绝 1 个；BH 在 `k=3` 时 `0.012≤0.015`、`k=4` 时 `0.030>0.020`，拒绝前 3 个。BH 明显更宽松，因为它控的是 FDR 而不是 FWER；适合探索性、指标多的场景。FWER 更适合「一个错误就可能让公司付出巨大代价」的确认性决策。

工业界的实现差异很大：Eppo 用「preferential Bonferroni」，主指标拿 `γα/k`，其余指标拿 `(1-γ)α/[k(m-1)]`，好处是主指标的 power 不随「加了多少个次要指标」而下降 [来源](https://docs.geteppo.com/statistics/multiple-testing/)；GrowthBook 提供 Holm（FWER）和 BH（FDR），校正家族是「所有 Goal 指标 × 变体 × 维度值」，并明确说 adjusted p 值没有严格对应的 CI [来源](https://docs.growthbook.io/statistics/multiple-corrections)；Optimizely 的 Stats Engine 把 sequential testing 和 FDR control 组合，2015 年官方对比称，相比 fixed-horizon，FDR<0.1 的变体约少 20%、结论性结果约少 39%（厂商自述，需独立验证）；Statsig 也提供 Benjamini-Hochberg 过程。

**「家族」怎么定，比用哪种校正更重要。** 主指标单独一个家族，用最宽松的 α（或 preferential 权重）；次要指标用 BH 控 FDR；guardrail 用 Holm/Bonferroni 控 FWER，因为假阴性比假阳性更危险；子群/维度切片单独一个家族，且优先看交互检验，而不是在每个子群里各做一次检验。

**SRM（Sample Ratio Mismatch）** 检验「观测到的各组样本量是否符合预期分配」。对 `k` 个变体，`χ² = Σ(O_i - E_i)² / E_i`，`df = k-1`。两组 50/50、总样本 100 万：观测 498,800 / 501,200，`χ²=5.76`、`p=0.016`，在 `α=0.001` 下不告警、在 `α=0.05` 下会告警；观测 497,000 / 503,000，`χ²=36`、`p≈2×10⁻⁹`，明确 SRM。在 100 万样本、50/50 下，`α=0.001` 对应的绝对偏差约 **0.33pp**（约 3,291 人），`α=0.0005` 约 **0.35pp**。大样本下很小的偏差也会显著，所以平台通常再加一个「绝对偏差」阈值。

Eppo 用 Pearson 卡方，`α=0.001`，并对维度 SRM 做 Bonferroni 校正；它明确说 SRM 检验**不是 sequentially valid**，每次刷新都跑会抬高实际 α，所以用更低的 0.001 来补偿 [来源](https://docs.geteppo.com/statistics/sample-ratio-mismatch/)。Statsig 用卡方独立性检验，并给出分档告警：`p<0.001` 且偏差 >0.1% 绝对值是红色，`0.001<p<0.01` 是黄色；它还检查 crossover units，同一用户被曝光到多个变体超过 0.1% 就警告、超过 1% 建议联系支持 [来源](https://docs-legacy.statsig.com/experiments-plus/monitor/)。微软的 SRM 论文用 `p<0.0005` 的保守阈值；第三方综述称微软在 10,000+ 实验中约 6% 出现 SRM（第三方数字，需谨慎引用）[来源](https://www.microsoft.com/en-us/research/publication/diagnosing-sample-ratio-mismatch-in-online-controlled-experiments-a-taxonomy-and-rules-of-thumb-for-practitioners/)。

排查时把实验交付拆成四段：**Assignment**（哈希偏差、ID 不稳定、用户自选、ramp 中途改比例）、**Execution**（重定向延迟、崩溃、缓存、变体性能差异、曝光未打点）、**Log processing**（埋点丢失、join 丢失、去重差异、管道 bug）、**Analysis**（触发式分析、后处理过滤、用户 vs session 口径）。分配平衡但曝光不平衡，说明问题在 execution/logging，不在分桶。SRM 门禁应该：每次刷新都跑但用低 α；SRM 未通过时隐藏 treatment effect，只显示样本量和诊断；分维度 SRM 用 Bonferroni；分配 vs 曝光分开监控；按小时/天画比例曲线找第一个失衡点；A/A 常驻；**不要用重加权「修复」**——重加权只能调整可见计数，不能重建缺失用户，只有在根因明确、受影响人群可机械识别、且排除规则不是看了结果才定的情况下，才允许受限分析，否则重跑。

**功效与 MDE。** 两组等样本、均值型指标：`n_per_arm = (z_{1-α/2}+z_{1-β})²(σ_T²+σ_C²)/Δ²`；比例型把 `σ²` 换成 `p(1-p)`。数值：基线 10%、相对提升 5%、`α=0.05` 双侧、power 80%，`n_per_arm ≈ 57,760`，总样本约 115,520。若 `ρ=0.5` 的 CUPED，样本量乘 `(1-ρ²)=0.75`，约 **43,320/组**；若 cluster 随机化、`m=50`、ICC=0.05，DEFF=3.45，膨胀到约 **199,300/组**。固定每组 5 万人、基线 10%，80% power 下 MDE 约 **0.532pp**；要检测 3% 的相对提升，这个样本量不够。

序贯检验不是「免费早停」：同样样本量下 power 低于固定样本。Eppo 说 sequential hybrid 的 CI 比固定样本宽约 10–15%；GrowthBook 说 sequential CI 一致地宽于 fixed CI。具体样本量膨胀必须用平台自己的模拟校准，不能抄一个「序贯要多 20% 样本」的常数。

**Cluster robust SE。** 随机化发生在组织、学校、城市、骑手站点，而分析发生在用户/订单级时，同一 cluster 内的观测相关，i.i.d. 方差会低估标准误。`DEFF = 1+(m-1)ρ_intra`，`n_eff = n/DEFF`；`m=50`、`ρ=0.05` 时 DEFF=3.45，「10 万用户」只相当于「2.9 万独立用户」。两条路线：cluster 级分析（先算 cluster 均值/总和再做 t 检验；简单稳健，但 cluster 大小差异大时要加权）、CRVE（个体级回归 + sandwich 估计；cluster 数 <50 时向下偏，需要 `t(G-1)` 临界值或 wild cluster bootstrap）。GrowthBook 用「比率指标 + Delta method」吸收 cluster 结构，要求 `organization_id` 与 `user_id` 一对多 [来源](https://docs.growthbook.io/experimentation-analysis/cluster-experiments)。

## 6.10 常见统计陷阱

把陷阱按「设计—分流—统计—解释」四层排，比列一张 20 条的清单更有用：同一症状在不同层的处置完全不同。

**表 6-14　常见陷阱与处置**

| 层 | 陷阱 | 症状 | 根因 | 处置 |
|---|---|---|---|---|
| 设计 | 双边市场按用户随机 | 对照组也被污染，效应符号可能反转 | 违反 SUTVA | cluster/switchback；先画干扰图 |
| 设计 | session 分桶测留存 | 留存被严重稀释 | 随机化单元跨会话不稳定 | 改用 user/account 单元 |
| 设计 | holdout 太小/太短 | 只有方向性，检不出小效应 | 功效由 holdout 组封顶 | 1%–5%、3–6 个月，或放粗阈值 |
| 设计 | MAB 当测量仪 | 效应估计有偏 | 自适应分配破坏 i.i.d. | MAB 只做优化，ATE 用固定分配 |
| 分流 | assignment 当曝光 | 效应被稀释，样本量不够 | 打点位置太早 | 代码分叉处打点；触发分析 |
| 分流 | 复用 salt | 两个实验分组高度相关 | 盐未按实验隔离 | 一实验一盐；2×2 卡方验证 |
| 分流 | 中途改权重/桶数 | 老用户翻转、SRM 爆发 | 区间边界移动 | 只改 coverage；改权重上新实验 |
| 分流 | 空 ID/机器人只落一侧 | 匿名流量全进第一桶 | 空值策略/过滤顺序 | 显式空 ID 策略；分流前过滤 bot |
| 统计 | 比率指标当均值 | SE 低估约 15.8% | 分母随机 | Delta method；先聚合到单元 |
| 统计 | pooled 方差构造 CI | CI 偏窄、显著性虚高 | 检验与 CI 用了同一方差 | 检验 pooled、CI unpooled |
| 统计 | CUPED 点估计配未调整方差 | CI 错、p 值错 | 部件错配 | 估计器、方差、决策规则成对 |
| 统计 | peeking/早停 | 假阳性 26%–57% | 固定样本看多次 | 预注册；序贯；监控与决策分开 |
| 统计 | SRM 后重加权 | 「修好」了比例，结论仍错 | 缺失用户无法重建 | 阻断分析、排查、重跑 |
| 解释 | 子群显著当异质性 | 假阳性、过度个性化 | 未做交互检验 | 交互检验；预注册少量子群 |
| 解释 | 显著当有效 | 上线后收益不达预期 | 效应量小、成本高、guardrail 受损 | 看效应量、CI、成本、guardrail |
| 解释 | 早停效应量做预测 | 高估真实效应（winner's curse） | 在显著时停 | 早停只做 ship/no-ship，不估效应 |

这张表可以压成三句话：**设计层的错误无法用统计修；分流层的错误无法用 CUPED 修；统计层的错误无法用更多流量修。** 平台的价值，是把这三层的前置校验做成默认路径，而不是等分析师在结果页发现异常。

## 6.11 对我们的启示

如果把本章压缩成可执行的建议，是六条。

**第一，平台抽象用「四对象 + 注册表 + 插件」，不要用「实验类型枚举」。** Assignment、Exposure、Schedule、Analysis 四个对象，配合随机化单元注册表（user/account/device/session/geo/market×time/query/conversation）和可版本化的分析插件（比例、Welch、Delta、分位数、CUPED、序贯、贝叶斯、CRVE），可以覆盖本章十种设计。每加一种实验类型，只是加一组配置和一个分析插件，而不是改一遍主流程。

**第二，分桶做成独立基础库，而不是平台的一个模块。** 这个库只做三件事：哈希、区间切分、金标测试；它应该被 SDK、服务端、离线复盘、日志校验共同依赖，任何业务代码都不允许自己写 `hash % 100`。配置 schema 里显式写死 `salt`、`bucket_count`、`hash_version` 三个字段，禁止运行时静默变更；多语言实现用同一份 JSON 测试向量，CI 不通过不允许发版。

**第三，扩量只改 coverage，不改 weights。** 这是最便宜的一致性保障。产品经理要「从 50/50 改成 70/30」时，平台应该默认引导「新建实验」，而不是允许原地改比例；如果必须原地改，强制开启 sticky，并在报表上标注「实际比例偏离」。绝不在实验中途改桶数或哈希版本；迁移走双写 + 对比 + 灰度。

**第四，统计默认组合是「频率派 + Welch/Delta + CUPED + SRM 门禁」。** 这四件事覆盖了大多数实验场景；序贯只用于 guardrail 监控和止损，不用于「宣布胜利」；贝叶斯作为可选读数，必须绑定先验配置和敏感性分析。多重比较按指标分层：主指标 preferential α、次要指标 BH、guardrail Holm、子群单独家族。所有配置（引擎类型、窗口、先验、校正方法、`N*`/`τ`、CUPED 协变量列表）写进结果快照，保证半年后可复现。

**第五，流量架构从 3–5 个层起步，holdout 放在最上层。** 建议一个 UI/交互层、一个算法/排序层、一个增长/营销层、一个发布层；每层预留 20–30% 空白流量给临时实验。holdout 用 1%–5%、3–6 个月，冻结后再测量；它不替代单实验分析，只回答「所有已上线改动的总和」。层数太多会让单实验样本不足，反而降低实验吞吐。

**第六，能力路线分三段。** 0–90 天：用户级 A/B/n + 正交分层 + 互斥域 + 曝光日志 + SRM 日报；90–180 天：CUPED + 序贯监控 + cluster 分配与 CRVE + holdout；180–365 天：switchback 调度器、interleaving 专用通道、HTE 交互检验。switchback 和 interleaving 不要包装成通用实验类型，它们是「专用设计器 + 分析模板」，先服务定价/派单和搜索/推荐团队。

**验收标准只需四条**：A/A 上名义 5% 的检验实际假阳性率不超过 5.5%；已知效应仿真上 power 与设计值相差不超过 2pp；CUPED 的方差缩减比例可复现；SRM 告警误报率低于 0.1%。这四条过了，统计引擎才算「能用」；否则功能列表再长，也只是报表。

最后是与其他章节的接口：本章定义的 Assignment、Exposure、Analysis 三张表，会在第 7 章的数据链路与平台架构中落成 schema；第 9 章的选型矩阵应把「默认统计方法、CUPED 窗口、SRM 阈值、分桶版本化、配置可导出」作为可验证项，而不是只勾「支持 CUPED」；第 10 章的 90 天 MVP 应以 6.11 的优先级为输入，先做「单元注册表 + 分桶库 + 曝光表 + SRM 门禁」这四件地基，再谈高级实验类型。

---

## 第 7 章 核心技术模块（下）：指标、架构、组织

> 本章回答「指标怎么算、平台怎么建、组织怎么推」：从曝光/归因到参考架构、权限审计、合规。

## 7.1 指标体系与 OEC

统计引擎决定「算得准不准」，指标体系决定「算的是什么」。OEC（Overall Evaluation Criterion）常被误解为「一个总分」，实际是一套决策结构：实验前约定用什么指标判断成败，指标冲突时谁优先。Kohavi 等在《Trustworthy Online Controlled Experiments》第 7 章要求 OEC 实验前确定、对改动敏感、平衡短期与长期，并能解释「为什么这个改动值得上线」[来源](https://www.cambridge.org/core/books/abs/trustworthy-online-controlled-experiments/metrics-for-experimentation-and-the-overall-evaluation-criterion/0A8BF7F06A1338FF6D10C49F4CD8A198)。

OEC 有三种典型误用：把北极星指标直接当 OEC（太滞后、太宏观，单个实验两周内推不动）、把 OEC 做成加权评分卡（权重拍脑袋，权重一改历史实验就不可比）、用 OEC 替代 guardrail（OEC 变好不代表可以上线，短期收入可能是在透支用户信任）。可操作的结构是：**1 个主指标（决定 ship/no-ship）+ 2–4 个 driver（解释主指标）+ 一组 guardrail（一票否决）+ diagnostic/counter（排障与对账）**。主指标用比率或人均值，不用总量，总量会被流量波动污染。

| 类型 | 回答的问题 | 决策权 | 典型例子 | 常见失败模式 |
|---|---|---|---|---|
| Success / OEC | 这个改动整体是否更好？ | 有，最终裁决 | 人均订单额、7 日留存 | 太滞后、被 novelty 污染 |
| Guardrail | 有没有把什么弄坏？ | 有，一票否决 | 崩溃率、P99 延迟、退款率 | 功效不足、方向搞反 |
| Diagnostic | 为什么好、为什么坏？ | 无，只解释 | 漏斗各步转化、分渠道 CTR | 被当成决策指标、只挑显著切片 |
| Counter | 数量对不对、链路通不通？ | 无，只对账 | 曝光 UV、进组 UV、订单事件数 | 与 success 混用、重复计数 |

指标不是越多越好。看 20 个指标、每个用 5% 显著性水平，至少一个假阳性的概率是 `1-0.95^20 ≈ 64%`。成熟平台不是限制数量，而是分层写进流程：OEC 和 guardrail 实验前注册，diagnostic 事后加但标注「探索性」，counter 只进数据质量面板。**OEC 的真正功能不是打分，而是把「什么结果对应什么动作」提前写死。**

「口径不一致」大多不是 SQL 写错，而是定义缺字段。工业级指标契约至少写清六组：标识与版本（metric_key、语义化版本、认证级别）、业务含义（一句话定义 + 反例）、分析实体（user/session/device/account）、聚合与分母（ratio 必须显式写分母）、时间窗口（归因窗口、聚合粒度、时区）、治理信息（owner、分层、血缘、行数/空值/分布断言）。缺一组，就会出现同名不同义、人均值和会话均值混用、转化率分母差十倍、历史报告悄悄漂移。

行业已经收敛出「事实表 + 指标定义」这个抽象。Eppo 把数据模型拆成 facts、assignments、entry points、entity properties；事实表只需「时间戳 + 实体标识」，指标在其上叠加聚合方式，比率、漏斗、分位数是独立类型[来源](https://docs.geteppo.com/data-management/definitions/overview/)[来源](https://docs.geteppo.com/data-management/metrics/)。GrowthBook 的 Fact Table 同样要求 `timestamp` 和至少一个标识列，并明确推荐新指标都用 Fact Table，而不是旧的「每个指标一段 SQL」模式[来源](https://docs.growthbook.io/app/metrics)。治理路线有三条：Airbnb Minerva 的集中式指标商店（第三方综述称 12,000+ 指标、4,000+ 维度、200+ 数据生产者）[来源](https://eu.36kr.com/zh/p/3730988847890694)、Netflix/Eppo 的指标即代码、LinkedIn UMP/Uber uMetric 的指标 API。共同点是：**指标是有 owner、有版本、有测试、有 SLA 的软件资产**；区别只在集中程度。Eppo 把「信任」产品化成 Certified 徽章：simple、ratio、percentile 可认证，funnel 不可[来源](https://docs.geteppo.com/data-management/certified-metrics/)。

版本化要做四件事：不可变、钉住（实验创建时记录指标版本）、可回填、可对比。Eppo 的增量任务默认回看最近 48 小时，先删除最近两天再重插，以吸收迟到数据；新指标或定义更新会自动从实验开始回填[来源](https://docs.geteppo.com/data-management/data-pipeline/)。这里要分清：48 小时是回看窗口，不是实验窗口。所有权要分业务 owner、数据 owner（pipeline、freshness、断言、on-call）、平台 owner（目录、权限、版本、回填工具）。多数公司处在 L1–L2：有指标字典，但定义与计算分离；直接从 L2 跳到 L4 往往失败，因为组织还没有「指标 owner」这个角色。

**指标不是报表里的一个字段，而是有 owner、有版本、有分母、有排除规则、有质量分的软件资产；OEC 不是加权公式，而是「主指标 + 护栏 + 预注册决策」的组织契约。**

## 7.2 曝光、归因与数据链路

分流 bug 通常当天能被发现，曝光 bug 可能潜伏半年，最后以一个「看起来显著、上线后消失」的结论收场。实验平台最脆弱的一厘米，就在 assignment（分配）与 exposure（曝光）之间。

三个概念必须分开：**Assignment** 是分流服务按 hash 把实体分到某个 variant，回答「如果这个用户来了，他应该看到什么」；**Exposure** 是用户实际看到了实验版本，回答「这个用户真的被处理了吗」；**Trigger / Entry Point** 是用户满足「可能被影响」的条件（进入搜索页、加购、打开弹窗），回答「从哪一刻开始算实验的影响」。三者的时间顺序通常是 assignment → exposure/trigger → outcome，但工程上经常错位：首页就分配了所有实验，用户可能永远不进商详页；服务端在请求入口求值 flag，页面却白屏；客户端缓存旧配置，曝光延迟几分钟才上报。Eppo 的官方表述很直接：有些实验在首页完成分配，但用户只有进入特定页面才真正暴露；可以用 Entry Point（又称 qualifying event）过滤分配源，**是否纳入实验、指标计时起点，都以 entry point 的时间戳为准**[来源](https://docs.geteppo.com/experiment-analysis/configuration/filter-assignments-by-entry-point/)。分配表负责「谁有资格」，入场点负责「从何时开始算」。

统计上更稳妥的默认是 **ITT（intent-to-treat）**：按分配时的 variant 分析所有人，不管有没有真的曝光。ITT 保守（把没曝光的人算进分母，效果被稀释），但无偏，因为分配是随机的，曝光不是。按曝光分析（per-protocol）看起来更「精准」，但曝光是治疗后变量：用户是否看到新版本，可能受新版本速度、崩溃、引导流程影响；按曝光过滤会把「因为新版本太慢而离开的人」排除掉，反而制造乐观偏差。实践建议：主分析用 ITT；同时报一个「曝光人群」的敏感性分析，明确标注它不是因果主结果；如果 assignment 与 exposure 差异超过 20%，先修分流/曝光链路，而不是靠统计方法补救。**当差异超过 20%，它已经是工程问题，不是统计问题。**

曝光重复上报是常态：页面刷新、SDK 重试、离线包补发、多个埋点同时触发。去重规则必须在平台层固定。Eppo 的分配表去重是标准三件套：对同一 subject–experiment 对只取实验日期范围内的第一条记录；如果一个 subject 出现多个 variant，把这些 subject 从结果中剔除，并在过滤比例超过阈值时告警；分配属性取「首次分配时」的值，避免用户旅行/换城市导致属性漂移，也避免 CUPED 用到未来信息[来源](https://docs.geteppo.com/data-management/definitions/assignment-sql/)。这三点分别对应**重复、冲突、时点泄漏**。

字节 DataTester 的公开实践更直接：SDK 调用分流方法时上报一条「实验曝光事件」，记录进组信息；后续指标计算认为「发生在进组之后的事件」受实验版本影响；曝光可能反复上报，**只有第一条曝光是有效事件**。他们后来把曝光从事件表里拿出来，转成用户表上的属性，原因是：曝光事件和普通事件混在一张表里量级太大，找第一条记录会随实验时长扫描越来越多分区，重复曝光还要额外去重；改成用户属性后，用户表规模只随新增用户增长，还少了一次 join，14 天以上实验的多天累计报告查询时长下降 50% 以上[来源](https://blog.csdn.net/m0_60025795/article/details/129880151)。另一篇优化文章提到，从实时流过滤曝光事件构建 `ab_log`、再与离线天粒度进组表按「最早进组时间」取 min，在部分客户环境减少 30% 以上的曝光事件量[来源](https://www.modb.pro/db/604087)。

这个优化值得展开：**曝光不是「又一条事件」，而是「用户的一个状态」**。实验周期越长、事件量越大，把首次曝光物化成用户级宽表越划算；代价是丢掉逐次曝光的 surface/request_id 上下文，排障能力下降。成熟做法是事件表保留 7–30 天做诊断，用户状态表做累计分析。

身份是第二个深水区。真实关系是多对多：一个 anonymous_id 可能对应多个 user_id（共用设备），一个 user_id 也可能对应多个 anonymous_id（多设备、清 cookie）；用户可能在实验中途登录，曝光在匿名态、转化在登录态。Eppo 的做法是：按 anonymous_id 取实验期内第一条记录，多 variant 则剔除；建立 anonymous_id→user_id 映射，每个 user_id 只关联实验期内第一个 anonymous_id；最后同时 join 匿名态和登录态指标[来源](https://docs.geteppo.com/guides/advanced-experimentation/anonymous-explainer/)。代价是可能轻微违反 i.i.d.，但能避免「剔除多 ID 用户」的选择偏差——多 ID 用户往往更活跃，剔除会系统性低估效果。这是**偏差换方差**，没有免费解。

归因窗口有起点和长度两个维度。起点用 assignment_ts 还是 exposure_ts/entry point，决定「早曝光晚转化」算不算；Eppo 以 entry point 为准。长度可以是 7/14/30 天、生命周期或「实验结束后 N 天」，Kameleoon 把 attribution window 做成独立配置项[来源](https://docs.kameleoon.com/user-manual/experiment-analytics/analyze-results/data-and-metrics/how-kameleoon-counts-conversions#attribution-window)。短窗口低估延迟转化（B2B、保险、大家电），长窗口更接近 LTV 但实验更久、后期污染更多。右删失最隐蔽：实验结束前最后几天曝光的用户没有完整 30 天窗口，直接算会低估；应固定「曝光后第 N 天」cohort 或等窗口跑满。建议默认 14 天（电商/内容）或 30 天（订阅/金融），实验前注册，同时报 7/14/30 天敏感性。

曝光日志最小 schema：`exposure_id`（幂等键，`hash(subject_id, experiment_key, variant, exposure_ts)`）、`subject_id + id_type`、`experiment_key + variant`（不要只存 flag name，flag 会复用）、`assignment_ts`、`exposure_ts`、surface/page/module、session_id、model/config_version、request_id、consent/bot_flag。尤其是 assignment_ts 与 exposure_ts 必须分开：只有曝光时间，无法区分「分配了没曝光」和「曝光了但没分配」；只有分配时间，无法判断曝光延迟。

SRM 是实验的体温计，不是病：观测分组比例与设计比例显著不符，通常不是随机波动，而是管道 bug。开源 SRM Checker 用 p<0.01[来源](https://www.lukasvermeer.nl/srm/docs/faq/)；LinkedIn 约 10% 的 triggered experiments 曾出现 SRM，Microsoft 约 6%，一年一万个实验的产品平均每天至少一次[来源](https://www.lukasvermeer.nl/srm/docs/faq/)。没有 SRM 告警，往往不是没问题，而是没检测。KDD 2019 把成因分五类：实验分配、执行、日志处理、分析、干扰[来源](https://www.lukasvermeer.nl/srm/docs/causes/)。最易忽略的：HLL++ 近似 UV 会频繁触发 SRM；treatment 新增埋点让「至少有一条事件」的用户更容易被记录，是可见性变高不是用户变多；treatment 更慢/更易崩，用户会在日志生成前离开，SRM 与指标下降同链。原则：SRM 未解释前不读效果指标，不用重新加权掩盖，只有缺失可证明随机才考虑回填或极端值边界。

**数据链路的三条契约——分配、曝光、指标——比任何单一引擎都重要。曝光应按「事实表」设计：幂等、可对账、带版本，而不是「顺手打一条日志」。**

## 7.3 实时、批处理与 warehouse-native

团队说「我们要实时」，通常混了三件事：**摄入实时**（事件几秒内进 Kafka/OLAP）、**指标实时**（转化率、人均 GMV 分钟级更新）、**决策实时**（统计检验、guardrail、SRM 分钟级刷新，能据此自动停实验）。第三层最难也最贵。绝大多数实验不需要秒级决策；需要秒级的是护栏与健康度（崩溃、延迟、支付失败）以及 SRM 早期预警。把「决策实时」当默认需求，会直接把架构推向全链路流式，代价是回填、维表 join、口径一致性都变难。

| 架构 | 做法 | 延迟 | 优点 | 代价 | 典型 |
|---|---|---|---|---|---|
| Lambda | 实时 OLAP + 离线数仓双链路 | 秒–分钟 + 天 | 实时看板快，离线口径全 | 两套 SQL/两套口径，容易对不上 | DataTester SaaS |
| Kappa | 全流式，Kafka/Flink 计算，失败重放 | 秒–分钟 | 一套逻辑，延迟低 | 维表 join、回填、历史重算困难 | 实时风控/推荐 |
| 仓库原生 | 定义在数仓，SQL 编译下推，只出聚合 | 分钟–小时 | 口径统一、可审计、易回填 | 依赖数仓并发/成本，交互延迟较高 | Eppo、Statsig WHN、GrowthBook |

字节 DataTester 的私有化架构是一个很好的 Lambda 案例：SaaS 采用「实时 + 离线」的 Lambda 架构；私有化为了减少资源开销、适应中小集群，只保留实时部分，由计算引擎对上层屏蔽差异；报告基于 ClickHouse 实时分析；分流服务用内存、Redis、DB 三级缓存，消息队列保证多节点一致，另有定期全量刷新兜底[来源](https://blog.csdn.net/m0_60025795/article/details/129880151)。这说明「实时」不是免费的：**私有化客户用「放弃离线链路」换资源，代价是历史重算和复杂分析的灵活性。**

ClickHouse 擅长单表查询和多维聚合，**join 是弱项**；要么把 join 提前做成宽表，要么把右表做小，避免大表拉本地建 hash[来源](https://www.modb.pro/db/604087)。DataTester 的做法：预聚合人粒度 `user_agg`（100–500 事件/人 → 1/100–1/500；4 亿事件、100 万用户查询提升 4 倍+）；`ab_log` 把「用户+进组时间」写实时表，再与离线天表按最早进组时间取 min，部分客户曝光事件量降 30%+；不同 variant 合并 GroupBy；AU 缓存/异步/Redis 把刷新压到 100ms。前提是指标、维度、版本可枚举且以天级累计为主；任意维度/时间窗探索会让预聚合失效。代价是更新删除不友好、join 弱、并发争抢、分区排序键复杂；适合实验报告，不适合唯一数仓。

Druid 的定位更窄：面向实时摄取、快速查询、高可用 OLAP；典型查询延迟从亚秒到几秒；适合事件型数据、高基数、时间序列、聚合报表；**不支持按主键低延迟更新已有记录**；**不适合大表 join 大表**；支持近似 count-distinct、近似分位数[来源](https://druid.apache.org/docs/latest/design/)。这几乎是「实验实时看板」的完美候选，但不适合「归因窗口 + 多维 join + 精确财务对账」的最终口径。合理分工是：Druid 做实时健康度/趋势，数仓做最终决策口径。

BigQuery 的 Storage Write API、Snowflake 的 Snowpipe Streaming 正在把流式写入做进数仓。Snowflake 在 2025-09-23 宣布 Snowpipe Streaming 的高性能架构 GA[来源](https://docs.snowflake.com/en/release-notes/2025/other/2025-09-23-snowpipe-streaming-high-performance-architecture)；BigQuery 也提供 Storage Write API 的流式写入路径[来源](https://cloud.google.com/bigquery/docs/write-api-streaming)。但**进仓快 ≠ 查询快**：高并发、复杂 join、窗口函数仍然要扫大量数据，成本随扫描量上升。仓库原生的真正优势不是延迟，而是口径唯一、可审计、可回填、复用数仓行/列级权限且 PII 不出仓；代价是交互体验，分析师从 ClickHouse 的秒级拖拽回到 BigQuery/Snowflake，可能要等几十秒到几分钟。

Eppo 是典型的仓库原生：整个 pipeline 是跑在客户数仓里的 DAG，只有最终阶段的匿名聚合结果出仓；分配汇总、核心指标、CUPED、维度、漏斗五条分支；增量刷新默认回看 48 小时，定义变更自动从实验开始回填；CUPED 用实验前 30 天数据做回归；高基数维度截断到 50 个值[来源](https://docs.geteppo.com/data-management/data-pipeline/)。另有文档显示其默认刷新节奏是 24 小时[来源](https://docs.geteppo.com/data-management/warehouse-best-practices/)。这里要分清：**48 小时是增量回看窗口，24 小时是报表刷新节奏，两者不是同一件事**；把它们混为一谈，会得出「Eppo 只能看两天」的错误结论。

仓库原生的成本是换了计费口。Statsig 给过一组透明基准：仓库成本通常占平台合同 5%–20%；小实验（≤5 万单元）单次加载 <$0.05、4 周生命周期 $0.25–$2；大实验单次 $0.25–$10、生命周期 $5–$280；并称其 WHN 成本是其他平台的 50%–66%（**厂商自述，需第三方验证**）[来源](https://docs-legacy.statsig.com/statsig-warehouse-native/guides/costs)。反例：客户 PoC 用未分区表，成本是竞品 120%；分区后 <60%。成本高度依赖数据建模；实验数、指标数、维度基数、刷新频率是四个杠杆，选型要按自己的仓做 PoC。

WHN 不划算的场景：需要分钟级/秒级决策或自动止损；实验密度极高、每个都跑全量历史，查询费超过订阅费；数仓很乱（无分区、无 dbt、口径不一），WHN 会放大问题；没有数据工程维护 SQL/权限/成本/回填；多仓/多云，一套 WHN 通常绑一个主仓。治理上，WHN 把数据访问权交给平台服务账号，必须做列级权限、PII 脱敏、查询审计、行级过滤，否则实验平台会成为绕过数仓权限的后门。

一句话选型：日级决策、指标多、要回填，选仓库原生；实时护栏、SRM 预警，选 ClickHouse/Druid；私有化资源有限，选 ClickHouse 单链路 + 预聚合；复杂归因、跨表 join，回数仓批处理。不要试图用一套引擎同时满足「亚秒交互」和「可审计回填」。**实时/批处理的真正分野不是延迟，而是「指标定义在哪里、能否回填、谁能审计」；正在收敛的形态是「仓库原生做决策口径 + 轻量 OLAP 做实时护栏」的混合架构。**

## 7.4 参考架构：控制面、数据面、分析面

实验平台表面上都在做「分流量、看结果」，内部却运行着三种完全不同的负载。控制面写少读多、强一致、低 QPS，坏了只是「不能改」，不能让正在运行的实验停摆；数据面读多写少、极高 QPS、最终一致，坏了必须继续服务，最多返回旧配置或默认值；分析面吞吐大、延迟容忍度高、可重跑，坏了不影响线上，但会让决策停摆。三者不能用同一套数据库、同一套 SLO、同一套发布节奏。

| 平面 | 核心职责 | 一致性 | 典型组件 | 故障影响 | 扩缩单位 |
|---|---|---|---|---|---|
| 控制面 | 实验/Flag 元数据、审批、RBAC、审计、版本、调度 | 强一致 | 元数据 DB、工作流、版本库、管理 API | 不能新建/修改，已运行实验继续 | 租户/项目，垂直扩 |
| 数据面 | 配置分发、边缘缓存、SDK 求值、曝光采集 | 最终一致/可用优先 | 分发服务、Relay/Edge、SDK、消息队列 | 返回旧配置或默认值，可能丢曝光 | 请求量/连接数，水平扩 |
| 分析面 | 事件入湖、指标、统计、报表、护栏 | 最终一致/可重跑 | Kafka、湖仓、Spark/Presto/ClickHouse | 结果延迟，不影响线上 | 数据量/实验数，批处理扩 |

Microsoft ExP 的公开架构被总结为实验门户、执行服务、日志处理、分析服务四部分[来源](https://arxiv.org/abs/1910.03878)，是三平面的雏形；Netflix XP 把分析面拆成 Metrics Repo、Causal Models、XP Viz 和 Platform API，并让分析代码可在本地 Jupyter 重跑，以保证可复现[来源](https://arxiv.org/abs/1910.03878)；美团 2024 年把实验设计/配置/流量/数据处理与分析方法库解耦[来源](https://tech.meituan.com/2024/09/09/New-Generation-Analysis-Engine-Driving-Data-Decisions.html)。

三条硬边界必须写进架构决策：**热路径不查库、不调分析服务**，控制面把配置编译成不可变快照，数据面只读快照，分析面只消费异步事件；**分析面不直接读在线控制库**，所有结论必须基于「实验版本 + 配置版本 + 曝光/指标数据」的不可变快照，否则今天跑出的结论明天无法复现；**配置版本与实验版本关联但不等同**，配置版本回答「用户当时看到什么」，实验版本回答「统计上比较的是什么」，扩流、改规则、换变体都应产生新的实验版本，分析时按版本和时间窗切分。否则 10% 流量和 50% 流量的样本混在一起算 SRM，一个百分比就把偏差洗白了。

对象模型至少包含 Tenant/Project/Environment、Flag、Experiment、Layer/Domain、Metric/Guardrail、Approval/AuditEvent。关键是：**Experiment 不是 Flag 的同义词，而是「Flag 版本 + 统计计划」的组合对象**。Flag 可以独立存在、独立回滚；Experiment 必须有开始/结束和决策，否则就是一笔糊涂账。生命周期建议 `draft → in_review → approved → scheduled → running → paused → concluded → archived`，旁路 `rejected/aborted/rolled_back`；没有假设、指标、护栏、MDE、负责人不许提交评审，没有双人审批不许进生产，没有 SRM/护栏检查不许自动结论，没有 Flag 清理计划不许归档。

```mermaid
flowchart LR
  subgraph CP[控制面]
    UI[实验与开关控制台]
    API[管理 API]
    WF[审批与生命周期]
    IAM[RBAC 与 SSO]
    AUD[审计]
    META[(元数据 DB)]
    VER[(不可变版本库)]
  end
  subgraph DP[数据面]
    DIST[配置分发]
    EDGE[边缘 Relay]
    SDK[SDK 本地求值]
    ASSIGN[分流与曝光]
  end
  subgraph AP[分析面]
    BUS[(Kafka)]
    LAKE[(湖仓明细)]
    METRIC[指标计算]
    STATS[统计引擎]
    REPORT[报表与决策]
  end
  UI --> API
  API --> WF
  API --> IAM
  API --> AUD
  API --> META
  API --> VER
  VER --> DIST
  DIST --> EDGE
  EDGE --> SDK
  SDK --> ASSIGN
  SDK -- 曝光事件 --> BUS
  BUS --> LAKE
  LAKE --> METRIC
  METRIC --> STATS
  META -- 实验版本 --> STATS
  STATS --> REPORT
  STATS -. 护栏触发 .-> WF
```

热路径应是：请求 → SDK 读取原子快照 → 取 unit_id → 按 layer/salt 哈希 → 查区间 → 得到 variant → 曝光写有界队列（不阻塞）→ 返回；后台批量压缩上报 → 消息队列 → 湖仓。整条路径没有数据库、没有 RPC、没有 JSON 解析；最坏情况是队列满，按采样/丢弃处理并打点 `exposure_dropped`。**「无状态」的真正含义是：正确性来自快照版本，而不是某台机器的内存状态。** 三个平面的失败模式不同，所以不能用同一个可用性目标；「控制面正确、数据面可用、分析面可复现」是架构宪法，而配置、实验、指标三个版本号是结论可复现的审计线索。

## 7.5 分流服务与配置下发

10 万 QPS 的最优解是「没有中心分流服务」：规则下发到 SDK/边缘，本地求值；中心只承担配置分发和治理。可信分流要满足确定性、均匀性、稳定性、正交性、可追溯。Google 的重叠实验设施把参数划分到多个层，层内互斥，层间用 `mod = f(cookie, layer) % 1000` 保证正交[来源](https://research.google/pubs/overlapping-experiment-infrastructure-more-better-faster-experimentation/)。工程上可简化为 `bucket = murmur3(salt + ":" + unit_id) % 10000`；salt 至少包含 experiment_id + version，同层共享互斥区间，不同层用不同 salt。不要用 `hash(unit) % 100` 分所有实验，否则实验之间天然相关。

三级缓存：L1 在 SDK 进程内放编译规则快照（>99% 求值，原子指针）、L2 在边缘/Relay/Redis 放环境快照（流式 + TTL）、L3 在对象存储/DB 放不可变版本（冷启动/灾备，版本寻址）。LaunchDarkly Relay 是客户机房里的 Go 应用，daemon 模式要求 SDK 与 Relay 共享持久化存储[来源](https://launchdarkly.com/docs/sdk/relay-proxy)；Unleash Edge 是内存缓存 + 流式/轮询，官方称单实例可处理「数万到数十万 RPS」[来源](https://docs.getunleash.io/unleash-edge)；GrowthBook Proxy 用内存 + Redis/MongoDB，靠 Webhook 失效[来源](https://docs.growthbook.io/self-host/proxy)。共同点：读离应用足够近，写留在中心。缓存要配 singleflight、stale-while-revalidate、磁盘快照；边缘重启没有本地快照，十万 SDK 同时回源会把中心打挂。

多区域是「读本地、写归属、版本单调」：每区完整只读副本，SDK 连最近区域，故障切邻区；控制面写租户 home region，跨区异步复制；冲突以 version 大者为准，同版本按 region priority，不依赖时钟；断连时用本地快照，恢复后从 `last_known_version` 增量追平，缺口太大全量拉取。数据驻留要求 EU/中国租户数据留在本区域，全局控制面只做路由。p99 预算：SDK 本地 <1ms、sidecar <3ms、边缘 <10ms、控制 API <300ms。尾延迟的隐藏杀手是可观测性本身：求值路径只做计数器和直方图，曝光走异步队列，高基数维度放日志不放指标标签。

fail-open 是每个 Flag 的产品决策：实验回退 control 并标记 `assignment_source=default`；发布开关回退 last-known-good；Kill Switch 回退 off；支付/风控 fail-closed；推荐回退热门。关键：实验回退 control 会损失功效，若故障与区域/设备相关，缺失不是随机的，会产生偏差；要记录 `fallback_reason`、`config_version`、`region`，分析时标为「降级期」。LaunchDarkly 用 SDK 缓存、CDN 缓存、代码默认值三层兜底[来源](https://launchdarkly.com/blog/designing-for-failure-to-avoid-disaster/)；OpenFeature 要求求值不抛异常，异常返回默认值[来源](https://openfeature.dev/specification/sections/flag-evaluation)。

配置下发是「流式为主 + 轮询兜底 + 周期全量对账」。LaunchDarkly Go SDK 有 Default/Streaming/Polling/PersistentStore/Daemon 五种模式，轮询默认/最小 30 秒[来源](https://pkg.go.dev/github.com/launchdarkly/go-server-sdk/v7@v7.13.3/ldcomponents)；Splitd 默认 streaming，轮询 Flag 30 秒、Segment 60 秒[来源](https://developer.harness.io/docs/feature-management-experimentation/sdks-and-infrastructure/optional-infra/split-daemon-splitd/)。下发单位是不可变快照：manifest 带 `schema_version`、`config_version`、`flags[version, checksum, blob_ref]`、`signature`；增量带 `base_version`/`new_version`，不匹配就全量；payload 签名，验签失败拒绝更新。版本按对象单调递增，全局版本只用于对账，不让时间戳充当版本。传播 SLO 独立定义：commit → 99% 边缘可见 p99 <5 秒，→ 99.9% SDK 可见 p99 <30 秒；「配置很旧但服务正常」会让用户分到旧版、曝光记新版，分析直接错位。**配置分发的正确性单位是不可变快照，不是消息；一致性判据是版本号，不是时钟。**

## 7.6 SDK 与 OpenFeature

SDK 是平台唯一进入业务进程的代码，同时是性能组件、数据采集器和一致性边界。第一原则是**求值不走网络**：启动拉全量快照，之后进程内哈希/规则匹配。Unleash 官方称后端 SDK 求值是「纳秒级」[来源](https://docs.getunleash.io/get-started/unleash-overview.md)；LaunchDarkly 也本地缓存。四个工程问题：规则编译（JSON → AST/字节码）、原子切换（新快照构建后替换指针）、内存上限（按 project/flag set 懒加载）、多语言一致（哈希/比较/类型转换一致，用 conformance 用例）。缓存分层：L1 进程、L2 本地磁盘（重启先加载上次快照）、L3 边缘/Relay，冷启动用镜像 bootstrap 或对象存储。LaunchDarkly persistent store 默认 15 秒[来源](https://pkg.go.dev/github.com/launchdarkly/go-server-sdk/v7@v7.13.3/ldcomponents)；Splitd 把规则放宿主机内存，通过 Unix socket 给 thin SDK 求值，避免 PHP 每请求重建缓存[来源](https://developer.harness.io/docs/feature-management-experimentation/sdks-and-infrastructure/optional-infra/split-daemon-splitd/)。目标是缓存生命周期长于请求、短于配置版本。

曝光上报：业务真正读到 Flag 并决定展示时记，不在初始化时记；字段包括 `experiment_id/version`、`flag_version`、`unit_id_hash`、`variant`、`bucket`、`timestamp`、`assignment_source`、脱敏 context、`event_id`；有界队列 + 批量 + gzip + 重试 + 磁盘 spill，队列满采样并打点；`event_id` 幂等，服务端按 `(experiment_id, unit_id_hash, variant, date)` 去重；SDK 计 `exposure_emitted`，服务端计 `exposure_ingested`，差异告警；不上传原始 PII。Splitd 默认 impressions 8192/1800 秒、events 8192/60 秒[来源](https://developer.harness.io/docs/feature-management-experimentation/sdks-and-infrastructure/optional-infra/split-daemon-splitd/)；LaunchDarkly Go SDK 10000/5 秒[来源](https://pkg.go.dev/github.com/launchdarkly/go-server-sdk/v7@v7.13.3/ldcomponents)。行业共识是批量、有界、定期 flush。

OpenFeature 是 CNCF 孵化项目，提供厂商中立 API、Provider、Context、Hooks、Events、Tracking、OFREP[来源](https://openfeature.dev/specification/)。价值是应用只依赖 `getBooleanValue` 等标准 API，换供应商只换 Provider；Hooks 在 before/after/error/finally 插入曝光和日志[来源](https://openfeature.dev/specification/sections/hooks)；OFREP 统一远程求值[来源](https://openfeature.dev/specification/appendix-c/)。但它不是实验平台：不定义实验对象、分流比例、SRM、CUPED、曝光去重，Tracking 仍是 experimental。它适合 SDK 抽象层，不适合统计分析层；flagd 是无 UI、无持久化的参考实现，从文件/HTTP/K8s/gRPC 同步，暴露 gRPC stream 和 OFREP[来源](https://flagd.dev/)。自建应「OpenFeature Provider + 自研实验语义」分层，不要把实验逻辑塞进 Provider。

移动端放大了问题：代码不可热改，treatment 随二进制预埋；审核 1–7 天；版本碎片让同一实验在不同版本上是不同 treatment；ATT/SKAdNetwork 让归因窗口模糊。所以第一功能是**版本门槛与兼容性管理**：Firebase Remote Config 下发 `minimum_version`[来源](https://firebase.google.com/docs/remote-config/use-cases/minimum-version)；Eppo 的 SemVer targeting 要求完整 `major.minor.patch`，`28.5` 不合法[来源](https://docs.geteppo.com/feature-flagging/concepts/targeting/)；格式不统一会静默不命中，直接制造 SRM。移动端有 installation ID、设备 ID、账号、会话四种单元，平台应提供**单元注册表**，建实验时强制声明随机化/分析/曝光三个单元并校验一致。生命周期：代码预埋 → 版本门槛 → 小流量 ramp → 等目标版本渗透率达标 → 开实验 → 曝光 → 指标窗口 → 清理 flag。发版日就开实验，会让「愿意升级的用户」污染样本。Firebase 单实验最长 90 天、同时 24 个、项目内 300 个[来源](https://firebase.google.com/docs/ab-testing/ab-concepts?hl=en)；SKAdNetwork 只给聚合延迟回传，不能当无偏真值[来源](https://developer.apple.com/documentation/storekit/skadnetwork)；崩溃/ANR 必须进护栏。

求值通常不是瓶颈，瓶颈是 JSON 解析、字符串拼接、内存分配、日志序列化。优化：ruleset 预编译、复用哈希 buffer、曝光异步批量、缓存请求内重复求值、控制配置体积（Cloudflare Flagship 单 app 25MB、单 variant 10KB[来源](https://developers.cloudflare.com/flagship/reference/limits/)）。边缘求值受四个限制：上下文不足、日志按地区/网络非随机丢失（直接 SRM）、多节点版本不一致、绑定 CDN/Worker。SDK 验收标准不是语言数量，而是跨端同一用户同一 variant、曝光可对账；边缘只用于 flag 和低上下文，曝光回中心；30 秒传播窗口内不开新实验、不判胜负。

## 7.7 多租户、权限、审批、审计

治理是把「谁能改、谁批、改了什么、何时生效」变成不可变事件。四级模型 `tenant → project → environment → object`；`tenant_id` 出现在所有表/消息/指标/日志，不靠分库隐式隔离。隔离三种：Pool（共享集群 + 行级安全 + 查询隔离，成本最低）、Silo（独立 DB/集群，强合规/超大租户）、Bridge（控制面共享，数据面/分析面在客户 VPC）。配额覆盖 Flag 数、实验数、QPS/SDK key、事件/天、并发分析任务、存储、审批人数；边缘 token bucket 返回 429 + `Retry-After`，分析面每租户队列 + 公平调度。

私有化难点是可运维：依赖矩阵、Helm/Operator、离线镜像/air-gap、离线签名 License（不 phone home，到期只读不锁死）、N-1 升级、可回滚 migration、自带 dashboard、元数据导出且曝光不回传。Unleash 有 cloud/hybrid/self-hosted，hybrid 是控制面在 Unleash、Edge 在客户侧[来源](https://docs.getunleash.io/deploy/hosting-options.md)；GrowthBook 单 Docker + MongoDB[来源](https://docs.growthbook.io/self-host)；LaunchDarkly Relay 形成「SaaS 控制面 + 私有数据面」[来源](https://launchdarkly.com/docs/sdk/relay-proxy)。数据驻留：租户选 region，元数据/曝光/分析结果留在该区；全局控制面只存路由和计费；每租户 KMS key；跨区复制可关闭；审计可导出 SIEM；删除租户做硬删除/加密擦除。

RBAC 三层：根级（用户/角色/SSO/Token/集成）、项目级（Flag/Experiment 创建/编辑/归档/移动）、环境级（开关/策略/变体/审批/应用/跳过）。Unleash 支持自定义根/项目角色、环境权限、用户组、SSO 同步[来源](https://docs.getunleash.io/concepts/rbac.md)。关键：**「能改实验」与「能看结果」必须分开**，否则可以一边改分流一边看未锁定结果，诱导 peek 和 p-hacking。审批是状态机：变更集（一次审批覆盖多个对象/字段）、`draft → in review → approved → scheduled → applied`、评审中修改撤销批准、多人规则（Unleash 最多 10 人）、定时应用 + 冲突挂起、break-glass 只作用于环境级且留审计[来源](https://docs.getunleash.io/concepts/change-requests.md)；LaunchDarkly approvals 拆成请求/评审/设置/环境配置[来源](https://launchdarkly.com/docs/home/releases/approvals)。

审计事件含 `event_id`、tenant/project/env、actor、action、resource、before、after、request_id、ip、approval_id、timestamp。Unleash Event Log 保留 `data` 与 `preData`，可过滤/导出 CSV/JSON[来源](https://docs.getunleash.io/concepts/events.md)。建议加哈希链、SIEM 导出，保留 1–3 年；决策记录与审计分开存。版本化四条件：不可变、可寻址、可比较、可回滚（回滚 = 旧内容发新版）。Kill Switch p99 <60 秒、配置回滚 p99 <5 分钟，靠指针切换 + 边缘增量推送，不靠重新编译[来源](https://launchdarkly.com/docs/home/releases/version-restore)。Flag 债务：Fowler 分 release/experiment/ops/permission 四类[来源](https://martinfowler.com/articles/feature-toggles.html)；平台应强制 owner/类型/过期时间，超期标 stale，联动 code references，自动清理 PR，CI 阻断未登记 Flag，项目技术债评分；Unleash 已产品化[来源](https://docs.getunleash.io/concepts/technical-debt.md)。**治理带宽守恒：官方路径越慢，shadow experiment 越多。**

## 7.8 规模、可用性与可观测性

先把数算清楚。10 万 QPS = 8.64 B 次求值/天；若 SDK 本地求值，中心只承担配置分发；20 万 SDK 按 30 秒轮询，配置请求约 6.7 k QPS。10 万实验 × 50 KB 元数据约 5 GB，10 个版本约 50 GB；10 万实验 × 10 变体 = 100 万变体，需要区间查找和编译快照。10 亿事件/天平均 11.6 k/s、峰值按 3× 约 35 k/s；200 B/事件 = 200 GB/天原始、约 20 GB/天 Parquet，90 天约 1.8 TB。以上为推断。

| 规模问题 | 常见误判 | 正确做法 |
|---|---|---|
| 10 万 QPS | 把中心做成高并发 RPC 服务 | SDK 本地求值；中心只发配置；边缘按 1 万–5 万 RPS/实例规划，N+1 |
| 100 万长连接 | 只算 QPS 不算连接 | 每实例 5 万–10 万连接，处理 fd、心跳、TLS 复用、优雅重启 |
| 10 万实验 | 以为元数据是瓶颈 | 元数据只有几 GB；瓶颈是快照大小、索引、调度与治理 |
| 10 亿事件/天 | 一上来就上 Flink | Kafka + 对象存储 + Spark/ClickHouse 足够；只有护栏/实时看板走流 |
| 查询爆炸 | 按事件量估容量 | 实验×指标×维度组合远大于事件量；预聚合与查询配额才是关键 |

10 万实验的真正挑战不是存储，而是：**快照大小**（每个 SDK 都加载全部会到几百 MB，必须按 project/environment/flag set 分区，单个 SDK 只加载几百到几千个 Flag）、**索引结构**（`flag_key` 哈希 + 规则区间表，不要线性扫描）、**实验调度**（运行中每日增量、结束按需重算、归档只留摘要）、**治理**（几万个 owner、几千个指标，没有审批/TTL/搜索/标签会被元数据淹没）。字节 DataTester 在 2023 年 6 月披露累计 240 万次实验、日新增 4000 个、同时运行 5 万个[来源](https://news.bjd.com.cn/2023/08/29/10546096.shtml)（第三方报道，引用厂商数据）；「累计」与「同时运行」是两个量级，后者对调度和快照的要求高得多。瓶颈排序：配置快照分发与冷启动 → 分析查询爆炸 → 曝光数据质量 → 控制面写冲突与审批体验 → 求值 QPS（只要本地化，反而最不是问题）。

| SLI | 定义 | 建议 SLO |
|---|---|---|
| 求值可用性 | 成功求值/总求值 | 99.99% |
| 本地/边缘求值延迟 | p99 | < 1 ms / < 10 ms |
| 配置传播 | commit → 99% 边缘可见 p99 | < 5 s |
| 曝光丢失率 | 1 - ingested/emitted | < 0.1% |
| 分析新鲜度 | 事件到达 → 报表可用 p95 | < 30 min |
| 控制 API | 可用性/p99 | 99.9% / < 300 ms |
| 回滚 MTTR | 点击 → 全球生效 p99 | < 60 s |

99.99% 的可用性意味着每月约 4.3 分钟不可用；99.9% 是 43 分钟[来源](https://sre.google/workbook/implementing-slos/)。不要给分析面定 99.99%，它可以用重跑换可用性；也不要给控制面定 99.99% 却不给数据库多活预算。观测要区分：指标看求值 QPS/错误/延迟、缓存命中、配置版本年龄、连接数、曝光队列深度/丢弃、Kafka lag、SRM 告警、护栏触发、审批时长；追踪只对配置拉取、边缘回源、分析任务打 span，不要对每次求值打 span；`experiment_id`/`flag_key` 放日志和 exemplar，不放 Prometheus label。

混沌演练覆盖：边缘被杀（关 10% 实例，p99 < 2×）、区域断连（本地快照继续服务）、缓存过期（singleflight 生效）、快照损坏（SDK 拒绝更新）、时钟漂移（版本仍单调）、Kafka broker 丢失（生产不丢）、热租户（配额生效）、惊群（本地快照 + 退避）、坏配置灰度（自动回滚）、高峰回滚（< 60 秒）。原则是定义稳态、注入真实事件、对照组证伪、最小爆炸半径、自动化[来源](https://principlesofchaos.org/)；AWS FIS 用 action/target/stop condition + CloudWatch 告警停止[来源](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)。**规模的敌人不是求值 QPS，而是快照分发、查询组合爆炸、曝光质量；SLO 要按平面分配。**

## 7.9 组织、流程与合规

先承认：多数实验不会赢。美团 2025 可信实验白皮书引用 Google 与 Microsoft 的统计：即使很有经验的人，对产品策略判断正确的概率也只有约三分之一[来源](https://tech.meituan.com/2025/05/22/meituan-AB-Online-Controlled-Experiment-01.html)。Spotify 自报实验胜率约 12%、学习率约 64%[来源](https://confidence.spotify.com/glossary/experimentation-maturity-model)；据第三方分析，Netflix 也只有很小比例的被测想法最终上线[来源](https://atticusli.com/blog/posts/how-netflix-runs-experimentation/)。如果考核胜率，理性团队就会只挑容易赢的实验、事后改口径，或干脆不登记。更可取的公式是：`实验能力 = 可信度 × 决策覆盖率 × 决策速度 ÷ 单位实验成本`；平台只能直接改善可信度与单位成本，覆盖率取决于流程是否够轻，速度取决于谁有权拍板。

成熟度可分 L0 无实验、L1 个人 ad hoc、L2 团队标准化、L3 平台化治理、L4 组合级；多数公司卡在 L1–L2，L3 的硬信号是预注册率、SRM 硬阻断、核心指标唯一 owner。

Fabijan 等人基于 Microsoft/Booking/Skyscanner/Intuit 的四阶段模型覆盖七个方面[来源](https://research.chalmers.se/publication/507720)；公开摘要没给每阶段完整命名，这里不臆造。据第三方转述，Booking 达到约 1000 个并行实验后，早期质量仪表盘发现 80% 实验没做功效计算[来源](https://atticusli.com/blog/posts/how-booking-com-runs-experimentation/)——规模化本身制造质量债务。

组织形态没有标准答案，但成功案例都把「证据生产」与「风险承担」分开。Netflix 是 hub-and-spoke + Informed Captain：中央 XP 管 assignment/下发/join/自动分析，领域 DS 管假设与解释，重大决策由单一 Captain 拍板[来源](https://atticusli.com/blog/posts/how-netflix-runs-experimentation/)。Booking 是分散决策 + 中央机器 + 大使网络：产品团队端到端拥有实验与决策，中央管平台/标准/质量/safeguard[来源](https://atticusli.com/blog/posts/how-booking-com-runs-experimentation/)。Google 2010 年 Search 是自助 + Experiment Council + 开放论坛[来源](https://research.google.com/pubs/archive/36500.pdf)；Spotify 是中央平台 + 自助 + Surface，exposure = Config Assigned 且 Applied[来源](https://engineering.atspotify.com/2020/10/29/spotifys-new-experimentation-platform-part-1/)。

建议三层治理：中央平台层管分流/曝光 SDK、指标语义、统计、SRM/AA、护栏、权限审计、实验库，不拥有业务假设；领域实验层由产品负责人拥有 hypothesis 与最终决策，DS 管设计完整性，工程管 assignment/exposure 质量；治理层只在高风险/跨域冲突时介入，指标委员会管定义与认证，法务管合规边界。评审按风险分级：

| 级别 | 触发条件 | 评审者 | SLA | 决策权 |
|---|---|---|---|---|
| Tier 0 自动 | 低风险 UI/文案；流量 <5%；无定价/隐私/资金 | 平台自动检查 | 分钟级 | 自动放行，事后抽检 |
| Tier 1 同伴 | 单团队、单 surface、可逆 | 团队内资深 DS/PM | 1 个工作日 | 建议，不阻断 |
| Tier 2 委员会 | 跨团队 surface；>20% 流量；核心指标 | 评审委员会 + 领域 DS | 3 个工作日 | 可要求整改/补功效/加护栏 |
| Tier 3 高管/合规 | 定价、资金、青少年、敏感数据、跨境、不可逆 | 委员会 + 法务 + 业务负责人 | 5–10 个工作日 | 否决或附条件放行 |

关键：默认不审、例外才审（Tier 0 占比低于 70% 说明分级失效）；评审设计而非结果；SLA 与升级写进章程；保留异议记录。Confidence Reviews 支持按 surface 配必审人，审批后改 variant/audience 重置审批[来源](https://confidence.spotify.com/docs/capabilities/experiments/reviews.md)。

预注册不是写 H0/H1，而是和真正的决策者写下「如果看到 X，就做 Y」。Eppo 指出 5 个指标×3 种状态=243 种结果组合，事先覆盖最可能的几种，明确 null、混合、护栏触碰时怎么办[来源](https://www.geteppo.com/blog/make-decisions-before-experimenting)；关键点：不太可能改变决策就别做；null 也要预注册动作；必须找到真正的决策者；允许非数据考量显性化。Eppo Experiment Protocol 把 entity、日志表、统计方法、默认时长、primary/guardrail、推荐决策、最大指标数预设进模板，偏离要写理由[来源](https://docs.geteppo.com/experiment-analysis/configuration/protocols/)。

信任是链：分配→曝光→指标→分析→决策。AA 验证 SDK 集成、分流、指标定义，建议新 SDK/数仓/代码变更后跑[来源](https://docs.growthbook.io/kb/experiments/aa-tests)；AA 通过不代表真实实验不会 SRM。SRM 红灯不读指标、不做决策；规则要进平台，红灯锁「Make Decision」。Statsig 阈值：p 0.001–0.01 黄色，p<0.001 且偏差≥0.1% 红色[来源](https://docs.statsig.com/experiments/monitor.md)；Eppo guardrail cutoff 用置信区间下界触碰即黄色、显著为负红色[来源](https://docs.geteppo.com/data-management/organizing-metrics/guardrails/)；Statsig Safeguards 可自动 pause/rollback/complete[来源](https://docs-legacy.statsig.com/safeguards/overview/)（2025-09-30 仍标 open beta，**待核实**）。这里**存在不同说法**：开源 SRM Checker 默认 p<0.01 告警，Statsig 把 p<0.001 且偏差≥0.1% 定红；阈值应与实验量/误报成本匹配。

合规把实验当数据处理活动：GDPR 要求合法/公平/透明/目的限制/最小化/存储限制/问责（Art 5）[来源](https://gdpr-info.eu/art-5-gdpr/)，合法性基础含同意/合同/法定义务/重大利益/公共任务/正当利益（Art 6），Art 22 自动化决策可拒绝/要求人工，跨境走充分性/SCC/BCR/例外（Art 44–49），最高 2000 万欧元或全球营业额 4%。CCPA/CPRA 适用年收入 >2500 万美元、年买卖/共享 10 万以上加州消费者/家庭、或 >50% 收入来自出售 PI 的企业[来源](https://oag.ca.gov/privacy/ccpa)；每次违规最高 2500/7500 美元。PIPL 要求合法正当必要诚信（Art 13），敏感/对外提供/跨境/公开单独同意（Art 14/23/29/39），最短保留（Art 19），自动化决策不得不合理差别待遇（Art 24），跨境走评估/认证/标准合同（Art 38–40），最高 5000 万元或上一年营业额 5%。

中国区特别约束：实验通常不属「合同必需」，PIPL 又无 GDPR 式正当利益，需谨慎落到同意或其他法定情形；跨境按 2024-03-22《促进和规范数据跨境流动规定》：非 CIIO 年出境 <10 万人（非敏感）豁免；10–100 万或 <1 万敏感走标准合同/认证；≥100 万或 ≥1 万敏感走安全评估[来源](https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm)。个人信息保护合规审计 2025-05-01 施行，处理 >1000 万人 PI 每两年至少审计一次[来源](https://www.gov.cn/lianbo/bumen/202502/content_7003767.htm)；算法推荐规定要求关闭选项、可删除个人特征标签、禁止交易价格等不合理差别待遇[来源](https://www.gov.cn/zhengce/2022-01/04/content_5728941.htm)。**个性化定价实验风险极高**，可能被认定「大数据杀熟」；不做个人差别定价，或只在有合法依据、可解释、可申诉范围内做，并提前法务评估（推断）。

AI/LLM 实验把 treatment 从「代码分支」变成「概率分布」：模型+prompt 版本+temperature/top_p+检索库+工具链+安全策略，任何一项变了都是新 treatment；记录必须绑定模型版本、prompt hash、参数、索引版本。arXiv 2407.10457 指出 LLM 评估常忽略非确定性，只测一个输出，greedy 与 sampling 差异显著[来源](https://arxiv.org/abs/2407.10457)；同一 treatment 重复输出有方差，MDE 更大，缓解是每单元多次采样，但成本线性上升。LLM-as-judge 有位置/冗长/自我增强偏差，强 judge 与人类偏好 80%+ 一致但仍需校准[来源](https://arxiv.org/abs/2306.05685)；judge 不是真值。用 LLM 代替人类做 A/B 更危险：替代终点框架下原始 LLM 输出只能恢复 39% 的人类处理效应[来源](https://arxiv.org/abs/2606.17165)，所以 LLM 实验只能做前置筛选，上线仍要真实用户 A/B。流程：离线 eval 门禁→shadow→在线 A/B→人工评审；成本看每成功任务/每用户/重试兜底。

## 7.10 模块级 build vs buy

不要按「平台」整体决策，而要按模块决策。分界线是**语义是否属于你**：实验对象模型、分流语义、曝光口径、统计方法、指标治理，是差异化且与业务数据强耦合，适合自建；Flag 求值引擎、配置分发、边缘缓存、多语言 SDK、可观测性，是商品化能力，适合采购或复用开源；指标计算、实验分析优先用现有湖仓，不另建分析数据库。

| 模块 | 自建理由 | 采购/OSS 理由 | 推荐 | 优先级 |
|---|---|---|---|---|
| 实验元数据 | 对象模型是核心资产 | 通用工作流可复用 | 自建 | P0 |
| 工作流/审批 | 流程与组织强相关 | 企业 BPM 可复用 | 自建或复用 | P0 |
| RBAC/SSO | 合规要求 | 企业 IAM 已具备 | 复用 | P0 |
| 配置分发 | 特殊网络/合规 | Relay/Edge 已解决多区域 | 采购/OSS | P0 |
| SDK | 需要业务上下文 | 多语言维护成本极高 | OpenFeature + 薄层 | P0 |
| 曝光管道 | 口径与数仓强耦合 | Kafka/Flink 通用 | 自建 | P0 |
| 指标/统计 | 差异化核心 | Eppo/Statsig/GrowthBook 可参考 | 自建 | P1 |
| 分析计算 | 已有湖仓 | 无需重复建设 | 仓原生 | P1 |
| 报表 UI | 实验工作流特殊 | BI 工具可嵌入 | 自建 | P1 |
| 可观测性 | 无 | OTel/Prometheus/Grafana 成熟 | 采购/OSS | P1 |

三套组合：**A 采购 Flag + 自建实验层**（LaunchDarkly/Unleash 做 Flag 求值和分发，自建实验元数据、曝光、统计；上线快，但两套控制面要 OpenFeature/双写过渡）；**B 开源自建一体化**（GrowthBook/Unleash + 自建分析；可控、私有化，但升级/SDK 兼容/边缘运维自担）；**C 全自研**（控制面、数据面、分析面全自建，SDK 用 OpenFeature，配置分发复用 Envoy/Redis/CDN；深度定制但投入巨大）。团队规模**存在不同说法**：架构调研按全栈自建估 15–25 人；路线图分册估 MVP 7 人、规模化 12–15 人、成熟 18–25 人；选型分册给 6–10 人核心团队（复用 OSS/云服务）。差异来自是否包含 SDK/边缘/SRE/私有化，预算前先对齐口径。

| 路线 | 控制面 | 数据面 | 分析面 | 强项 | 代价/限制 | 适用 |
|---|---|---|---|---|---|---|
| Flag-first SaaS（LaunchDarkly/Split） | 成熟、审批/RBAC 强 | SDK+Relay/Edge | LaunchDarkly 原生统计完整（频率派/贝叶斯/序贯/CUPED/SRM）；Split/Harness FME 偏实验编排 | 交付安全、生态、多语言 | 统计深度因产品而异；成本随 seats/MAU | 研发驱动、Flag 先行 |
| Experiment-first SaaS（Statsig/Eppo/Amplitude） | 实验/Flag 一体 | 全球边缘、仓库原生 | 统计强、报表快 | 实验效率、贝叶斯/序贯 | 数据出域/合规；定制受限 | 增长/产品实验密集 |
| 开源自建（Unleash/GrowthBook/Flagsmith） | 可自托管、权限/审批 | SDK+Edge/Proxy | GrowthBook 自带统计，其他需外接 | 成本可控、私有化 | 运维/升级/SDK 兼容自担 | 有平台团队、私有化 |
| 大厂自建（Google/Microsoft/Netflix/ByteDance/Meituan） | 深度定制、分层/域 | 自研 SDK/边缘 | 自研指标/统计/湖仓 | 规模、统计深度、组织贴合 | 投入巨大、复用难 | 实验是核心 |
| 云厂商（DataTester/Firebase） | 托管、开箱即用 | 厂商边缘/SDK | 托管分析 | 上线快、与云集成 | 锁定、跨境/合规、定制弱 | 用该云、实验不是核心 |

供应商稳定性必须进入选型。Google Optimize 于 2023-09-30 停服[来源](https://support.google.com/analytics/answer/12979939?hl=en)；AWS Evidently 于 2025-10-17 终止[来源](https://aws.amazon.com/blogs/mt/support-for-amazon-cloudwatch-evidently-ending-soon/)；Split 被 Harness 收购（官方称 2024-06-11 完成交割，DLA Piper 公告口径为 2024-07，**存在不同说法**，以官方交割日为准）[来源](https://www.harness.io/press-and-news/harness-completes-acquisition-of-split-software)；Eppo 于 2025-05-05 被 Datadog 收购[来源](https://www.datadoghq.com/about/latest-news/press-releases/datadog-acquires-eppo-to-expand-its-ai/)；Statsig 于 2025-09-02 宣布加入 OpenAI，2026-05-05 产品/品牌/客户转入 Amplitude，原团队留 OpenAI[来源](https://statsig.com/blog/openai-acquisition)[来源](https://statsig.com/blog/statsig-amplitude-phase-1)；Optimizely 于 2024-09-30 收购 NetSpring[来源](https://www.optimizely.com/company/press/optimizely-acquires-netspring)；Unleash Edge OSS 的 LTS 到 2025-12-12、EOL 为 2026-12-31[来源](https://docs.getunleash.io/unleash-edge)。合同必须写清：配置/曝光历史/指标定义可导出（尤其 **assignment 级曝光日志**，只有聚合报表无法复算历史）、迁移协助期、子处理商变更通知、价格保护、停服/被收购时的数据保留与删除证明、escrow。

什么时候不该自建：实验 <100/年、团队 <3 人，SaaS 更划算；没有数仓/埋点，先补数据基础；合规不允许出境又不愿私有化运维，先混合架构；只做灰度发布，Flag 平台足够。务实的组合是：**控制面与实验语义自建，Flag 求值/配置分发用 OSS 或采购，SDK 用 OpenFeature 薄层，指标计算仓原生，可观测性采购**。落地 90 天对象模型/SDK 本地求值/曝光入 Kafka/SRM/审批审计，180 天边缘多区域/CUPED/指标平台/版本化，12 个月私有化/多租户/混沌/自动回滚。**自建的是语义，采购的是通道；语义一旦外包，实验平台就退化成报表工具。**

---

## 第 8 章 全球案例、学术与趋势

> 本章拆解 Netflix、Airbnb、Booking.com、Microsoft、Google、Meta、LinkedIn、Uber、Spotify、Etsy、DoorDash、Instacart、Amazon 的实践，并给出学术脉络与 2026-2028 趋势。

## 8.1 海外大厂案例地图：十三家公司，一张约束地图

把 Netflix、Airbnb、Booking.com、Microsoft、Google、Meta、LinkedIn、Uber、Spotify、Etsy、DoorDash、Instacart、Amazon 排成一张表，最容易犯的错误是按「实验数量」排队。口径不同：Microsoft 说「每年超过一万个」，Uber 说「任意时刻一千个以上」；作为对照，字节说「日新增四千个」。三个数字不能直接比较。真正决定平台形态的是三个变量：**业务结构决定的随机化单元、组织最痛的那一环、公开材料允许我们看到的粒度**。

| 公司 | 业务约束 | 平台/关键设计 | 公开规模（年份） | 最值得抄 |
|---|---|---|---|---|
| Netflix | 订阅流媒体，科学家密度高 | XP：Metrics Repo + Causal Models + 非分布式统计栈 | 1.5 亿订阅、数百实验/年（2019） | 科学家可编程性 |
| Airbnb | 双边住宿，指标多且杂 | ERF：Airflow DAG + core/target/certified | 500 并发、2,500 指标/天（2019） | 指标分层与认证 |
| Booking.com | 高频交易决策 | 重叠实验 + 预注册 + 可搜索仓库 | 1,000+ 并发（2019） | 决策文化产品化 |
| Microsoft | 多产品线、强合规 | ExP 四组件 + trustworthiness 检查链 | >1 万实验/年（2018） | 可信度流水线 |
| Google | 海量流量、多团队 | domain/layer 分层正交 + launch layer | 2007 年前后启用（第三方讲义） | 流量复用抽象 |
| Meta | 社交网络、快速迭代 | PlanOut DSL + namespace/segment + Gatekeeper | 2024–2026 未公开 | 实验即代码 |
| LinkedIn | 数千研发、热路径 | Lix 引擎 + DSL + T-REX | 引擎 20x/14.7x 提升 | 分流引擎性能 |
| Uber | 双边市场、多城市 | XP + 四类方法路由 + universal holdout | 1,000+ 并发、1,000+ 指标 | 方法路由 |
| Spotify | 多团队、学习型组织 | Confidence + EwL 学习率 | 约 300 团队、64% 学习率（2025） | 平台 KPI 设计 |
| Etsy | 中等规模、实验健康 | 早期不平衡检测 | 未公开 | 先修分流 |
| DoorDash | 三方市场 | Curie + switchback/budget-split | 每天数百至数千（2024） | 干涉设计 |
| Instacart | 履约/地理 | cluster + 区域内方差缩减 + geo DiD | 未公开 | 非用户随机标准解 |
| Amazon | 电商/卖家生态 | 内部平台 + 卖家 MYE | 内部未公开 | 能力产品化 |

这张表不是「最佳实践清单」。同一套设计换一个约束就会失效：Google 的分层正交建立在「流量巨大、团队极多、参数可切分」之上；DoorDash 的 switchback 建立在「三方市场、供需实时再平衡」之上；Netflix 的非分布式统计栈建立在「科学家密度高、实验周期以周计」之上。**平台设计是约束的函数，不是流行的函数。**

三条跨案例规律值得先记住：其一，平台成熟度不看实验数量，看「无效实验拦截率」和「结论复现率」——Microsoft 的检查链、Etsy 的早期不平衡检测、Spotify 的 health check 都在做这件事；其二，组织模式决定平台形态，Netflix/Airbnb 是「中央平台 + 嵌入式科学家」，Spotify 是 CoE，Booking 是同行评审，Microsoft 是评审委员会；其三，最难复制的是指标治理与信任机制，算法只排第三，CUPED、序贯、贝叶斯都能买到，但「指标谁负责、曝光怎么算、SRM 谁排查」买不到。

> **口径与冲突**：字节「同时在线 5 万」（2023）与「7 万」（2025）存在不同说法，量级一致、时点不同；快手「145 倍」是特定模板的最大提升，不是平均提升，部分转述把它写成平均值，存在不同说法；Datadog 收购 Eppo 的对价官方未披露，「约 2.2 亿美元」来自第三方分析，存在不同说法。本文以官方公告/论文优先，第三方数字只作量级参考。

## 8.2 Netflix / Airbnb / Booking.com：三种「规模化」

三家公司经常被放在一起讲「实验文化」，但它们规模化的对象完全不同：Netflix 规模化**方法**，Airbnb 规模化**指标**，Booking 规模化**决策**。这个区别决定了三套平台不能互相照搬。

### 8.2.1 Netflix：把平台做成科学家的可编程工作台

Netflix 的实验平台 XP，其公开论文《Engineering for a Science-Centric Experimentation Platform》是目前工业界对「平台如何服务科学家」描述最完整的一手材料（arXiv:1910.03878，2019）[来源](https://arxiv.org/abs/1910.03878)。

架构是四层加一个反直觉选择。实验日志抽取后附用户元数据落 S3；Metrics Repo 用 Python 定义指标并**程序化生成 SQL**，重活交给 Spark；切片查询交给 Presto，因为它比 Spark/Hive 更适合交互式过滤聚合；统计计算由 Causal Models 库完成；可视化经 XP Viz 输出到 ABlaze，同一套代码也能在 Jupyter 里跑。

最反直觉的是：**整个统计计算栈是非分布式的**。Netflix 明确说，这样做是为了降低科学家贡献新方法的门槛——分布式实现难调试、难复现，会把统计学家挡在门外。代价是单机内存装不下全量数据，于是用「充分统计量压缩」来换：正态分布只需条件均值与方差即可汇总，论文称压缩率经常达到 100 倍，几百 GB 数据可以塞进一台机器；无法用充分统计量表达的方法，则用经过元分析验证的、影响可控的有损压缩。数值性能靠 C++ 基元兜底，官方称可在数秒内对上百万用户计算数百个 treatment effect。

统计上最重要的是「用潜在结果框架统一任意模型」。Causal Models 不把 t 检验、OLS、分位数回归、panel model 写成一堆特判，而是要求每个模型实现两个方法，平台统一完成「训练—复制数据—全量施治—全量不施治—预测—求差—算方差」，统一产出 ATE、CATE、DTE。它让「加一个新统计方法」从改平台变成写一个类。

信任机制有两个可以直接抄：指标计算有端到端集成测试，跑真实样本数据，任何改动都不能悄悄改变既有报表；允许对历史实验做**元分析回放**——改一个指标定义，先看它会让过去数百个已结实验的结论怎么变，再决定是否上线。这是「指标变更管理」的教科书级做法。

边界也要说清楚：论文口径是 1.5 亿订阅、每年数百个实验、XP 已运行 9 年（2019）。它不是毫秒级在线决策系统。2023–2024 年 Netflix 官方博客连载序贯检验，说明固定 horizon 的默认做法正在向「持续监控」扩展，具体上线范围待核实[来源](https://netflixtechblog.com/sequential-a-b-testing-keeps-the-world-streaming-netflix-part-1-continuous-data-cba6c7ed49df)。

### 8.2.2 Airbnb：指标平台才是实验平台的地基

Airbnb 的 ERF 是「指标平台」思路的代表。官方博客复盘了从 Ruby 脚本到 Airflow 管道的演进[来源](https://medium.com/airbnb-engineering/https-medium-com-jonathan-parks-scaling-erf-23fd17c91166)。

关键是从「一条巨查询」到 DAG。早期 ERF 用一条巨大的 Hive 查询算完所有指标，导致源表反复扫描、无法断点续跑、依赖检查必须等所有指标表就绪。迁移到 Airflow 后，计算拆成许多独立 task，可以增量重跑、并行、只重算受影响的指标，端到端耗时从 24 小时以上降到约 45 分钟。

指标分层是 ERF 最值得抄的设计：**core / target / certified**。core 是每个实验必看的体检项；target 是发起人声明的重点指标，UI 优先展示；certified 由数据工程审计并承诺 SLA。三层同时解决「指标太多看不过来」和「口径没人负责」。ERF 还支持 dimensional cuts，规模约 500 个并发实验、每天约 2,500 个不同指标、约 5 万个「实验×指标」组合（2019 年前后）。

代价：认证会排队，紧急实验可能等不到 certified；维度切片与「实验×指标」组合数呈乘法增长，必须「常用切片预计算 + 按需计算」。小团队实验量不大时，Airflow + 分层认证会过重。

### 8.2.3 Booking.com：把「重叠实验」当成产品决策方式

Booking.com 的实验负责人 Lukas Vermeer 在官方访谈中给出了一组可引用口径：**任意时刻有超过 1,000 个并发实验**；实验可以重叠；公司推行**预注册**，发起人必须先写假设、预期影响与指标；平台是所有历史实验的**可搜索仓库**，同行可以评审彼此的设计[来源](https://partner.booking.com/en-gb/click-magazine/industry-perspectives/role-experimentation-bookingcom)。

为什么故意允许重叠？理由不是统计上的，而是外部效度上的：两个改动各自有效，不代表一起上线仍有效；隔离测试反而看不到真实交互。他们承认重叠有交互效应与归因复杂的局限，但判断「做一个更好的产品」优先于「做完美的科学」。文化机制是透明、问责、领导层公开承认「可以失败」——如果组织认定「领导一定对」，实验就退化成给结论找证据。

代价：重叠实验放大交互效应与 SRM 排查难度；预注册与评审增加前置成本；1,000 个并发意味着大量长尾小流量实验，功效不足会普遍存在。这套模式适合高频决策的 C 端交易产品，不适合强监管、改动不可逆的场景。

| 维度 | Netflix | Airbnb | Booking.com |
|---|---|---|---|
| 规模化的对象 | 方法/科学家 | 指标/口径 | 决策/实验量 |
| 关键机制 | Causal Models API + 元分析回放 | core/target/certified + DAG | 重叠实验 + 预注册 + 可搜索仓库 |
| 规模口径 | 1.5 亿订阅、数百实验/年（2019） | 500 并发、2,500 指标/天（2019） | 1,000+ 并发（2019） |
| 主要代价 | 非分布式天花板、治理成本 | 认证排队、组合爆炸 | 交互效应、功效不足 |
| 可移植性 | 低（需科学家密度） | 高（指标分层） | 高（流程） |

三种规模化不能同时做。一个组织若连指标口径都没统一，先学 Netflix 只会得到一台更贵的 p 值生成器；若实验量不足，先学 Booking 的重叠实验只会制造大量 underpowered 结论。对多数 DAU 千万级、已有数仓的公司，Airbnb 的指标分层与 Booking 的预注册是投入产出比最高的两件事。三家的共同点更值得注意：都把「实验定义」与「分析」分开，都投资了可搜索的实验记忆——**实验记忆是唯一会随实验数量增加而增值的资产**。

## 8.3 Microsoft / Google / Meta / LinkedIn：四个瓶颈，四种答案

这四家经常被当成「大厂平台」笼统比较，但它们回答的是不同问题：Microsoft 修**可信**，Google 修**流量复用**，Meta 修**表达力**，LinkedIn 修**性能**。把四套设计混着抄，是平台建设中最常见的翻车方式。

### 8.3.1 Microsoft ExP：把「可信」做成一等公民

微软 ExP 是「trustworthiness 优先」的范本。ICSA 2018 论文给出四个核心组件：experimentation portal、experiment execution service、log processing service、analysis service；服务对象从 bing.com 到移动 App，再到 Windows 设备驱动；**每年超过一万个实验**；目标是「任何改动都能被 A/B 实验覆盖」，并做到「想法几分钟变实验、实验几小时出首版可信结果」[来源](https://www.microsoft.com/en-us/research/publication/the-anatomy-of-a-large-scale-experimentation-platform/)。

trustworthiness 是一套检查链：**SRM 诊断**（KDD 2019 把 SRM 从分析师经验变成平台可告警的故障类型[来源](https://dl.acm.org/doi/abs/10.1145/3292500.3330722)）、**A/A 测试**、**guardrail 监控**、**OEC 与决策规则**、**功效/MDE 预估**、**实验评审委员会**。Kohavi/Tang/Xu 的书把这些整理成章，第 21 章专讲 SRM 与 trust-related guardrail[来源](https://experimentguide.com/)。统计栈以固定 horizon 为主，配合序贯做早期监控；CUPED 由微软/斯坦福团队 2013 年系统化；比率指标用 delta method，重尾用 bootstrap/分位数。微软的贡献不是发明检验，而是把方法**产品化、默认化、可审计化**。

代价：一万个实验/年包含大量低价值实验；四段式架构在超大规模下产生跨团队依赖；检查链拖慢周期。值得抄的是「检查链」，不是「四组件」的具体实现。

### 8.3.2 Google：分层正交是流量复用的核心发明

Google 2010 年的 KDD 论文《Overlapping Experiment Infrastructure》奠定了「分层实验」的工业标准[来源](https://research.google/pubs/pub36500/)。据第三方讲义，Google 自 2007 年前后开始使用这套设施[来源](https://speakerdeck.com/srihari/overlapping-experim)。

核心抽象是 domain / layer / experiment：**domain** 按 cookie、user id 等哈希切流量；**layer** 是一组互斥参数的集合，layer 内实验共享流量、彼此互斥；**layer 之间正交**，不同 layer 用不同 salt 哈希，同一用户在不同 layer 的分组相互独立；**launch layer** 做灰度发布与「必须全量」的配置；**diversion 函数必须是纯函数**，否则用户会在实验组之间闪烁；**conditions** 在分流后做二次过滤（国家、平台、机房）。

统计上最容易被忽略的是：**正交只保证分流独立，不保证效应可加**。同一用户被多个实验同时影响时，layer 的划分本身是治理问题：谁拥有哪个 layer、哪些参数必须同层、哪些实验禁止叠加，都需要平台规则约束。Google 公开材料以固定 horizon 为主，配合多重比较校正；CUPED 由微软团队 2013 年提出，Google 等公司随后广泛采用。

产品状态：Google Optimize 已于 2023-09-30 停服，官方建议迁移 GA4 与 Firebase[来源](https://support.google.com/analytics/answer/12979939)。**Google 内部的分层实验基础设施与对外产品是两套东西**——评估商业平台时，不要把「Google 内部用分层实验」当成「Firebase A/B Testing 很强」的证据。

### 8.3.3 Meta：PlanOut 定义「实验即代码」，Gatekeeper 定义「配置即灰度」

Meta 对工业界最大的贡献是 PlanOut。WWW 2014 论文把实验从「应用代码里的 if-else」抽象成**参数化 + 声明式脚本**：实验者只描述「哪些 unit、按什么概率、分到哪些参数值」，应用代码通过 `get()` 取值，实验逻辑与业务逻辑解耦[来源](https://ar5iv.labs.arxiv.org/html/1409.3174)。

分流机制的关键细节：PlanOut 不直接哈希 unit，而是把「namespace + experiment + 变量名 + unit id」拼成字符串再做 SHA1，例如 `user_signup.my_exp.button_color.42`。这带来确定性（同一 unit 永远同一组）、平台无关（PHP/Python/JS 算出来一样）、**变量间独立**（改一个变量的 salt 不会扰动另一个）。设计能力覆盖 A/B、factorial、条件分流、多 unit/嵌套 unit、自定义 operator；**曝光日志在 `get()` 时自动记录**，把「被分配」与「实际曝光」分开。namespace/segment 用来管理同一批流量上的迭代实验，每次分配新 segment，不改运行中的实验。

Gatekeeper 管「这个功能对谁开、开多少」，PlanOut 管「实验怎么设计、参数怎么分」，两者分工清晰[来源](https://www.sigops.org/s/conferences/sosp/2015/current/2015-Monterey/008-tang-online.pdf)。限制（论文自述）：全局优化、预分层、图聚类、bandit 都需要离线预计算或自定义 operator；网络效应无法自动解决；DSL 有学习成本。Meta 未公开 2024–2026 年规模。

### 8.3.4 LinkedIn：把分流引擎做成高性能 DSL 运行时

LinkedIn 的实验基础设施有两块公开资产：分流引擎 **Lix** 与分析平台 **T-REX**。Lix 最初用 Clojure 写，弱类型、内存开销大、GC 停顿长，且熟悉 Clojure 的工程师少。重写为 Java 后，官方数字是：顺序求值快 20 倍、并发快 14.7 倍、内存降到约 1/10.2，并消除超过 50ms 的 GC 停顿；同时引入 Lix DSL，声明式描述随机分流与分段，保证同一实验对同一用户永远给出同一 treatment[来源](https://www.linkedin.com/blog/engineering/ab-testing-experimentation/making-the-linkedin-experimentation-engine-20x-faster)。

这段经历的价值不在「Java 比 Clojure 快」，而在**分流引擎是热路径**：它被每次请求调用，性能直接决定实验密度与延迟预算；DSL 把「实验配置」从代码发布中解耦，才可能天级迭代。代价是 DSL 图灵完备性受限、调试工具要另建、老实验迁移有兼容风险。LinkedIn 也是 CUPED 的诞生地（2013），并在 KDD 2015 的《From Infrastructure to Culture》中讨论社交网络效应、不可随机化场景、以及「基础设施易建、文化难建」[来源](https://dl.acm.org/doi/10.1145/2783258.2788602)。T-REX 目前支持哪些统计方法，官方未给出完整清单，待核实。

| 公司 | 瓶颈假设 | 核心抽象 | 组织配套 | 主要代价 | 适用条件 |
|---|---|---|---|---|---|
| Microsoft | 结论不可信 | 检查链 | 评审委员会 | 周期变长 | 多产品线、强合规 |
| Google | 流量不够复用 | domain/layer | layer owner | 治理复杂 | 海量流量、多团队 |
| Meta | 表达力/迭代速度 | PlanOut DSL | 设计评审 | DSL 工具链 | 高频产品实验 |
| LinkedIn | 分流热路径性能 | Lix 引擎 + DSL | 平台团队 | 重写迁移 | 数千研发、高并发 |

最常见的三种翻车：抄了 layer 却没有 layer owner，参数冲突；抄了 DSL 却没有调试工具，实验配置变成黑盒；抄了 Microsoft 的检查链却没有评审容量，实验排队两个月。四者不是互斥方案，而是不同瓶颈的答案——先诊断自己的瓶颈，再选抽象。

## 8.4 Uber / Spotify / Etsy / DoorDash / Instacart / Amazon：实验设计跟着业务结构走

这六家把实验设计从「统计方法选择」变成「业务结构识别」。共同结论是：**随机化单元不是默认的用户，而是由干涉结构决定的**；统计方法不是越高级越好，而是要与问题类型匹配。

### 8.4.1 Uber：一个平台，四类方法，按问题路由

Uber 的 XP 是「方法组合」的最佳公开样本。官方口径：**任意时刻有 1,000 个以上实验**，覆盖司机端、乘客端、Uber Eats、Freight；支持 A/B/N、因果推断与 MAB；指标库超过 1,000 个，用协同过滤做指标推荐[来源](https://www.uber.com/blog/xp/)。

四类方法对应四类问题：**固定 horizon A/B/N** 用 Welch t、卡方、Mann-Whitney、delta method、bootstrap，多 treatment 用 BH 控制 FDR，默认 alpha=0.05、power=0.8；**序贯 SPRT/mSPRT** 主要不是提前宣布胜利，而是**监控线上事故**，用 jackknife/block bootstrap 处理同用户多天相关；**因果推断**用合成控制与 DiD 处理城市级定价等无法随机化的场景；**bandit** 用 Thompson、UCB、contextual MAB、Bayesian optimization 做内容、超参、预算与自动 rollout。

工程上检测两类「实验病」：SRM（重查随机化机制）与 **flickers**（用户在组间切换，直接剔除）；指标预处理含异常值聚类、CUPED、DiD 预偏差校正；平台提供 **universal holdout** 度量域内所有实验的长期累积效应。MAB 的代价博客写得很坦承：它优化累计收益，不是无偏效应估计，长期效应、护栏与解释力都更弱。因此 Uber 是「按问题路由」，不是用一个引擎包打天下。

### 8.4.2 Spotify：从「实验速度」转向「学习率」

Spotify 的平台叫 Confidence。其 2025-09 官方博客给出罕见的平台 KPI 复盘：2018 年只有约 40 个团队在规律实验，目标是 300 个；2021 年底超过 200 个团队，2022 年接近 300 个[来源](https://engineering.atspotify.com/2025/9/spotifys-experiments-with-learning-framework)。

核心概念是 **Experiments with Learning（EwL）**。Spotify 认为用 win rate 衡量平台是错的，实验的第一价值是**风险管理**——发现「不该上线」的改动。EwL 要求结果「有效」（分流、埋点、指标正常，无 SRM）且「可决策」（显著正向且无护栏恶化 / 检出回退 / 功效足够的中性但信息量充足）。按此口径，整体学习率约 **64%**，团队间 16%–76%；两个承载约 80% 实验的组织，学习率约 64%、win rate 仅约 **12%**。大部分价值来自「确认无效」与「发现回退」，不是「找到赢家」。官方还披露：58 个团队在移动端首页跑了 520 个实验，EwL 被用来分配测试带宽。

统计立场（2026 年最新）：Spotify 明确**不增加 Bayesian 模式**。理由很技术：flat prior + 后验阈值在数值上等价于频率派；真正有额外保证的是「Bayes factor stopping + 良好校准的经验贝叶斯先验」，但它要求按指标维护先验、历史实验库足够大可交换，维护成本与误用风险超过收益；双模式还会造成规划、监控、解释不一致[来源](https://engineering.atspotify.com/2026/9/why-spotify-is-not-using-bayesian-a-b-testing)。组织上，engagement team 做 CoE，health check 前置，实验结束强制填「为什么结束」，区分 Aborted 与 Unpowered。EwL 可能被 gaming（降低 MDE 让更多实验「中性且有功效」），所以用 win rate、实验量、精度做护栏。

### 8.4.3 Etsy：把「不平衡检测」产品化

Etsy 的工程博客曾专文讨论 **imbalance detection for healthier experimentation**，在实验早期检测分流不平衡，把 SRM 从「事后发现」变成「上线即监控」[来源](https://www.etsy.com/codeascraft/imbalance-detection-for-healthier-experimentation)。具体算法未完整公开，待核实。对中等规模公司，这个点比「上 CUPED」更划算：多数结论错误源于分流/埋点/曝光口径，不是方差太大。限制是早期检测灵敏度受样本量限制，阈值太紧会造成告警疲劳。

### 8.4.4 DoorDash：三方市场必须换随机化单元

DoorDash 的实验平台由配置平台、分析平台 **Curie**、指标平台组成；Curie 从结果页 MVP 长成分析中枢，编排用 Dagster，存储用 data lake + Snowflake，探索分析走 Databricks[来源](https://opendatascience.com/experimentation-platform-at-doordash/)。规模是「每天数百到数千个实验、每个实验数十亿数据点」；为提速使用 surrogate metrics、方差缩减、指标变换、triggered analysis 与 moments algorithm。

干涉是核心难题：外卖是消费者—骑手—商家三方市场，用户级随机化会因供需再平衡失效。解法是 **switchback**（时间片轮换，控制时间固定效应）与 **budget-split**（预算切半做对照）。代价：switchback 功效低于用户级随机，要求时间片多、carryover 可控；budget-split 牺牲部分收入效率。

### 8.4.5 Instacart：随机化粒度低于分析粒度时怎么办

Instacart 公开了两个方法点。其一是 **variance reduction below the randomization grain**：随机化在仓/区域，分析在用户/订单粒度时，直接细粒度 CUPED 会破坏一致性，需在 cluster 内构造协变量、在正确粒度做方差缩减[来源](https://tech.instacart.com/variance-reduction-below-the-randomization-grain-31719f87a7d2)。其二是 **geo-based A/B + DiD**：catalog 等无法用户级随机的场景，按地理区域分组，用 DiD 控制区域固定效应与共同时间趋势[来源](https://tech.instacart.com/geo-based-a-b-testing-and-difference-in-difference-analysis-in-instacart-catalog-2ba05e744a3f)。合起来是「聚类随机化 + 区域内方差缩减 + 地理 DiD」的标准解；cluster 少于 20 个时推断很脆弱。

### 8.4.6 Amazon：内部大规模实践 + 对外产品化

Amazon 内部实践主要通过 Kohavi 等人的论文与书籍公开（OEC、guardrail、长期效应、SRM），与 Microsoft ExP 同源：平台价值在于「让每个改动都可被证伪」，不是「让每次实验都显著」；Amazon Science 也公开过定价实验讨论[来源](https://www.amazon.science/publications/science-of-price-experimentation-at-amazon)。更有辨识度的是对外产品化：Manage Your Experiments 允许卖家对 listing 标题、主图、A+ 内容做 A/B，Seller Central 文档 2026-10 仍可访问[来源](https://sellercentral.amazon.com/help/hub/reference/external/GYZYA77YZTWTF7YZ)。这把内部能力封装成卖家增长工具，平台收流量与广告收益，不收软件订阅费。限制是单个 listing 流量小、功效不足、周期长，且只能覆盖少数可编辑要素。

| 公司 | 业务结构 | 随机化单元 | 关键方法/机制 | 平台亮点 | 主要代价 |
|---|---|---|---|---|---|
| Uber | 双边市场 + 多业务 | 用户/城市/时间 | 四类方法路由、mSPRT 监控、universal holdout | 方法路由 | 方法多、培训成本 |
| Spotify | 多团队内容平台 | 用户 | 频率派、EwL、拒绝贝叶斯 | 学习率 KPI | 指标可 gaming |
| Etsy | 中等电商 | 用户 | 早期不平衡检测 | 实验健康前置 | 小样本灵敏度 |
| DoorDash | 三方市场 | 时间片/预算 | switchback、budget-split、代理指标 | 干涉设计 | 功效/收入效率 |
| Instacart | 履约/地理 | cluster/geo | 区域内方差缩减、geo DiD | 非用户随机标准解 | cluster 少时脆弱 |
| Amazon | 电商/卖家生态 | listing/卖家 | OEC/guardrail；MYE | 能力产品化 | 卖家侧功效不足 |

最值得抄的两个：**Spotify 的学习率 KPI**，解决「平台怎么证明自己有用」；**Uber 的方法路由**，解决「什么问题用什么方法」。Etsy 是中等规模公司性价比最高的案例：先把分流修好，再谈 CUPED。DoorDash/Instacart 的价值在「先识别干涉结构，再选随机化单元」的设计顺序——把它们当「高级统计插件」会失败。

## 8.5 中国大厂公开资料与学术脉络：五条路线，三种加码

中国大厂的公开材料有一个共同偏向：少谈「实验文化」，多谈指标怎么算、干涉怎么处理、链路怎么扛规模。这不是文化不重要，而是超级 App 与双边市场把工程约束推到了前面。证据层级也很清楚：论文 > 官方文档 > 工程博客 > 专利/新闻。

| 公司 | 主攻 | 关键公开事实 | 方法亮点 | 代价 |
|---|---|---|---|---|
| 字节 | 图计算 + 因果 + 规模化 | 2012 引入、2016 产品化、2021 对外开放；2023 日新增 4,000+、在线 5 万+；2025 在线 7 万+、累计 340 万+ | ITR、Parleiden、DQ | 图/模型复杂度 |
| 微信 | 指标计算 OLAP 化 | PVLDB 2024：数万指标/数万策略、数百 PB/天 | BSI + 1024 桶、Spark+ClickHouse | BSI 表达力、批处理延迟 |
| 阿里淘天 | 实时数仓/湖流一体 | 通天塔 2015 起步、100+ 场景；Fluss 618 峰值千万级、1 秒内 | 列裁剪、Delta Join、域-层-正交 | 实时链路重、State 大 |
| 美团 | 分析引擎解耦 | 8 篇白皮书；11+ 方法、7+ 分组、10+ 检验 | CAR、二元 CUPED、统合分析 | 方法多、门槛高 |
| 快手 | Doris 指标生产 | 2,000 BE/10 万核；Spark 21 分钟→最大 145 倍、资源 -72% | Colocate Join、Local Distinct Grouping Sets、CUPAC | 集群重、元数据运维难 |

字节的独特之处不是规模，而是把干涉做成了产品线。ITR 用线性、树、神经网络三种模型预测实验期指标，再用 stacking 学权重，官方称在一条业务线 10 个指标上最高再降约 20% 方差（自报）；Parleiden 把 Leiden 并行化，快约 10 倍，数小时可处理约 1 亿节点、300 亿条边；DQ 把实验推断形式化为策略评估，论文称在抖音把 MSE 降低 99%[来源](https://arxiv.org/abs/2305.02542)。架构主线是分流 SDK、指标平台、图平台、因果推断平台四者解耦，才撑得住日均 4,000 个新实验[来源](https://server.it168.com/a2024/1023/6866/000006866793.shtml)。

微信论文给出一条硬约束：**随机化单元必须不低于分析单元的粒度**。BSI 把曝光、指标、维度统一编码为「分析单元 ID + 值」，让同一用户在所有 BSI 中位置一致，天然完成 Join；按 1024 个 segment 并行，再按 1024 个 bucket 做桶级重采样估方差；Spark 例行预计算 + ClickHouse 即席下钻。代价是 BSI 只适合非负整数、中位数等不可分解聚合需近似，且不是端到端实时[来源](https://ar5iv.labs.arxiv.org/html/2405.08411)。阿里通天塔 2015 年起步、覆盖 100+ 场景；Fluss 实践把实时性代价讲透：原链路曝光作业 70% 的 IO 为不需要的列付钱，成交归因 State 达 100TB；改造后 IO 降 25%、资源降 30%、减免 95TB State、CPU/内存降 80%+，618 峰值千万级流量、平均延迟 1 秒内[来源](https://developer.aliyun.com/article/1672360)。

美团 8 篇《可信实验白皮书》是中文最系统的一套：BETA 分析引擎与分流/配置/数据生产解耦，覆盖随机对照、随机轮转、准实验、观察性研究；样本少于 40 时，完全随机的不同质比例超过 6%，CAR 可控制在 5% 以下；一个反例是「分析单元比分流单元细、却用错方差公式」时，真实无提升的实验被误判显著的概率接近 50%[来源](https://tech.meituan.com/2025/05/22/meituan-AB-Online-Controlled-Experiment-01.html)。快手把 Doris 做到极致：2,000 BE、10 万核，Spark 21 分钟链路最大提升 145 倍、资源降 72%，代价是 FE 元数据在千万级 Tablet 时接近 400GB[来源](https://www.selectdb.com/blog/1719)。

滴滴 Apollo 公开 6,000+ 实验/周，CAR 在 95% 情况下把 1 万司机人群的组间差异控制在 0.8% 以下（完全随机可达 14%+）；但已按 CR 分流完的实验无法回溯修复[来源](https://blog.csdn.net/didi_tech/article/details/106424045)。百度专利采用子组交叉配对 + 多重检验校正；B 站专利侧重分层配置、任务关联、按用户分流。

三条学术线很清楚：**方差缩减**（CUPED → 字节 ITR、快手 CUPAC、美团二元 CUPED）、**干涉**（字节 DQ/Parleiden、快手 Balanced Louvain、美团半城 DiD）、**指标计算**（微信 BSI、快手 Doris、阿里 Fluss）。第三条是相对独特的贡献：把统计推断前置到存储/计算层，而不是在 BI 层做。风险也在这里——模型化方差缩减若没有分层 A/A 校准，容易低估方差、抬高假阳性。

与欧美对比：欧美公开材料更强调 trust chain、组织文化、标准；中国更强调规模工程、干涉、指标计算。公开缺口是序贯、贝叶斯、HTE 的系统细节几乎看不到；「没公开」不等于「没做」。一个有趣的反转是：中国平台常把分析引擎与分流解耦（美团 BETA），美国平台常把 flag 与 experiment 集成（Statsig/Eppo）；两者其实在同一个终点汇合——共享 assignment ID，分离分析面。

> **口径与冲突**：字节 5 万与 7 万是时点差异；美团 2024 与 2025 的方法数量口径不同（7 种分组/16 种方法 vs 11+ 方法/7+ 分组/10+ 检验），存在不同说法；快手 145 倍是最大提升；滴滴 6,000+/周是 2020 年数据，现状待核实。

## 8.6 学术基础与标准：学术解决「对不对」，平台解决「用不用得起来」

学术史的主线不是「发明更多检验」，而是把「可信推断」拆成可产品化的检查点。

《Trustworthy Online Controlled Experiments》2020 年出版；官方简介称基于「每家公司每年运行超过 20,000 次受控实验」的实践[来源](https://www.cambridge.org/core/books/trustworthy-online-controlled-experiments/D97B26382EB0EB2DC2019A7A7B518F59)。它把经验整理成三层：指标层（OEC 与护栏）、可信层（SRM、A/A、Twyman's law、novelty/primacy）、组织层（评审、实验记忆、边际成本）。OEC 不是「老板最关心的指标」，而是一个同时约束短期收益与长期价值的目标函数；SRM 则被比喻为「发烧」——是多种数据质量问题的共同症状，不是单一病因[来源](https://www.kdd.org/kdd2019/accepted-papers/view/diagnosing-sample-ratio-mismatch-in-online-controlled-experiments-a-taxonom)。

CUPED 是「论文到默认」最成功的案例。WSDM 2013 的原始论文要解决的不是「如何显著」，而是「同样流量下如何更快、更稳地检测真实效应」[来源](https://dl.acm.org/doi/10.1145/2433396.2433413)。调整后的指标 Y_cv = Y − θ(X − E[X])，方差缩减约 1−ρ²：ρ=0.5 省约 25% 方差，ρ=0.7 省约 51%。GrowthBook 文档转引 Netflix 2016 年「部分关键指标减约 40% 方差」、Microsoft 2022 年「相当于给多数指标增加 20% 流量」，但这是特定指标、特定用户结构的结果，不是通用承诺[来源](https://docs.growthbook.io/statistics/cuped)。工程上难的不是公式，是数据：pre-period 不能被处理污染、必须在随机化单元上做、新用户缺失、重尾要缩尾、比率指标要用 Delta method、θ 的不确定性要计入方差。

Peeking 的数学很残酷：Evan Miller 2010 年的例子中，真实无差异、每来一个样本就看一次并「显著就停」，最终误报率可高达 26.1%，是名义 5% 的五倍多[来源](https://www.evanmiller.org/how-not-to-run-an-ab-test.html)。三条解法：group sequential/alpha spending（预设看点，功效有损）、always-valid/mSPRT（任意停时有效，但 CI 更宽、要调混合分布）[来源](https://ar5iv.labs.arxiv.org/html/1512.04922)、贝叶斯（解释直观，但「后验 95%」不是频率派错误率）。Optimizely Stats Engine 用的是 always-valid 路线[来源](https://www.optimizely.com/contentassets/9205a8a811e84957a7cca527d4af20be/whitepaper_optimizely_stats_engine.pdf/download)；GrowthBook 的序贯只支持频率派，靠 N*（默认 5,000）调参，文档明确说 CI「一致地更宽」[来源](https://docs.growthbook.io/statistics/sequential)。Uber 则把序贯用于监控事故，不用于提前宣布胜利。

多重比较的公式不难，「家族」定义才难。一次看 20 个独立指标，至少一个假阳性的概率约 64%；FWER 管「至少一个假阳性」，FDR 管「显著结果中假阳性的期望比例」。平台通常支持 Holm/Bonferroni 与 BH，但 GrowthBook 坦承：校正后的 p 值没有直接对应的置信区间，平台是用 adjusted p 反推「等效标准误」再构造 CI，属于 ad-hoc[来源](https://docs.growthbook.io/statistics/multiple-corrections)。这提醒我们：adjusted p 与 CI 不一致，是很多平台的隐藏坑。

标准只走到「求值」这一层。OpenFeature 是 CNCF incubating 项目、Apache 2.0，规范覆盖 Flag Evaluation API、Providers、Evaluation Context、Hooks/Events/Tracking、OFREP 远程求值[来源](https://openfeature.dev/specification/)。它标准化了「给定 context，求一个 flag 的值」，但没有标准化实验分配语义（随机化单元、salt、分层、互斥、holdout）、曝光事件契约、指标语义、统计方法与治理。所以它是「flag 世界的 USB-C，不是实验平台的 ISO」[来源](https://openfeature.dev/)。相邻的指标语义层（dbt Semantic Layer/MetricFlow、Cube）与遥测标准（OpenTelemetry）各自解决一段，但 OTel 不定义「实验曝光」这一语义事件。未来 2–3 年最值得关注的标准化，不是又一个 flag API，而是曝光 schema + 指标语义契约。

| 概念 | 原始文献 | 产品化 | 2026 状态 | 仍未解决 |
|---|---|---|---|---|
| CUPED | WSDM 2013 | Microsoft/LinkedIn → Eppo/GrowthBook/Statsig | 头部指标默认开 | pre-period 污染、新用户 |
| Always-valid | mSPRT 2015 | Optimizely Stats Engine | 序贯选项普及 | CI 变宽、N* 调参 |
| SRM 分类 | KDD 2019 | ExP/Etsy/GrowthBook | 自动检测普及 | 根因下钻仍靠人 |
| PlanOut | WWW 2014 | Meta → OpenFeature provider | flag API 标准化 | 分配/曝光语义未标准化 |
| OEC | 书 2020 | 实验注册表单 | 仍常被跳过 | 组织激励 |

学术解决「估计量对不对」，平台解决「默认值、数据契约、解释成本」。多数失败不在公式，而在 last mile：默认参数、指标类型、SRM 下钻、审计记录。

## 8.7 2026–2028 趋势判断：从「实验工具」到「决策层」

把 2023–2026 的事件分成「事实」与「叙事」两层，能避免把厂商发布会当成趋势。

| 日期 | 事件 | 结构含义 |
|---|---|---|
| 2023-09-30 | Google Optimize 停服 | 超大规模厂商退出通用实验产品 |
| 2024-05-29 | Harness 收购 Split | 实验并入交付平台 |
| 2024-10-17 | AWS 宣布 Evidently 终止（2025-10-17 停服） | 云厂商实验被折叠进配置服务 |
| 2025-05-05 | Datadog 收购 Eppo | 实验并入可观测性 |
| 2025-09-02 | OpenAI 以 11 亿美元收购 Statsig | AI 公司买实验基础设施 |
| 2026-05-05 | Statsig 产品与客户转给 Amplitude | 被收购不等于产品更安全 |
| 2026-05-26 | Cloudflare Flagship 公测 | 边缘 flag 从基础设施侧进场 |
| 2026-07 | AWS AppConfig 上线原生实验 | 云厂商以配置管理重回实验 |
| 2026-09-16 | VWO 与 AB Tasty 统一为 Wingify | PE 整合，年收入超 1 亿美元 |

| 趋势 | 证据强度 | 2028 可证伪信号 | 对我们的动作 |
|---|---|---|---|
| 套件化/去平台化 | 强 | 独立实验厂商收入破 1 亿美元 | 采购加所有权/迁移条款 |
| 决策层与度量层解耦 | 中强 | 头部厂商默认 BYO 数仓 | 自建分配/曝光/指标语义 |
| 统计收敛：CUPED + 序贯默认，贝叶斯退居展示 | 中强 | 监管要求固定样本 | 默认组合，不押单一范式 |
| 干涉感知设计成为一等公民 | 强（案例） | switchback 成为标准配置 | 实验创建时做设计路由 |
| AI 实验分两层：AI 辅助 vs 评估 AI | 弱到中 | 可审计 LLM judge 替代在线实验 | 先离线 eval + 人工校准 |
| 标准缺口转向曝光/指标语义 | 中 | OTel/厂商联盟发布 exposure schema | 内部先定 schema |

三个反趋势同样重要：PE 控股（Everstone/Wingify、Centre Lane/Monetate）会带来提价与打包销售，方法论创新放缓；整合会降低独立厂商的路线图自主性；云厂商的实验能力始终是云服务附属品，不能写进三年战略。AI 叙事目前跑在方法前面——「用 AI 辅助实验」已普遍落地，「用实验评估 AI」还缺公开的统计方法论文。

我的判断是：到 2028 年，实验平台不会消失，但会变成「决策层」——上面是实验设计、治理与学习记忆，下面是数仓、边缘与 flag。独立的中间层要么被分析/可观测/交付平台吸收，要么靠垂直场景（移动、电商、合规）存活。买家最该盯的不是功能清单，而是三个信号：所有权是否稳定、数据能否导出、是否支持 OpenFeature 与数仓原生。

## 8.8 推荐阅读与启示

### 8.8.1 推荐阅读：按问题，不按名气

如果只读三篇：Netflix XP 论文（平台如何服务科学家）、Google 2010 分层论文（流量复用）、Kohavi 书（可信推断的完整框架）。统计补三篇：CUPED 原论文、Always Valid Inference、Evan Miller 的 peeking 文章。平台补三篇：Airbnb ERF、LinkedIn Lix、Eppo 架构文档[来源](https://docs.geteppo.com/reference/architecture-and-security/)。组织与中国补三篇：Booking 访谈、Spotify EwL、美团白皮书 01。趋势补两篇：Datadog 收购 Eppo 的官方说明[来源](https://www.datadoghq.com/blog/datadog-acquires-eppo/)、Statsig + Amplitude Phase 1[来源](https://statsig.com/blog/statsig-amplitude-phase-1)。

### 8.8.2 对我们的启示

| 优先级 | 动作 | 依据 | 12 个月验收信号 |
|---|---|---|---|
| P0 | 统一曝光 schema 与 20 个核心指标 | Airbnb/微信/美团 | 所有实验可下钻到端/版本；10 个 A/A 通过 |
| P0 | SRM/A-A/guardrail 做成门禁 | Microsoft/Etsy/美团 | 未解释 SRM 阻断解读；告警 24h 内定位 |
| P1 | 分层正交 + 域级 holdout | Google/Uber | 每个域有 owner；5% 长期 holdout |
| P1 | 默认固定 horizon + CUPED；序贯只用于止损 | Uber/Spotify | 头部指标 CUPED 覆盖；序贯不用于宣布赢 |
| P1 | 随机化单元路由 | DoorDash/Instacart/字节 | 市场/地理/社交场景有设计模板 |
| P2 | 学习率 KPI + 实验记忆 | Spotify/Booking | 可搜索仓库；季度学习率而非实验数 |
| P2 | OpenFeature 适配 + warehouse-native 分析 | Eppo/GrowthBook/Cloudflare | 业务代码只依赖 OF；明细不出仓 |

三不要：不要抄 Netflix 的非分布式栈（科学家密度不够）；不要第一年做 MAB 自动调流量（归因与长期效应弱）；不要把 flag 平台当实验平台（灰度只证明没坏，不证明有效）。

十三个案例最终收敛为一句话：实验平台的竞争力，是让「不可信的结论」更少、让「可信的结论」更快，不是让统计方法更多。前 12 个月做指标与信任，6–18 个月做复用，18 个月以后再碰复杂设计——这个顺序，比任何架构图都重要。

---

## 9. 综合对比与选型建议

> 本章不追求「谁排第一」，而是回答：**在我们这样的公司（DAU 千万级、已有埋点/数仓、多端、多个业务线）里，哪一层该买、哪一层该建、哪一层必须自己治理。**

### 9.1 一张纸看完全局：七类玩家与 2026 年的所有权变化

先看「今天谁还是独立公司」。2023-2026 年的整合，已经让很多熟悉的名字换了主人：

| 原品牌 | 2026 年状态 | 关键变化 | 对买家的含义 |
|---|---|---|---|
| Optimizely | 独立（Insight/Episerver 系） | 2024 收购 NetSpring 补产品分析 | DXP 打包，实验是其中一个模块 |
| VWO + AB Tasty | **Wingify** | 2025 Everstone 控股 VWO；2026-09 与 AB Tasty 合并为 Wingify | 两套引擎合并期，路线图与续费条款要盯紧 |
| Split | **Harness FME** | 2024-05-29 宣布、2024-06-11 交割 | 从轻量工具变成交付平台的一部分 |
| Statsig | **Amplitude 旗下** | 2025-09 OpenAI 以 11 亿美元收购；2026-05 产品/客户转给 Amplitude | 「被巨头收购」不等于产品更稳，客户可能被剥离 |
| Eppo | **Datadog 旗下** | 2025-05 被 Datadog 收购 | 与 Product Analytics/APM 整合，独立路线图减弱 |
| SiteSpect | **Monetate 旗下** | 2025 被 Monetate 收购 | 服务端测试能力并入个性化套件 |
| LaunchDarkly | 独立 | 2025 收购 Highlight，转向 Guarded Releases | Flag 强；实验模块有独立统计引擎（默认频率派，支持贝叶斯/序贯/CUPED/SRM），但定位仍偏「发布安全」 |
| Cloudflare Flagship | Cloudflare | 2026-05 public beta | 边缘 Flag，不是实验平台 |
| AWS Evidently | **已停服** | 2024-10 公告，2025-10-17 终止 | 云厂商原生实验的失败样本；AppConfig 2026-06 补实验编排，但不做统计推断 |
| Google Optimize | **已停服** | 2023-09-30 | Web 优化时代结束，流量转向第三方 |

> 这张表本身就是选型的第一条建议：**把「供应商未来 3 年是否还独立运营这个产品」纳入评分**。具体日期与来源见第 1 章与第 8 章。

### 9.2 五条路线：没有全能冠军，只有匹配

| 路线 | 代表 | 最适合 | 3 年 TCO 量级（DAU 1000 万，本报告测算） | 主要风险 |
|---|---|---|---|---|
| **A. 一体化 SaaS** | Amplitude Experiment（含 Statsig）、Optimizely、Wingify | 想 1-3 个月上线、数据团队不强、预算充足 | 1500-4300 万人民币 | 数据出域、按量计费失控、供应商并购 |
| **B. Warehouse-native SaaS** | Eppo by Datadog、GrowthBook Cloud | 有数仓、指标口径复杂、要求严谨统计 | 1000-3000 万人民币 | 数据延迟、数仓成本、供应商锁定 |
| **C. 开源自建** | GrowthBook、PostHog、Unleash/Flagsmith | 有平台团队、强合规/私有化、愿意二次开发 | 1350-2000 万人民币（含 3 人团队 + 0.5 SRE） | 统计/治理缺口、升级与安全运维 |
| **D. Flag 为主 + 补统计** | Unleash/Flagsmith + 数仓统计；LaunchDarkly/Harness FME 可原生做实验 | 已有 Flag 体系、实验量不大、想渐进建设 | 900-1700 万人民币 | 纯 Flag 平台缺统计；两套系统口径不一致 |
| **E. 纯自研** | 字节/阿里/美团模式 | 超大规模、实验是核心竞争力、有稳定平台团队 | 1900-3300 万人民币（6-10 人团队） | 周期长、统计人才稀缺、组织推广难 |

**关键判断**：

1. **A 路线适合「买时间」**，不适合「买可信度」。一体化 SaaS 的统计默认值通常够用，但当你需要自定义指标、分层正交、跨业务互斥、Holdout 时，会碰到产品边界。
2. **B 路线是 2023-2026 年最重要的架构分化**。它把「指标计算」留在数仓，把「实验编排 + 统计」放在平台。对已有数仓的公司，这是**长期口径一致性最好**的路线；代价是实时性（通常 T+15min 到 T+1）和数仓工程能力。
3. **C 路线的真实成本被严重低估**。GrowthBook 能覆盖 60-70% 的标准需求，但「实验治理、超大规模分流、跨端一致性、实时指标」仍要自建；3 年人力成本通常是软件订阅费的 3-5 倍。
4. **D 路线是最被低估的务实方案**。如果公司已经有 LaunchDarkly/Split，没必要推翻重来——它们已有实验与统计模块，补「曝光落数仓 + 统一指标 + 实验治理」即可；如果只有 Unleash/Flagsmith 这类纯 Flag 平台，则还要补统计服务与实验管理 UI。缺点是两套系统的实验生命周期不统一。
5. **E 路线只适合「实验是核心产品能力」的公司**。纯自研的失败通常不是技术，而是「统计团队留不住、业务不信任、平台变成报表工具」。

### 9.3 加权 scorecard：把「感觉」变成「可辩论的数字」

以下权重针对「DAU 千万级、多业务线、已有数仓」的互联网公司。不同公司应调整权重，但**不要删掉「供应商稳定性」和「退出成本」**。

| 维度 | 权重 | 评分要点 | 常见误判 |
|---|---|---|---|
| 统计可信度 | 20% | 频率派/贝叶斯/序贯是否可选；CUPED、SRM、多重比较、比率指标、护栏是否产品化；文档是否给公式 | 只看「支持 CUPED」四个字，不看默认参数与边界 |
| 规模与性能 | 15% | 分流 QPS、p99、配置下发延迟、多区域、降级策略、SDK 覆盖 | 用 POC 的 1 万 QPS 推断生产 10 万 QPS |
| 数据架构 | 15% | 是否支持曝光落数仓、warehouse-native、实时/批处理、指标口径治理 | 忽略「平台指标」与「数仓指标」的双口径 |
| 实验治理 | 10% | 分层/互斥、Holdout、审批、RBAC、审计、生命周期、实验冻结 | 把「能建实验」当成「能治理实验」 |
| Feature Flag/发布 | 10% | Flag 生命周期、渐进发布、目标人群、自动回滚、OpenFeature | 把 Flag 平台当实验平台买 |
| 集成与生态 | 10% | 数仓、CDP、埋点、BI、OpenFeature、SDK 语言 | 忽略「换供应商时 SDK 替换成本」 |
| 总成本 | 10% | 订阅/按量/私有化/人力/数仓查询成本 | 只算 license，不算数仓扫描与人力 |
| 供应商稳定性与退出 | 5% | 所有权、融资、并购史、数据导出、escrow、迁移支持 | 假设「大厂不会停服」 |
| 中国合规/私有化 | 5% | 数据出境、等保、信创、私有化、国内网络 | 把「海外 SaaS 能用」当成「能合规」 |

**用法**：每个候选打 1-5 分，加权求和；但真正的价值不在总分，而在**分歧点**——如果业务、数据、安全三方对同一维度的打分差异超过 2 分，说明需求没对齐，先开会，不要选型。

### 9.4 决策树：从「约束」出发，而不是从「功能」出发

```mermaid
flowchart TD
    A[开始：我们要建/换实验平台] --> B{数据能否出域/上公有云?}
    B -- 否 --> C{有平台团队且愿意维护?}
    C -- 是 --> D[GrowthBook 自托管 / DataTester 私有化 / 自研]
    C -- 否 --> E[放弃自建，选国内私有化厂商或集团内平台]
    B -- 是 --> F{已有数仓且指标口径成熟?}
    F -- 否 --> G[一体化 SaaS：Amplitude Experiment / Optimizely / Wingify]
    F -- 是 --> H{月实验数 > 100 或有多业务互斥?}
    H -- 否 --> I[GrowthBook Cloud / PostHog / Eppo by Datadog]
    H -- 是 --> J{实时性要求 < 1 分钟?}
    J -- 是 --> K[自建流式分流 + 统计，或 Statsig 类实时平台]
    J -- 否 --> L[Warehouse-native + 自建治理层]
    D --> M[补：统计引擎、指标语义层、治理]
    L --> M
    K --> M
```

这张树的三个分支点，对应三个真问题：

1. **数据能不能出去**：不能出去，就别评估海外 SaaS 的统计能力，先看私有化/开源自建。
2. **有没有数仓口径**：没有，warehouse-native 是空中楼阁；先补指标平台。
3. **实验量级与治理复杂度**：月实验 <100、无跨业务互斥，SaaS/开源足够；>100 或多业务，治理层必须自建。

### 9.5 供应商 shortlist：按场景，不按排名

| 场景 | 首选 | 备选 | 不建议 |
|---|---|---|---|
| 3 个月上线、增长团队主导 | Amplitude Experiment（含 Statsig） | Optimizely、Wingify | 纯自研 |
| 有数仓、要严谨统计 | Eppo by Datadog、GrowthBook Cloud | 自建 + GrowthBook | 纯 Web 优化套件 |
| 强合规/私有化/中国网络 | GrowthBook 自托管、火山引擎 DataTester | 自研、PostHog 自托管 | 海外 SaaS |
| 已有 Flag、只想补实验 | Harness FME、LaunchDarkly（原生实验统计） | Unleash/Flagsmith + 自建统计 | 推翻 Flag 重来 |
| 超大规模、实验是核心竞争力 | 自研 + 开源组件 | 字节 DataTester 私有化 | 纯 SaaS |
| 搜索/推荐排序 | Interleaving 自研 | 专业排序实验平台 | 通用 A/B 平台 |

**谈判要点**（适用于任何 SaaS）：

- **按「曝光量/实验数」而不是「MAU」计价**，避免为不参与实验的用户付费。
- **写入「控制权变更」条款**：被收购/停服时，有权终止并按比例退款，供应商需提供 6-12 个月迁移支持。
- **数据导出必须包含**：实验配置、分流规则、曝光明细、指标定义、历史结论；不是只导出 CSV 报表。
- **POC 必须用真实业务指标**，至少跑一个 AA test、一个 SRM 注入测试、一个比率指标实验；不要只看 demo。
- **SLA 要写清**：分流服务可用性、p99 延迟、配置下发延迟、故障赔付；不要接受「99.9% 月可用」这种模糊表述。

### 9.6 中国企业的五个特殊考量

1. **数据出境**：海外 SaaS 的「warehouse-native」通常仍需要把指标/曝光元数据传到境外做统计；如果数据不能出境，优先私有化或国内云。
2. **私有化的真实成本**：不是「装一个软件」，而是「一套需要持续升级、监控、备份、安全补丁的分布式系统」；至少预留 2-3 名运维/平台工程师。
3. **国内网络与 SDK**：海外 SDK 的 CDN、DNS、证书在國內可能不稳定；分流服务不可用时的 fail-open 策略必须提前设计。
4. **等保/信创**：国企/金融客户常要求等保三级、信创适配；开源方案要评估国产数据库/中间件兼容性。
5. **组织现实**：国内很多公司的「实验平台」由数据团队主导，但流量与发布权限在工程团队；选型时必须让双方共同签字，否则上线后没人维护。

> **本章结论**：对 DAU 千万级、已有数仓的公司，最务实的路线不是「买一个全能平台」，而是 **「自建分流与治理 + 采购/复用 warehouse-native 统计 + 用 OpenFeature 解耦 SDK」**。这条路线 3 年 TCO 通常在 1000-2000 万人民币，比纯自研低 50% 以上，比纯 SaaS 更可控。

---

## 10. 参考架构与落地路线图

> 本章给出一个「不依赖某家厂商」的目标架构，以及从 0 到 1、从 1 到规模化的路线图。它假设：DAU 千万级、已有埋点与数仓、多端（Web/iOS/Android/服务端）、多个业务线、需要私有化或至少数据可控。

### 10.1 六条设计原则

1. **决策与度量解耦**  
   决策层（Flag/定向/分流 SDK）追求低延迟、高可用、可离线求值；度量层（曝光、指标、统计）追求口径一致、可回溯、可重算。两层通过**统一 exposure schema** 连接，而不是通过某个厂商的 SDK 强耦合。

2. **控制面薄、数据面厚**  
   控制面负责「实验/Flag 的定义、审批、版本、权限、审计」，可以买、可以开源二次开发；数据面负责「分流、曝光、指标、统计」，必须与业务口径深度耦合，建议自建或深度定制。

3. **配置下发「最终一致 + 快速收敛」**  
   SDK 本地缓存全量规则，启动时拉取、运行时订阅变更；配置服务不可用时 fail-open 到默认值/上次版本。**不要在下游请求链路里同步调用配置服务**。

4. **曝光是实验的第一公民**  
   没有曝光日志，就没有可信的实验。曝光事件必须包含：experiment_id、variant、unit_id、timestamp、context、assignment_source、config_version。曝光去重、采样、延迟上报都要设计。

5. **统计引擎可替换**  
   统计层通过「指标数据 + 实验配置」的标准输入对接，允许频率派/贝叶斯/序贯多引擎并存；不要把统计逻辑写死在业务代码里。

6. **实验元数据是资产**  
   实验定义、分层、互斥、Holdout、指标口径、历史结论必须可导出、可版本化、可重放。选型/自建时，**元数据模型比 UI 更重要**。

### 10.2 目标架构

```mermaid
flowchart TB
    subgraph Clients["客户端 / 服务端"]
        W[Web / H5]
        M[iOS / Android]
        S[Backend Services]
        E[Edge / BFF]
    end

    subgraph Decision["决策面（低延迟）"]
        SDK[OpenFeature SDK / 本地求值]
        CFG[配置分发服务<br/>版本 / 灰度 / 订阅]
        ASN[分流服务<br/>哈希 / 分层 / 互斥]
        FLAG[Flag 服务<br/>定向 / 放量 / kill switch]
    end

    subgraph Control["控制面（管理）"]
        EXP[实验管理<br/>假设 / 设计 / 生命周期]
        APR[审批 / RBAC / 审计]
        META[(实验元数据库<br/>Postgres/MySQL)]
        REG[指标注册表<br/>口径 / 版本 / owner]
    end

    subgraph Data["数据面（度量）"]
        COL[曝光/事件采集<br/>Kafka / Pulsar]
        WH[(数仓<br/>ClickHouse / Doris / BQ / Snowflake)]
        MET[指标计算<br/>dbt / SQL / Flink]
        STAT[统计引擎<br/>频率派 / 贝叶斯 / 序贯]
        REP[报表 / 实验结论]
    end

    subgraph Ops["治理与集成"]
        OBS[可观测性 / SLO]
        BI[BI / 看板]
        CDP[CDP / 用户属性]
        AUD[审计日志]
    end

    W --> SDK
    M --> SDK
    S --> SDK
    E --> SDK
    SDK --> CFG
    SDK --> ASN
    SDK --> FLAG
    CFG --> META
    ASN --> META
    FLAG --> META
    EXP --> META
    APR --> META
    META --> REG

    SDK -->|曝光事件| COL
    COL --> WH
    WH --> MET
    MET --> STAT
    STAT --> REP
    REG --> MET
    EXP --> STAT
    REP --> BI
    OPS --> CFG
    OPS --> ASN
    CDP --> ASN
    AUD --> META
```

**模块说明**：

| 模块 | 职责 | 关键设计 | 建议 |
|---|---|---|---|
| OpenFeature SDK | 统一求值接口，屏蔽供应商 | provider 可插拔；本地缓存；默认值 | 自建薄封装 + 采用 OpenFeature 规范 |
| 配置分发 | 规则版本、灰度、订阅 | 全量快照 + 增量推送；版本号；回滚 | 自建（Redis/etcd + SSE/长轮询） |
| 分流服务 | 哈希、分层、互斥 | 无状态、确定性、salt 隔离、单元测试 | 自建 |
| Flag 服务 | 定向、放量、kill switch | 与实验共享规则模型；审计 | 自建或复用 LaunchDarkly/Unleash |
| 实验管理 | 假设、设计、生命周期 | 状态机；模板；预注册；冻结 | 开源二次开发或自建 |
| 指标注册表 | 口径、版本、owner | 指标 DSL；血缘；口径变更审批 | 自建（与数仓指标平台统一） |
| 曝光采集 | 事件收集、去重、采样 | schema 校验；幂等；延迟容忍 | 自建（Kafka + 数仓） |
| 统计引擎 | 检验、CUPED、序贯、SRM | 输入标准化；可重算；多方法 | 复用 GrowthBook/Eppo 或自研 |
| 报表 | 实验结论、护栏、下钻 | 置信区间、effect size、segment | 开源/自建 |
| 治理 | 审批、权限、审计、冻结 | 多租户；实验冲突检测 | 自建 |

### 10.3 分阶段路线图

#### 阶段 0：0-90 天，MVP（一个业务、一个端）

**目标**：让 10-20 个实验跑起来，且结论可信。

- **范围**：服务端实验 + 一个客户端（Web 或 App）；单层分流；A/B 两变体；基础指标（转化率、人均值）；频率派 + SRM 检测。
- **必做**：
  - 统一 exposure schema 与埋点 SDK；
  - 确定性哈希分桶（MurmurHash3 + salt），单测覆盖均匀性/独立性；
  - 实验管理最小闭环：创建 → 审批 → 上线 → 曝光 → 报表 → 归档；
  - AA test 与 SRM 自动告警；
  - 护栏指标（崩溃率、延迟、收入）接入；
  - 分流服务 p99 < 20ms，可用性 99.9%，fail-open。
- **不做**：可视化编辑器、MAB、CUPED、跨业务互斥、实时指标。
- **验收**：至少 10 个实验上线；AA test 通过率 >95%；SRM 告警可在 5 分钟内定位；业务方愿意用。

#### 阶段 1：90-180 天，规模化（多业务、多端）

**目标**：支持 5+ 业务线、月实验 100+，建立治理。

- **范围**：iOS/Android/服务端多端 SDK；正交分层；互斥实验；Holdout；比率指标；CUPED；序贯检验；warehouse-native 指标；RBAC/审批/审计。
- **必做**：
  - 层/域模型：不同业务用不同 layer + salt，保证正交；
  - 互斥组：同一链路实验不能叠加，冲突检测前置；
  - Holdout：按用户长期保留 1%-5%，衡量体系整体增量；
  - 指标注册表：口径、owner、版本、血缘；
  - 实验评审：高风险实验（收入、合规、推荐）强制评审；
  - 数据质量：曝光去重、机器人过滤、延迟监控、回填。
- **验收**：月实验 100+；跨业务冲突率 <1%；指标口径争议 <5 个/月；实验结论复核通过率 >90%。

#### 阶段 2：180-365 天，智能化与规模化

**目标**：从「能跑实验」到「实验驱动决策」。

- **范围**：实时指标（分钟级）；MAB/Interleaving；CATE/异质效应；AI/LLM 实验；多区域/私有化；成本优化。
- **必做**：
  - 实时链路：Flink/ClickHouse，曝光到报表 <5 分钟；
  - 高级实验：Switchback（双边市场）、Cluster（地理）、Interleaving（搜索/推荐）、MAB（流量分配）；
  - AI 实验：prompt/模型版本因子设计、非确定性输出的样本单位、延迟/成本护栏、LLM-as-judge 的偏差校准；
  - 实验知识库：历史结论、可复用假设、失败案例；
  - 成本：数仓分区/列裁剪、曝光采样、报表预聚合。
- **验收**：实验周期缩短 30%；高价值实验占比 >30%；实验结论被产品/运营引用率 >50%；平台月活用户 >300。

### 10.4 团队与预算

| 阶段 | 编制 | 年成本量级（人民币） | 说明 |
|---|---|---|---|
| MVP | 1 PM + 3 后端 + 1 前端 + 1 数据/统计 + 1 SRE = 7 人 | 300-500 万 | 统计可先用外部顾问 |
| 规模化 | 12-15 人：平台、SDK、数据、统计、产品、SRE | 600-1000 万 | 统计团队 2-3 人 |
| 智能化 | 18-25 人 | 1000-1800 万 | 含实时链路、AI 实验、治理 |

> 这是「自建」的人力成本，不含服务器/数仓。若采用「自建分流 + 采购统计」，人力可压缩到 6-8 人，年成本 300-600 万，但需要接受供应商的统计边界。

### 10.5 平台成功指标（不要只看实验数量）

| 指标 | 定义 | 目标（12 个月） |
|---|---|---|
| 实验速度 | 从提出假设到上线的时间 | 中位数 < 5 天 |
| 实验吞吐 | 每月完成的实验数 | 100+ |
| 可信度 | AA test 通过率；SRM 率 | >95%；<2% |
| 决策影响 | 有明确「上线/回滚/迭代」决策的实验占比 | >80% |
| 护栏覆盖 | 带护栏指标的实验占比 | 100%（高风险） |
| 平台采用 | 月活实验用户 / 目标用户 | >60% |
| 性能 | 分流 p99；配置下发 p99 | <20ms；<1s |
| 成本 | 单实验数仓查询成本 | 同比下降 30% |

### 10.6 风险清单

| 风险 | 表现 | 缓解 |
|---|---|---|
| 统计不可信 | SRM 频发、结论反复 | 曝光校验、AA test、SRM 自动归因、统计评审 |
| 数据口径分裂 | 平台报表与数仓报表对不上 | 指标注册表、单一事实源、口径变更审批 |
| 组织不信任 | 业务方绕过平台自己跑 | 早期赢单案例、实验评审、培训、把平台指标纳入考核 |
| 供应商锁定 | SDK 无法替换、数据导不出 | OpenFeature、曝光落数仓、合同写入导出/退出条款 |
| 性能事故 | 分流服务超时拖垮业务 | 本地缓存、fail-open、旁路开关、压测 |
| 实验冲突 | 同一用户被多个实验影响 | 分层/互斥、冲突检测、全局实验看板 |
| 新颖效应 | 短期涨、长期跌 | Holdout、长期指标、重复实验 |
| AI 实验偏差 | LLM 输出非确定性、评估偏差 | 固定 seed/温度、人工校准、多评委、成本护栏 |
| 合规 | 数据出境/隐私 | 私有化、脱敏、同意管理、数据保留策略 |

> **本章结论**：实验平台的难点不在「建一个能开实验的网站」，而在「让实验结论可信、让组织愿意用、让成本可控」。路线图应该按「可信度 → 规模化 → 智能化」推进，而不是一上来就做可视化编辑器和 MAB。

---

## 附录

### 附录 A：引用来源汇总

全文共引用 370 个唯一链接（按出现顺序）：

1. <https://www.reuters.com/legal/transactional/openai-acquire-product-testing-startup-statsig-appoints-cto-applications-2025-09-02/>
2. <https://www.bloomberg.com/news/articles/2025-09-02/openai-to-buy-product-testing-startup-statsig-for-1-1-billion>
3. <https://support.google.com/analytics/answer/12979939?hl=en>
4. <https://monetate.com/resource/how-does-the-sunsetting-of-oracle-maxymiser-impact-cx-and-personalization/>
5. <https://www.harness.io/press-and-news/harness-completes-acquisition-of-split-software>
6. <https://www.businesswire.com/news/home/20250630514541/en/Monetate-Acquires-SiteSpect-to-Deliver-AI-Native-Personalization-and-Testing-at-Enterprise-Scale>
7. <https://wingify.com/news/vwo-and-ab-tasty-unite-as-wingify/>
8. <https://en.yna.co.kr/view/RPR20260916007800353?section=press-release/index>
9. <https://www.tmcnet.com/usubmit/2026/07/30/10422711.htm>
10. <https://www.sitecore.com/resources/insights/artificial-intelligence/cms-and-conversion-optimization>
11. <https://www.optimizely.com/company/press/episerver-completes-acquisition-of-optimizely>
12. <https://www.centrelanepartners.com/2022/10/28/kibo-spins-out-personalization-business-under-the-monetate-brand/>
13. <https://www.sitecore.com/company/newsroom/press-releases/2021/03/sitecore-acquires-boxever-and-four51>
14. <https://www.dbta.com/Editorial/News-Flashes/Oracle-Snaps-Up-Customer-Experience-Optimization-Specialist-to-Expand-Marketing-Cloud-106113.aspx>
15. <https://www.optimizely.com/company/press/optimizely-acquires-netspring>
16. <https://www.optimizely.com/de/company/press/opal-workforce>
17. <https://certification.optimizely.com/docs/guides/experimentation/configure-mutual-exclusion/>
18. <https://certification.optimizely.com/docs/concepts/experimentation/performance-edge/>
19. <https://certification.optimizely.com/docs/concepts/experimentation/stats-engine-deep-dive/>
20. <https://support.optimizely.com/hc/en-us/articles/33424529987597-CUPED-Controlled-experiment-Using-Pre-Experiment-Data>
21. <https://support.optimizely.com/hc/en-us/articles/13409080412173-Optimizely-s-automatic-sample-ratio-mismatch-detection>
22. <https://support.optimizely.com/hc/en-us/articles/42734792850061-Configure-a-Bayesian-A-B-test>
23. <https://www.optimizely.com/plans/>
24. <https://www.vendr.com/marketplace/optimizely>
25. <https://help.wingify.com/hc/en-us/articles/58766108516889-Configure-Holdout-Groups-in-Feature-Experimentation>
26. <https://wingify.com/pricing/>
27. <https://help.wingify.com/hc/en-us/articles/58831743266969-About-Wingify-Data360>
28. <https://wingify.com/blog/new-stats-engine-and-enhanced-wingify-reports/>
29. <https://help.wingify.com/hc/en-us/articles/59066074450841-What-is-the-Math-Behind-SmartStats>
30. <https://help.wingify.com/hc/en-us/articles/58838252139545-Achieve-Accurate-Campaign-Results-with-SmartStats-Configuration>
31. <https://docs.abtasty.com/web-experimentation-and-personalization/campaign-creation-and-dashboard/types-of-campaigns>
32. <https://docs.abtasty.com/account/tag-integration/understand-ab-tasty-tag-implementation-methods/choose-between-synchronous-and-asynchronous-methods>
33. <https://docs.abtasty.com/server-side/sdks/sdk-overview>
34. <https://docs.abtasty.com/reporting-and-performances/reporting/frequentist-analysis-mode>
35. <https://docs.abtasty.com/help-center/faq/faq-sequential-testing-alerts>
36. <https://docs.abtasty.com/reporting-and-performances/reporting/sample-ratio-mismatch>
37. <https://docs.kameleoon.com/developer-docs/web-experimentation/technical-concepts/flicker-management-and-performance>
38. <https://docs.kameleoon.com/user-manual/experiment-analytics/statistical-methods/choosing-the-right-statistical-method-for-ab-testing>
39. <https://docs.kameleoon.com/user-manual/experiment-analytics/analyze-results/results-page-tabs/health-menu>
40. <https://www.einpresswire.com/article_print/852526197/kameleoon-launches-vibe-experimentation-with-prompt-based-testing>
41. <https://support.convert.com/hc/en-us/articles/360015870371-server-side-testing->
42. <https://support.convert.com/hc/en-us/articles/statistical-models-in-convertcoms-ab-testing-platform>
43. <https://www.convert.com/pricing/>
44. <https://doc.sitespect.com/knowledge/sitespect-implementation>
45. <https://monetate.com/>
46. <https://doc.sitespect.com/knowledge/sitespect-and-single-page-applications>
47. <https://doc.sitespect.com/knowledge/sitespect-statistics>
48. <https://experienceleague.adobe.com/en/docs/target/using/activities/activities>
49. <https://www.miaprova.com/blog/two-customers-asked-us-the-same-question-inside-of-a-week-what-exactly-do-we-get-if-we-move-from-adobe-target-standard-to-premium/>
50. <https://experienceleague.adobe.com/en/docs/target/using/activities/auto-allocate/automated-traffic-allocation>
51. <https://experienceleague.adobe.com/en/docs/target/using/activities/auto-target/auto-target-to-optimize>
52. <https://experienceleague.adobe.com/en/docs/target/using/activities/automated-personalization/algo-random-forest>
53. <https://experienceleague.adobe.com/en/docs/target-dev/developer/server-side/on-device-decisioning/overview>
54. <https://www.miaprova.com/blog/adobe-target-had-a-quietly-big-year-at-summit/>
55. <https://business.adobe.com/products/target/pricing.html>
56. <https://kirro.io/adobe-target-ab-testing>
57. <https://experienceleague.adobe.com/zh-hant/docs/core-services/interface/data-collection/rdc?lang=zh-Hant>
58. <https://www.cnbc.com/amp/2019/03/25/mcdonalds-announces-acquisition-to-personalize-the-drive-thru.html>
59. <https://newsroom.mastercard.com/news/europe/de-de/newsroom/pressemitteilungen/de-de/2022/april/mastercard-starkt-mit-abschluss-der-ubernahme-von-dynamic-yield-seine-services-zur-kundenbindung/>
60. <https://www.mastercard.com/us/en/business/consumer-acquisition-and-engagement/personalization/dynamic-yield.html>
61. <https://support.dynamicyield.com/hc/en-us/articles/360034513414-Dynamic-Allocation>
62. <https://dy.dev/docs/choose>
63. <https://www.vendr.com/marketplace/dynamic-yield>
64. <https://monetate.com/resource/monetate-introduces-forte/>
65. <https://monetate.com/maestro/>
66. <https://docs.monetate.com/docs/implementation-overview>
67. <https://docs.monetate.com/docs/enable-auto-promotion-for-experiences>
68. <https://docs.monetate.com/docs/create-an-automated-personalization-experience>
69. <https://www.sitecore.com/platform/conversion-optimization>
70. <https://developers.sitecore.com/learn/faq/xm-personalize/personalize-cdp>
71. <https://doc.sitecore.com/personalize/en/users/sitecore-personalize/introduction-to-experiments-in-sitecore-personalize/introduction-to-experiments-in-sitecore-personalize.html>
72. <https://doc.sitecore.com/personalize/en/users/sitecore-personalize/introduction-to-decisioning-in-sitecore-personalize.html>
73. <https://doc.sitecore.com/personalize/en/users/sitecore-personalize/introduction-to-experiments-in-sitecore-personalize/running-an-experiment-with-optimized-testing/understanding-multi-armed-bandit-calculations.html>
74. <https://www.vendr.com/marketplace/sitecore>
75. <https://clonepartner.com/blog/sitecore-xp-end-of-support-2026-the-version-by-version-guide>
76. <https://www.21cloudbox.com/support/sitecore-xm-cloud-china.html>
77. <https://www.gartner.com/reviews/product/oracle-maxymiser-legacy>
78. <https://origin.peerspot.com/products/comparisons/monetate-intelligent-personalization-engine_vs_oracle-maxymiser-eol>
79. <https://developer.harness.io/docs/feature-management-experimentation/split-to-harness/migrate-from-split-to-harness/how-it-works>
80. <https://statsig.com/blog/openai-acquisition>
81. <https://docs.statsig.com/experiments/overview>
82. <https://docs.statsig.com/experiments/holdouts-introduction>
83. <https://docs.statsig.com/statsig-warehouse-native/features/statistics>
84. <https://statsig.com/blog/announcing-cure>
85. <https://docs.statsig.com/statsig-warehouse-native/native-vs-cloud>
86. <https://docs.statsig.com/experiments/monitor>
87. <https://docs.statsig.com/statsig-warehouse-native/features/experiment-options>
88. <https://amplitude.com/blog/amplitude-and-statsig-partnership>
89. <https://statsig.com/blog/statsig-amplitude-phase-1>
90. <https://statsig.com/pricing>
91. <https://docs.geteppo.com/reference/architecture-and-security/>
92. <https://docs.geteppo.com/statistics/cuped/>
93. <https://docs.geteppo.com/statistics/multiple-testing/>
94. <https://docs.geteppo.com/data-management/organizing-metrics/guardrails>
95. <https://docs.geteppo.com/statistics/global-lift/>
96. <https://docs.geteppo.com/statistics/interaction-detection/>
97. <https://www.datadoghq.com/about/latest-news/press-releases/datadog-acquires-eppo-to-expand-its-ai/>
98. <https://docs.growthbook.io/overview>
99. <https://github.com/growthbook/growthbook>
100. <https://github.com/growthbook/growthbook/blob/main/LICENSE>
101. <https://docs.growthbook.io/statistics/overview>
102. <https://docs.growthbook.io/statistics/sequential>
103. <https://docs.growthbook.io/statistics/cuped>
104. <https://www.growthbook.io/pricing>
105. <https://www.growthbook.io/blog/how-to-migrate-from-statsig-to-growthbook>
106. <https://amplitude.com/docs/data/warehouse-native/overview>
107. <https://amplitude.com/docs/faq/sequential-testing>
108. <https://amplitude.com/docs/feature-experiment/experiment-theory/bayesian-statistics>
109. <https://amplitude.com/docs/feature-experiment/troubleshooting/sample-ratio-mismatch>
110. <https://amplitude.com/docs/feature-experiment/implementation>
111. <https://amplitude.com/docs/feature-experiment/local-evaluation>
112. <https://amplitude.com/pricing>
113. <https://leaderpost.com/press-releases/globe-newswire/launchdarkly-surpasses-200-million-in-arr-as-demand-for-runtime-control-accelerates/>
114. <https://launchdarkly.com/docs/guides/statistical-methodology/choosing>
115. <https://launchdarkly.com/docs/guides/statistical-methodology/cuped>
116. <https://launchdarkly.com/blog/warehouse-native-experimentation-comes-to-bigquery-databricks-and-redshift/>
117. <https://launchdarkly.com/how-it-works/platform-architecture/>
118. <https://launchdarkly.com/blog/what-happened-what-we-learned-and-how-were-improving/>
119. <https://launchdarkly.com/pricing/>
120. <https://developer.harness.io/feature-management-experimentation/use-fme/experimentation/key-concepts/fixed-horizon>
121. <https://developer.harness.io/docs/feature-management-experimentation/sdks-and-infrastructure/>
122. <https://github.com/Flagsmith/flagsmith>
123. <https://docs.flagsmith.com/experimentation>
124. <https://www.flagsmith.com/pricing>
125. <https://configcat.com/docs/advanced/variation-id-for-analytics>
126. <https://configcat.com/pricing/>
127. <https://www.getunleash.io/blog/unleash-moving-to-agplv3>
128. <https://www.getunleash.io/blog/series-b>
129. <https://support.google.com/analytics/answer/12979939>
130. <https://firebase.google.com/docs/ab-testing/ab-concepts>
131. <https://aws.amazon.com/blogs/mt/support-for-amazon-cloudwatch-evidently-ending-soon/>
132. <https://aws.amazon.com/blogs/devops/running-production-experiments-with-aws-appconfig-experimentation/>
133. <https://blog.cloudflare.com/flagship/>
134. <https://www.volcengine.com/product/DataTester>
135. <https://www.365trade.com.cn/jfwzb/775230.jhtml>
136. <https://www.alibabacloud.com/help/zh/pai/a-b-experiment/>
137. <http://www.gdebidding.com/nhpbgs/199863.jhtml>
138. <https://www.cac.gov.cn/2024-03/22/c_1712776611775634.htm>
139. <https://learn.microsoft.com/en-us/azure/azure-app-configuration/concept-feature-management>
140. <https://openfeature.dev/>
141. <https://aicon.infoq.cn/2025/shanghai/speaker/9508>
142. <https://docs.byteplus.com/en/docs/DataTester/Learn-about-A-B-Testing-Products-DataTester>
143. <https://docs.byteplus.com/en/docs/DataTester/Traffic-Shunt-Agent>
144. <https://docs.byteplus.com/en/docs/DataTester/Basic-Concept>
145. <https://www.doit.com.cn/p/475545.html>
146. <https://docs.byteplus.com/en/docs/DataTester/Traffic-Layer-and-Mutual-Exclusion-Domain>
147. <https://docs.byteplus.com/en/docs/DataTester/How-to-Interpret-the-Experiment-Report>
148. <https://docs.byteplus.com/en/docs/DataTester/Enhanced-Shunt-Uniformity>
149. <https://docs.byteplus.com/en/docs/DataTester/MAB-Multi-Armed-Bandit-Intelligent-Tuning-Experiment>
150. <https://server.it168.com/a2024/1023/6866/000006866793.shtml>
151. <https://arxiv.org/abs/2305.02542>
152. <https://developer.aliyun.com/article/1672360>
153. <https://zhuanlan.zhihu.com/p/390417035>
154. <https://zhuanlan.zhihu.com/p/394253252>
155. <https://arxiv.org/abs/2201.00689>
156. <https://help.aliyun.com/zh/open-search/industry-algorithm-edition/a-or-b-tests>
157. <https://help.aliyun.com/en/ahas/product-overview/delisting-announcement-of-function-switch-function-module>
158. <https://cloud.tencent.com.cn/developer/article/2156664>
159. <https://cloud.tencent.com.cn/developer/article/2346725>
160. <https://arxiv.org/abs/2405.08411>
161. <https://patents.google.com/patent/CN110830234B/zh>
162. <https://docs.abetterchoice.ai/guide/experiments/stats-engine-and-validation>
163. <https://arxiv.org/abs/2408.04441>
164. <https://doi.org/10.1145/3711896.3736906>
165. <https://tech.meituan.com/2024/09/09/New-Generation-Analysis-Engine-Driving-Data-Decisions.html>
166. <https://zhuanlan.zhihu.com/p/147203168>
167. <https://arxiv.org/abs/2202.10887>
168. <https://ziyuan.baidu.com/wiki/2727>
169. <https://cloud.baidu.com/doc/AI_REC/s/Flw4scq90>
170. <https://www.selectdb.com/blog/1719>
171. <https://arxiv.org/abs/2608.04625>
172. <https://zhuanlan.zhihu.com/p/715370120>
173. <https://github.com/bilibili/abtest>
174. <https://www.bilibili.com/read/cv21106590/>
175. <https://zhuanlan.zhihu.com/p/10465095421>
176. <https://testerhome.com/column_channels/38235>
177. <https://zhuanlan.zhihu.com/p/587995471>
178. <https://zhuanlan.zhihu.com/p/641222646>
179. <https://zhuanlan.zhihu.com/p/25685006>
180. <https://cloud.tencent.cn/developer/article/2536676>
181. <https://www.sohu.com/a/848315597_121665362>
182. <https://www.infoq.cn/article/T7HCVlTeUCSroDRhT1FF>
183. <https://news.e-works.net.cn/category802/news115463.htm>
184. <https://docs.byteplus.com/en/docs/DataTester/Server-Side-SDK-Overall-Description>
185. <https://www.infoq.cn/article/alimama-large-scale-online-hierarchical-experiment>
186. <https://www.infoq.cn/article/tmall-app-ab-test/>
187. <https://tech.meituan.com/2025/08/22/meituan-AB-Online-Controlled-Experiment-08.html>
188. <https://tech.meituan.com/2019/11/28/advertising-performance-experiment-configuration-platform.html>
189. <https://s3plus.meituan.net/ddfile/2025%E5%8F%AF%E4%BF%A1%E5%AE%9E%E9%AA%8C%E7%99%BD%E7%9A%AE%E4%B9%A62025.8.20.pdf>
190. <https://arxiv.org/abs/2602.08569>
191. <https://blog.itpub.net/70048664/viewspace-3184138/>
192. <https://eureka.patsnap.com/patent/CN115391184B>
193. <http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html>
194. <https://www.gov.cn/zhengce/zhengceku/2022-01/04/content_5666429.htm>
195. <https://www.growthbook.io/about>
196. <https://docs.growthbook.io/warehouses>
197. <https://docs.growthbook.io/self-host>
198. <https://docs.growthbook.io/self-host/production>
199. <https://docs.growthbook.io/faq>
200. <https://docs.growthbook.io/lib/build-your-own>
201. <https://docs.growthbook.io/statistics/details>
202. <https://docs.growthbook.io/app/experiment-results>
203. <https://docs.growthbook.io/statistics/multiple-corrections>
204. <https://docs.growthbook.io/self-host/env>
205. <https://posthog.com/pricing>
206. <https://posthog.com/docs/experiments/creating-an-experiment>
207. <https://posthog.com/docs/how-posthog-works>
208. <https://posthog.com/docs/how-posthog-works/clickhouse>
209. <https://github.com/PostHog/post-mortems/blob/main/2025-09-29-flags-is-down.md>
210. <https://posthog.com/docs/experiments/statistics-bayesian>
211. <https://posthog.com/docs/experiments/statistics-frequentist>
212. <https://posthog.com/docs/experiments/cuped>
213. <https://posthog.com/docs/experiments/exposures>
214. <https://posthog.com/docs/feature-flags/cutting-costs>
215. <https://posthog.com/docs/self-host>
216. <https://github.com/Unleash/unleash/releases/tag/v8.0.0>
217. <https://docs.getunleash.io/get-started/unleash-overview>
218. <https://docs.getunleash.io/concepts/activation-strategies>
219. <https://docs.getunleash.io/guides/a-b-testing>
220. <https://docs.flagsmith.com/experimentation/analyse-an-experiment>
221. <https://docs.flagsmith.com/experimentation/statistics>
222. <https://docs.flagsmith.com/performance/edge-proxy>
223. <https://docs.flipt.io/v2/concepts>
224. <https://docs.flipt.io/v2/configuration/analytics>
225. <https://docs.flipt.io/v2/licensing>
226. <https://github.com/openflagr/flagr>
227. <https://openflagr.github.io/flagr/flagr_overview>
228. <https://openflagr.github.io/flagr/flagr_exposure>
229. <https://openflagr.github.io/flagr/flagr_eval_exposure_pipeline>
230. <https://openfeature.dev/specification/>
231. <https://flagd.dev/>
232. <https://openfeature.dev/specification/sections/tracking>
233. <https://www.kdd.org/kdd2019/accepted-papers/view/diagnosing-sample-ratio-mismatch-in-online-controlled-experiments-a-taxonom>
234. <https://github.com/FeatureProbe/FeatureProbe/blob/main/README_CN.md>
235. <https://featureprobe.github.io/FeatureProbe/zh-CN/reference/structure/>
236. <https://featureprobe.github.io/FeatureProbe/zh-CN/reference/evaluation-rules/>
237. <https://featureprobe.github.io/FeatureProbe/zh-CN/reference/metric-explanation/>
238. <https://featureprobe.github.io/FeatureProbe/blog/FeatureProbe%20bayesian/>
239. <https://docs.abrouter.com/docs/managing/makingdecisions/>
240. <https://superposition.juspay.io/docs/basic-concepts/context-aware-config/how-all-this-works/>
241. <https://superposition.juspay.io/docs/basic-concepts/experimentation/experiment-groups/>
242. <https://www.getunleash.io/pricing>
243. <https://www.exp-platform.com/Documents/2013-02-CUPED-ImprovingSensitivityOfControlledExperiments.pdf>
244. <https://arxiv.org/abs/2004.12489>
245. <https://engineering.atspotify.com/2026/1/why-we-use-separate-tech-stacks-for-personalization-and-experimentation>
246. <https://doi.org/10.1145/1835804.1835810>
247. <https://www.itl.nist.gov/div898/handbook/pri/section3/pri333.htm>
248. <https://arxiv.org/abs/2311.14698>
249. <https://arxiv.org/abs/1501.00450>
250. <https://docs.statsig.com/experiments/layers-overview>
251. <https://docs.growthbook.io/app/holdouts>
252. <https://docs.geteppo.com/experiment-analysis/holdouts/>
253. <https://arxiv.org/abs/1903.08755>
254. <https://arxiv.org/abs/2009.00148>
255. <https://docs.geteppo.com/experiment-analysis/switchbacks/>
256. <https://arxiv.org/abs/2508.00751>
257. <https://arxiv.org/abs/2303.10094>
258. <https://docs.geteppo.com/sdks/architecture/overview/>
259. <https://raw.githubusercontent.com/optimizely/go-sdk/refs/tags/v0.1.0/optimizely/decision/experiment_bucketer_service.go>
260. <https://docs.statsig.com/sdks/how-evaluation-works>
261. <https://launchdarkly.github.io/ruby-server-sdk/LaunchDarkly/Impl/EvaluatorBucketing.html>
262. <https://docs.geteppo.com/sdks/event-logging/assignment-logging/>
263. <https://docs.geteppo.com/statistics/confidence-intervals/statistical-nitty-gritty/>
264. <https://docs.growthbook.io/statistics/quantile>
265. <https://docs.statsig.com/experiments/statistical-methods/methodologies/cuped>
266. <https://www.evanmiller.org/how-not-to-run-an-ab-test.html>
267. <https://www.optimizely.com/field-notes/articles/statistics-for-the-internet-age-the-story-behind-optimizelys-new-stats-engine>
268. <https://docs.geteppo.com/statistics/confidence-intervals/analysis-methods/>
269. <https://docs.geteppo.com/statistics/sample-ratio-mismatch/>
270. <https://docs-legacy.statsig.com/experiments-plus/monitor/>
271. <https://www.microsoft.com/en-us/research/publication/diagnosing-sample-ratio-mismatch-in-online-controlled-experiments-a-taxonomy-and-rules-of-thumb-for-practitioners/>
272. <https://docs.growthbook.io/experimentation-analysis/cluster-experiments>
273. <https://www.cambridge.org/core/books/abs/trustworthy-online-controlled-experiments/metrics-for-experimentation-and-the-overall-evaluation-criterion/0A8BF7F06A1338FF6D10C49F4CD8A198>
274. <https://docs.geteppo.com/data-management/definitions/overview/>
275. <https://docs.geteppo.com/data-management/metrics/>
276. <https://docs.growthbook.io/app/metrics>
277. <https://eu.36kr.com/zh/p/3730988847890694>
278. <https://docs.geteppo.com/data-management/certified-metrics/>
279. <https://docs.geteppo.com/data-management/data-pipeline/>
280. <https://docs.geteppo.com/experiment-analysis/configuration/filter-assignments-by-entry-point/>
281. <https://docs.geteppo.com/data-management/definitions/assignment-sql/>
282. <https://blog.csdn.net/m0_60025795/article/details/129880151>
283. <https://www.modb.pro/db/604087>
284. <https://docs.geteppo.com/guides/advanced-experimentation/anonymous-explainer/>
285. <https://docs.kameleoon.com/user-manual/experiment-analytics/analyze-results/data-and-metrics/how-kameleoon-counts-conversions#attribution-window>
286. <https://www.lukasvermeer.nl/srm/docs/faq/>
287. <https://www.lukasvermeer.nl/srm/docs/causes/>
288. <https://druid.apache.org/docs/latest/design/>
289. <https://docs.snowflake.com/en/release-notes/2025/other/2025-09-23-snowpipe-streaming-high-performance-architecture>
290. <https://cloud.google.com/bigquery/docs/write-api-streaming>
291. <https://docs.geteppo.com/data-management/warehouse-best-practices/>
292. <https://docs-legacy.statsig.com/statsig-warehouse-native/guides/costs>
293. <https://arxiv.org/abs/1910.03878>
294. <https://research.google/pubs/overlapping-experiment-infrastructure-more-better-faster-experimentation/>
295. <https://launchdarkly.com/docs/sdk/relay-proxy>
296. <https://docs.getunleash.io/unleash-edge>
297. <https://docs.growthbook.io/self-host/proxy>
298. <https://launchdarkly.com/blog/designing-for-failure-to-avoid-disaster/>
299. <https://openfeature.dev/specification/sections/flag-evaluation>
300. <https://pkg.go.dev/github.com/launchdarkly/go-server-sdk/v7@v7.13.3/ldcomponents>
301. <https://developer.harness.io/docs/feature-management-experimentation/sdks-and-infrastructure/optional-infra/split-daemon-splitd/>
302. <https://docs.getunleash.io/get-started/unleash-overview.md>
303. <https://openfeature.dev/specification/sections/hooks>
304. <https://openfeature.dev/specification/appendix-c/>
305. <https://firebase.google.com/docs/remote-config/use-cases/minimum-version>
306. <https://docs.geteppo.com/feature-flagging/concepts/targeting/>
307. <https://firebase.google.com/docs/ab-testing/ab-concepts?hl=en>
308. <https://developer.apple.com/documentation/storekit/skadnetwork>
309. <https://developers.cloudflare.com/flagship/reference/limits/>
310. <https://docs.getunleash.io/deploy/hosting-options.md>
311. <https://docs.getunleash.io/concepts/rbac.md>
312. <https://docs.getunleash.io/concepts/change-requests.md>
313. <https://launchdarkly.com/docs/home/releases/approvals>
314. <https://docs.getunleash.io/concepts/events.md>
315. <https://launchdarkly.com/docs/home/releases/version-restore>
316. <https://martinfowler.com/articles/feature-toggles.html>
317. <https://docs.getunleash.io/concepts/technical-debt.md>
318. <https://news.bjd.com.cn/2023/08/29/10546096.shtml>
319. <https://sre.google/workbook/implementing-slos/>
320. <https://principlesofchaos.org/>
321. <https://docs.aws.amazon.com/fis/latest/userguide/what-is.html>
322. <https://tech.meituan.com/2025/05/22/meituan-AB-Online-Controlled-Experiment-01.html>
323. <https://confidence.spotify.com/glossary/experimentation-maturity-model>
324. <https://atticusli.com/blog/posts/how-netflix-runs-experimentation/>
325. <https://research.chalmers.se/publication/507720>
326. <https://atticusli.com/blog/posts/how-booking-com-runs-experimentation/>
327. <https://research.google.com/pubs/archive/36500.pdf>
328. <https://engineering.atspotify.com/2020/10/29/spotifys-new-experimentation-platform-part-1/>
329. <https://confidence.spotify.com/docs/capabilities/experiments/reviews.md>
330. <https://www.geteppo.com/blog/make-decisions-before-experimenting>
331. <https://docs.geteppo.com/experiment-analysis/configuration/protocols/>
332. <https://docs.growthbook.io/kb/experiments/aa-tests>
333. <https://docs.statsig.com/experiments/monitor.md>
334. <https://docs.geteppo.com/data-management/organizing-metrics/guardrails/>
335. <https://docs-legacy.statsig.com/safeguards/overview/>
336. <https://gdpr-info.eu/art-5-gdpr/>
337. <https://oag.ca.gov/privacy/ccpa>
338. <https://www.gov.cn/lianbo/bumen/202502/content_7003767.htm>
339. <https://www.gov.cn/zhengce/2022-01/04/content_5728941.htm>
340. <https://arxiv.org/abs/2407.10457>
341. <https://arxiv.org/abs/2306.05685>
342. <https://arxiv.org/abs/2606.17165>
343. <https://netflixtechblog.com/sequential-a-b-testing-keeps-the-world-streaming-netflix-part-1-continuous-data-cba6c7ed49df>
344. <https://medium.com/airbnb-engineering/https-medium-com-jonathan-parks-scaling-erf-23fd17c91166>
345. <https://partner.booking.com/en-gb/click-magazine/industry-perspectives/role-experimentation-bookingcom>
346. <https://www.microsoft.com/en-us/research/publication/the-anatomy-of-a-large-scale-experimentation-platform/>
347. <https://dl.acm.org/doi/abs/10.1145/3292500.3330722>
348. <https://experimentguide.com/>
349. <https://research.google/pubs/pub36500/>
350. <https://speakerdeck.com/srihari/overlapping-experim>
351. <https://ar5iv.labs.arxiv.org/html/1409.3174>
352. <https://www.sigops.org/s/conferences/sosp/2015/current/2015-Monterey/008-tang-online.pdf>
353. <https://www.linkedin.com/blog/engineering/ab-testing-experimentation/making-the-linkedin-experimentation-engine-20x-faster>
354. <https://dl.acm.org/doi/10.1145/2783258.2788602>
355. <https://www.uber.com/blog/xp/>
356. <https://engineering.atspotify.com/2025/9/spotifys-experiments-with-learning-framework>
357. <https://engineering.atspotify.com/2026/9/why-spotify-is-not-using-bayesian-a-b-testing>
358. <https://www.etsy.com/codeascraft/imbalance-detection-for-healthier-experimentation>
359. <https://opendatascience.com/experimentation-platform-at-doordash/>
360. <https://tech.instacart.com/variance-reduction-below-the-randomization-grain-31719f87a7d2>
361. <https://tech.instacart.com/geo-based-a-b-testing-and-difference-in-difference-analysis-in-instacart-catalog-2ba05e744a3f>
362. <https://www.amazon.science/publications/science-of-price-experimentation-at-amazon>
363. <https://sellercentral.amazon.com/help/hub/reference/external/GYZYA77YZTWTF7YZ>
364. <https://ar5iv.labs.arxiv.org/html/2405.08411>
365. <https://blog.csdn.net/didi_tech/article/details/106424045>
366. <https://www.cambridge.org/core/books/trustworthy-online-controlled-experiments/D97B26382EB0EB2DC2019A7A7B518F59>
367. <https://dl.acm.org/doi/10.1145/2433396.2433413>
368. <https://ar5iv.labs.arxiv.org/html/1512.04922>
369. <https://www.optimizely.com/contentassets/9205a8a811e84957a7cca527d4af20be/whitepaper_optimizely_stats_engine.pdf/download>
370. <https://www.datadoghq.com/blog/datadog-acquires-eppo/>

### 附录 B：术语表

- **A/B/n**：同时比较两个及以上变体的对照实验。
- **CUPED**：Controlled-experiment Using Pre-Experiment Data，用实验前数据做协变量以降低方差、提升灵敏度。
- **SRM**：Sample Ratio Mismatch，实际分流比例与设计比例显著不符，通常意味着实验实现或数据链路有 bug。
- **OEC**：Overall Evaluation Criterion，用于权衡短期与长期、收益与代价的总体评估指标。
- **MDE**：Minimum Detectable Effect，给定功效与样本量下能检测到的最小效应。
- **Sequential Testing**：允许在实验过程中多次查看并提前停止的统计方法，控制整体假阳性率。
- **Delta Method**：用泰勒展开近似非线性指标（如比率、人均值）方差的方法。
- **Holdout**：保留一部分用户长期不进入任何实验，用于衡量实验体系整体增量。
- **Orthogonal Layers**：用不同 salt/层让多个实验在同一批用户上正交分流，互不干扰。
- **Switchback**：按时间片交替切换实验组/对照组，适用于双边市场与强干扰场景。
- **Interleaving**：把多个候选结果交错混排，用偏好比较替代绝对指标，适合搜索/推荐排序。
- **MAB**：Multi-Armed Bandit，在探索与利用之间动态分配流量。
- **Warehouse-Native**：实验平台不存储明细数据，指标计算下推到客户数仓。
- **OpenFeature**：CNCF 的 Feature Flag 开放标准，用于解耦 SDK 与供应商。
- **Guardrail Metrics**：护栏指标，用于确保实验不损害体验、性能、收入等底线。
- **Novelty Effect**：新功能初期带来的短期新鲜感效应，可能导致实验高估长期收益。

### 附录 C：研究方法与分工

- **L0 基线**：市场大事记、40 家厂商清单、14 个开源项目 GitHub 活跃度。
- **深度研究（25 路并发）**：A1-A6 商业平台；B1-B5 中国平台；C1-C5 开源；D1-D6 技术模块；E1-E3 案例与学术；F1-F2 交叉验证与缺口补全。
- **分册合成（7 路）**：S-A1、S-A2、S-B、S-C、S-D1、S-D2、S-E。
- **终稿**：执行摘要、市场地图、选型矩阵、参考架构与路线图。

> 本报告由多个研究 agent 并行产出后人工/主控合成。所有价格、融资、收购信息以文中标注日期为准；采购前请以供应商最新报价与合同为准。