思考 | 关于AB实验的实战应用

前两年随着用户增长的兴起，AB实验作为重要的增长工具在行业里显得时髦起来，但目前来说AB实验已经算是行业里的基础设施，大部分公司都有在用，其原理也谈不上复杂。

也就不免会有知识的诅咒，知道了就会有不就是 xxx 的不屑感。

但随着我进行过大量实验后的感觉是，将理论应用于实践并取得成绩，远比知道理论难得多，也有价值的多。

所以这次我更多的篇幅是——围绕实战过程中的会遇到的问题和能提高些取得收益的可能性来讲。

一、AB实验是什么

对同一个问题，有≥2套解决方案（小到一个元素，大到一套方案保证变量的唯一性即可），对同一组人群（样本量足够）进行随机分组；在同一时间维度，进行实验组和对照组的实验，通过少量且相同的衡量指标，衡量哪套解决方案的结果表现更好，并采用。

比如以下是美团的搜索结果页实验：

问题：哪种结果页的商品展现形式更能提高用户筛选的效率，提高用户下单的转化率。

解决方案：3套搜索结果页的商品表现形式。

人群：搜索结果页的用户（注：这里最好使用结果页这层的用户，也算是常见的问题，有些同学习惯直接使用大盘的用户分组，但如果搜索模块渗透率不高的话，局部数据收益在大盘中表现不敏感，可能就直接波动掉了。）

少量且相同的衡量指标：页面ctr、点击转化率、下单转化率、人均成交额（注：一般app只有一个北极星指标，但也会监控少量其他的关键性指标，比如视频app除了留存还会监控pt和人均vv，如果有广告的话也会监控收入的相关指标；其中常见的问题是指标过多 啥都想要 ，还会让有的人钻漏洞，所有实验都能找到一个指标来说取得了正向的结果。）

二、AB实验能解决什么问题

有些团队在使用一段时间AB实验后，可能会出现很多质疑声，比如说为什么要花这么多资源来做AB实验呢？尤其是开发和测试同学，因为从他们的视角来看这些都是工作量啊，所以要清楚的认识到AB实验到底能解决什么问题，并与团队达成共识。

1）方案争议较大时，减少低效争议带来的内耗，降低高层拍板带来唯上的低效文化，提高决策效率。

常见的现象是老板和产品之间，产品和交互、视觉、开发之间，对于某些方案无法达成一致，再加上一些专业性权威性等面子问题，需要消耗大量时间和心力来撕逼，互相妥协后还可能留下了合作关系的不和谐；如果总是让老板来拍板的话，本质是一种决策的官僚化。

这样的情况做个实验测测就好了。虽然坦率的说，很多皮毛的争议都然并卵，在互联网1.0时代还感觉像是个大事，在互联网2.0时代，数据量化下可能大都差异不大。

2）有多组解决方案时，提高获取认知效率，提高产品进化效率。

这个情况下AB实验是很有用的，互联网产品相比传统实体产品的很大优势来自于迭代速度快，修改调整的成本低。

但即便如此，从发应用市场到数据回收也需要不短的时间。

如果我有对一个问题有几种解决方案，串行着测试的话，拿到结论可能要花一两个月的时间；而使用实验的话，在一个数据周期里就能拿到实验结果，获取认知的效率大大提升了。

3）多团队在进攻同一个指标，或同期上线多个策略时，明确收益点和负向点，避免收益淹没、认知偏差、侥幸心理和收益分配矛盾。

这个问题应该也是普遍存在的。

同时上多个策略的时候，数据好的话，美滋滋完大家开始抢功劳，都觉得是自己的策略带来的。

数据躺平的话，感觉大家折腾一顿也没啥卵用，还会甩锅是其他人的策略拉平了自己的收益。

最惨的时候是数据差的时候，先不说互相甩锅了，老板发脾气了解是怎么搞跌的数据，归因到底是哪个策略出问题的时候，可能大家都一脸懵逼，然后归因不出来的话大概率是要回滚的，一个版本的时间就废掉了。

所以有不确定的大动作时，尽量用实验安排上，成功或失败都是明明白白的。

4）按日期的数据看收益，但波动较大时，AB实验数据衡量更敏感，明确是否有收益，避免数据负向归因时成本较高。

大部分产品的关键指标每天都会有小幅的波动，遇到特殊时间的话波动会加大，如果你做的策略直接赶上了，可能会回收不到笃定的收益，可能会直接版本回滚。

而AB实验在验证收益的时候表现更加直观和敏感。

5）实验机制更好的保证产品的简洁、必要和不臃肿，最糟糕的是以你做了多少功能来表达自己的苦劳，而不是为用户创造了多少价值。

