谈谈A/B测试

加入Booking.com已经有三个多月了,这家公司对于A/B测试可以说是做到了极致。每一个功能都需要去做A/B测试,只有达到这个功能设计时预期的指标才能上线(FULL ON)。重要的重构或者技术改造,复杂的bugs修复,也需要实验来验证没有副作用才能上线。

对于很多国内的公司来讲,可能听起来完全不符合快速响应,拥抱变化的要求。我们iOS团队的迭代周期为两周,意味着每两周就有一个新版本App Store上线。每个版本都包含很多实验改进。这种迭代速度,我想很多公司都难以达到。

我们经常会看到很多软件突然功能和界面大改,用户骂声一片。一些软件加入了新功能,但是后来发现只有很少的人使用,但又不敢不顾现有的使用者移除这个功能,结果最后软件越来越庞大,也给开发人员带来很大的维护成本。又如一些软件删除了某种功能,但用户反反响不好,不得已又加回了该功能。这些问题,在A/B测试的世界里都可以解决。

A/B测试的假设很重要,每一个实验来源于对用户行为或者需求的分析进而产生的假设。每个假设需要有明确的最终衡量实验成功与否的指标。常用的指标有net conversion(消费人数/访客数),net comission(净收入,可以平均到每个消费的用户,或者每个访问的用户),cancellers’ rate(取消订单的人数/访客数)。但是可以选用的指标不限于此,每个实验选用什么指标因实验而异。

这就要求每一个我们设计的功能,目的要明确,而且可以通过指标来测量。

这样做有三个明显的好处。

第一,明确了这个功能的目的,要解决的问题。发现问题和解决问题同样重要。这么做避免了花费大量时间之后,才发现解决方案和问题根本不匹配,或者问题根本不存在。

第二,作为开发者,产品经理或者设计师,我们都对自己的设计,自己的成果有很主观的偏爱。通过假设中的指标来衡量更加客观。如果指标之外的某些数据变好或者变差,我们需要去分析原因。假设中的指标中性但是其他指标突出,我们不应该把实验FULL ON,我们要去分析,修正指标,重新实验。我们的目的是通过A/B测试来了解用户,进而让我们的产品获得成功,而不是为了让实验FULL ON。

第三,如果一个问题无法衡量,我们需要去思考,是不是我们没有找到合适的角度来衡量。如果不是,对于一个无法衡量的功能,我们是否真的明确了要解决的问题?还是我们在浪费时间试图解决一个无解的问题(心理学称gravity problems)?如果我们做一个没有办法衡量的实验,我们能从中学到什么,以后如何改进?思考了这些问题以后,绝大多数无法来衡量的功能都是产品不需要的。如果是因为技术原因无法衡量,应该先保障技术基础再来实验,这样确保每个实验都能从中学习。

A/B测试的每一个实验的改变,都最好是原子的(不可再拆分的),这样我们可以确定某一个改变产生的影响,没有其他的噪音。如果一个大的改动,应该把它分解,一步一步来实验。听起来很耗时,但是可以保证一个大的改动中每个最终给用户的细节,都是经过验证,甚至不同尝试后,相对更好的体验。

另一个A/B测试常见的问题是对于结果中性的实验要不要FULL ON。这个问题要根据具体的例子来分析。如果是未来roadmap中的一步,FULL ON它。如果带来了技术负债或者保留着个实验会增加以后维护的成本,停掉它。如果没有用户行为的改变,也不会带来任何商业价值,那舍弃掉。

有些时候,对于实验结果数据,每个人都有不同的解读,这种时候,可以通过接下来后续跟进的follow up实验来验证,帮助解读。

P.S. A/B测试并不影响0–1的过程。设计的不断迭代,通过用户反馈的不断完善,0–1的过程本身就和A/B测试一样,包含着实验和客观对待事实的精神。


如果喜爱Apple平台开发,clean code以及应用框架,开发者编程之外所需的soft skills感兴趣的话,可以关注这个微信公众号,或者Twitter上follow我@guanshanliu。

如果你在上海,可以参加CocoaHeads Shanghai我们每月的Apple开发者活动,更多信息见 https://meetup.com/CocoaHeads-Shanghai

Like what you read? Give Guanshan Liu a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.