标签: 实验平台

实验平台搭建与诊断冲刺 2 周内，把你的 A/B 实验从"看看数据"变成"支撑 AI 决策的可信反馈闭环"。 服务范围：面向 内容、电商、SaaS 与平台型业务，不承接游戏行业相关咨询。 A/B 实验不是一个按钮，也不是一个报表，而是一套让产品、算法、运营和增长团队能持续学习的贝叶斯系统。 尤其关注 AI / Agent 决策是否具备可信反馈闭环 —— 这是下一个十年增长团队的核心基础设施。 适合谁 本服务特别适合： 📈 内容 / 电商 / SaaS 的产品 / 增长 / 算法团队 🔬 日均 DAU 10 万+，正在遇到实验规模瓶颈的团队 🤖 准备引入 AI Agent 决策，但缺乏可信测量体系的团队 典型场景： “我们的实验结果经常互相矛盾，产品和数据团队吵个不停” “分流好像有问题，同一个用户进多个组，数据根本不敢信” “想上 AI 做自动决策，但连 A/B 实验的基线都没打牢” “实验做了不少，但真正推动产品前进的没几个” 服务周期 🕒 2 周密集诊断 + 4 周陪跑实施（可选） 六维诊断框架 我提供实验平台与增长测量体系的诊断、设计和实施陪跑，覆盖六个核心模块： 模块 诊断对象 核心问题 流量管理与分流能力 分层、分桶、互斥、正交 是否支撑实验规模和复杂度 实验管理与流程规范 创建、审核、发布、回滚、归档 是否有完整生命周期管理 统计分析引擎能力 p-value、置信区间、CUPED、序贯检验 结论是否科学可信 指标体系健康度 北极星指标、护栏指标、长期指标 是否避免短期指标误导 工程架构与稳定性 SDK、配置、日志、容灾 是否稳定可靠 实验文化与组织效能 假设质量、复盘机制、决策习惯 是否真正用实验学习 实验驱动增长的四大场景 场景 目标 衡量方式 用户体验优化 持续优化产品手感与体验 时长、留存、GMV / 完成率 产品特性探索 验证产品方向，降低创新风险 用户需求满足度、功能渗透率 增长与运营效率 产品内与渠道侧双向优化 ROI、渠道生命周期、获客成本 商业化收益 平衡用户体验与变现效率 ARPU、LTV、付费深度 你将拿到什么（核心交付物） 不是空泛的"咨询报告"，而是工程团队拿到就能用的决策文档： ...