实验机制保证了决策环节的存在，正向就全量，没收益就直接下线。

不然看到关键指标也没啥影响，下线功能还要再发一个需求，可能就逃避了决策环节把功能留在了产品上，最后产品越来越臃肿，你可能还沉浸在自己的苦劳里自我感动。

6）业务处于确定性高的精细化运营阶段，数据的增长大都来自大量的线性优化提升，而不是大的激进的策略。

一般发展期的业务会有很多收益显著的事情可做，即便没有AB实验，也可以做到数据变化显著。

但业务到了成熟期之后，这样的事就少了很多，你只能做大量的线性优化，一定周期里堆出来比较显著的收益。

7）错误的认知会导致团队的精力、时间和资源走向错误方向，但实验数据永远不会骗人。

有些负责人对业务有扭曲力的认知，可能自我说服的偏执，做出损失很大的错误决策，但可以通过AB实验做一些辅助认知，因为数据永远不会骗人。

尊重实验结果 尊重数据，是要坚持的事情。

三、AB实验的类型

一般实验分为正交实验和互斥实验两类，另外精细化运营的时候还会被经常用到的是圈层实验，具体如下：

互斥实验：指的是实验与实验共用一层流量，互相不产生交叉，类似实验1中3个实验组，实验3和实验4，共用一层流量。

正交实验：实验与实验分别用不同层的流量，不产生互相的干扰，即便另一层也在做实验，但那一层流量到了这一层也是均匀分配的，不影响这一层实验变量的唯一性。

像头条 快手这些大app能同时进行大量的实验，本质是使用了正交实验。

这里划分层的方式很有趣，也是判断正交实验使用是否灵活的一种方法。

有的人按照一个功能来分为一层，这样的话能做的实验数量会很有限。

其实可以做到更灵活，一个功能可以分一层，一个页面也可以分一层，一个也元素可以分一层，甚至一个元素的颜色、形状、大小都可以分成一层。

这样的话大量的实验得以并行，没有很多约束。

圈层实验：通常受众比较大的增长点做完了，更多的会去做用户的精细化运营，满足某些群体没有被很好满足到的需求，以带来业务的增长，圈层实验在这个时候就可以起到很好的帮助。

• 比如多日无播放行为的用户做一个圈层，做做引导或者Push；
• 比如下载页无内容的用户做一个圈层，做做冷启时优质内容的推荐；
• 比如某一兴趣标签的用户做一个圈层，提供更匹配的服务等等。

四、AB实验实战中常见的问题

有了上面对AB实验的认知后，其实在实战中还会遇到很多巨坑的问题，一个坑没避过，实验的宝贵时间和投入的资源就被浪费了，还有可能得出误导性的结论。

1）用户串组问题，要保证用户id的唯一性。

这个问题比较坑，在新用户实验可能会遇到。

如果有些公司的安卓手机在获取设备号前后，或者注册前后使用不同的id，会导致体验完实验变量的用户被二次分组，再次流入到其他组中，最终数据结果不可用。

2）用户出组问题，要保证实验对象的不变性。

这个问题在圈层实验中可能会遇到。

圈层实验要在需求里写清楚用户在AB实验中不会出组。

比如通过兴趣标签或者用户行为进行的用户圈层，当他的兴趣标签或者行为产生了变化，实验结束前用户身上的实验id不能消失，不然用户会从实验组中退出；不同组退出用户的比率和成分不一样，也会导致数据的结果不可用。

3）交叉实验没有策略互相覆盖的问题，要保证策略的执行。

一般不同团队在做衔接实验的时候，可能会遇到这种问题。

比如做新用户的兴趣选择实验，以便用户进入产品后看到更匹配的内容推荐。

但如果这个时候推荐层本身也在做实验，没有做好对接的话，可能会导致兴趣选择层的几个实验组用户都流入了推荐层的某一组中；而这个实验的结果是由兴趣选择和推荐一起作用才有可能产生的，不然就拿不到预期的结果，得出失败的结论。

4）交叉认知不足，导致无法并行大量实验问题，不要学其形无其神。

这个我在上一部分已经讲过，这里不做再次讲解。

5）不会看数据的问题，没从直接影响指标（分层、分群、局部）到大盘指标。

一般做实验的时候都是用变量去影响一个直接指标或者局部指标，然后通过这个指标去撬动大盘的指标，而不是直接做大盘指标的。

• 比如说做推荐模块的实验，一定是先提升了推荐模块的数据，再带动了大盘的增长；
• 比如说做播放环节的实验，一定是先提升了播放环节的体验，才带动了大盘的数据提升。

