experimentation-platform-orchestrator

实验平台决策协调器

一份面向资深产品和工程领导者的实战指南，帮助他们做出实验平台决策，并在决策失误时采取补救措施。

选择实验平台，一开始看似简单，之后却会在数年间持续产生影响。选错平台会让你付出代价：实验数量减少（因为团队会回避难用的工作流）、成本增加（因为不合适的定价模式与你的使用情况不匹配）、被供应商锁定（因为迁移是实实在在的工程工作，而不是更改配置），以及文化偏移（因为平台的默认设置会影响团队对实验的认知）。

这项技能能帮助你首次就做出正确决策，并在决策失误时制定迁移计划。

使用此技能的时机：从零开始选择平台、评估是否切换平台、决定是否从多平台整合到单一平台，或规划已获批准的迁移。

---

此技能的用途

此技能涵盖平台选择、多平台决策、迁移规划和治理设置。不涵盖实验设计（请使用 experiment-design）、结果解读（请使用 experimentation-analytics）或功能标记运维（请使用 feature-flagging）。需要了解特定平台的 MCP 详情时，请将此技能与相关集成专题站点搭配使用。

目标读者是负责做出决策或纠正以往决策的产品经理、工程领导者或数据负责人。行文风格果断直接，不会说“视情况而定，你自己逐一评估”。决策空间有其实际边界，资深顾问可以在一个下午内梳理你的情况，并给出站得住脚的建议。

平台选择的 7 项考量

评估每个平台时，都会涉及相同的七个问题。先如实回答这些问题，再阅读各个平台的介绍，最后参考决策矩阵。顺序很重要：数据架构和统计严谨性是基础，其余考量都建立在此之上。

1. 数据架构。 实验数据存在哪里？有三种模式。供应商原生模式（Statsig、Optimizely）将数据保存在供应商的存储中。产品套件模式（PostHog、Amplitude）通过一个事件管道整合分析和实验。数据仓库原生模式（GrowthBook、Eppo）在你现有的数据仓库中运行 SQL。数据架构决定了安全审查的深度、数据驻留要求、统计深度和成本结构。

2. 统计严谨性。 平台是否实现了 CUPED、序贯检验、比例指标的 delta 方法和多重检验校正？在销售沟通中很容易核实：询问“比例指标使用什么方差估计量？”以及“是否支持始终有效的 p 值？”现代平台（Statsig、Eppo、PostHog 的部分功能）具备这些能力。较旧的平台或自行搭建的平台往往不具备。

3. MCP 可用性。 此处介绍的七个平台中，除 Eppo 外（截至 2026 年 5 月），其他平台都有第一方或托管 MCP。对于 AI Agent 从头到尾创建和读取实验的 Agent 工作流而言，MCP 可用性更重要；对于传统的人工驱动实验，其重要性较低。如果你的团队积极采用 AI，值得将其纳入考量。

4. 功能标记集成。 实验和功能标记是否位于同一个平台？Statsig、Optimizely、GrowthBook 和 PostHog 都将两者整合在一起。Eppo 仅支持实验。Kameleoon 专注于创意个性化。如果你还需要将功能标记运维作为生产基础设施，请查看 feature-flagging 了解运维规范；平台必须同时支持这两方面，否则你就得接受使用第二种工具。

5. 分析深度。 你能否在查看实验结果的同一界面中查看漏斗、留存和群组？PostHog 和 Amplitude 在这方面最强（以分析为先的产品）。Statsig 提供强大的分析层。Optimizely 和 GrowthBook 则以实验为先，分析是辅助功能。

6. 治理和审计。 谁可以在生产环境中更改定向规则？谁可以发布实验？谁可以读取敏感指标？企业版（Optimizely、LaunchDarkly Federal）对此有成熟的处理机制。开源平台（GrowthBook、PostHog self-hosted）则需要自行构建治理机制。对于受监管行业（医疗保健、金融、公共部门），这是决定性因素。

