微店AB实验平台架构演进

前言

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

在完成了最初的功能需求以后，咱们陷入了思考，在这个数听说话的时代，咱们不少部门不少决策都是经过拍脑壳决定的，好比产品经理大手一挥，就随意决定了购物车按钮的颜色，究竟是黑色比红色带来的点击率高仍是偏偏相反，亦又如咱们某业务同窗想改版某个展现算法，作法很粗暴，两个版本各跑半个月，观察是否能够进行变动。在深刻了解了整个公司的AB情况以后，发现存在一些共性的情况：

一、每一个产品线独立一套，或者压根就没有AB
二、独立设计开发、维护
三、支持少许规则
四、实验缺少严谨性
五、大多使用配置上线

上述情况，反应出当时微店AB存在的问题：资源浪费、人力占用、缺少灵活性、结果置信度低、周期长等等。
针对上述广泛存在的问题，咱们推荐团队提出设计一套通用的AB测试平台：Flood。Flood原意是洪流，咱们就是要控制滚滚而来的访问洪流，让其按照咱们设定的“轨道”去运行。

平台架构演进

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

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

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

流量切割模型

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

一、同一个业务系包含多个实验并向的进行，好比前端页面须要改版，后端推荐策略须要同时在线AB测试等。
 二、流量能够按照一些规则进行切割，业务组内能够共享流量。

基于这两个强需求，咱们参考了google的流量切割模型，见参考[1]。流量分域分层模型，在每一个流量域以内，流量是互不干扰的，在每一个流量域以内能够分层，知足不一样层次的AB实验。
流量切割模型以下所示：

踩过的一些坑

一、流量切割的准确性和稳定性

在具体的实践中，发现用来路由的用户ID并非均匀分布，直接分流会形成流量不许确。因此不能依赖分流id自身的分散度，最好将id进行打散操做，可是这样会带来后续统计的问题，须要提早设计好。不少场景下，对于相同的用户id，在不切换流量的状况下返回的结果应当一致，既可重入，不然会给用户形成极大的疑惑。好比推荐算法每次一刷新返回的都是彻底不一样的商品推荐。

二、实验碰撞
在进行分层实验时，常常会碰到以下问题：

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

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

三、流量扩张
假设有三个桶，初始流量为：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虽然能够知足几乎全部的业务需求，可是还存在不少能够改进的地方，后续咱们主要在实验方法和数据统计上进行进一步的探索：

• 进行多变量实验

• AA test

• 数据统计的科学性

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