案例：千级并发实验，从互斥桶到重叠框架 客户画像：头部内容平台，MAU 亿级，产品 / 算法 / 商业化团队并行做实验 核心痛点：用互斥桶模型，流量不够用，实验排期要等 1 个月；而且实验结果经常互相污染 服务周期：2 周诊断 + 3 个月架构升级陪跑 本案例已完全脱敏，不指向任何特定客户或行业；服务范围不含游戏（含手游 / 休闲 / 中重度）行业。 问题诊断 团队遇到的不是"流量不够"的问题，而是实验架构从根上就不支持规模化： 问题 具体表现 业务影响 流量模型落后 还是传统的互斥桶模型，一个实验占一个桶 同时跑20个实验就把流量占满了，新实验排期要等 分流逻辑混乱 没有正交分层，产品改个UI会影响算法实验 算法团队说结果不准，产品团队说他们乱改，天天吵架 特性耦合严重 feature、bundle、experiment 混在一起 改一个功能要动N个实验配置，上线必出事故 指标分散 每个团队看自己的指标，没人看护栏指标 短期指标涨了，但长期留存掉了，还不知道为什么 核心判断：不是招更多分析师就能解决的问题——必须从流量架构层面重构，否则实验越多，越乱。 我们的方案 不是"加服务器扩容"，而是整个实验体系的结构化升级： 第一步：流量架构重构 基于Google重叠实验框架，设计流量域、层的切分方案 新增域/活跃域拆分，算法层/UI层/商业化层正交隔离 实现完全基于实验的配置分发，流量利用率提升两个数量级 第二步：特性拆分与治理 打通业务研发（特性 feature）→ 发版（bundle）→ 实验（experiment）管线 正交特性拆分标准，提升流量同质性 实验治理SOP：什么能开实验、什么不能、谁来审核 第三步：决策效率升级 收敛核心指标体系：北极星指标 + 护栏指标 + 分类指标 综合分/质量分/效能分，一张表看实验健康度 CUPED + 贝叶斯分析，降噪提速，更快出可信结论 第四步：组织文化配套 全员实验方法论培训，统一"什么是可信结论"的语言 创意库建设 + 大模型辅助，提升创意产能 交付清单 🏗️ 《重叠实验框架架构设计方案》 🧪 《流量域/层/桶划分与正交隔离规范》 🔗 《feature-bundle-experiment 管线设计》 📊 《实验指标体系 + 决策评分卡》 📋 《实验治理SOP + 审核矩阵》 🗺️ 《3个月架构升级路线图》 结果 ✅ 实验并发能力从几十个提升到千级，实验排期从"等一个月"变成"随时开" ✅ 流量利用率提升两个数量级，同样的流量能跑更多实验 ✅ 实验结果互斥污染问题基本解决，产品和算法团队终于不吵架了 ✅ 实验决策速度提升50%，从"看一周数"变成"3天就能拍板" ✅ 创意产能提升，实验数量上来了，产品迭代速度明显加快 👉 查看完整服务介绍：实验平台搭建与诊断冲刺 ...

增长不是一次灵感，也不是某个爆款素材、某个新渠道、某个产品改版带来的偶然结果。 真正可持续的增长，来自一套能够不断提出假设、验证假设、沉淀结论、再继续迭代的实验体系（贝叶斯方法）。 我想用一句话概括这个观点：实验即增长。 这也是展博增长实验室推出的产品（实验&增长咨询服务，面向内容、电商、应用等非游戏行业提供实验&增长的诊断、咨询、平台建设、业务陪跑等服务）。 尤其在面向全球市场的数字业务里，这句话更接近现实。因为数字业务面对的是高度不确定的市场：不同国家、不同文化、不同平台、不同获客环境、不同用户付费习惯，都可能让同一个产品表现出完全不同的增长曲线。 在这种环境下，企业不能只依赖经验判断，而要依赖实验。 一、为什么说“实验”是增长的基础？ 科学的基础不是“我觉得”，而是“可论证”。 从证据可信度来看，我们可以看到一个从低到高的金字塔：案例研究、观察研究、类实验、随机控制实验，以及更高层级的统合分析。 这些方法形式不同，但本质上都在回答同一个问题： 某个变化，是否真的带来了结果？ 在商业增长里，这个问题尤其关键。 比如： 留存提升，是因为新手引导改得更好，还是因为这批用户质量本来更高？ ROI 提升，是因为素材策略有效，还是因为渠道算法短期波动？ 付费率提升，是因为礼包设计更合理，还是因为活动期间用户天然更愿意付费？ 如果没有实验体系，团队很容易把相关性误判为因果关系，把短期波动误判为方法论，把偶然成功误判为可复制能力。 所以，增长团队真正需要的不是更多“拍脑袋的优化建议”，而是一套持续验证因果关系的机制。 二、为什么增长离不开实验？ 增长是所有商业组织前进的动力。 但增长本身不是一个单点问题，而是一组连续问题： 如何让更多用户看到产品？ 如何让用户愿意下载或进入游戏？ 如何让用户留下来？ 如何让用户持续活跃？ 如何让用户付费？ 如何让 LTV 高于获客成本？ 这些问题之间相互关联，任何一个环节的改动，都可能影响整体增长效率。 在数字业务里，增长链路尤其长：从素材、广告、商店页、下载、首日体验、新手引导、核心循环、活动运营、付费设计，到广告变现和再营销，每一步都有优化空间。 这也是为什么我认为： 增长不是找到一个答案，而是建立一套不断找到答案的系统。 这个系统的核心，就是实验。 三、数字业务公司的四类典型实验场景 如果把数字业务公司的增长拆开看，实验至少会发生在四个关键场景里：用户体验、产品特性、买量与营销效率、商业化收益。 1. 用户体验实验：优化用户进入产品后的第一感受 用户体验实验关注的是：用户是否愿意继续玩下去。 常见实验包括： 新手引导流程调整 首局难度设计 UI 布局优化 任务系统节奏 奖励反馈强度 核心玩法教学方式 衡量指标通常包括： 使用时长 次日留存、七日留存 对局数 关卡完成率 GMV 或早期付费转化 用户流失节点 例如，一个产品可能会测试两种新手引导：一种是强引导，明确告诉用户每一步怎么操作；另一种是弱引导，让用户更快进入核心玩法。 表面上看，强引导更“清楚”；但实验结果可能显示，弱引导让用户更快获得乐趣，反而提升了留存。 这就是实验的价值：它能帮助团队摆脱主观偏好，回到用户真实行为。 2. 产品特性实验：探索产品该往哪里发展 产品特性实验关注的是：产品是否真正解决了用户需求。 常见实验包括： 新玩法模块 社交系统 排行榜 活动机制 关卡类型 道具系统 个性化内容推荐 这类实验不只是验证“功能有没有用”，更重要的是帮助团队判断产品方向。 ...