甚至有些实验虽然提高了局部效率，但本身不能撬动大盘，但其本身确是有价值的。

比如说你给视频产品提供了调整播放速度的功能或者学舞蹈时的镜像功能，他可能不会对播放时长留存等数据带来直接的提升，但他本身是有价值的；你可以看他的使用率，可以定性获取用户需要的必要性，也可以问问自己的常识。

而有些同学做实验会直接拉大盘指标来看数据效果，可能会出现这种情况，有局部收益的需求被草率下掉，有体验价值的被直接干掉了。

还可能出现的问题是，这个实验没有成功的原因是什么，哪里不符合预期，是否还有可继续的空间，都无从得知，因为你没看过程的局部的数据嘛。

6）实验结果数据的置信度

一般实验结论要经过置信度检验环节，不然数据结论不可信。

部分同学，应该是少量的吧，可能是面子问题，正向5天 负向2天也认为实验是正向的，或者提升很微弱其实并不可置信，也说是实验是正向的。

唉，其实意思不大。

但从维持团队的积极性来看，也可以理解，毕竟没有大的伤害；但如果要用来作为支持开展大项目的论据的时候，一定要慎重地进行置信度检验。

7）实验是验证你基于用户和规律洞察后的假设，不要用实验代替假设。

这个问题应该是普遍存在的，大概率会造成产研之间的矛盾，也会伤害到产品同学自身的发展。

因为实验可以快速验证假设，也就大大降低了决策的成本，确定不了的方案就直接上实验测一下。

但长此以往也会削弱产品经理的深度思考能力，用实验代替自己的思考。

甚至没有用户洞察、没有行业分析、没有高质量的假设，很浅的想到或者找到一堆方案就往实验上扑，最终会为了实验而实验。

而这些低质量的实验大概率成功率也很低，团队疲于奔命又不认可的搞了一大顿之后，信心和积极性会很受打击，你离离开也就不远了。

8）实验探索的坚韧性，很多人会通过简单的尝试, 得出对这个世界太多的否定结论。

有的同学做实验，上线后数据好了就全量，数据负向就下线，然后这个实验就结束了。

但其实很多大些颗粒的事情，做成是没有那么顺利的。

即便数据是负向的，也有很多可研究的可能性。

• 可能需求是对的，你产品设计的表意有问题，用户没看懂；
• 可能用户需要一段时间的培养，不是直接能产生效果的变量；
• 可能需求是不对的，但是你发现了新的进攻点；

甚至可能是实验执行出问题了，或者数据出错了，要修正一下。

做成一个实验是很难的，要有耐性不断探索认知，才可能发现稀稀拉拉的新机会。

五、AB实验的边界

以上讲了很多AB实验的Why和How，但同时也要知道AB实验只是一个工具，不是万能的，只能解决有限的问题，也有很多问题是解决不了的。

1）战略性的 需要长期经营投入的项目不能通过实验来验证。

有些老板喜欢什么事情都上个实验看看效果，其实暴露的是自己对战略的思考不深度 不笃定 没耐心。

2）分流后会形成新变量，会对实验效果产生影响的项目不能通过实验来验证。

一般单角色的产品路径比较适合做AB实验，比如注册登录、搜索、推荐等等。

但多角色交叉的产品环节有时就不适合做AB实验。

比如社交和社区中的一些功能，因为用户与用户之间会相互影响，不太可能我有你没有，强做的话大概率会产生很多客诉问题；还会产生的问题是，因为分流的比例让变量的体验也按比例有了折扣，所以不能得到正确的结论。

3）见效周期较长的项目，不建议通过实验来验证。

一般样式的变化，或者用户痛苦已久的问题一上线，很快就可以看到直观的效果。

但也有些功能需要用户慢慢培养习惯的，尤其当你的目标用户是下沉市场的群体或者中老年群体的时候。

即便做的话，也要足够的耐心来等待。

4）确定性较高的、体验性的优化不需要通过实验来验证。

这个在上面部分也有提到，实验的目的是为了验证你的假设，或者方案很不确定的情况下提高你的决策效率。

但如果你已经很笃定了，或者确实是一些很体验性的优化，就真不需要再做实验了，维护多版本的功能，还是会增加不少开发和测试的工作量的。

六、结束

OK，以上就是我个人在长期的实验过程中遇到的问题和总结的思考。

不一定完全正确，在读的同学可以用审视的态度来看，独立思考最重要，有问题和建议也欢迎反馈给我。

另外，不能指导行动和作用于实践并达到目的的理论没有意义，希望能在你的实践过程中有所帮助。

作者：白鱼，微信公众号：夜里一支烟

本文作者 @白鱼

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！