5.1.2 A/B测试的定义和分类
当面对一个改进目标有两种甚至多种不同的方案时，为了避免盲目决策带来的不确定性和随机性，将各种不同的实验同时放到线上让实际目标群体选择，然后利用实际数据分析结果辅助决策。这种手段就是A/B测试。
一般来说，如果按照使用场景分类，可以将A/B测试分为服务端实验、客户端实验、页面实验。
●服务端实验：只涉及后端策略开发、不涉及界面改变的实验被称为服务端实验。该实验一般只涉及排序策略或过滤策略的更改，即实验组只更改某一个模块的排序、过滤、内容召回逻辑。实际工作中，大多数推荐策略实验都是服务端实验。
●客户端实验：涉及客户端发版的A/B测试被称为客户端实验。一般需要做好客户端的两套埋点体系，才能得到两套页面交互方案。
●页面实验（PC端、RN、H5等）：涉及界面的改变但不需要客户端发版，只需要在某个页面上进行实验，被称为页面实验。实际工作中，推荐策略上很少使用页面实验。
其中，服务端实验是使用频率最高的，迭代速度较快，甚至可以实现小时级迭代。客户端实验是一种成本高昂的实验方式，只有少数大型页面改版才需要进行两个及以上的交互方案开发，难点在于不同交互方案如何控制唯一的变量因素，以及交互方案都需要做埋点。PC端或RN页面是一种比较灵活的方式，虽然页面体验不如原生页面，但是迭代灵活，可以快速验证。实际工作中，如果涉及交互改版，则在技术方案上尽量选择页面实验。
如果按照用户分组方式分类，A/B测试可以分为以下几类。
●客户端-流量随机实验：在客户端内，采用时间戳等策略进行随机分组，也就是说同一个用户第一次进入和下一次进入可能会进入不同页面的策略。
●客户端-已注册用户随机实验：比较常用，也就是说非注册用户无法参与实验，并且每一个确定的用户ID在实验期间访问始终会进入相同页面的策略。
●客户端-所有注册用户随机实验：最常用，也就是说非注册用户也可以参与实验，并且每一个确定的用户ID在实验期间访问始终会进入相同页面的策略。
●其他端-网页端/小程序端/H5端实验：实际工作中使用较少，用户可以使用浏览器ID、微信openid等随机进入页面的策略。
在实际的内容型产品推荐策略中，客户端实验是最主流的。流量随机实验一般用于特定目的，比如不追求同一个用户连续两次进入同一页面，而用户随机实验（无论是否包含未注册用户）则是追求同一个用户连续两次进入同一页面。实际上，这两种情况置信度计算方式的分母是不同的，前者是以曝光为基本单位，后者（比较常用的方式）则是以用户为基本单位。
在数据量级较小的产品上可以使用流量随机（时间戳分流）的方式，因为即使用户量只有几千人，但几千人产生的曝光行为会远远大于用户数量，时间戳分流的方式可以增大数十倍的数据量，并且能得到一部分数据结论（但是仍有明显的弊端，将在下文阐述）。Netflix曾发表相关论文（interleaving的方法）介绍了这种以曝光为基本单位的实验优势。根据论文所述，这种方式的优点如下。
●消除了A/B组测试者自身属性分布不均的问题，通过给予每个人相同的权重，降低了重度消费者对结果的过多影响。A和B两组实验之间重度消费者的微小不平衡也可能对结论产生不成比例的影响，比如内容付费行为是一种概率很低的行为，尽管分流算法可以在理论上认为随机打散，实际工作中还是会有某一组的重度用户多一点的情况，这就严重影响了实验的准确性。
●灵敏度和准确性高。用更少的用户量（约为传统A/B测试的1%）和更短的时间实现传统A/B测试的效果，实现快速粗筛的策略。
按照论文所述，该手段可以实现内容付费相关产品中的典型A/B测试需求，但缺点是为了满足流量随机的严格统计要求，需要设计比较复杂的工程。同时因为该手段以曝光为基本单位，难以得出新策略的具体收益（比如“新策略实验组比对照组人均停留时长增加了20秒”的类似结论是无法通过该方法计算出来的），所以只能用来更快地比较策略好坏，但不能论证策略的明确收益。
更成熟的A/B测试分流方式是基于用户分组的，一部分互联网产品是允许用户不登录就可以使用的，一部分互联网产品则要求必须登录才能使用。实际工作中，具体根据设备ID及用户ID分组需要视情况而定。
那么，A/B测试是否是所有公司的必需品？如果产品只有很低的用户量，是否需要搭建A/B测试系统？笔者的答案是：否。
笔者认为业界对于A/B测试的认知有些偏颇，其实A/B测试在小公司的优先级并没有那么高。对小公司（尤其是天使轮和A轮的公司）而言，重要的事是产品的自然留存、对VC的“故事”和现金流是否能够产生正向影响，而非A/B测试和内容标签系统等。
A/B测试系统本身具有较高的系统复杂度。对于创业者而言，A/B测试很像是一个能看到附近海域有哪些岛屿的昂贵的罗盘。客观事实是A/B测试系统需要相对完善的数据埋点、权限分明的数据平台、靠谱的实验分流设计、流程化的实验报告，而这些都是非常大的投入，而且大多数公司并不满足数据驱动的技术条件。在未搭建好一个相对可用的A/B测试后台的情况下，经常出现的情况是，一线工程师在不足1000人的实验组上得到了某个实验结论，而结论却与大家的基本假设完全相悖，显得不合常理。在开启每一个A/B测试之前，实验发起人总会有一个基本假设，但实验结果往往让相关同事困惑。实际上，这些困惑都是用户量级过小、数据采集问题、显著性计算方式等引起的。笔者的观点是，A/B测试只是罗盘，当公司的数据平台和基础很好时可以选择强数据驱动；反之，应该选择弱数据驱动。
“虚心接纳数据但不迷信数据”应该是每一个策略产品经理坚持的价值观，至于当主观判断和实验数据结论发生偏差时如何决策，则需要具体案例具体分析，这可能正好考察策略产品经理是否有判断力吧！
A/B测试后台可以显著提升公司在细分策略上的正确率。部分优秀的互联网公司往往将A/B测试的发布流程和实验平台做到极致，这样能带来如下主要收益。
●减少团队争执，提升团队效率。实际工作中，往往不同职位的同事在用户理解上有差别，此时最好的方式是低成本开发A/B测试，用客观科学的实验结果终止无谓的争论。
●在短期收益上，提升决策正确率。正如“地铁的电梯是让人快速离开，而商场的电梯是让人尽量留下来”，A/B测试的数据驱动无法取代顶层设计，领导者的组织设计和商业设计能力不能被A/B测试代替。对于团队来说，优秀的A/B测试平台在短期指标上可以显著地提升决策正确率。
●多组实验同步。优秀的A/B测试平台可以将流量真正意义地做到正交化，为多个团队提供并行验证的机会，提升公司的人员效能。平庸的A/B测试平台无法将流量真正打散，导致线上只能同时开启少数实验，团队成员需要排队做实验，降低了公司策略迭代的效率。