7. 成本结构。 供应商原生模式的成本随事件量增长。数据仓库原生模式的成本随席位数和数据仓库计算量增长。产品套件模式的成本随所有功能的合并事件量增长。让定价方式与实际使用模式相匹配。高流量初创公司和低流量企业面对的供应商原生定价并不相同；选择适合未来发展轨迹的成本结构，而不只是当前月份最合适的方案。

---

Statsig

将现代实验和功能管理整合在一个平台中。内置 CUPED 和序贯检验。由产品经理主导，使用体验出色。OpenAI、Notion、Brex、Figma 均在使用。

优势。 快速启动第一个实验。整合实验和功能标记，免去第二种工具带来的额外成本。统计严谨性符合当前研究成果。MCP 提供对实验、门控、动态配置和指标的完整 CRUD 操作。

注意事项。 定价随事件量增长，高规模下可能变得昂贵。该平台对实验应如何运行有明确主张；想采用自定义统计工作流的团队可能会与默认设置产生冲突。不提供一流的自托管选项。

理想客户。 快速增长的 SaaS 公司，希望用一个平台同时管理功能标记和实验，重视开箱即用的统计深度，并且能够接受供应商原生的数据架构。

---

PostHog

开源产品操作系统，集成了产品分析、实验、功能标记、调查、会话回放、错误跟踪和 LLM 分析。提供免费套餐。

优势。 覆盖完整漏斗。实验与为其提供背景信息的分析功能相邻。MCP 提供 200 多种工具（使用 ?features= 等范围限定方式，保持 Agent 上下文精简）。自托管选项成熟。开源许可让你免受供应商锁定。

注意事项。 随着规模扩大，所有功能的事件总量可能导致定价出人意料。功能范围广，可能让新手引导显得繁杂。实验的统计深度不错，但在 CUPED 默认设置等高级功能方面，仍略逊于 Statsig、Eppo 等专用实验平台。

理想客户。 希望在一个界面中使用分析、实验和功能标记，重视开源灵活性，并能适应其广泛功能的产品驱动型增长 SaaS 团队。

---

GrowthBook

开源、原生基于数据仓库的实验平台。数据保留在你的数据仓库中（Snowflake、BigQuery、Redshift、Postgres）。可自托管或使用云服务。

优势。 数据主权。由于数据仓库已经付费，规模扩大后更容易控制成本。根据其公告，这是首个用于实验的开源生产级 MCP。统计默认设置成熟，支持贝叶斯和频率学派模式切换。从数据仓库自带指标，因此实验指标与分析指标在定义上保持一致。

注意事项。 设置工作量高于供应商原生方案。你需要承担数据仓库的计算成本（这通常是优点而非缺陷，但会体现在不同的财务科目中）。社区规模小于 Statsig 或 PostHog。界面精致度比供应商平台稍逊一筹。

理想客户。 已经运行数据仓库、数据成熟度高的团队；需要数据驻留能力的受监管行业；以及看重开源所提供退出选择的团队。

---

Optimizely

长期领先的企业级平台。提供 Web Experimentation 和 Feature Experimentation。个性化能力强，并支持非技术用户进行可视化编辑。

优势。 企业级治理成熟。可视化编辑让营销人员无需工程师协助即可发布实验。客户成功团队实力强。托管式 Remote MCP 可在基于浏览器的 ChatGPT 和 Claude.ai 中使用。

注意事项。 价格昂贵。定价面向营销预算，而非工程预算。产品积累了数十年的功能，熟悉和使用都需要时间。统计默认设置偏保守，但若要寻找最新的方差缩减技术，这个平台并非最佳选择。

理想客户。 由营销主导的组织、实验项目成熟的企业，以及将非技术人员创建实验视为硬性要求的团队。

---

Amplitude

行为分析平台，并将实验和功能标记作为附加功能提供。所有客户均可使用托管式 MCP，包括免费套餐用户。

优势。 如果你的团队已经使用 Amplitude 进行分析，那么添加实验是阻力最小的选择。群组和行为细分能力出色。免费套餐（每月 1,000 万个事件）非常慷慨。

