abtest(复盘如何从01搭建AB Test系统)

本文笔者将对如何搭建一个AB test系统做完整的回顾以及复盘。文章讲述内容包括:搭建AB text 过程中如何进行调研?如何将测试分层,制定衡量指标?以及,具体的业务流程和功能设计如何? 随...

本文笔者将对如何搭建一个AB test系统做完整的回顾以及复盘。文章讲述内容包括:搭建AB text 过程中如何进行调研?如何将测试分层,制定衡量指标?以及,具体的业务流程和功能设计如何?

复盘:如何从0~1搭建AB Test系统

随着公司业务的发展,慢慢已经从做新功能,变成优化功能,至于怎么优化功能,精细化运营已经很难直观判断。尤其作为裂变增长组的PM,对公司现有砍价、助力、签到等工具的优化,尤其需要引入AB Test这种科学的评估工具。

所以,第一时间收到要从0搭建一个AB Test系统以后,自己就很认真的投入进去。从需求调研到竞品分析,再到系统设计和功能设计,再到具体的产品设计、后台原型和需求文档,以及最后的首期AB Test上线并输出结果。

发现更换3个字的按钮文案后,取得了一个远超出预期的结果,按钮点击率从21%直接提升到39%。

以下是如何从零搭建一个AB Test系统的回顾和复盘:

一、AB Test1. 什么是AB Test?

简单来说,就是归属于互联网行业的对照实现——即通过设置实验组和对照组,参与单一变量法来评估两个组别的差距。自从2000年谷歌将其应用于互联网产品以来,逐步成为互联网精细化运营的必备方法。

简单来说,就是就是在产品正式全面迭代之前,为同一个目标制定不少于两个的方案,将用户分流至对应方案内,在保证每组用户特征相同的前提下,根据用户的真实数据反馈,帮助产品决策。

复盘:如何从0~1搭建AB Test系统

ABTest的具体介绍个人认为VWO的写的最好,参考:What Is A/B Testing?

2. AB Test 解决什么问题?

对一个产品设计,已经能难直观判断是否真的是“优化”,这个改变,可能是文案的优化、按钮的颜色、界面的布局或者功能的迭代,也可能是推荐算法。

AB Test可以辅助设计者通过实际用户的使用反馈,来确定到底哪个方案更优。

复盘:如何从0~1搭建AB Test系统3. 什么是一个好的AB测试?有明确的测试目标:【立即参加】和【加入学习】哪个文案转化率更好?有清晰的衡量标准:订单转化率&按钮点击率。有精确的测试结果:如【立即参加】和【加入学习】,点击率在90%的置信区间内没有差别?二、调研

作为一个PM,收到要搭建一个AB Test系统的时候,最先想到要做的就是调研,既包括竞品调研(第三方AB Test供应商),也包括需求调研(需求场景、目标用户)。

1. 竞品调研

主要调研了3个AB Test解决方案供应商,2个国内,1个国外,分别是:吆喝科技、Testing和VWO。

大概了解了AB Test的系统构成和功能设计,这部分可以直接搜索对应的公司官网,体验DEMO。不过很遗憾,因为公司业务的去中心化的特点,无法直接使用一些成熟的第三方服务。

2. 需求调研

目标用户:

毫无疑问,会用到AB Test的都是公司内部用户,对于笔者所在的电商公司,会有PM、运营、研发(作者在第一阶段忽略了研发,但研发也确实是AB Test的使用者之一)。

接下来就到了具体向用户收集需求的阶段,作者在需求收集阶段做了两件事情:

召集了一次用户访谈,主要为PM、运营、设计的组长,简单收集了大家对AB Test的需求,主要想用来测什么,有了初步的调研结果。在公司Wiki上建了一个AB Test项目,发给了上面说的所有潜在用户,收集用户需求。主要内容一是简单介绍了AB Test,二是设计了一个表格邀请所有潜在用户填写,主要涉及这几个项目,并且举了自己手上产品砍价文案的例子。复盘:如何从0~1搭建AB Test系统

发给同事以后,收到了很多反馈,比如:

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

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

AB Test需求梳理:

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

三、抽象后的使用场景

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

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

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

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

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

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

复盘:如何从0~1搭建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业务流程和功能设计

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

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

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

复盘:如何从0~1搭建AB Test系统六、完成系统设计

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

复盘:如何从0~1搭建AB Test系统七、一期功能设计(删掉所有非必要的)

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

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

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

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

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

1. 具体产品设计

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

2. 上线后的结果

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

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

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

复盘:如何从0~1搭建AB Test系统

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

一些复盘的Tips1. 是否需要一个专门的运营后台来管理实验?

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

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

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

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

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

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

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

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

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

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

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

题图来自Unsplash,基于 CC0 协议

  • 发表于 2022-10-30 15:10:19
  • 阅读 ( 185 )
  • 分类:科技

0 条评论

请先 登录 后评论
陈超
陈超

480 篇文章

你可能感兴趣的文章

相关问题