选对平台，只解决了"用什么"；完成交付，才能回答"有没有拿到业务结果"。顾问不跟 SaaS 抢生意，也不跟技术团队抢活——在采购、自建、交付、拿结果的全过程里，提供专家经验和指引。

作者：zhanbo · 2026-07-13

tl;dr

  • 两个 Studio 都采购过火山引擎 ABTester：一个项目我参与到选型，一个项目我补上了后续交付。它们恰好说明，顾问的价值不在于"卖平台"或"替研发写代码"，而在选型和交付两端提供专家指引，把工具转化为业务结果。
  • 我推出了「实验平台落地诊断」和「发行平台提效诊断」，本季度限 2 家。邮件 zanhe@139.com 或加微信 zanhe1984，主题写"实验落地"或"发行提效"，帮你判断采购、自建、交付这条链上，专家经验应该补在哪一段。

两个 Studio，两种参与方式

2025 年，我先后接触了两个游戏团队的实验能力建设项目。为保护客户信息，本文分别称其为 Beta Studio 和 Alpha Studio。

Beta：研发资源有限，选择 SaaS 快速起步

2025 年中，Beta 希望升级实验能力。

当时业务部门有明确需求，但缺少足够的专项研发资源。在内部自建与采购 SaaS 之间，团队最终选择了火山引擎 ABTester，希望借助成熟产品更快建立实验能力。厂商的行业影响力和已有案例，也是选型的重要因素。

我参与了前期咨询和选型讨论，但没有继续跟进后续交付，因此无法评价项目最终效果。

这段经历留下的核心问题是：

买到平台，只是确定了实验能力的技术载体，并不代表企业已经获得了实验能力。

选型结束后，仍有一系列问题需要解决：

  • 业务数据和实验参数如何接入；
  • 参数配置是否依赖软件版本发布；
  • 指标口径和验收标准如何定义；
  • 流量框架是否适合实际业务；
  • 谁负责平台运营和实验复盘；
  • 实验结论如何进入业务决策。

这些问题不会随着合同签署自动解决。

Alpha：有了自建分流，为什么仍然跑不快？

Alpha 在 2024 年上半年也采购了火山引擎 ABTester。由于实验参数与软件发版耦合较重，团队随后自建了分流能力。

但第一版只支持互斥桶。

互斥桶可以避免实验冲突，却会把流量切割成相互独立的区域。随着实验数量增加，可用流量很快成为瓶颈。平台虽然"能跑实验"，却难以支持产品、算法和商业化团队同时开展大量实验。

我是在这个阶段作为顾问参与项目的。

后续迭代中，团队引入了类似 Google 重叠实验基础设施的分层、分域和正交流量框架。只要实验修改的参数和影响范围不同，就可以在控制冲突的前提下共享流量。

升级之后，平台能够支持上千量级的实验并发，产品交互、算法和商业化实验得以大规模并行，并最终明显推动了北极星指标。

真正产生价值的不是"并发数字"本身，而是团队建立了一条完整链路：

业务假设 → 实验配置 → 并行验证 → 指标分析 → 上线或回滚 → 收益追踪

实验平台由此从一套分流工具，变成了业务持续优化的基础设施。

一个停在选型，一个补上交付

Beta 和 Alpha 不能被简单概括为"一个失败、一个成功"。

我没有参与 Beta 的后续交付，没有一手信息判断最终结果。两个项目真正形成的对照，是实验平台建设中的两个阶段：

项目我的参与阶段核心问题已知结果
Beta Studio咨询与选型研发资源有限，如何快速建立实验能力选择 ABTester，后续未继续参与
Alpha Studio自建后的迭代与交付流量利用率与实验并发不足支持上千量级实验并发，并推动业务指标

Beta 说明，选型阶段需要辅导。

Alpha 说明，无论采购 SaaS 还是内部自建，交付阶段都需要专家参与。

实验平台建设并不是一个单点采购项目，而是一条连续的价值链：

业务目标 → 方案选型 → 系统集成 → 流量与指标体系 → 实验运营 → 可信结论 → 业务收益