三个 Studio 的实验复盘:广度、深度、精度,对应三类增长瓶颈——以及你怎么拿到同样的增长红利。 作者:zhanbo · 2026-07-15 tl;dr 我近距离参与过三个出海 Studio 的实验平台建设,他们从实验里拿到的,不是某一次优化,是把不确定性变成可复利增长的组织能力。 广度、深度、精度——三种实验红利对应三类增长瓶颈:验证太慢、流量不够、结论不可信。 如果你正卡在实验平台建设、或者跑了实验却拿不到真实增长,可以邮件 zanhe@139.com 交流,主题写"实验红利"。 一、连续两年全球下载第一,靠的不是运气 一款 2022 年上线的方块消除游戏,2024、2025 连续两年拿下全球手游下载榜第一,2025 年一年下载 3.68 亿次,累计超 8 亿,月活过 3 亿。纯靠应用内广告变现,月流水千万美元级。 它的开发商对媒体只说过一句很朴素的话:任何要改动的地方,都会先做 A/B 测试,确认不会伤到这个庞大的用户盘,才真正上线。(数据来源:AppMagic / mobilegamer 2025 年度下载榜) 连续两年第一,不可能是运气。运气不会重复。能重复的,是一套把"改一下试试"变成"可信决策"的机制。 这几年我近距离参与过三个出海 Studio 的实验能力建设,从平台选型一直到交付落地。今天把这三段复盘摊开,讲一件事:这些团队从实验里,到底拿到了什么。 (下面三个案例都做了脱敏,用 Alpha / Beta / Gamma 代号。) 二、三个 Studio,三种实验红利 Beta:广度——把"赛马"变成一条验证流水线。 Beta 是一家老牌出海厂,打法是海量试新,一年能测十几款产品,每隔两三个月出一款新品。这种打法对实验能力的要求不是"深",是"快而准"——能不能用最小成本判断一个玩法、一个买量素材、一个变现节奏值不值得加码。我参与了他们的实验平台选型,帮他们先想清楚"这平台到底要解决哪类验证"。对这种 Studio,实验红利是广度:把老板拍脑袋的赛马,变成一条标准化、可复用的验证流水线。 Alpha:深度——一款爆品,靠上千并发实验持续打磨。 Alpha 是另一个极端:不铺量,就一款产品,但要把它打磨到全球第一。最初也买了第三方 SaaS,后来因为实验参数和发版耦合太重、成本高,转向内部自建——但自建的分流只做到互斥桶,实验一多就撞车,流量根本不够分。我是后面作为顾问介入的,帮他们把流量框架从互斥桶升级到重叠实验,把并发顶到上千个实验同时跑,产品、算法、商业化实验并行。对这种 Studio,实验红利是深度:同样的流量,能验证的假设多了一个数量级。 Gamma:精度——从"能跑实验"到"实验结论可信"。 Gamma 是一家多品类的长线厂,数独、填色、麻将、拼图,每个细分都做到头部,靠的是长期稳定的迭代。我参与过他们实验平台的几次演进:2019 年那版 1.0 解决的是"分析方法",把实验数据算对;到 2021 年,讨论的核心已经变成 bias reduction——怎么把选择偏差、幸存者偏差、偷看数据这些让结论失真的东西剔掉。对这种 Studio,实验红利是精度:当你一年要做几百个实验,哪怕只有 0.5% 的假阳性,也够让你全量上线一堆其实没用的改动。 三、他们到底从实验里拿到了什么 把三段拼起来,答案就清楚了。他们拿到的从来不是"某一次优化涨了多少",是三样更底层的东西。 ...