注意事项。 实验是次要功能，而非主打功能。统计深度一般。如果实验是团队的主要工作，Amplitude 很少是合适的选择；如果实验只是辅助能力，而分析才是核心，它就很适用。

理想客户。 以分析为先、需要将实验作为补充能力而非核心功能的团队。希望免费套餐同时提供分析和实验功能的产品市场契合度（PMF）前期团队。

---

Eppo

原生适配数据仓库，统计严谨，Twitch、DraftKings 和 Perplexity 都在使用。统计默认设置表现出色，包括贝叶斯与频率学派切换、序贯检验和 CUPED。

优势。 统计严谨是其核心卖点。团队中数据科学家和统计学家占比较高，这一点也体现在默认设置上。原生适配数据仓库的架构符合数据成熟团队已在采用的模式。报告清晰，以决策为导向。

注意事项。 截至 2026 年 5 月，没有官方 MCP。仅提供 REST API。如果工作流依赖 AI Agent 读取和编写实验，Eppo 目前无法满足需求。可关注未来的 MCP 发布情况。定价面向企业，没有实用的免费层。

理想客户。 由数据团队主导的组织，统计严谨性至关重要，数据仓库已是唯一可信数据源，并且 AI Agent 工作流是未来的考虑事项，而非当前需求。

---

Kameleoon

专注于将实验胜出方案转化为生产代码工作流的平台。AI 驱动的个性化功能。在 mcp.kameleoon.com/mcp 提供托管 MCP，支持 OAuth，并配有 7 个专用工具。

优势。 它能将营销网站实验中的胜出方案转化为永久性的 React 组件，这是一种真实存在的工作流，而其他平台通常会迫使团队手动处理。为内容网站提供 AI 驱动的个性化功能。其 MCP 专为从实验胜出到代码落地的路径而设计。

注意事项。 功能范围比其他平台窄。无法替代 Statsig 或 Optimizely 来运行产品实验。它通常与其他平台搭配使用，而非作为主平台。

理想客户。 在营销或内容网站上运行实验，并且需要将胜出变体转化为永久代码的团队。几乎总是与主产品实验平台搭配使用。

---

决策矩阵：不同场景下的平台选择

矩阵位于 references/platform-decision-matrix.md，其中包含详细示例。摘要如下：

• 纯 SaaS、快速增长，想用一个平台同时管理功能标志和实验。选择 Statsig。如果还需要分析功能，则选择 PostHog。
• 偏好开源、需要数据主权、希望原生适配数据仓库。选择 GrowthBook 或 Eppo。
• 企业级、由营销团队主导、需要深度个性化。选择 Optimizely。
• 已深度使用 Amplitude 进行分析。继续使用 Amplitude，除非统计能力不足成为瓶颈。
• 由数据团队主导、统计严谨性至关重要、暂不需要 MCP。选择 Eppo。
• 需要将营销网站上的胜出方案转化为生产代码。在主平台旁添加 Kameleoon。
• 受监管行业（HIPAA、FedRAMP），需要自托管。选择自托管版 GrowthBook。自托管版 PostHog 也是可行选择。
• 产品市场契合度（PMF）前的创业公司、流量较低、需要免费层。使用 PostHog 免费层或 Statsig 免费层；等流量足以支撑成本评估后，再做出正式选择。
• 每月事件数超过 1 亿，成本控制是首要限制因素。选择 GrowthBook 或 Eppo。在这个规模下，原生适配数据仓库的定价更具扩展性。
• AI 优先的团队，工作流以 MCP 为先。选择 Statsig、PostHog 或 Optimizely。等 Eppo 发布 MCP 后再考虑。

---

多平台：何时合理，何时混乱

当不同平台上的界面确实各不相同，且彼此没有重叠时，多平台是合理的。用 Kameleoon 做营销网站个性化，用 Statsig 做产品实验，就是一种清晰的拆分：界面不同、受众不同、指标集不同，没有重叠。第二个工具的成本是值得的，因为工作流不会冲突。

