随着互联网的高速发展，每天都有成千上万新应用，新功能上线。对于拥有大流量的应用来说，一个微小的页面改版或者后台推荐算法一个微小的参数调整都会带来巨大的影响，如何能够相对安全的验证这些改动是否真正有助于业务的正向提高？最容易想到做到的就是做AB实验。
A/B test 原理
AB测试是互联网领域通用的方法。将用户分成几组相似的用户群，实验组展示新版本功能，对照组展示老版本功能，根据用户反馈数据，评估新版本的好坏。
科学的AB实验要求保证每次实验只有一个变量，各组其他所有元素都必须保持一致。如果每个变量都独立切分流量会大大制约实验的效率，一是实验流量变少，得出显著结果的时间会拉长。二是可以并行的实验量受到了制约。如果不切分流量实验，无法验证效果的变化究竟是那个改动带来的。比如首页广告位优化了展示样式，后端同时也更新了推荐算法参数。那最后用户的停留时间和点击率的变化究竟是谁的贡献哪？显然就无从得知了
而目前市面上各个公司对上述问题的解决，都是基于谷歌的这篇论文《Overlapping ExperimentInfrastructure More, Better, Faster Experimentation》的理念去设计的，我目前的公司也不例外。具体见下图
对着这张图我们来讲几个概念。
1.流量正交：层与层之间流量是正交的，一份流量穿越每层实验时，都会再次随机打散，且随机效果离散。
2.流量互斥：实验在同一层拆分流量，且不论如何拆分，不同组的流量是不重叠的。
3.分层原则：通常来说有依赖关系的实验点必须划分在同一层，例如页面背景颜色和字体颜色必须在同一层，如果页面背景颜色和字体颜色都被设置成蓝色，那么我们就看不到页面上的字了），没有依赖关系的实验点可以划分在不同层，每个变量实验点只出现在一个层中，不会出现在多层中。
图中的PC，M站，APP，相当于是3个域，各个域的流量之和等于该公司的100%流量。
每个域下可以切分流量正交层，即图中示意的推荐，搜索，购物车推荐，大促推荐，商详页推荐，UI。 这6层的流量是相等的且等于APP域的流量（这里是指不考虑各个场景间流量损失的情况下，各层间应是如水流一样，流量相等。）
每一层中可以再进行具体的实验，进行流量互斥。比如在推荐里的召回层，进行切分了召回策略实验1，2，3.这个时候 召回策略1+2+3的流量之和= 召回层的流量=推荐层的流量=APP域的流量。
所以通过这样一套设计后，就可以非常高效便捷的实现多层实验的并行且相互无干扰。
什么时候不适合A/B test ?
主要是两种场景下，A/B test 会失效：
1）从测试到全量时，无法控制非实验条件不变
常见的线上产品是用户自己使用，比如你刷抖音和别人刷抖音其实是互不干扰的，抖音修改了算法在20%用户下算法效果提升，在全量用户后算法效果应该也是提升的。
但如果放量后人群间会互相影响，就难以保证A/B test 的实验效果了。比如滴滴的分单算法做了调整，一半的司机使用新算法，一半的司机使用旧算法，新算法的司机如果拿了更多的订单，就会影响其余司机。那么可能全量之后算法效果不变或者下降。
2）不能做随机性分配的场景：
典型的如商品定价策略，由于涉及大数据杀熟问题，你是不能直接做商品原价的A/B 测试的。
从A/B test 联想到经济学的外部性
之前做一些项目分析时，很容易只关注到调整部分的提升与否。就像微观经济学的假设视角，关注在任何的外部变量后，微观的变化如何，再推广至全局。但是很容易忽略的是，微观的改变，对系统中其他个体的外部性，这些外部性可能是正，可能是负，会对整个系统有影响。所以不能只因为一些变量导致这部分微观群体的收益提升了，就认为系统整体收益提升了。
举个我最近的工作例子。我对一批加价商品做了特殊的策略处理，并投放到feeds的指定坑位进行流量加权。一开始我只去关注这批商品加价后，订单的下降/提升，流量的机会成本，损失的订单收益 及加价后的收益是否能打平。
但是却忽略了这批商品对于整个feeds场景的挤压，忽略了这个场景整体的GMV变化情况。
关于A/B test就先聊到这了。A/B结果衡量P-value值等，大家可以再去自行了解，不过多介绍。下一期接着聊电商。