选对平台，只解决了"用什么"；完成交付，才能回答"有没有拿到业务结果"。顾问不跟 SaaS 抢生意，也不跟技术团队抢活——在采购、自建、交付、拿结果的全过程里，提供专家经验和指引。 作者：zhanbo · 2026-07-13 tl;dr 两个 Studio 都采购过火山引擎 ABTester：一个项目我参与到选型，一个项目我补上了后续交付。它们恰好说明，顾问的价值不在于"卖平台"或"替研发写代码"，而在选型和交付两端提供专家指引，把工具转化为业务结果。 我推出了「实验平台落地诊断」和「发行平台提效诊断」，本季度限 2 家。邮件 zanhe@139.com 或扫码加微信，主题写"实验落地"或"发行提效"，帮你判断采购、自建、交付这条链上，专家经验应该补在哪一段。 两个 Studio，两种参与方式 2025 年，我先后接触了两个团队的实验能力建设项目。为保护客户信息，本文分别称其为 Beta Studio 和 Alpha Studio。 Beta：研发资源有限，选择 SaaS 快速起步 2025 年中，Beta 希望升级实验能力。 当时业务部门有明确需求，但缺少足够的专项研发资源。在内部自建与采购 SaaS 之间，团队最终选择了火山引擎 ABTester，希望借助成熟产品更快建立实验能力。厂商的行业影响力和已有案例，也是选型的重要因素。 我参与了前期咨询和选型讨论，但没有继续跟进后续交付，因此无法评价项目最终效果。 这段经历留下的核心问题是： 买到平台，只是确定了实验能力的技术载体，并不代表企业已经获得了实验能力。 选型结束后，仍有一系列问题需要解决： 业务数据和实验参数如何接入； 参数配置是否依赖软件版本发布； 指标口径和验收标准如何定义； 流量框架是否适合实际业务； 谁负责平台运营和实验复盘； 实验结论如何进入业务决策。 这些问题不会随着合同签署自动解决。 Alpha：有了自建分流，为什么仍然跑不快？ Alpha 在 2024 年上半年也采购了火山引擎 ABTester。由于实验参数与软件发版耦合较重，团队随后自建了分流能力。 但第一版只支持互斥桶。 互斥桶可以避免实验冲突，却会把流量切割成相互独立的区域。随着实验数量增加，可用流量很快成为瓶颈。平台虽然"能跑实验"，却难以支持产品、算法和商业化团队同时开展大量实验。 我是在这个阶段作为顾问参与项目的。 后续迭代中，团队引入了类似 Google 重叠实验基础设施的分层、分域和正交流量框架。只要实验修改的参数和影响范围不同，就可以在控制冲突的前提下共享流量。 升级之后，平台能够支持上千量级的实验并发，产品交互、算法和商业化实验得以大规模并行，并最终明显推动了北极星指标。 真正产生价值的不是"并发数字"本身，而是团队建立了一条完整链路： 业务假设 → 实验配置 → 并行验证 → 指标分析 → 上线或回滚 → 收益追踪 ...