当不同平台上的界面有重叠时，多平台就会变得混乱。用 Statsig 和 Optimizely 同时做产品实验，会造成成本重复、数据分散，还会引发“哪个才是唯一可信的数据来源”的问题；而这个问题偏偏会在最糟糕的时刻浮现，也就是领导层意见不一致、需要答案的时候。

80/20 法则：80% 的团队应选择一个平台并整合。真正需要覆盖多个界面（营销网站、产品应用和内容网站）的 20% 团队，可以在明确划分所有权边界的前提下，采用多平台方案。

采用真正的多平台方案时，三种协调模式必不可少。所有权矩阵要明确每个平台负责哪些界面。统一的指标定义要确保两个平台中的“激活率”采用相同的计算方式（这很难，也是大多数多平台设置悄然出现偏差的原因）。可对账的仪表板则能让你在两个平台上查看定义相同的同一指标。详情见 references/multi-platform-orchestration.md。

---

迁移模式

迁移是那些不怎么光鲜的工程工作，它能让平台决策具备可恢复性。以下是五种常见路径。

从 Statsig 迁移到 PostHog。 公司不再满足于纯实验，希望将分析与实验整合时，通常会采用这条路径。工作量：3 到 5 个工程师周。并行运行 4 到 8 周，验证两个平台的实验是否得出相同结果，建立信任后再切换。

从 Optimizely 迁移到 Statsig。 预算吃紧或进行现代化改造时，通常会采用这条路径。工作量：4 到 8 个工程师周。先审查功能是否齐全（Optimizely 有一些 Statsig 不具备的个性化功能）。先迁移实验，再迁移功能标志。只有旧平台上的所有进行中实验都结束后，才停用 Optimizely。

从 PostHog 迁移到 Eppo。 当统计严谨性成为关键限制因素，且数据仓库已经是事实记录系统时，通常会采用这条路径。工作量：6 到 10 个工程师周。通常会保留 PostHog 用于分析，并用 Eppo 运行实验。应为最终的双平台状态制定计划，而不是追求彻底替换。

从 GrowthBook 迁移到 Eppo。 当商业支持和更深入的统计功能开始物有所值时，通常会采用这条路径。工作量：2 到 4 个工程师周，因为两者都原生支持数据仓库；数据已经存储在你的技术栈中。

迁移到 Statsig。 从混乱的多平台方案中整合平台时，通常会采用这条路径。工作量取决于平台数量和进行中的实验；顺利整合也需要 6 到 12 个工程师周。

迁移规范见 references/migration-playbook.md。每次迁移都应遵守三条规则：不要无限期并行运行，不要一次性切换，也不要在所有进行中的实验结束前停用旧平台。

---

成本的现实

坦诚地说。原生于供应商的平台（Statsig、Optimizely）按事件计费，通常每百万个事件收费 0.10 至 0.50 美元。小规模时容易预测，规模极大时则会令人吃不消。原生于数据仓库的平台（Eppo、付费版 GrowthBook）按席位和数据仓库计算资源计费；付费层级的典型价格范围为每年 5,000 至 50,000 美元，而数据仓库计算资源的费用会记在另一项财务账目上。产品套件型平台（PostHog、Amplitude）按所有功能的事件总量计费；重度使用时通常最划算，而只需要实验功能时则最贵。

免费层级。PostHog 每月免费提供 1M 个事件。Statsig 免费提供 1M 个事件。Amplitude 每月免费提供 10M 个事件，并包含基本功能。GrowthBook 是免费的开源软件。Optimizely 和 Eppo 没有实质性的免费层级。

陷阱。只看标价会忽略总成本。总成本包括工程师时间、统计准确性（错误结果的实验可能比一年的平台费用代价更高）、治理开销和迁移风险。标价对财务很重要；总成本则关乎产品迭代速度。详情和财务沟通模式见 references/cost-and-pricing-models.md。

