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：全量切入。
文章初发于：https://liushaohan.com/2019/01/08/abtest怎么设计？/
作者：寒少归来兮
链接：https://www.jianshu.com/p/4a708ba8312f