同样在做 AB 测试，别人靠它持续迭代、增长一路向上，我们的实验却结果不可靠、推全就反转。问题往往不在平台，而在你没建之前就该想清楚的那几件事。 作者：展博 / 2026-06-22 tl;dr 竞对靠实验跑赢了，你也想做，但「实验结果不可靠、推全后效果反转、不知道该信哪个指标」——这些不是平台不够强，是实验体系没建对。 实验时涨、推全后反转，最常见的原因有三个：偷看数据提前停、只挑显著指标报、没看护栏指标。这三个坑和平台贵不贵没关系。 判断一个提升是否可信，不能只看 p<0.05，还要看效应量、护栏指标有没有掉、长期效应是否成立。 80% 的实验平台问题不是技术问题，是指标口径、流程、组织问题。 你以为缺的是工具，其实缺的是共识。 建平台之前，先花半天做个体检。 决策前花小钱搞清楚「值不值得建、该怎么建」，比拍脑袋投几十万、再发现方向错了，便宜太多。 一、你可能正被这几个问题困住 先不谈平台、不谈架构。我想先问你几个问题——如果你是增长、产品或者数据负责人，看看下面这些是不是你正在经历的： 「竞对靠实验跑出来了，我们也想做实验，但不知道从哪儿下手。」 看到对手用 AB 测试快速迭代、增长曲线一路上扬，你也想复制这套打法，可一落到自己团队，连「第一个实验该怎么设计」都说不清楚。 「我们的实验平台，结果好像不太可靠。」 平台是有了，可同一个实验，不同人看出来的结论不一样；今天说显著，明天又说不显著。你心里其实没底——这些数到底能不能信？ 「实验时看着涨，推全之后效果反转，或者根本没达到预期。」 这是最让人崩溃的一种。实验阶段明明指标涨了，信心满满全量上线，结果线上效果反转，甚至还不如不改。那当初那个「提升」，到底是真的，还是数据骗了你？ 「到底该看哪些指标？怎么判断一个提升是不是可信？」 一个实验看十几个指标，挑一个涨的报上去，算不算成功？p 值小于 0.05 就一定靠谱吗？留存没动、付费涨了，能推全吗？ 「说到底——我们的实验平台，建得到底对不对？」 花了钱、花了人，可越用越怀疑：是不是从一开始方向就错了？ 如果这些问题你中了一半以上，那我可以负责任地说：这些大概率不是「平台不够强」的问题，而是「实验体系没建对」的问题。 而后者，加再多机器、买再贵的 SaaS 也解决不了。 下面我们一个一个拆。 二、一个真实的场景：平台建好了，然后呢？ 先说一个我反复见到的场景，它正是上面那些问题的总和。 一家公司，老板拍板「我们要数据驱动」，于是数据团队花了三个月，搭了一个看起来很专业的实验平台：能分流、能看报表、能跑 AB。 然后呢？ 产品团队觉得「这玩意儿太麻烦，我直接上线不行吗」； 增长团队自己有一套买量看数的逻辑，不鸟这个平台； 数据团队辛辛苦苦建的东西，三个月后没人用，结论也没人信。 钱花了，平台有了，但增长没变快。 这不是个例。根据我的观察，有实验平台的团队里，大概 80% 都卡在「建了但没人用」这个状态。 更要命的是，这个坑很贵——你不是损失了搭平台的几十万，你损失的是「本可以用来验证增长假设的几个月时间」。 三、为什么会这样？因为大部分问题，根本不是技术问题 很多团队一想到「实验能力不行」，第一反应是「我们的工具不行，得建个更好的平台」。 这是最常见的误判。 先说结论：实验体系的问题，可以拆成四层，技术只是最浅的一层。 阻力层 典型表现 真相 工具层 「我们没有实验平台」「分流都做不了」 这是最容易解决的，花钱花人就能搞定 流程层 「实验做完就忘了」「没人写假设」「结论存哪了？」 工具再好，流程不通照样白搭 组织层 「数据团队建平台，产品团队不用，增长团队自己玩」 三权不清，谁都不为实验结果负责 文化层 「老板拍板，实验数据不算数」「失败的实验没人敢说」 最深的一层，建再好的平台也救不了 这里最关键的是：很多你以为的「技术问题」，其实是流程或组织问题。 ...

