综合对比与选型建议

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

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

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

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

关键判断：

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 千万级、多业务线、已有数仓」的互联网公司。不同公司应调整权重，但不要删掉「供应商稳定性」和「退出成本」。

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

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

点击放大

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

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

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

谈判要点（适用于任何 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 更可控。