03 商业平台（下）

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 的一体化平台来源。它最值得抄的不是功能数量，而是同一个 gate 可以先 1% 放量，再直接转为实验，曝光口径不变。Flag 与实验共用同一套分流与曝光日志，比“Flag 厂商 + 实验厂商”拼装方案少了一次对账。Flag 侧有 Gates、Dynamic Config、Segments、Release Pipelines；实验侧覆盖 A/B/n、Layers、Holdouts、MAB、Switchback 来源。很多公司的实验流量要从发布系统里“借”，借一次就要重新埋点；Statsig 把这件事产品化了。

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

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

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

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

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

公开价：Developer 免费 2M events/月、50k replays；Pro $150/月含 5M events、100k replays，超额 $0.05/1K events；Enterprise 询价来源。计费口径是 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 做展示来源。很多厂商都说自己“warehouse-native”，差别在谁定义 assignment。Eppo 把 assignment 做成一等公民：客户要在 SQL 里定义“谁在什么时间被分到哪个变体”，Eppo 才能把曝光、指标、实验配置 join 起来。这不是 UI 功能，而是语义契约。

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

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

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

Eppo 2024-08-20 完成 2,800 万美元 B 轮；2025-05-05 被 Datadog 收购，品牌变为“Eppo by Datadog”，官方称继续服务存量与新增客户来源。第三方传对价约 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 环境来源。官方称 3,000+ 家公司使用，GitHub 上 8,506 stars、884 forks、154 contributors、最近提交 2026-10-16 来源。它的差异化是可拥有、可审计、便宜：核心开源，企业功能另授权；云版按席位计价，BYO warehouse 时实验与 Flag 流量不限量。但“开源”不等于“免费”：enterprise/ 目录走 GrowthBook Enterprise License，Holdouts、Contextual Bandits、post-stratification、审批、SCIM 都在企业版来源。这条边界必须写清楚，否则 POC 时“什么都有”，上线后“什么都要加钱”。

统计上，官方明确“默认贝叶斯”，理由是大多数客户觉得概率陈述更直观；频率派引擎做两样本 t 检验，可叠加 CUPED 与序贯来源。贝叶斯默认用无信息先验，可开启 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 的代价来源。把 GrowthBook 的序贯说成 mSPRT 是常见的事实错误。

CUPEDps 是 CUPED + post-stratification：CUPED 用实验前 14 天（默认，可调）的同指标数据做回归调整；post-stratification 用预计算维度（如国家）做分层，企业版功能；官方称在合适条件下等价于多拿 20%+ 流量来源。多重比较提供 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 开源免费、企业版另授权来源。官网另设 CDN Requests 1M/月（Pro 2M，超出 $10/M）、Bandwidth 5GB/月（Pro 20GB，超出 $1/GB）——“BYO warehouse 不限量”不等于分发成本为零。

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

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

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

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

Amplitude 的默认是序贯检验，官方 FAQ 明确实现是 mSPRT，允许随时看结果而不膨胀假阳性；固定 horizon 的 t 检验在 peeking 下会把 5% 的 α 膨胀到 30–50% 来源。这个数字是它默认序贯的最好理由。

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

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

定价（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 来源。实验能力按 active experiment 数量分层，高级类型是 add-on——实验密度高的团队，账单远高于“2M events 免费”的直觉。

2026-05-05 起，Amplitude 同时运营 Experiment 与 Statsig，定位为“AI 产品开发的 validation stack”：Amplitude 做行为分析，Statsig 做实验与发布验证来源。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 来源。实验统计是五家里最完整的：Bayesian、Frequentist fixed-horizon、Frequentist sequential 三种模式，默认频率派；CUPED 按 Deng et al. (2013) 的 ANCOVA/CUPED 处理，不兼容百分位；多重比较有 Bonferroni 与 BH；SRM 内置；还有 stratified sampling 来源来源。官方还明确警告：贝叶斯不控制假阳性率，大量 A/A 测试也可能出现高“胜率”。这句话值得所有把“Chance to Win”当决策依据的团队贴在墙上。

仓原生是它 2025–2026 的关键补强：2025 年支持 Snowflake，2026-06-25 扩到 BigQuery、Databricks、Redshift；Data Export 把曝光同步进仓，指标在仓内计算，只把聚合、去标识结果回传展示来源。注意：原始数据不出仓，不等于分析完全在仓内完成——统计与报告仍由 LaunchDarkly 侧完成。

