A/B测试实践全总结

A/B测试是一种评估不同设计方案效果的方法,尤其在网站设计中,通过对比不同版本的用户反馈来选择最佳方案。这种测试强调单变量改变,确保结果的有效性。文章介绍了基于后端和前端的A/B测试实现方式,并通过EA公司《模拟城市》游戏网站的案例展示了A/B测试如何提高转化率。
摘要由CSDN通过智能技术生成

一:基本概念


网站设计中,我们经常会面临多个设计方案的选择,比如某个按钮是用红色还是用蓝色,是放左边还是放右边。传统的解决方法通常是集体讨论表决,或者由某位专家或领导来拍板。虽然传统解决办法多数情况下也是有效的,但A/B 测试(A/B Testing)可能是解决这类问题的一个更好的方法。

所谓 A/B 测试,简单来说,就是为同一个目标制定两个方案(比如两个页面),让一部分用户使用 A 方案,另一部分用户使用 B 方案,记录下用户的使用情况,看哪个方案更符合设计目标。当然,在实际操作过程之中还有许多需要注意的细节。

A/B 测试最核心的思想,即:

  1. 多个方案并行测试;

  1. 每个方案只有一个变量不同;

  1. 以某种规则优胜劣汰。

需要特别留意的是第 2 点,它暗示了 A/B 测试的应用范围,——必须是单变量。

另外,虽然 A/B 测试名字中只包含 A、B ,但并不是说它只能用于比较两个方案的好坏,事实上,你完全可以设计多个方案进行测试,比如ABC测试,“A/B 测试”这个名字只是一个习惯的叫法。

回到网站设计,一般来说,每个设计方案应该大体上是相同的,只是某一个地方有所不同,比如某处排版、文案、图片、颜色等。然后对不同的用户展示不同的方案。

要注意,不同的用户在他的一次浏览过程中,看到的应该一直是同一个方案。比如他一开始看到的是 A 方案,则在此次会话中应该一直向他展示 A 方案,而不能一会儿让他看 A 方案,一会儿让他看 B 方案。

同时,还需要注意控制访问各个版本的人数,大多数情况下我们会希望将访问者平均分配到各个不同的版本上。要做到这些很简单,根据 cookie (比如 cookie 会话ID的最后一位数字)决定展示哪个版本就是一个不错的方法。

要实现 A/B 测试,我们需要做以下几个工作:

1、开发两个(或多个)不同的版本并部署;

2、收集数据;

3、分析数据,得出结果。

二:实践方法


从左到右,3条较粗的竖线代表了 A/B 测试中的3个关键角色:客户端(Client)、服务器(Server)、数据层(Data)。从上到下代表了3种访问形式:

  1. 无 A/B 测试的普通访问流程(Non AB test)

  1. 基于后端分流的 A/B 测试访问流程(Back-end AB test)

  1. 基于前端分流的 A/B 测试访问流程(Front-end AB test)。

A/B 测试需要将多个不同的版本展现给不同的用户,即需要一个“分流”的环节。从上图中我们可以看到,分流可以在客户端做,也可以在服务器端做。

传统的 A/B 测试一般是在服务端分流的,即基于后端的 A/B 测试(Back-end AB test),当用户的请求到达服务器时,服务器根据一定的规则,给不同的用户返回不同的版本,同时记录数据的工作也在服务端完成。

基于后端的 A/B 测试技术实现上稍微简单一些,不过缺点是收集到的数据通常是比较宏观的PV(Page View)信息。虽然可以进行比较复杂的宏观行为分析,但要想知道用户在某个版本的页面上的具体行为往往就无能为力了。

基于前端的 A/B 测试则可以比较精确地记录下用户在页面上的每一个行为。它的特点是,利用前端 JavaScript 方法,在客户端进行分流,同时,可以用 JavaScript 记录下用户的鼠标行为(甚至键盘行为,如果需要的话),直接发送到服务器记录。

下面,我将重点介绍一下我们在基于前端的 A/B 测试上的一些实践。

首先遇到的问题是如何分流的问题。对于大部分需求来说,我们希望各个版本的访问人数平均分配。可以根据某一个 Cookie ID 来划分用户,比如“123.180.140.*.1267882109577.3”,可以根据这个 Cookie ID 的最后一位(在本例中是“3”)来划分人群,比如单数的显示 A 版本,偶数的显示 B 版本。

正确展示对应的版本后,就要开始采集需要的数据了。当前版本有多少 PV (Page Views,访问量),如果需要记录这个数据的话,在正确版本加载完成之时就要发送一个打点信息。不过很多需求中,具体版本的 PV 的精确数值可能不是很重要,而且要收集这个信息需要多一次打点操作,所以一般情况下这个数据是可选的。

必须的数据是测试区域内用户的点击信息。当用户在测试区域点击了鼠标左键(无论这个点击是点击在链接、文字、图片还是空白处),我们就需要发送一条对应的打点信息到打点服务器。一般来说,这个打点信息至少需要包含以下数据:

  • 当前 A/B 测试以及版本标识

  • 点击事件的位置

  • 点击时间戳(客户端时间)

  • 当前点中的URL(如果点在非超链接区域,此项为空)

  • 用户标识(比如 Cookie ID)

  • 用户浏览器信息

三:应用例子


今年,EA公司发布新版《模拟城市》(SimCity)游戏时,在网站做了一个A/B测试,以便试验转化率在不同的布局下是否有变化。

下面是两个不同的版本:

B版本与A版本的差别在于新版本删除了Pre-Order的促销广告图片,页面更清爽一些。

结果数据显示,A版本的转化率为5.8%,B版本的转化率为10.2%,提高了43.4%。

这几乎是一个完美的A/B测试案例:有明确的测试目标,清晰的衡量标准(订单转化率),以及完美的结果数字。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

产品大道

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值