基于前端的 A/B 测试上的实践问题

基于前端的 A/B 测试则可以解决上面的问题。它的特点是，利用前端 JavaScript 方法，在客户端进行分流，同时，可以用 JavaScript 记录下用户的鼠标行为（甚至键盘行为，如果需要的话），直接发送到对应的打点服务器记录。这样的好处是不需要技术部（如果你们和我们一样，前端工程师与后端工程师分属不同部门的话）参与，并且可以比较精确地记录下用户在页面上的每一个行为，甚至包括后端方法难以记录到的无效点击！

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

一、分流

首先遇到的问题是如何分流的问题。对于大部分需求来说，我们希望各个版本的访问人数平均分配。解决办法有很多种，比较简单的一种即是前面提到过的，根据某一个 Cookie ID 来划分用户，前提是你的网站上每一位访客在第一次访问时就要有一个不重复的 Cookie ID，比如“123.180.140.*.1267882109577.3”。然后，可以根据这个 Cookie ID 的最后一位（在本例中是“3”）来划分人群，比如单数的显示 A 版本，偶数的显示 B 版本。

因为 Cookie ID 一般设定后不会轻易改变，基于 Cookie ID 的好处是我们能很好地对访客保持一致性，某个用户如果第一次看到的是 A 版本，那他刷新后看到的还是 A 版本，不会一会儿看到 A 版本一会儿看到 B 版本。但不足之处就是如果用户浏览器不支持 Cookie 的话，分流就不能正常进行了。不过，现代浏览器默认情况下都是支持 Cookie 的，如果真有用户的浏览器不支持 Cookie ，那也应该是极少数特殊情况，对结果的影响非常微小，对于这些特殊情况，我们一般可以安全地忽略掉。

还有一点需要注意的是，A/B 测试的页面必须有较高的 UV （Unique Visitor，独立访客数），因为分流带有一定的随机性，如果页面 UV 太小，分到每一个版本的人数就更少，结果很有可能被一些偶然因素影响。而 UV 较大时，根据大数定理，我们得到的结果会接近于真实数据。就像想知道一个地方的成年人的平均身高，当然是取的样本越大结论越可信。

二、展示

决定向当前访问者显示哪个版本后，怎么用前端的方法加载对应的版本呢？这需要分情况处理。

一般情况下，如果两个版本只有一个较小的区域不一样，我们可以同时将两个区域的 HTML 都加载到当前页面中，先用 CSS 把它们隐藏起来（也可以默认显示一个版本），等 JS 判断出该显示哪个版本后，再控制对应版本的 CSS 显示。

有时候，测试区域比较大，代码比较多，或者需要后台较多的计算资源，如果一开始就把两个版本的 HTML 全加载到当前页面中，就会需要比较大的开销（比如带宽、后台计算量）。这种情况下，我们可以先把测试区留空，之后再用 Ajax 的方式延迟加载。

还有的时候，测试区域非常大，几乎占了整个页面，或者完全就是不同的页面，这时，用 Ajax 方式加载也不适合了，可以将不同的版本做成不同的页面，然后再用 JS 跳转。不过这样的方式并不是很好，因为前端 JS 跳转需要一定的时间，这个过程很有可能被用户感受到，并且留下不好的体验。对这个问题，似乎没有很好的解决办法，至少在前端层面很难好解决，所以并不是非常推荐这种跳转方式，如果真的需要跳转，最好是在服务器端由后端代码来操作。

三、数据采集

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

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

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

点击事件的位置

点击时间戳（客户端时间）

当前点中的URL（如果点在非超链接区域，此项为空）

用户标识（比如 Cookie ID）

用户浏览器信息

为了尽可能精确地还原用户的点击位置，我们的页面对前端有比较高的要求，要求页面在不同的浏览器下有基本一致的表现，至少在IE6、7、8以及 Fiefox 下，页面横向的元素要精确一致，纵向上很难做到完全一致，但也要尽可能保持统一。另外，这样的测试也不太适合自适应宽度的页面，比较适合定宽的页面，为了避免不同分辨率下页面左右空白不同导致鼠标点击位置的不同，点击位置取的应该是相对于测试区域左上角的位置。除此之外，最好再记录一下测试区域相对于页面内容左上角的位置，在后面还原点击分布图以及绘制热区图时会用到这个数据。

四、数据存储

我们使用了一台专用的服务器收集打点信息，为了能支持尽可多尽可能密集的打点请求，这台服务器的 apache 服务网站目录下只有两个静态文件，分别是 abtest.html 和 abtest.gif ，两者都是非常小的空白文件（空白图片）。访客端进行打点时，只需要以 GET 的方式带上相关的参数请求两个文件中的任意一个即可。比如：http://yanet22.blog.163.com/
这个请求可以通过 Ajax 的方式发送，也可以通过 JS 在页面上创建 new Image() 对象的方式完成。

对打点服务器来说，这只是一条普通的 HTTP 请求，它会在日志里留下一条普通的日志记录，形如：

123.180.140.* – - [13/Jan/2010:15:21:15 +0800] “GET /abtest.gif?a=123&b=456&c=789 HTTP/1.1″ 304 – “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.6 (KHTML, like Gecko) Chrome/4.0.266.0 Safari/532.6″

可以看到了，除了 JS 发送给我们的信息外，Apache 还帮我们记录了一些信息，比如访客 IP 、服务器时间、用户浏览器信息。

对于数据记录和存储来说，到这一步就足够了。Apache 静态文件 + 日志的方式足够高效，基本不用担心性能的问题。剩下的，就是另外一个问题，如何从 Apache 日志中读取打点信息并加以分析，这已经和前端无关了，并且是一个比较复杂的问题，将在后续日志中介绍。

分享标题：基于前端的 A/B 测试上的实践问题
转载来源：https://www.cdcxhl.com/news38/166388.html

成都网站建设公司_创新互联，为您提供用户体验、商城网站、ChatGPT、网站策划、外贸网站建设、网站建设

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联