---

治理与团队适配

权限层级、审批工作流、审计追踪和环境晋级是治理的四大支柱。谁创建实验、谁修改生产环境中的定向规则、谁查看敏感指标、谁批准发布。企业版开箱即提供这些功能。开源且可自托管的平台要求你自行构建这些功能；如果你有足够的工程能力，这没问题；如果没有，这就是一个无法接受的障碍。

团队适配对决策的影响，超过大多数评估所承认的程度。PostHog 和 GrowthBook 适合工程师主导和 PLG 团队。Optimizely 适合市场营销主导的团队。Eppo 和 GrowthBook 适合数据团队主导的团队。Statsig 适合 PM 主导的团队。平台的默认设置会让团队的实验文化朝其主要用户的方向发展；选择与你真正希望负责运行实验的人相匹配的平台。

入门成本。新 PM 需要多久才能上线第一个实验？Statsig 和 PostHog：数小时到数天。Optimizely：数天到数周。Eppo 和 GrowthBook：取决于数据仓库和指标是否已接入（已接入则数天，未接入则数周）。详情见 references/governance-and-team-setup.md。

---

MCP 能力层

对于 AI 优先的团队，MCP 能力层正逐渐成为决定性因素。截至 2026 年 5 月的当前情况：

• 除 Eppo 外，涵盖的七个平台都提供第一方或托管 MCP。Eppo 仅提供 REST API。
• 能力相差一个数量级。PostHog 提供 200 多个工具；Kameleoon 提供 7 个。工具越多不一定越好；合适的规模取决于你的工作流。
• 对于 AI Agent 端到端运行实验的 Agent 工作流，优先选择通过 MCP 提供完整 CRUD 功能的平台：Statsig、PostHog、GrowthBook、Optimizely。
• 对于 MCP 辅助人工操作的人工主导工作流，七个平台都适用（Eppo 可通过 REST 实现）。

MCP 的可用情况正在快速变化。做出承诺之前，请检查任何平台的最新情况。值得关注 Eppo 未来是否发布 MCP，以弥补当前的差距。并排能力对照表见 references/mcp-capability-comparison.md。

---

何时应暂缓决策

有时正确的答案是“现在还不行”。以下是四种情况。

尚未达到产品市场契合度（PMF）。实验基础设施为时过早。使用免费套餐（PostHog 或 Statsig）来消除阻碍，等到流量足以让任何平台发挥作用后，再做出真正的决策。

验证单个实验。不要为了一个实验就挑选平台。使用任何免费且方便的工具。平台决策适用于把实验作为一项常规实践的团队，而不是刚开始做实验的团队。

尚未形成实验文化。工具无法解决文化问题。如果团队还没有开展实验，选择一个高级平台也不会改变现状。先建立文化；等实验顺利开展后，平台的选择自然会变得明朗。

即将被收购或进行重大转型。等尘埃落定后再决定。收购方很可能已经有偏好的平台。

---

常见错误

平台决策中反复出现十二种模式。简而言之：

• 选择了最便宜的。总成本远比标价重要。
• 选择了功能最多的。用不到的功能会成为技术债务。
• 一开始就尝试使用多个平台。之后几乎总会变成整合项目。
• 已经超出平台的能力范围，却因迁移成本而继续使用。平台成本会不断累积；迁移成本则是固定的。
• 根据演示做出选择。演示以展示效果为导向；实际使用才能揭示真实的权衡。
• 没有检查治理机制。推出后才发现任何人都能修改生产环境的定向规则。
• 选择的平台不适合团队类型。由 PM 主导的团队使用由营销主导的平台，会持续产生摩擦。
• 低估了数据仓库的配置工作。原生支持数据仓库的平台要求数据仓库已经就绪。
• 跳过了对统计深度的审查。后来一次关键实验暴露出决策结果错误。
• 忽视了 MCP 的发展趋势。为 AI 优先的团队选择了不支持 MCP 的平台。
• 根据演示而非试用来确定需求简报。简报中的假设经不起真实使用的检验。
• 续约时没有重新评估。市场变了，需求简报却没有变。