架构数字很漂亮：SSE 流式下发、100+ POP、初始化 25ms、变更 200ms 内到达，SDK 内存缓存、断网可求值；配置下发延迟 SLO 为 Developer <300ms、Foundation <200ms、Enterprise <150ms 来源。但 2025-10-20 的 AWS us-east-1 故障说明“流式 + 多区域”不是银弹：内部降载变更切到冷缓存旧路由，SDK 重试风暴，服务端 streaming 全球约 99% 连接错误，事件摄取还发生了数据丢失来源。配置可以靠本地缓存继续服务，但实验数据丢了就是丢了；合同要写清 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、自动回滚）单独定价来源。对 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 来源。有资料写“2024-07”，与官方交割日不符，存在不同说法，以官方新闻稿为准。截至 2026-10，官网出现“Runtime Configuration”品牌层，但文档仍用 FME，是否正式改名待核实。统计是纯频率派：固定 horizon 用 Welch's t-test，序贯用 mSPRT，官方明确不提供贝叶斯；默认每组至少 355 个独立观测才开始算显著性（固定 horizon 最低 10、序贯最低 100），内置 review period 与 SRM 来源。MCC 有独立文档；护栏自动测量；CUPED 在公开统计文档中未检索到，写“不支持”不严谨，写“公开文档未提供，需书面确认”更准确。架构上每天服务 500 亿次 flag evaluation，双层 CDN 全球 <200ms 下发来源。互斥实验靠父子 flag 拼装，官方明确代价是“每个实验分到的流量变少、跑得更久”。商业风险：并进 DevOps 后 roadmap 受 CI/CD 影响；品牌更名频繁；Harness 还保留一套更老的 Feature Flags 产品，同一厂商两套 flag 并存，买前必须确认买的是哪套；FME 定价需询价。

Flagsmith 的核心卖点是“真开源”：核心 flag、远程配置、targeting rules 用 BSD-3-Clause，可自托管、fork、商用；GitHub 约 6,597 stars 来源。实验能力截至 2026-10 仍是 Beta：多变量 flag 分流，SDK 采集 exposure 与 conversion，事件进托管仓或客户 ClickHouse/Databricks；结果页给 lift、95% credible interval、win probability 来源。细节说明成熟度：结果最多每 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 来源。两份记录各取一栏，存在不同说法但可解释。

ConfigCat 只做 feature flag + remote config，不碰实验统计。它给每个被服务过的值生成 Variation ID，让客户端随事件发给 Amplitude、GA、Mixpanel、Segment，由外部工具分析来源。这是“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 不限来源。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 轮来源来源。它的 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。

图 1 · Flag、实验与曝光的数据流

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

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

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

停服后，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、多重比较来源。它是“移动端够用版”，不是 Optimize 替代品。

AWS 官方博客 2024-10-17 宣布 CloudWatch Evidently 将于 2025-10-17 停止支持，期间只提供关键安全补丁、不再接受 limit increase，建议迁 AppConfig 来源。有第三方 GitHub issue 写“2025-10-16 停服”，与官方差一天，存在不同说法，以官方为准。Evidently 停服时，AppConfig 只有 flag/segment，编排和推断都要自己做；2026-06，AWS What's New 上线 AppConfig experimentation，2026-09-30 官方博客给出完整架构来源。它做“实验编排 + 分流 + 曝光日志”：控制面定义 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、分层、互斥来源。它们负责“让用户看到哪个版本”，不负责“判断哪个版本更好”。

中国云厂商的实验能力，基本是“内部平台外溢”或“场景化能力”，不是横向 SaaS。火山引擎 DataTester 是字节内部 Libra 的对外产品，2012 年引入 A/B、2016 年产品化、2021 年对外开放；中原银行项目中标 96 万元/27 个月，神策报价 85 万，另一家 139 万来源来源。阿里云 PAI A/B 只面向 LLM/搜索推广的模型服务，功能免费、算力另计，限四地域来源。腾讯云公开目录未见独立通用 A/B SKU（待核实）。京东科技 ABTest 3.0 服务南航数科，中标 256 万元（含税） 来源。这些报价说明：国内私有化的真实价格带是“百万级”；对 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 施行）把出境分成安全评估、标准合同/认证、豁免三档来源；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。

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

商业平台（下）：现代平台、Flag 与采购