经手的实验平台多了以后从不同公司流量框架的设计和应用中吸取一些经验，下面展开说下我的理解 流量的理解 AB实验需要通过对随机、同质、独立的流量施加不同的方案，通过实验观测看不同方案的优劣。所以第一步是对自己流量的理解 流量的生态包括哪些参与者，比如 互联网中搜索引擎用户 电商领域中买家、卖家 内容领域中的消费者和创作者 外卖中骑手、商家、买家 游戏领域中玩家（又有玩法的区分比如PvP中玩家相互就不独立） 流量的随机性通常在流量框架中通过技术手段可以解决，比如hash分流、轮询分流等 流量的同质性正常在流量随机的过程中可以保障，在用户分布（画像、指标的分布）相对比较极端的场景需要进行同质性检验确保实验可信 流量的独立性在选择流量框架的时候需要重点考量，针对外卖、打车等场景简单随机无法保证流量的同质性和独立性，需要更复杂的流量框架或者分流算法 流量框架的选择 AB实验方法由Google引入互联网后，实验方法成为各大公司标配。实验的本质对随机打散的同质、独立流量施加控制。按照流量生态的差异大概沉淀出以下的流量框架 重叠流量框架，基于层域进行流量管理，被大多数互联网公司采样，可以参考Google论文 Overlapping Experiment Infrastructure: more,better,faster experimentation 重叠实验框架：更多更好更快的做实验 ，在实验配置的时候进行参数的冲突检测。 基于约束的流量框架，通常适合双边、多边业务形态的公司。由实验者制定约束，平台根据实验者制定的约束，确保无法避免潜在交互影响的实验没有同时曝光给用户。如微软、Uber等公司，实验平台都集成了检测交互作用的自动化系统，以避免实验间潜在交互影响。 实践案例 市场上实验平台的设计都要在充分理解业务流量的基础上，解决流量分配随机、同质、独立要求，具体的实现路径就是重叠流量框架（在实验的时候再进行参数冲突控制）、基于约束的流量框架（本质是一种提前进行实验参数冲突控制的策略） Google重叠流量框架以及四种实现 不同公司按照业务的复杂度，可以选择figure a-d四种不同复杂度的流量框架实现。 美团AB实验白皮书 白皮书 中介绍了美团流量的特点、流量框架的设计，以及提供的一系列实验分析工具，整体上确保实验平台的科学可信。 滴滴Adaptive分流 参考：https://blog.51cto.com/u_15060460/2673616 随机分流的过程中进行用户指标的平衡，增强流量的同质性 分流单元定义和分流方法 流量生态和流量框架的结合包括分流单元的定义和分流方法的选择。 分流单元 通常的分流单元可以包括以下： user_id 适用大部分互联网场景，包括device_id、cookie_id、uuid等类似标识 request_id 适用商业化场景 poi、Geohash等位置标识，适用O2O等场景 分流方法 hash分流，随机分流并且分流结果固定，通常在重叠流量框架中通过层id等加盐确保层间正交性、时间戳更新进行流量再打散等 轮询方法，在用户属性（国家、设备等）或者先验指标（例如ecpm）方差较大情况下通过轮询方法保证各组流量的同质性，通过随机进行轮询顺序的打散，通过cache确保流量进组的稳定性 以上总结了实践中对流量生态理解、流量框架选择、以及具体流量框架实现中的一些考量。 关键要解决 流量的随机性、独立性、同质性 流量分配和参数控制中避免冲突 从而确保流量框架的可信性、实验结果的科学置信。