任何一环断开，平台都可能停留在"已经购买"或"已经上线"，而无法持续产生结果。

选型阶段，顾问帮助客户把需求变成验收标准

企业选型时，容易把注意力集中在品牌、报价、功能清单和标杆案例上。但平台是否适合，最终取决于业务场景和落地条件。

顾问在选型阶段需要帮助客户明确：

  • 支持用户、设备、请求还是其他实验单元；
  • 是否覆盖产品、算法与商业化实验；
  • 参数能否动态下发，是否与版本发布解耦；
  • 数据回传的字段、延迟和准确性；
  • 是否支持互斥、正交与重叠实验；
  • 后续需要投入多少研发和运营资源。

顾问不是替客户指定厂商，而是完成一次关键翻译：

把模糊的业务需求，翻译为可比较的能力要求、可执行的 PoC 和可验收的交付标准。

客户最终选择 SaaS、自建还是混合架构，可以根据自身资源决定。

交付阶段，顾问帮助平台形成业务结果

实验平台同时涉及流量分配、指标体系、统计分析、参数管理、研发流程和组织协作。

SaaS 厂商可以提供标准产品，内部技术团队可以完成集成与开发，业务团队可以提出增长问题，但三者未必自然形成闭环。

顾问在交付阶段需要帮助团队解决：

  • 哪些能力适合采购，哪些应该自建；
  • 哪些实验可以重叠，哪些必须互斥；
  • 如何提高实验吞吐量而不牺牲可信度；
  • 如何设计核心指标、护栏指标与诊断指标；
  • 如何让实验结论进入上线、回滚和复盘流程。

这几种角色并不冲突：

SaaS 提供产品能力，内部团队提供工程与业务能力，顾问帮助这些能力更快形成结果。

实验平台真正的交付，不是完成部署，也不是跑出第一个实验，而是让业务团队能够低成本、规模化地产生可信结论，并把有效结论持续转化为业务增长。

你的实验平台卡在哪一段？

如果团队正在采购、自建实验平台，或者平台已经上线但迟迟用不起来，可以先回答以下问题：

  • 数据字段、回传延迟和准确性是否写入 PoC 验收标准？
  • 平台只支持互斥桶，还是可以管理重叠与正交实验？
  • 实验参数是否仍与软件版本发布强耦合？
  • 是否同时定义核心指标、护栏指标和诊断指标？
  • 实验结论是否有固定的评审、上线和复盘流程？
  • 成功实验上线后，是否持续追踪业务收益？
  • 业务、产品、数据和研发是否对平台目标形成共识？

如果其中有三个以上问题无法明确回答，团队缺少的可能不是更多功能，而是采购、架构或交付链路中的关键一段。

两项诊断服务，本季度限 2 家

实验平台落地诊断

适合正在比较 SaaS 与自建、已经采购但使用率较低，或者已有分流能力但实验规模受限的团队。

诊断将覆盖业务场景、数据指标、流量框架、工程条件、实验分析和组织运营，帮助团队找出当前瓶颈，以及优先级最高的三个改进项。

邮件 zanhe@139.com 或加微信 zanhe1984，主题写 “实验落地”，并附上一句话现状，例如：

已经采购实验平台，但参数仍然依赖版本发布，每月只能运行少量实验。

发行平台提效诊断

适合正在建设出海发行、营销数据或智能投放平台，但存在多渠道数据不一致、人工对账与复盘成本高、投放经验难沉淀等问题的团队。

诊断将围绕数据底座、指标口径、业务流程、平台能力与 Agent 场景，判断最值得优先建设或改造的环节。

邮件 zanhe@139.com 或加微信 zanhe1984，主题写 “发行提效”，并附上一句话现状，例如：

Meta、Google 和 MMP 三套数据长期对不上，投放复盘仍依赖人工整理。

延伸阅读

说明：Beta Studio 和 Alpha Studio 均为脱敏代号。Beta 项目仅参与前期咨询与选型，未参与后续交付，本文不对其最终实施效果作判断；Alpha 案例基于实际咨询项目复盘，涉及客户经营和技术细节的部分已进行抽象处理。