一款好的互联网产品的诞生,绝不是开发完、发布到上线就结束了。你必须得加入埋点跟踪,进行后续数据统计,不断维护,细心打磨,小心的版本迭代等。

为了给用户带来更好的体验,你希望在页面上新增一个功能,而该功能可以通过A、B两种(也可能多种)展示方案来呈现,但你们不确定哪种方案更能符合预期。此时,产品和设计便产生了分歧。

通常这种情况下,要么以老资格的产品或设计来决定使用哪种方案,或者当产品和设计(研发)争执不下时,干脆由上一级领导来决策。

但你知道,凡事无绝对。

鉴于复杂的环境和产品的差异,上面的决策或许并不能让产品发展更好,甚至可能带来相反的预期。因为互联网产品能否成功,并非是某个设计师或者领导说的算,关键的决策者还是在用户。如果选择的方案正好是用户所需的,那皆大欢喜。但倘若选择上线的方案并不受欢迎,那可能会导致用户的流失,对用户量大的站点,更是可能造成不小的损失!因此,选择A方案还是B方案,真的很难权衡。

那么,如何既保持平稳升级、提高用户体验,又可以规避上面的风险呢?也就是说,有没有一种方式,可以像类似灰度发布,即让50%的用户看到A方案的新功能,而另外50%看到的是B方案的新功能。然后,再看哪种方案更能让用户接受,再决定100%覆盖此方案呢?

当然有,而这种方式,就是所谓的 A/B测试。

一、A/B测试

A/B测试是通过对比两个(或多个)版本页面的优劣,从而提高网页转化率的一种统计方法。它是一种“先验”的统计假设体系,即我们首先会评估用户心理状态,模拟用户的操作流程,然后设定不同的版本页面,最终让用户决定哪个版本为最佳版本。

其中,我们把当前版本称为可控版本(control),改动的版本则是实验版本(variation)。

我们可以在很多场景使用 A/B测试,小到文案修改、按钮颜色、布局变化,大到版本迭代。

例如,下面呈现了布局方面的 A/B测试:

测试结构图

通过上面的图片,可以看到,左侧A方案的注册表单在中间,而右侧B方案在底部。最后的结果是,A方案的注册人数为50人,B方案则有75人,明显方案B比方案A更好。

还有一个更明显的例子,听说谷歌每个月都会通过 A/B测试 从几百个方案中筛选出最优的哪几个,从而达到月营收提升2%左右,规模增加十多亿美元。

也因为用户基数巨大的原因,当它站点的页面广告位左移一个像素或许会带来X%的增收,而右移一个像素却可能带来Y%的亏损。

既然A/B测试功能这么强大,那么我们应该怎么做呢?

二、举个例子

一般做A/B测试,都需要经历以下几个流程:

  • 业务背景
  • 试验假设
  • 优化指标
  • 测试结果
  • 结论分析

根据这些流程,以信贷页面为例来说明:

业务背景:调整提交按钮的文案,旨在帮助更多用户进行借贷服务。

试验假设: 把提交按钮的文案,由 “预览借款信息” 改为 “立即取现”,可以极大满足用户的迫切需求,提升用户借贷的服务质量,带来更高的绑卡取现交易。基于这个假设,设定了以下两个版本:

借贷版本对比

优化指标: 提交按钮的点击率,最终对应版本的绑卡率和取现交易笔数

测试结果: “立即取现”版本的绑卡率和取现交易笔数降低了 10.67%

借贷版本统计

结论分析: 不符合假设预期。“立即取现”虽然直观上满足了用户当前需求,但同时也给用户造成了压迫感。而“预览借款信息”虽然目的性没那么强烈,但它减缓客户的焦虑感,让客户有信心进入下一个页面,进一步完成借贷服务的后续流程。说明针对产品不同的场景,要把握用户的心里需求。

另外,通过 A/B测试,我们可以告别主观和经验主义。我曾经在营销活动的页面做了一项 A/B测试,旨在判断两个版本的优劣,从而提高app的下载率,如图:

app下载版本对比

在原始版本中,当用户完成了上一页的操作进入到该页面时,会在页面顶部下拉出一个 notification弹框,5秒后弹框上滑隐藏。倘若用户点击弹框,会下载app。另外,点击区域 2 和 3,也会下载app。

在实验版本中,当用户完成了上一页的操作进入到该页面时,顶部没有 notification弹框,其他与原始版本都相同。

