研究设计与市场地图
从七类玩家、2023-2026 大事记到市场规模，先建立一张可用的市场地图；再决定用什么框架做选型。
1.1 我们到底在回答什么问题#
这不是一份「A/B 测试工具排行榜」。排行榜只能回答「谁的功能多」，却回答不了三个更关键的问题：
- 买什么：当公司已经有埋点、数仓、Feature Flag 和发布系统时，实验平台应该买哪一层，还是自己补哪一层？
- 怎么建：如果自建，哪些模块是真正的难点，哪些只是工作量？为什么很多团队「三个月上线，三年不敢用」？
- 怎么用：为什么同样一套平台，字节、Airbnb、Booking.com 能跑出每年数万个实验，而多数公司一年只跑几十个、且一半结论不可信？
因此，本报告把「竞品调研」拆成五层：市场与产品 → 中国实践 → 开源方案 → 核心技术模块 → 组织与案例，最后回到「自建 / 采购 / 开源自建」的决策。
1.2 研究方法：25 路并发 + 三层校验#
本次调研采用「分治 + 交叉验证」的方式：
| 层级 | 工作 | 产出 |
|---|---|---|
| L0 基线 | 市场大事记、厂商清单、开源活跃度 | 统一事实底座 |
| 深度研究 | 25 个并发研究任务：商业平台、中国大厂、开源、技术模块、案例 | 25 份原始调研 |
| 交叉验证 | 对高风险论断逐条核验；补齐覆盖缺口 | 事实修正与增补 |
| 分册合成 | 7 位分册主编重新组织、交叉对比 | 7 个主题分册 |
| 终稿 | 执行摘要、选型矩阵、参考架构、路线图 | 本报告 |
信息可信度分为三级：
- A 级：官方文档、官方博客、GitHub 源码/Release、同行评审论文、上市公司公告。
- B 级：厂商工程博客、QCon/ArchSummit 演讲、权威媒体（Reuters、Bloomberg 等）、可复现的第三方评测。
- C 级：招聘 JD、二手转述、社区讨论、无法追溯的「据说」。
报告中凡涉及「某平台支持 CUPED」「某公司实验数量」这类关键能力，优先使用 A 级来源；只有 C 级来源的，会明确标注「待核实」。
研究局限（必须先说清楚）：
- 实验平台的核心架构通常是商业机密。厂商公开的是「能力清单」，不是「实现细节」；中国大厂的公开资料尤其滞后，很多平台名称、上线时间来自演讲或招聘信息，无法逐一核实。
- 价格极不透明。多数企业级产品「需询价」，公开起价往往只覆盖最小套餐，不能外推到大客户实际成交价。
- 统计能力很难从外部验证。厂商都说自己「支持 CUPED / 序贯 / 贝叶斯」，但实现质量、默认参数、边界处理差异很大；本报告只能核实「官方是否宣称 + 文档是否给出方法说明」，不能替代真实数据上的复现。
- 市场在快速整合。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、Bloomberg）；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 章。
本章结论：市场不缺工具，缺的是「可信的实验基础设施」。选型的第一性问题不是「谁功能多」，而是「我的数据在哪、我的决策链路是什么、我愿意为可信度付多少钱」。