ABTest怎么设计?

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怎么设计?/

你可能感兴趣的:(ABTest怎么设计?)