典型的AB实验平台建设功能列表，可以参考： 需求大类具体需求需求分类交付物优先级相关人备注业务理解流量控制文档调研报告P0业务团队AB产品&后端业务服务端流量控制&实验方法：正交，互斥，缓存（加锁），继承，条件筛选实验配置文档接口规范(AB后端)P0AB产品&后端业务服务端配置文件格式和schema实验配置配置管理功能配置后端(AB后端)P0AB产品&后端配置管理员按照配置协议进行配置管理配置分发功能TRD+分流服务P0AB产品&后端业务服务端AB后端提供分流接口、分流算法、缓存加锁(按需)业务服务端接入、返回客户端概念抽象文档PRD+系统功能P1AB产品项目，层，实验，分组，参数，条件等实验管理实验列表功能PRD+系统功能P2AB产研实验列表以及实验管理功能（启停、扩缩、分组管理、参数管理、版本管理、审批、通知等）创建实验功能PRD+系统功能P2AB产研实验设计模板 ，包括 设计 目标 条件 埋点 指标 白名单 冲突检测等权限管理功能PRD+系统功能P2AB产研鉴权和数据隔离参数管理功能PRD+系统功能P3AB产研业务产研实验参数体系，提高实验效率，构建实验知识库最小样本量功能PRD+系统功能P3AB产研分析师/DS依赖指标体系和实验分析方法支持流量检验功能PRD+系统功能P3AB产研分析师/DS依赖指标体系和实验分析方法支持流量监控功能PRD+系统功能P2AB产研数仓进量监控、进量控制等数据链路埋点文档埋点规范P0客户端分析师数仓埋点确认以支持实验分析数据同步数据同步任务P1数仓分析师确保埋点事实数据落库、实验跟踪数据落库，支持实验分析数据建模数据数据资产P0数仓分析师分层的数据资产ods dwd dws ads dim指标计算指标计算数据计算任务P1AB产研数仓预计算vs实时计算指标定义功能PRD+系统功能P3AB产研数仓分析师分析师对口径负责实验分析实验看板功能PRD+系统功能P0AB产研分析师数仓基础看板支持实验分析多维分析功能PRD+系统功能P3AB产研分析师数仓支持多维分析（指标和数据体系的迭代增强）置信分析功能PRD+系统功能P3AB产研分析师/DS数仓置信区间、P-value或者胜出概率置信计算数据计算任务P3AB产研分析师/DS数仓数据资产确保支持统计量的计算

