ABTest难点在采集数据和统计数据。当然首先要确认测试的指标。

What is A/BTesting?

ABTest是什么？

在同一时期，同一个流程或页面，设计几种方案，上线随机分发，并行运行一段时间后收集数据，通过数据分析来验证方案的优劣。

ABTest是统计学上的一个命题，尽可能的追求单一变量。在中学化学实验中也多次应用该方法。

ABTest一般配合灰度发布，也可以单独服用。

灰度发布，更偏用户让少量的用户群先使用某些功能，看效果，再推向更多的用户群体，下文在怎么实施ABTest时会提到。

ABTest不是什么？

全量用户更新的功能，前后版本的对比数据，不论更新前后数据表现如何，都不是ABTest，因为有多干扰项。

同一时期同一版本流程、页面有太多不一样，那么ABTest也仅能做定性分析。

Why do we do it?

针对不同团队的资源和风格，在产品的某些阶段，当团队无法确定哪种方案是更好的，又想摒弃拍脑袋、一言堂的方式，那么用ABTest使数据来反馈是更优更科学的做法。

正确使用ABTest实验得出的结果，择其优避其害，推广到全集，更有利于我们做出正确的决策。

When to do it?

在产品初期，笔者以为，资源有限的情况下，可以使用线下（人肉）ABTest的方式进行。

几个方案的UI设计稿，在种子用户群（抽几波人）中进行访谈。

根据最终反馈的结果进行再次优化和抉择。

在产品成长期，有一定的用户量和相对固定的流程后，再次优化，可以采用线上的方式，对不同方案进行分发，然后采集数据。

Who do it?

其实产研营都可以去做，研发的ABTest今天不讲。说下产品和运营的ABTest。

产品和UI：色调风格，信息布局，页面信息优先级，流程跳转等方面。

运营：文案、时间点、触达方式、流量来源、分发渠道、广告等运营干预策略的对比。

How to do it?

指标确定

每次ABTest都有个核心目标，不论是注册量、转化率、成交量、点击量、点击率、停留时间、渠道效果、UI布局、用户体验、产品功能、算法效果等皆可。

方案设定

设计ABTest，不仅仅是不同方案进行验证，而是一个整体的解决方案。各行业各产品大家会有各自不同的方案，这里讲下应注意到的点：

• 参与测试的方案相差不要太大，不然即便有好的结果，也很难有所总结，形成知其然不知其所以然的局面

• 同一时间段，多个方案并行

• 亦可单一测试方案，与现有方案比较，但现有方案的检测样本要降权归并到测试方案，再进行比较

• 切入流量的方案

• 回滚容灾方案

• 数据统计方案

• 线上全量切换方案

采集数据方案-待完善

如何采集数据，取决于测试的指标所映射的元类型和依赖的载体。

元类型有：元素型，页面型，流程型。

载体：H5、web、小程序、App、浏览器插件等。

切入流量

采用灰度发布的方式。

• 参与测试的用户群体要随机，不要选择特定人群，要皆可代表全量用户

• 参与测试的用户要保证一定的活跃度，不然周期会拉长，结果很难收敛

• 测试期间，同一用户仅使用同一方案，切忌中途切换方案（即用户自选或者系统轮换）

• 测试时长，至少度过一到两个产品使用周期，不要结果收敛，立即停止

RUN

回滚容灾方案，通过API或在后台进行控制，可让参与测试的方案回滚到线上正式版本。尤其是App，需要应用市场审核，需要一定的时间。

方案执行时机：

• 出现BUG或不兼容
• 用户反馈极差

数据统计

数据统计，将多个渠道的数据，尽可能的保持同一纬度的进行运算对比。

根据对比结果，选出胜出方案。

统计的误区：

当数据表现不好时：从多维度进行分析，提防辛普森悖论导致结论与实际南辕北辙，从而错过更好的方案。

当数据表现好时：也有可能是页面过于新奇、交互比较炫酷等其他正向的原因导致用户停留时间，点击率等，需要再拉长测试时间，当用户习惯该方案后，再次查看数据。

测试合并

将参与测试的几种方案的产品，调节为胜出的方案，再看数据反馈。

正式发布

App:发布新的版本，将初始方案设定为测试中的胜出方案，若用户整体反馈或数据出现大面积下滑，则回滚。

web：全量切入。