实验时,以每个版本下载的复合总量(可点区域的下载总和)作为核心优化指标。

在实验开始前,我们会直观的认为三个区域的点击下载数肯定要比两个区域的多,这个应该没什么问题吧?

但经过一段时间的实验,查看数据后台,截图如下:

app下载版本统计

我们发现,这样结果出乎我们的意料,即三个点击区域的下载量却低于两个点击区域,出现了 辛普森悖论 统计现象。

测试版本虽然只有两个下载区域,但在下载率上,却比原始版本的三个区域高出了 2.58% 的下载率。最终,产品组决定使用测试版本作为迭代方案。

当确定版本后,你便可以结束A/B测试实验,因为你已经知道哪种方案更适用于用户了。

除了网页,你还可以把A/B测试应用在iOS或Android等原生界面,甚至,有的A/B测试服务提供商还支持后端测试。

三、A/B测试工具

前面所描述的,包含了A/B测试的定义、流程和优势。或许你会疑惑,我们怎么操作,才能像上面的案例一样,在管理后台看到不同版本的数据呢?这就要说到A/B测试工具,你也可以称之为服务。

目前看来,国内做A/B测试的服务商还是比较少的。而国外在这方面似乎成熟多了,有不少A/B测试服务商。

免费的有谷歌的Website Optimizer,收费的则有Optimizely以及UsabilityHub。不过我都没使用过,也不能展开细说。

而上面案例所使用的A/B测试,是我司在国内一家云服务提供商购买的,该厂商支持免费使用一部分功能,如果需要,也可以购买一些扩展服务。

而你要做的,只是在需要测试的页面,引入该服务商提供的SDK,该SDK会自动根据网络、地域或人群等环境差异,结合设置的版本流量,给用户提供相应比例的页面版本,示例代码如下:

<script src="https://sdk.xx.com/abtest.js"></script>

设置默认版本并初始化,再根据不同版本,编写对应的逻辑代码:

abtest('init', {
appKey: 'your app key',
defaultFlags: {isNewText: false}
})

if (abtest.get('isNewText')) {
// 新文案版本的操作
} else {
// 老文案版本的操作
}

同时,服务商SDK可能还提供了埋点,这样,你便知道在某个版本下,用户点击按钮数:

<button onclick="abtest('track', 'clickBtnTimes', 1)">统计点击次数</button>

完成上述操作,你只需要等待一段试验期,然后,在后台系统查看数据即可。

这里说到的是利用编程模式来进行A/B测试,当然,还有其他形式,此处不一一举例。

四、局限性

多变量场景

通过上面的说明,我们知道,A/B测试的最佳使用场景是单变量。

但当某个版本有多个变量(功能)需要上线时,使用A/B测试可能并不能得到准确的结果,因为变量之间会相互干扰,无法进行正确的对比。

其实对于变量相对少的版本更新,也是有替代方案的。

比如,此次上线需求的内容为同时更改文案和颜色(红色 -> 蓝色,“立即购买” -> “带它回家”)。我们当然不能一个使用原始版,一个使用既变文案又变背景色的版本,因为文案和背景色可能相互影响。

那么,你可以将原始版本拆分为四个小版本:

  • 原始版本:红色背景,“立即购买”
  • 实验版本1:红色背景,“带它回家”
  • 实验版本2:蓝色背景,“立即购买”
  • 实验版本3:蓝色背景,“带它回家”

然后,将这四个版本各设置25%的流量。再通过一段时间的实验,最终决定使用哪个文案,哪种颜色。

另外,如果你新增的功能是冒险性的,你可以在后台手动调整流量,让小部分用户无感知的使用新功能,对比用户的行为数据,找出用户的关注点。

用户少场景

当站点的用户技术很小时,A/B测试出来的结果往往是不准确,没有什么参考性的。此时,你可以考虑将着陆页投放到一些知名站点,再结合A/B测试,应该能产生积极的反馈。

五、总结

为打造一个好的互联网产品,我们需要不断优化和迭代。那么,如何知道新版本对用户产生了怎样的影响?A/B测试或许是一个不错的选择。

通过A/B测试,我们可以在对用户影响产生最小的情况下,完成正确的部分更新和版本迭代,在降低产品风险的同时,既留存了用户,也提升用户转化率。进一步而言,根据这些数据,我们也可以针对性(系统、地域、人群)的向不同人群发布不同版本。

可以说,做到真正用数据说话,其实,A/B测试也是互联网产品不断调整发展方向的一个重要指标。