From Enterprise to Cloud (1)
From Enterprise to Cloud (2) --- A/B Testing I
From Enterprise to Cloud (3) --- A/B Testing II
From Enterprise to Cloud (4) --- A/B Testing III
From Enterprise to Cloud (5) --- A/B Testing IV
From Enterprise to Cloud (6) --- 测量术 I

 

我比较推崇A/B Testing，主要原因是它可以成为一种从企业级开发到互联网开发转变的驱动力，一个Mindset转变的诱因。个人认为，这个驱动力的作用也许大于A/B Testing自身对产品演化的价值。

之所以这么讲是因为，沉浸在企业级开发多年的人很难迅速地转变成为互联网开发短平快，分析数据不断改进的过程。一方面是技术上的问题（比如说，组件部署能力），另一方面是组织结构和人的Mindset的问题。后者有时候更加难于改变。PM按照日程安排要在1个月之内完成功能设计，如何说服他以及组织的其他人员冒着延期的风险接受数据先行的思路？如何让Dev愿意付出额外的成本去提供功能的可用性统计？A/B Testing的作用是可以提供足够多的有说服力的例子（尤其是反例）。这些例子能够帮助我们在整个转变中争取到足够多的支持力量。

另一方面，我不认为A/B Testing是“银弹”。千万不能误以为A/B Testing是解决一切功能设计问题和提升创新能力的灵丹妙药。实际上，正如之前所说，A/B Testing只能告诉我们结果，不能告诉我们原因，只能增量提升，而不能突破性创新。仅从需求分析的角度来说，A/B Testing是Usability Study 的补充而不是替代。

Usability Study仍旧是必不可少的工具。早期的paper prototyping可以行之有效地淘汰不好的主意以及识别出错误的假设，之后的alpha测试，用户调研等等都能够在不同阶段获得对软件的反馈。我们经常会做的事情是邀请用户到实验室，并且让用户完成一些任务。观察人员站在单面透明的玻璃墙背后，记录和讨论用户的每一个行为，观察到用户的每一次皱眉和每一个笑容。类似的Usability Study可以比A/B Testing更有效以及更深入的理解客户。

抓取网络上一篇文章对三种不同技术的分析，个人觉得部分数值值得商榷，但大体思想我还是非常赞同的。image

http://www.nngroup.com/articles/ab-testing-usability-engineering/

 

好了。还是接着上一篇随笔，详细地介绍一下要做A/B Testing，我们需要提供什么架构。抛开数据采集和数据挖掘以后再谈，我觉得有三个方面值得注意：a.) 随机策略，b.) 分配策略，c.) 退出策略。

随机策略的主要功能是把用户和策略关联起来。A/B Testing的价值主要就体现在“随机”这个词上。我见到过一些A/B Testing的例子试图提供细粒度的控制，比如说，有选择的对两个不同的组织进行测试对比，我个人认为这是不对的，至少，这种方法得到的测试结果不一定具备普适性。一个好的随机策略需要提供如下功能：

  • 用户是随机选择的。可以通过A/A Testing来定期测试这一点；
  • 一个用户在整个测试中，只会被分配一种测试页面。不要试图用session，cookie等可变量作为随机算法的输入，可以考虑用用户的唯一id；
  • 有一种慢慢启动的算法，最好自动中止实验。A/B Testing 比较常见的是对所有用户50%-50%的实验，可如果实验页面有问题，那么可能有50%的用户立即就会被影响。一个办法是缓慢的开启实验，比如说从0.01% 开始递增，并且监控错误比率。超过一定值时，能够做到自动取消实验；
  • 同时进行的两个实验，从概率分布角度上来说不能互相干扰。

取决于你能提供的输入，有不少方法可以实现上述策略，比如说MD5。我的A/B Testing的输入是用户唯一id，MD5可以保证随机分布，一致性，和无干扰。如果有兴趣实现自己的框架的同学，可以参考论文，Practical Guide to Controlled Experiments on the Web: Listen to Your Customers not to the HiPPO以及相关的引用。

接下来是分配策略。常用的有很多种分配策略，比如客户端分配和服务器端分配，重定向，据说也有架设反向代理将请求分配到不同的服务器上的。做选择的时候，如下几点我比较关心：

  1. 额外的硬件及其维护成本；
  2. 对性能的影响。 A/B Testing对我们的一个重要用途就是改进算法提高性能；
  3. 对代码可维护性的影响；

以下是从上述论文及其相关论文中整理出来的分配策略的架构设计简介和针对以上三点分析。Traffic Split需要独立的反向代理，因为我的项目去增加这种服务成本太高（沟通，维护），所以直接就被排除了。Page Rewriting会增加服务器的响应时间，因为响应时间是我们现在的最高优先级（呃，因为之前做的不好），所以基本上也排除了。

客户端分配这种方法挺常用，有不少第三方的支持，比如Google Website Optimizer。但它额外的Ajax请求会增加响应时间，并且其测试范围有些，比如相对很难对服务器的改动进行测试。

最后我们选择了服务器端分配的方式。它易于访问存储在数据库中的用户id，既能支持客户端的实验，也能支持服务器上的。当然，它的缺点也很明显，测试相关的代码会分散在很多地方，测试完成之后还要手工的清理。

image

 

关于A/B Testing架构设计，最后想说的是退出策略 -------- 什么情况下我们有足够的信心认为实验已经完成？多大的数据量，多长时间合适？本来想一口气写完，然后开始下一个话题，instrumentation。但突然发现我没办法清楚地解释退出策略，容我些时间翻翻论文，下次再说吧。