发给同事以后，收到了很多反馈，比如：

• 运营同学想测试：banner高度是否影响的点击率？
• 设计同学想测试：不同分享按钮的颜色能不能提升点击率？
• 大数据同学想测试：不同推荐算法的点击率啊？
• ……

这时候，就有了明确的目标用户和使用场景，结合之前对竞品的分析，大概知道了涉及哪些模块和功能，就进入了下一个需求&功能梳理阶段。

AB Test需求梳理：

作者在需求梳理阶段，分成了主要三个方面：一是希望测试的功能（即测试的范围），二是想通过什么数据来评估实验差异，三是有没有具体的分流&分流需求。

三、抽象后的使用场景

结合分层情况，从简单到复杂，将AB测试的范围分成了以下几个层次，从左到右为从实现难度从容易到难，测试范围从小到大，划分成了4个层次和微信生态内的测试，具体如下：

1. 表现层：主要指一些UI、文案、颜色层面，比如：按钮文案不同，界面布局不同、某些小元素的颜色、样式不同等，相对来说是最简单的层次，有AB Test系统以后，仅需要少量的前端研发就能支持的实验。
2. 信息层：主要某些信息是否展示，如销量、倒计时等，也相对比较简单。
3. 功能层：指对单个功能的修改迭代（前面两个层次都不涉及对功能的修改），会对用户使用流程等造成影响。

如将之前注册流程从3步改成2步，或迭代电商下单流程等，可以用于功能的灰度发布。

这里要指出的是：研发会在这个层面有相对较多的测试需求，如测试不同SDK的崩溃率，不同第三方服务的线上响应速度等，做系统设计的时候一定要记得收集研发的需求。

版本层，可以理解成为对功能的大幅度修改，可以使用AB Test作为灰度发布的工具，如：首页大的改版，商详页的重大改版等。

另外，有一个专属于微信的，就是微信推送（模板消息的文案、推送策略）和分享的（文案、配图），公司主做微信社交电商业务，也加入了考虑范围内。

于是就有了上方这个图，之后就到了整个功能的业务流程设计。

四、衡量指标

顺便收集了需要通过什么指标来衡量AB Test时不同版本的差异，梳理后主要有以下几个。也需要在系统设计初期和研发沟通，确认能收集到对应数据。

• 点击通过率 Click-through Rate (CTR)
• 转化率 Conversion Rate (CR)
• 更新率 Renewal Rate
• 跳出率 Bounce Rate
• 平均保留率 Average Retention
• 平均使用量（应用，手机网站、网页，App屏幕或游戏场景上的时间），
• 平均每用户事务数Average Transactions Per User
• 净推动者指数 Net Promoter Score (NPS)
• 客户满意率 Customer Satisfaction Rate
• 平均每用户收入 Average Revenue Per User (ARPU)
• 平均订单大小 Average Order Size

五、AB Test业务流程和功能设计

经过竞品的调研，结合公司实际情况，将业务流程拆分成四步，即：

1. 发起实验，主要是产品或运营。
2. 配置实验，即通过代码方式，实现AB版本的差异以及数据收集等。
3. 开始实验，即实验上线，包括了在实验过程中一些流量比例的管理，查看实时数据等。
4. 结束实验，即实验有结果以后，结束实验。

通过业务流程的分析，基本就能划分出需要哪些系统功能和运营后台功能了（其实第一个版本可以不需要运营后台，详细的分析在最后）。

六、完成系统设计

所有以上的合集，就是ABTest整体的业务流设计，之后就可以通过这个完整的系统设计，来指导具体的产品设计了。

七、一期功能设计（删掉所有非必要的）

AB Test这类相对复杂系统的搭建其实有两种形式：一种是业务驱动的搭建方式，比较像MVP，我们先能简单的测，再去迭代更多功能；另一种是系统架构的方式，一开始就搭建一个相对比较完善的系统功能。

大部分公司都会选择业务驱动的方式，自己就是如此。因此，这时候就需要确定首期到底AB Test什么？

最后，采用了业务驱动的搭建方式，并且确定了首期要上线的测试是什么——即验证在砍价活动的列表页，将主按钮从【去砍价】变成【免费拿】能否提升点击率，也就是最早提到的数据的实验。

因为系统设计阶段，基本搭建的是完整的AB Test系统需要的功能点，这时候需要做的就是确定一期功能点。删的方法也比较简单，就是把所有没有必要的功能都删掉。最后做到，如果没有这个功能，这个实验就做不下去。

最后和研发反复沟通以后，并且根据当前研发资源加了一些白名单、流量比例调整等，同事去掉了很多非必要功能，包括了版本分流、实时查看数据等（在上面的系统架构图中用虚线框住的部分）。那么，减掉这些以后，就是一期需要做的功能，这时候搭建AB Test系统的主要需求分析和设计阶段就完成了。

1. 具体产品设计

之后就进入具体的产品设计，简单来说就是结合竞品“抄”了，这部分没有太多值得分享的点。关键的事项都已经在之前做了，不外乎做原型，交互设计，写文档之类，不再赘述。

2. 上线后的结果

首期上线以后，取得了还算不错的效果，修改一个三个字的文案，用户点击进入商详的点击率直接从21%提升到了39%。

看到结论的时候也略显震惊，虽然笔者大概能猜到新文案会好一些。但远没有意料到简单的三个字会有这么大的变化，点击率几乎翻了一倍（可以在99.99%置信度里认为方案二更好）。

略有感慨：PM随时随刻要对未知的充满好奇和敬畏。

于是这就完成了AB Test系统从0~1的搭建！！

一些复盘的Tips

1. 是否需要一个专门的运营后台来管理实验？

初期不需要，如果是专注于做实验，得出结论，在一期的时候只需要有基础的系统功能就行（实现版本差异、分流、看数据这三步）。

因为在实际开发出运营后台之后，发现运营后台能做的事情非常有限，反倒花了很多的资源和精力，不过完成的系统架构分析一定是必不可少的。

2. 在收集实验场景的时候一定要问研发

自己在做的时候就是只收集了产品、运营、设计的需求，到后期的时候才发现研发也是AB Test的用户之一，在设计的时候也需要覆盖他们的使用场景。

3. 公司是否有必要自己做一个AB Test系统？

必要性不强，现在可用的这类第三方服务商很多，比如：GrowingIO、VWO等，他们提供了很完善的后台功能和SDK，只需要比较少的接入成本就能开始测试。

如果不是公司规模特别大，或者有限制无法接入第三方平台，建议都使用第三方服务。

4. 在什么阶段应该引入AB Test？

最常用到AB Test的就是增长部门，但什么时候应该引入AB Test，应该是在找到了一条相对比较可靠的增长路径之后，通过AB Test来优化这条路径。

因为AB Test所能带来的优化基本都是百分比型的，对还没有找到自己核心增长方式的业务来说，提升有限，反倒会花费很多资源。增长PM在那个阶段应该更加投入到能带来指数型或者倍数增长的方式里去。

本文由 @ 陌紫丰田 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议