本文来源2022-09在Datafun上做的关于AB实验平台建设的分享。 为什么我们需要AB实验平台 A/B 实验应用作为论证的黄金方法，目前已经成为很多企业必然的选择，但是实际上如何在企业内部去建设实验平台，还充满了很多选择路径。目前的实验平台，包括在线实验的数量，已经成为衡量互联网公司体量、业务量以及用户量的一个隐藏指标。一些大厂的实验平台，同时在线实验数量超过 10000，可能每个月新建的实验数量都会大于 1000。 AB实验是论证的黄金方法 上图列出了一些数据分析方法，比如案例研究、观察研究、类实验、随机控制实验，以及统合分析，即结合随机实验和观察研究去做一些综合分析。 这几层分析方法中存在一些通用的因素，首先，样本是定向的样本还是随机的。第二个是有没有控制，比如最下面的案例研究是没有控制的，它可能针对一个群体做分析，而 AB 实验天然会分成对照组和实验组，是有控制的。最后一个就是实验结论是否可以复现，是否科学。这三个因素的不同导致了整个分析方法可信度的差异。从下往上，可信度逐步提升。AB 实验是分析成本最低的一个方法，可以通过工程化的方法来提效，通过 AB 产品化的方式来降低使用门槛。 AB 实验有三个主要的特点： 先验性，用事实说话，可以通过小流量低成本来得到一些结论。 科学性，实验分析时会用到假设检验的方法，相对来说是比较科学的。 推断性，通过随机流量控制可以排除混杂因素的干扰，聚焦到我们的控制变量和实验策略上。 当然AB实验也不是万能的，一些适用和不适用场景： 适用场景 产品迭代 用户运营 算法优化 营销和用户增长 商业化 不适用场景 战略或者重大决策 缺少数据或者样本的情况 商业、道德、技术的限制 AB实验的定义 AB 实验源于假设检验。我们在线上流量中取出一小部分（较低风险），完全随机地分给原策略A和新策略B（排除干扰），再结合一定的统计方法，得到对于两种策略相对效果的准确估计（量化结果）。 这一套基于小样本的实验方法同时满足了低风险，抗干扰和量化结果的要求，因此不论在互联网产品研发还是科学研究中，都被广泛使用。 真实的业务场景，例如客户端交互实验、搜广推策略实验等场景承载大量的DAU，每天大量新的功能、算法及其他等待上线，一方面业务人员无法承担其中任何一个错误特性直接影响用户体验、商业收入的严重后果，另一方面业务人员又希望能够分离并量化每个特性的影响。 因此，我们需要设计并坚持使用一套数据驱动的方法，使得业务人员可以以较小的风险对新feature进行评估，积极试错积累经验；并且我们设计的该方法有能力排除其他因素（比如同时开发的其他feature以及时间因素等）的干扰；最后，除了‘好’或者‘不好’，我们希望这个方法最好也能够给出 定量的结果。 为了解决上述问题，普遍使用的方法论是小流量随机实验，也就是我们常说的AB实验。 AB实验包括三个核心要素：流量、干预、效果，其中流量满足： 同质性：控制组和实验组的样本同质（消除偏差） 独立性：符合样本独立稳定假设（SUTVA）即样本之间不应该有干扰 可控性：通过随机分流消除所有已知未知因素的影响，聚焦当前干预方案 同时实验设计三原则（由统计学家费希尔提出）：区组，重复，随机。 实验平台的选择 整个 A/B 平台的建设，主要有两个思路，第一个就是直接采购第三方平台；另外一个就是自建平台。 国内目前比较好的第三方产品，比如火山引擎，无论是产品 feature 还是整个应用情况都比较好，因为它是基于自己内部的最佳实践。另外腾讯也开放了第三方平台。热云、神策数据也提供了 SaaS 的实验平台。国外的厂商也比较多，像 VWO 实验测试平台、谷歌的 Optimize、源自Meta的Statsig以及 Optimizely 等等，都是一些比较有竞争力的产品。 第三方平台通常适用于用户体量比较小，数据跟分析的基建还相对比较薄弱的公司。通过第三方平台的使用，提升公司内部数据以及分析的认知。 用户行为分析和 A/B 实验是紧密联系的，因为它们都是基于用户的行为，让用户来告诉我们答案，包括底层的一些分析引擎、存储引擎的等基建也都是可以复用的，这也是火山引擎的 A/B 测试和分析能力，和用户行为分析能力都是紧密耦合在一起的原因。 对于公司自建平台，国内主流的一些互联网厂商也都有很好的实验平台，比如滴滴、美团、阿里、网易、新浪微博等，甚至有一些公司内部有多个实验平台。国外的微软、谷歌也都有非常有特色的实验平台。这些公司也都是用户体量比较大，实验场景多，数据分析基础比较强的公司。在自建实验平台的时候，如果公司业务体量大的话，不同的业务可能结合自身的需求都建过一些实验平台了，这时候还要推动平台从 N 到 1 的建设。在新建平台时，就要考虑业界的最佳实践，同时还要考虑业务方的独特诉求。这样在公司内部推行实验平台的时候才能顺畅，并且最终可能变成全公司通用的实验平台。 实验平台案例及效果 业界一些实验平台建设案例和应用效果： ...