微店AB实验平台架构演进

前言

    随着微店业务的蓬勃发展，各种业务系统纷纷上线，各类推荐、搜索调优算法应运而生。微店AB测试平台Flood诞生于核心推荐和搜索系统，最初想解决的问题也很简单，比如：哪种搜索精排算法比较好、哪种推荐策略带来的业务转化率更高。

在完成了最初的功能需求之后，我们陷入了思考，在这个数据说话的时代，我们很多部门很多决策都是通过拍脑袋决定的，比如产品经理大手一挥，就随意决定了购物车按钮的颜色，到底是黑色比红色带来的点击率高还是恰恰相反，亦又如我们某业务同学想改版某个展示算法，做法很粗暴，两个版本各跑半个月，观察是否可以进行变更。在深入了解了整个公司的AB状况之后，发现存在一些共性的状况：

1. 每个产品线独立一套，或者压根就没有AB

2. 独立设计开发、维护

3. 支持少量规则

4. 实验缺乏严谨性

5. 大多使用配置上线

上述状况，反应出当时微店AB存在的问题：资源浪费、人力占用、缺乏灵活性、结果置信度低、周期长等等。

    针对上述普遍存在的问题，我们推荐团队提出设计一套通用的AB测试平台：Flood。Flood原意是洪流，我们就是要控制滚滚而来的访问洪流，让其按照我们设定的“轨道”去运行。

平台架构演进

Flood整体架构大致分为三个阶段演进，第一个阶段是做作为搜索系统的内嵌模块提供服务的，支持的功能也比较有限，整体架构如下图（注：为了突出说明初始版本的AB，全面简化了搜索架构）：

第二个阶段独立出来一个通用的AB测试平台，这个阶段主要支持后端AB实验，整体架构图如下：

第三个阶段着重支持规则引擎，规则引擎支持丰富的人群定向选择，比如：支持当前网络环境是4G的浙江用户看到某个功能，同时支持前端AB测试，整体架构图如下：

流量切割模型

当时设计流量模型主要考虑了如下几点：

1.      同一个业务系包含多个实验并向的进行，比如前端页面需要改版，后端推荐策略需要同时在线AB测试等。

2.      流量可以按照一些规则进行切割，业务组内可以共享流量。

    基于这两个强需求，我们参考了google的流量切割模型，见参考[1]。流量分域分层模型，在每个流量域之内，流量是互不干扰的，在每个流量域之内可以分层，满足不同层次的AB实验。

流量切割模型如下所示：

踩过的一些坑

1. 流量切割的准确性和稳定性
   在具体的实践中，发现用来路由的用户ID并不是均匀分布，直接分流会造成流量不准确。所以不能依赖分流id自身的分散度，
   最好将id进行打散操作，但是这样会带来后续统计的问题，需要提前设计好。
   很多场景下，对于相同的用户id，在不切换流量的情况下返回的结果应当一致，既可重入，否则会给用户造成极大的疑惑。比如推荐算法每次一刷新
   返回的都是完全不同的商品推荐。
   
   

2. 实验碰撞
   在进行分层实验时，经常会碰到如下问题：

   实验名	分桶1	分桶2
   前端按钮颜色AB	A1	A2
   后端推荐策略AB	B1	B2

   这时候恰好都采用的userId作为分流依据，并且分桶流量各50%（简化问题设置），并且分流逻辑一致，这时候即使通过数据发现A1>A2，B1>B2，其实实验结果并不科学，
   只能说明A1->B1 > A2->B2。为了解决这个问题，最好采用：f(userId, salt)再进行分流，这里Flood平台salt采用的就是appId。
   
   

3. 流量扩张
   假设有三个桶，初始流量为：80%，20%，0%。简化流量切割模型：id%100，这时候假设第三个桶需要扩张10%的流量，切换前后流量区间发生很大变化，如下表：

   实验名	桶1	桶2	桶3
   切换前	0-79	80-99	无
   切换后	0-69	70-89	90-99

   切换之后实际上桶1，桶2和桶3覆盖的用户人群都发生了变化，这里最好的实践是：桶2原有流量不变，桶3从基准桶1中切换10%流量过去。

展望

目前Flood虽然可以满足几乎所有的业务需求，但是还存在很多可以改进的地方，后续我们主要在实验方法和数据统计上进行进一步的探索：

1. 进行多变量实验

2. AA test

3. 数据统计的科学性

参考

[1]  Overlapping Experiment Infrastructure: More, Better, Faster Experimentation