灰度发布和A/B测试和分桶测试和多变量测试

最近开会，涉及到一些产品策略的问题。
正好在网上查了相关的资料。
转载一下，也算是下次方便深入研究。
转载地址：
https://blog.csdn.net/shanshangyouzhiyangm/article/details/81456991

灰度发布
灰度：
把黑色定为基本色，每个灰度对象都是0%（白色）到100%（黑色）的中间值，简而言之，灰度就是不饱和的黑色。

灰度发布：
是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。除了AB test灰度发布另一种思想是，只发布给一小部分用户，如：App在发布之前，可能会针对性的给一小批种子用户发送下载链接，或者到小的应用市场去发布。用小流量发布的方式来检验新版会不会有问题。

为什么要做灰度发布
很多公司在定义一个产品，一个功能的时候，有的说白，有的说黑，但是互联网产品真正的定义者是谁？当然是用户，你说了不算，我说了也不算，用户口碑才是硬道理，因此需要一个灰度周期，让用户决定其生死，定义其黑白。
灰度发布对产品研发的重要性不言而喻，用业内的话说就是顶级的PM也只能跑赢一半的ABtest像Uber, Airbnb, Wish这些新一代的企业，都是从第一天开始就做AB测试来做产品迭代优化的，所以他们才会不断提升高速发展。
反面例子就是人人网，人人从诞生开始就没脱离过Facebook的影子，很多功能和设计都是直接照搬，不考虑水土服不服，不做测试，直接裸奔上线，完全碰运气的玩法。

如何做A/B测试？
适合做A/B测试的情况
其实当产品到一定规模的时候，也就是日活（日IP）达到一定数值的时候，任何改版都应该首先经过AB测试小流量验证，建议日活1000以上就开始做试验。如果用户体量小，就50% 50%对比试验，分层试验可以大幅度增加并行试验数量。如果用户体量到达百万千万级别，可以用小流量测试各种不同的功能，比如一个文案的改动，一个icon的优化带来的点击率有没有增加，增加了就继续扩大测试流量，减少了或是继续优化或是直接关掉。需要注意的是，在一些特定的功能点上，比如聊天页面增加一些真的情侣或者亲人的功能，我们在流量选取上就应该考虑这些目标包不包含此功能针对的特定人群。

如果从来没有用过AB测试，那可以先尝试从一个小改动开始，熟悉AB测试的实施流程,在关键环节的修改上做实验。特别是后端算法变更，像搜索算法、推荐算法、push算法等等，AB测试肯定是必不可少的。还有一些我们拿捏不定或者争执不下的前端改动，都应该进行AB测试。关键环节熟练之后，我们可以并行的去尝试更多的地方的修改。

AB测试的周期？
试验的周期一般是7天，覆盖周末和周中的用户行为。对于复杂一些的测试，可以跑2周甚至1个月。还有一个办法，就是看试验结果的置信区间的收敛速度，如果置信区间达到3%-5%已经可以决策了，就可以停止试验了。正常情况下，我们需要大流量试验来验证大型新功能，比如新推荐算法，新学习模型，新聊天功能。然后我们可以同时用流量分层的方法做很多很多小试验，比如改UI改文案，看看有什么改变能带来用户转化的提升。同时跑10个以上的试验很正常，这种并行决策实际上大幅度提高了产品优化效率，而不会延缓迭代。

总结
合理运用灰度发布和A/B测试，对于PM来讲，是必须要掌握的核心技能之一，我们每天都在研究、体验、设计产品，有时会想当然的觉得这个流程不复杂，这个操作很简单，用户应该上来就会用，不知不觉间就把我们思维强加给了用户。细节决定成败早已不是空谈，对于任何可能影响到用户体验的地方，都应该防患于未然，已经被无数优秀的产品证明，用户粘性是最重要的。

分桶测试(bucket testing BTS)
诸位看官可能已经意识到了，如何优化一个搜索产品，实际情况应该比我上面说的更加复杂，这真是一个坏消息；不过我们也有一个好消息，因为对于这个问题的答案，业界已经有答案了，这就是分桶测试(bucket testing)，简称BTS。

所谓的分桶测试，是让不同的用户在访问特定的互联网产品的时候，由系统来决定用户的分组号（我们称为bucket id），然后根据分组号，令用户看到的是不同的产品版本，用户在不同版本产品下的行为将被记录下来，这些行为数据通过数据分析形成一系列指标，而通过这些指标的比较，最后就形成了各版本之间孰优孰劣的结论。

A/B测试 (A/B Testing)
分桶测试的最简单形式，称为A/B testing。即设定一个基准桶，再设定一个或以上的测试桶。然后考察测试桶与基准桶之间在各项指标上的差异，最后确定测试桶的效果。这种方法论，很容易在现实生活中找到影子。其实，改革初期建立的深圳特区，就是一场伟大的A/B testing，基准桶就是中国内地，测试桶就是深圳，当时各自的用户量是9亿 vs 30万（以当时的人口计算）。对于A/B testing而言，测试桶的用户量、流量都不会太大，这是为了确保BTS万一失败，对于整体系统的影响尽量小。当然，测试桶的用户量、流量也不能太少，否则测试效果容易受到未知因素的干扰，而变得不稳定。对于A/B testing而言，判断测试组与基准组孰优孰劣非常简单，只要将二者的指标进行对比即可。但是，如果版本中包含多个因素，那么确定每个因素的贡献，就不好评估了。这就好比，我们不能仅仅根据内地与深圳的GDP差异，就能断定是因为当时良好的投资环境，还是地理因素，或其它什么因素，是导致了深圳当时成功的主要因素。所以，利用A/B测试，我们往往只能知道how，而不能知道why。

多变量测试 (Multivariate Testing)
分桶测试的高级形式，是多变量测试。在多变量测试中，每个可以改变的地方称为因素，而每种因素的可能具有的状态称为水平。比如，你想同时改变某个搜索产品的按钮颜色、排序算法、索引数据这3个地方，那你需要一个3因素的多变量测试。如果，按钮的颜色为3种，那“按钮颜色”这个因素是3水平的。多变量测试允许你在同一时间测试多个要素处于不同水平时对于搜索产品的影响。通过多变量测试，你能十分清楚的看到不同的变化组合，对最终效果的影响。

举例而言，如果对某个搜索产品进行BTS测试的范围为：3种按钮颜色、2种排序算法和2种索引数据，那么该如何确定效果最佳的搭配呢？一般，我们会进行排列组合，产生不同的版本，使得每个版本对应一种水平的组合，这样我们就要构造322=12种版本参加BTS测试。接下来我们只要确定好每个版本的流量分配即可，即哪些桶对应哪个版本。

最后，也是最有难度的地方在于，如何通过各版本的指标分析，来确定哪个版本最好、每个因素贡献程度以及结论的可靠性。这将比A/B测试要复杂的多，建议各位看官在有兴趣尝试之前，回顾一下统计学的假设检验、实验设计方面的知识。限于篇幅，这里我们就不展开。

最后说明下，多变量测试的威力在于同一时间内可以进行多个因素的测试，可以为我们节省时间，但在使用这个工具的时候，切忌贪心，不要同时进行太多因素的测试。这是因为，在一定时间内，网络流量是有限的，而同时进行太多的测试，就要创建大量的版本，这将摊薄每个版本能够得到的流量。而流量不足时，会导致统计指标的可靠性变差。

done！