详情请参阅 references/common-mistakes.md，其中介绍了各种症状、根本原因、解决方法和预防措施。

---

框架：可持续平台选择的 11 项考量

选择或评估实验平台时，请逐项审视以下 11 项考量。得出建议之前，先回答每一项。跳过其中任何一项，都可能导致团队在一年后陷入迁移项目。

1. 数据架构。 供应商原生、产品套件原生，还是数仓原生。其他所有决策都取决于这一模式。
2. 统计严谨性。 CUPED、序贯检验、比率指标的 delta method、多重检验校正。在销售沟通阶段就要核实；不要想当然。
3. MCP 可用性。 当前能力及发展趋势。如果团队积极拥抱 AI，应提高这一项的权重。
4. 功能标记集成。 使用同一平台还是单独的平台。做一次决定，并接受其影响。
5. 分析深度。 是否在同一界面中提供漏斗、留存和群组分析。这决定你是否需要另一个工具来构建分析层。
6. 治理。 权限、审计、审批工作流、环境晋级。对受监管行业而言，这些不可妥协。
7. 成本构成。 按事件数、席位数还是数仓计算量计费。让成本构成与你的使用量发展趋势相匹配。
8. 团队适配度。 由 PM、工程师、数据团队还是市场团队主导。平台的默认设置会将团队文化引向其主要用户群体的方向。
9. 入门成本。 新团队成员启动首次实验所需的时间。越快越好；不同平台之间差异很大。
10. 迁移成本。 如果选错了，退出方案是什么。迁移成本越高，决策时所需的信心就越强。
11. 多平台适配度。 这一层能否与已有平台无缝配合，还是会造成重叠。

该框架的结论有三种：给出有理由支撑的首选建议；如果情况确实难以判断，则列出两个候选项；如果尚未满足前置条件（没有流量、没有相应文化、即将转型），则建议“暂缓”。

---

参考文件

• references/platform-decision-matrix.md - 按情境划分的平台矩阵，并附有最常见决策情境的实例。
• references/migration-playbook.md - 五种常见迁移的分步模式，包括工作量估算和验证方法。
• references/mcp-capability-comparison.md - 七个平台的 MCP 能力对比矩阵。
• references/multi-platform-orchestration.md - 真正采用多平台方案时的职责边界、共享指标定义和核对仪表板。
• references/cost-and-pricing-models.md - 定价模式、不同流量级别下的实际成本范围，以及与财务团队沟通的常见方式。
• references/governance-and-team-setup.md - 权限级别、审计轨迹要求、环境晋级规则和团队适配度评估。
• references/common-mistakes.md - 十二种失败模式，每种都包含症状、根本原因、修复方法和预防措施。

---

结语：犹豫不决时，就选稳妥的

如果分析后确实仍有歧义，就选稳妥的方案。稳妥意味着成熟、文档完善、用户群体庞大，而且即使后来发现选错了，也能平稳迁移。对于 SaaS，Statsig 是稳妥之选；对于产品驱动增长，PostHog 是稳妥之选；对于企业，Optimizely 是稳妥之选；对于原生数据仓库，GrowthBook 是稳妥之选。

稳妥的方案未必是最优解，但几乎从不会错。等情况明朗、团队也积累了足够经验，知道自己真正需要什么之后，再追求最优解也不迟。选择稳妥方案的代价，只是略微牺牲效率；而选择小众方案后发现选错，代价则是一个会打断整整一年产品工作的迁移项目。

如果团队对该选哪个稳妥方案意见不一，那就是一个数据层面的信号：情况还不够明朗，无法让任何一个答案显得明显正确。选出排名最高的两个方案，各试用 30 天，用真实使用数据对照包含 11 项考量的框架进行评估，然后做出选择。不要跳过试用；演示无法反映真实使用情况，而这些问题只有试用才能揭示。