搭建企业级 AB/Testing 平台实践
什么是AB测试？
在现实的产品迭代场景中，我们经常会遇到多个方案的选择的问题，在这里迭代的可以是UI界面，可以是算法策略。简单来说就是为同一个产品目标制定两个方案，一部分用户走A方案，另一部分走B方案，然后通过日志记录用户的使用情况，并通过结构化的日志数据分析相关指标，如点击率、转化率等，从而得出哪个方案更符合预期设计目标，并最终将全部流量切换至符合目标的方案。
AB测试的价值？
- 为评估产品优化效果提供科学的证据，量化收益
- 判断方案的好坏，不断迭代优化，提升企业变现能力
- 科学性的实验能够提升组织在产品层面的决策能力
企业级AB/Testing平台实现
整体架构
客户端实验权衡
实验配置下发是指 各变量的配置，配置描述了变量的行为应该是怎样的。
a) 最简单的架构。
优点： 实现简单，服务端实验和客户端实验都可采用
缺点： 业务需要关注AB的显式调用； 每次调用都会有一个时间delay（除非找个恰当的时间 否则影响用户体验）
b) 利用“边缘网络”，一般是一个负载均衡服务器的角色，这个角色还提供了分流的功能
优点：符合一般网站的架构，业务无需关注显式的AB调用
缺点：不合适客户端实验，因为客户端很多交互发生在本地而不发起网络调用
c) SDK
优点： 业务无需关注显式的AB调用。非常适合于客户端实验和服务端实验。在前端各个组件间不需要传递AB变量，随用随调（有缓存）
缺点： 实现较为复杂，需要引入前端人力
实验期间的目标
实验设计时的目标：
- 希望尽快得到实验结论，尽快决策
- 希望收益最大化，用户体验影响最小
- 希望实验结论可靠
多实验存在相互影响的实验设计
多团队合作中，经常遇到多业务交集的问题，以我近期主要负责的春节活动为例，老板会问：
- 春节活动-明星红包子活动贡献了多少 DAU？春节活动-家乡卡子活动贡献了多少 DAU？
- 春节活动总共贡献了多少 DAU？
严谨一点，我们采用了 AB 实验的方式核算，最终可能会发现一个问题：春节活动各个子活动的贡献之和，不等于春节活动的贡献，为什么呢？
- 有的时候，活动 A 和活动 B，有着相互放大的作用，这个时候就会 1+1 > 2
- 还有的时候，活动 A 和活动 B，本质上是在做相同的事情，这个时候就会 1+1 < 2
这个时候，我们准确量化春节活动的贡献，就需要一个【贯穿】所有活动的对照组，在 AB 实验系统中通俗称作贯穿层。
这样分层后，我们可以按照如下的方式量化贡献：
- 计算春节活动的整体贡献：实验填充层-填充层填充组 VS 贯穿层-贯穿层填充组
- 计算活动 A 的贡献：活动 A 实验层中，实验组 VS 对照组
- 计算活动 B 的贡献：活动 B 实验层中，实验组 VS 对照组
业务迭代的同时，如何与自身的过去比较
上面谈到了【贯穿层】的设计，贯穿层的设计其实不但可以应用在多个活动的场景，有些场景，我们的业务需要和去年或上个季度的自身对比，同时业务还不断在多个方面运用 AB Test 迭代。
类似与上面这种层次设计，在推荐系统中较为常见，在某一些产品或系统中，贯穿层不能够完全没有策略，那么采用去年或上个季度的策略，代表着基准值，从而量化新一个周期的增量贡献
我们可以量化：
- 每个小迭代对整个系统的贡献：实验层中的实验组 VS 对照组
- 周期内，系统全部迭代与上个周期的比较：实验填充层 VS 贯穿层 1（或贯穿层 2）
- 同时，可以量化去年策略的自然增长或下降，以衡量旧有系统是否具有长期的适用性（作为系统设计者，更应鼓励设计具有长期适应性的系统）：贯穿层 1（上个季度的策略）VS 贯穿层 2（去年的策略）
