每个工程师都应该了解的：A/B 测试。
概念
A/B 测试，是一种数据分析手段，它可以对产品特性、设计、市场、营销等方面进行受控实验。在实验中，数据样本被分到两个“桶”中，分别加以不同的控制和处理，然后对采集回来的信息进行对比分析。
举例
场景：修改 UI 上一个引导用户点击“下一步”按钮的交互设计，但是不知道设计改动前后哪一种效果更佳。
方案：A/B 测试。
原理：让一部分用户体验新的 UI，另一部分用户继续使用旧的 UI，再对采集回来的数据进行分析，对不同组用户在这个页面上的转化率进行比较，观察在哪一种 UI 下，用户更愿意往下走。
结果：有了数据分析，就可以判断新的设计是否改进了用户体验。
注意事项
1. 永远不要过分相信自己的直觉。
有时候，我们会觉得一个功能特征的改动是理所当然的，更新后效果肯定更好。比如，改线上代码。但这样做，真的没问题吗？
此时，不妨先停下来仔细想想。或者把自己的想法和别的工程师、设计师、产品经理深入交流一下，看看大家的意见和建议。
角色不同，背景不同，考虑问题的方式、角度也就不同。当不确定哪种方式更好的时候，A/B 测试是个不错的选择。
2. 实验样本的数量和分配很重要。
小样本偏差会很大。
另外，需要确保随机分配给 A 组和 B 组的数据是绝对公平的。即：分配算法不会让两个桶的数据产生额外的干扰。避免误差。
3. 分析的维度尽可能全面。
A/B 测试不能只关注单一指标。关注测试目标的同时还需要留意附加风险。如，案例中 UI 交互的调整，测试目标是转化率，但倘若高转化率的方案会导致其他问题，比如提高了出错率，改方案也应当舍弃。
4. 其他组的改动对 A/B 测试产生的影响。
当 A/B 测试成为一个广泛使用的工具后，产品很多特性的改动都会用到这个工具。这也就意味着，当你在采集数据做分析的时候，别人也在做同样的事，只不过策略和数据样本不同。
换句话说，你在跑 A/B 测试比较 A 和 B 的优劣，另一个同事在跑 A/B 测试比较 C 和 D 的优劣，结果因为实现细节的原因，A 组中大部分样本同样也是 C 组改动过的样本。这样一来，两个实验可能就会相互影响。因此，要做足够的分析，确保实验结果考虑到了这种相关性的影响。
5. 比较值的趋势必须是收敛的，而不是发散的。
要想比较结果有实际的统计意义，一定是每天采集数据的比较结果逐步收敛，最终趋于稳定。如果一周内 A 比较好，后面又开始波动，B 变得更好，这样来回波动的结果是没有太大参考价值的。
另外，即使比较值趋于稳定，还要确保这个稳定数据所处的阶段不在一个特殊时期。如果恰好有促销或者类似的市场活动，那么即便获得了稳定的结果，这个结果也不一定是普适的。
6. 数据埋点。
数据的埋点和采集是 A/B 测试成功的关键。
前端埋点一般可以采集实时数据，后端埋点可以采集实时事件，也可能是一些聚合数据。要视具体情况和应用而定。
7. 形成一个流程，或者设计一个工具。
A/B 测试作为一个工具，只有在它足够灵活、好用的情况下，才能更广泛地应用到日常的产品迭代和开发中。
做好一套包括埋点、采集、处理和具备 UI 的工具，会让工程师事半功倍。
8. 试图给每个结果一个合理的解释。
不用过分相信数据。试着去给每个结果一个合理的解释，如果解释不了，可能它就是个 bug。
9. 必要的时候重新设计实验。
很多实验会有不同版本，每个版本都会根据实验结果做一些改动和调整。
如果发现实验设计上有漏洞，或是代码实现有问题，那就需要随时调整或者重新设计实验，重新取样、分析。
实验的版本控制，会让分析和重新设置的过程更加快捷。
10. 不同客户端分开进行实验。
Web 端、iOS、Android 尽可能分开观察。很多时候，同样的实验数据对比，在不同的客户端会有完全不同的结果。如果不分开，很可能让数据变得难以解读，或者出现“将只对移动客户端成立的结果扩展到 Web 端”，这样以偏概全的错误。
小结
A/B 测试是一种行之有效的产品验证和功能改进方法。
基于工具和数据验证自己的想法，有助于持续进行功能改进、推动产品的发展。
