背景
随着公司业务的发展，慢慢已经从做新功能，变成优化功能，至于怎么优化功能，精细化运营已经很难直观判断。尤其作为裂变增长组的PM，对公司现有砍价、助力、签到等工具的优化，尤其需要引入AB Test这种科学的评估工具
所以第一时间收到要从0搭建一个AB Test系统以后，自己就很认真的投入进去，从需求调研到竞品分析，再到系统设计和功能设计，再到具体的产品设计、后台原型和需求文档，以及最后的首期AB Test上线并输出结果
发现更换3个字的按钮文案后，取得了一个远超出预期的结果，按钮点击率从21%直接提升到39%。以下是如何从零搭建一个AB Test系统的回顾和复盘
首先什么是AB Test
简单来说就是归属于互联网行业的对照实现，即通过设置实验组和对照组，参与单一变量法来评估两个组别的差距。自从2000年谷歌将其应用于互联网产品以来，逐步成为互联网精细化运营的必备方法
简单来说，就是就是在产品正式全面迭代之前，为同一个目标制定不少于两个的方案，将用户分流至对应方案内，在保证每组用户特征相同的前提下，根据用户的真实数据反馈，帮助产品决策
ABTest的具体介绍个人认为VWO的写的最好，参考：What Is A/B Testing?
AB Test 解决什么问题
对一个产品设计，已经能难直观判断是否真的是‘优化’，这个改变，可能是文案的优化、按钮的颜色、界面的布局或者功能的迭代，也可能是推荐算法。AB Test可以辅助设计者通过实际用户的使用反馈，来确定到底哪个方案更优
什么是一个好的AB测试：
有明确的测试目标，【立即参加】和【加入学习】哪个文案转化率更好
有清晰的衡量标准，订单转化率&按钮点击率
有精确的测试结果，如【立即参加】和【加入学习】，点击率在90%的置信区间内没有差别
作为一个PM，收到需求的第一步永远是调研
作为一个PM，收到要搭建一个AB Test系统的时候，最先想到要做的就是调研，既包括竞品调研（第三方AB Test供应商），也包括需求调研（需求场景、目标用户）
竞品调研
主要调研了3个AB Test解决方案供应商，2个国内，1个国外，分别是吆喝科技、Testing和VWO，大概了解了AB Test的系统构成和功能设计，这部分可以直接搜索对应的公司官网，体验DEMO。不过很遗憾，因为公司业务的去中心化的特点，无法直接使用一些成熟的第三方服务
需求调研
目标用户
毫无疑问，会用到AB Test的都是公司内部用户，对于笔者所在的电商公司，会有PM、运营、研发（作者在第一阶段忽略了研发，但研发也确实是AB Test的使用者之一）
接下来就到了具体向用户收集需求的阶段，作者在需求收集阶段做了两件事情。
一是召集了一次用户访谈，主要为PM、运营、设计的组长，简单收集了大家对AB Test的需求，主要想用来测什么，有了初步的调研结果
二是在公司Wiki上建了一个AB Test项目，发给了上面说的所有潜在用户，收集用户需求。主要内容一是简单介绍了AB Test，二是设计了一个表格邀请所有潜在用户填写，主要涉及这几个项目，并且举了自己手上产品砍价文案的例子
发给同事以后，收到了很多反馈，比如
运营同学想测试banner高度是否影响的点击率
设计同学想测试不同分享按钮的颜色能不能提升点击率
大数据同学想测试不同推荐算法的点击率啊
等等等等
这时候，就有了明确的目标用户和使用场景，结合之前对竞品的分析，大概知道了涉及哪些模块和功能，就进入了下一个需求&功能梳理阶段
AB Test需求梳理
作者在需求梳理阶段，分成了主要三个方面，一是希望测试的功能（即测试的范围），二是想通过什么数据来评估实验差异，三是有没有具体的分流&分流需求
抽象后的使用场景
结合分层情况，从简单到复杂，将AB测试的范围分成了以下几个层次，从左到右为从实现难度从容易到难，测试范围从小到大，划分成了4个层次和微信生态内的测试，具体如下
表现层，主要指一些UI、文案、颜色层面，比如按钮文案不同，界面布局不同、某些小元素的颜色、样式不同等，相对来说是最简单的层次，有AB Test系统以后，仅需要少量的前端研发就能支持的实验
信息层，主要某些信息是否展示，如销量、倒计时等，也相对比较简单
功能层，指对单个功能的修改迭代（前面两个层次都不涉及对功能的修改），会对用户使用流程等造成影响。
如将之前注册流程从3步改成2步，或迭代电商下单流程等。可以用于功能的灰度发布。这里要指出的是研发会在这个层面有相对较多的测试需求，如测试不同SDK的崩溃率，不同第三方服务的线上响应速度等，做系统设计的时候一定要记得收集研发的需求
版本层，可以理解成为对功能的大幅度修改，可以使用AB Test作为灰度发布的工具，如首页大的改版，商详页的重大改版等
另外有一个专属于微信的，就是微信推送（模板消息的文案、推送策略）和分享的（文案、配图），公司主做微信社交电商业务，也加入了考虑范围内
于是就有了上方这个图，之后就到了整个功能的业务流程设计
衡量指标
顺便收集了需要通过什么指标来衡量AB Test时不同版本的差异，梳理后主要有以下几个。也需要在系统设计初期和研发沟通，确认能收集到对应数据
点击通过率 Click-through Rate (CTR)
转化率 Conversion Rate (CR)
更新率 Renewal Rate
跳出率 Bounce Rate
平均保留率 Average Retention
平均使用量（应用，手机网站、网页，App屏幕或游戏场景上的时间），Mean Usage (Time on app, mobile web, mobile webpage, an app screen or game scene)
平均每用户事务数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系统的主要需求分析和设计阶段就完成了
具体产品设计
之后就进入具体的产品设计，简单来说就是结合竞品‘抄’了，这部分没有太多值得分享的点，关键的事项都已经在之前做了，不外乎做原型，交互设计，写文档之类，不再赘述
上线后的结果
首期上线以后，取得了还算不错的效果，修改一个三个字的文案，用户点击进入商详的点击率直接从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在那个阶段应该更加投入到能带来指数型或者倍数增长的方式里去
