hy – 禾一

A/B测试：实现方法

上文介绍了 A/B 测试的基本概念，接下来我们继续探讨如何实现A/B测试。

我们先来看一个图：

A/B testing 部署概念图

（注：感谢Algo提供本图。）

上图展示了A/B测试的实现原理。从左到右，四条较粗的竖线代表了A/B测试中的四个关键角色：客户端（Client）、服务器（Server）、数据层（Data）、数据仓库（Data－Warehouse）。从上到下代表了三种访问形式：无A/B测试的普通访问流程（No－AB－test）、基于后端的 A/B 测试访问流程（Back-end AB test）、基于前端的 A/B 测试访问流程（Front-end AB test）。

一般情况下，用户在一次浏览中，会从客户端（Client）发起一个请求，这个请求被传到了服务器（Server），服务器的后台程序根据计算，得出要给用户返回什么内容（Data），同时向数据仓库（Data Warehouse）添加一条打点信息，记录本次访问的相关信息。这个过程也就是图上横向的流程。数据仓库收集到足够的数据之后，就可以开始进行分析（Analytics）了，这也即是图中右上角的部分。

A/B 测试需要将多个不同的版本展现给不同的用户，即需要一个“分流”的环节。从上图中我们可以看到，分流可以在客户端做，也可以在服务器端做。传统的 A/B 测试一般是在服务端分流的，即基于后端的 A/B 测试（Back-end AB test），当用户的请求到达服务器时，服务器根据一定的规则，给不同的用户返回不同的版本，同时记录数据的工作也在服务端完成。

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

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

这一阶段的流程大致如下图所示：

A/B 测试打点生命周期

数据打点该如何发送以及如何存储呢？这要取决于你的打点服务器如何存储信息。

四、数据存储

我们使用了一台专用的服务器收集打点信息，为了能支持尽可多尽可能密集的打点请求，这台服务器的 apache 服务网站目录下只有两个静态文件，分别是 abtest.html 和 abtest.gif ，两者都是非常小的空白文件（空白图片）。访客端进行打点时，只需要以 GET 的方式带上相关的参数请求两个文件中的任意一个即可。比如：

http://abtest.xxx.com/abtest.gif?abid=1-a&clickBlockX=244&clickBlockY=372&clickBlockW=392&clickBlockH=76&clickTime=

1263264082137&clickRX=233&clickRY=47&clickURL=&clickBeaconID=
123.180.140.*.1267882109577.3&browserType=FireFox

这个请求可以通过 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 日志中读取打点信息并加以分析，这已经和前端无关了，并且是一个比较复杂的问题，将在后续日志中介绍。

源地址：http://www.aliued.cn/?p=2976

基础小科普！浅谈「列表视图」与「网格视图」的用法

一、根据信息选择合适的视图

因为从事电商行业已经有一段时间，且在迭代的过程中学到了不少相关知识。所以抽空写了一篇关于「列表视图」与「网格视图」的文章分享给各位。

列表视图（上图左）：

列表视图适合许多长文本信息的展示，如标题、描述、评论等，它可以帮助用户更好的理解商品的相关信息；
通过阅读习惯与眼动模型的研究，列表视图符合「最重要的内容应该置于左边，次要的放在右边」的实验结果。

网格视图：

网格视图更多的是突出图像的。它更适用于文字信息较少，图像层级更重的页面。
用户主要以图像确认网格视图的信息，所以通常可以一次扫描4-6个视图。

列表视图和网格视图都可以看成是一个组件，组成元素有图像、标题、评论、位置等。区别就在于将这些元素进行合理的布局或组合，用于页面的相关信息展示。

二、搜索与查看

通过多次的 A/B 测试表明：列表视图用于搜索结果展示页更受用户的欢迎。但是，在主页和类别页面上观察到相反的情况，其中大多数参与者在浏览和查看他们可能想要的商品详情时，更喜欢用网格视图。因为网格视图更突出图像本身，首先通过对图像的了解，再查看其它更详细的信息，是用户在电商产品中的主要使用习惯。

总而言之，我们需要在相关页面中给出更加合理的视图，符合用户的心理预期。如，网格视图让用户大致了解了某商品信息，触发用户点击欲望；列表视图让用户了解某商品详细信息，触发用户下单欲望。

三、尽量减少信息，帮用户做选择

许多人认为列表视图具有更多空间，能放置更多信息，其实不然。用户很容易被各种各样的信息淹没，陷入选择悖论。如，你在列表视图上放置了大量信息，用户就无法一眼辨识出该商品的大体信息，也就被轻易忽略了。

A/B 测试也是一种了解哪些信息会影响用户做出决定的好方法。我们发现标题、价格、评论、位置、商品说明和金额都会对转化产生一定影响。而这些信息中，标题、价格、评论（数）是必不可少的。因此它们在两种视图中都有一定的比重。其余的信息，就根据场景来做删减即可。

如今，我们仍然能看到许多电商产品在设计时采用列表视图与网格视图。这是件好事，我们应该根据每个页面的目的，做出相应的展示形式。符合用户当时的场景才最为重要。这句话不仅仅针对两种视图的选择，在其他功能的设计上也是如此。

学会充分利用两个视图，不要在这两个视图上放置相同的信息，否则就会导致两个视图失去自身的应有价值。

四、最后给用户展示更好的内容

有了以上的视图选择建议，之后就是底层逻辑了。

你还记得你看到的眼睛凝视强度从上到下减少的热图吗？通过查看这份热图，可以根据浏览历史记录、用户的搜索情况、关注卖家的行为、喜欢的商品等因素构建推荐算法，并使用它来对商品进行排序，推给用户。

