5

前言

随着微店业务的蓬勃发展,各种业务系统纷纷上线,各类推荐、搜索调优算法应运而生。微店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虽然可以满足几乎所有的业务需求,但是还存在很多可以改进的地方,后续我们主要在实验方法和数据统计上进行进一步的探索:

  • 进行多变量实验

  • AA test

  • 数据统计的科学性

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


微店技术
430 声望122 粉丝

微店,手机开店商业模式的开创者,行业内的遥遥领先者,同时也是去中心化网络的积极探索者。