再是研究那些销量很高的产品，除了推广之外，在设计上有什么影响用户的布局方式？如，假设颜色是用户选择围巾的关键信息，那么就应该在描述的开头就说明可选颜色的信息。如果仔细看一些平台的商品信息，你会发现许多这样的例子。

以上内容就是电商产品在视图选择上的原因所在。希望帮助到各位。

原文链接：《List or Grid, It Is Not Important》 Mei

线框图和原型图的区别

线框图并非是原型，但即使是经验丰富的设计师也可能会将两者混为一谈。实际上，两者的差别还是非常多且明显的，那么就让我们通过这篇文章分辨清楚这俩概念，一劳永逸。

线框图

线框图是产品设计的低保真呈现方式。它有三个简单直接而明确的目标：

1、呈现主体信息群

2、勾勒出结构和布局

3、用户交互界面的主视觉和描述

正确地创建了线框图之后，它将作为产品的骨干而存在。

它就像一幢建筑的蓝图一样，将细节规定地明明白白。

线框图的视觉特性

线框的视觉特性局限性非常明显。通常设计师会只需要使用线条、方框和灰阶色彩填充（不同灰阶标明不同层次）就可以完成。

简单的矢量线框图

一个简单的线框图最终需要包含的内容有图片、视频、文本这些东西。所以，通常情况下，被省略的地方会用占位符来标明，而图片通常被带斜线的线框来替代，文本会按照排版，用一些标识性的文字所替代。

线框图的优势

线框图的制作是快速而廉价的，特别是当你使用诸如UXPin、Balsamiq、Axure这样的软件来制作的时候。当然，线框图也理当是在设计之初就使用这些工具来制作。

比起创建一个完整细致高保真的线框图，搜集反馈信息来得更加重要。为什么这么说呢？

一般而言，大家更注重软件的功能、信息架构、用户体验、用户交互流程图、可用性，这些东西，而不是考虑这些因素的美学特征。同时，在这种情况下，根据需求进行修改也无需涉及代码调整和图形编辑。

交互式线框图

有的时候，设计师喜欢提高线框图的保真度而强调用户界面的某些方面的重要性，以及展示和快速测试、各种视觉元素之间相互作用的合理性。用以解决这些问题的方案就是使用交互式线框图，也叫做可点击式线框图。

创建这种更加复杂的线框图你就需要用UXPin了，它是专门用来制作线框图和原型设计的工具了。互动式线框图可能是用来向开发团队和客户最合适的演示工具了。当你碰上客户的经典问题”如果我点击这个按钮会发什么什么”的时候，你所需要做的就是在互动式线框图中按下那个按钮。”就是这样”，你只需要这样回答。的确，这种方式令人印象深刻，引人入胜。

谨慎展示线框图

当你需要展示的对象是一个彻头彻尾的门外汉的时候，你就要小心了。他可能是你的客户，也可能是参与合作的某个非技术背景主管，他们并不知道，线框图和最终的产品可能看起来毫无关系。所以，他们有可能并不能很快地明白两者的内在联系和运作方式，是否要演示，如何演示，一定要拿捏好这其中的度。

这是Fernando Guillen快速手绘出来的APP的用户操作流程图。当然，这无疑是最早期的设计版本。

线框图设计流程中最重要的组成部分之一，看完这张手绘的流程图你就明白，为什么要耗费时间来向他们解释什么是线框图（笑），以及为什么要这么用线框图。或者，你干脆跳过这个版本。

原型

原型的要求比线框图/可交互式线框图要高，它要求必须是可交互的，并且尽可能贴合最终的用户界面的高保真模型。

制作原型的目标非常明确：尽可能真实地模拟用户和界面之间的交互。当一个按钮被按下的时候，相应的操作必须被执行，对应页面也必须出现，尽可能地模仿完整的产品体验。

原型的视觉特征

毫无疑问，原型是必须囊括产品该有的美学特征，并且尽量贴合最终版本。基本上，当原型制作出来的时候，它就是一副画皮，除了不具备血肉骨骼，该有的眉眼皮肤和化妆都有了，也就是说，它无需涉及HTML/CSS/JS，不用考虑服务器端的程序和数据库实现。

在UXPin中制作的交互原型设计

主色调和主视觉必须到位，重点内容理应呈现出来，信息保障和版式设计也当在合理范畴以内。点击相应的元素之后，原型也应出现对应的交互回馈。

原型的优势

原型为何如此重要？因为原型通常拿来给真正的用户测试产品用的。早期的原型测试能够节省巨量的开发成本和时间，如此一来，团队就不会因为不合理的交互界面而让后端的产品架构都白做了。所以，对设计师和开发者而言，原型是用来测试产品的绝妙工具。

另外，将原型提供给用户，并跟踪用户反馈，这样的基本的用例对洞察产品各个细节能收到奇效的，并且可以鼓舞整个团队。使用前文我所说的软件，单靠设计师介入就可以快速高效地构建原型而无需程序员介入，这是极为省事的。

设计流程

深入了解了设计的本质，掌握线框图和原型之间的区别之后，你就站在用户体验设计的世界门口。

当你能够将这一系列的产品设计环节，整合成一个具有凝聚力、高效的工作流程，神奇的事情自然会发生。

在我管理一个用户体验设计部门数年之后，我在工作中碰到的最大的错误，就是我们将线框图视作一次性的、非必要的设计环节。因此，我们急于推动整个产品设计的进程，不会在设计线框图的环节做过多停留，尽管这个环节是非常有用且重要的。这直接导致我们的线框图看起来非常潦草凌乱，无法用作产品设计的蓝图了，就更不用提基于此构建一个健壮有效的原型和可用的产品了。