前言
随着微店业务的蓬勃发展,各种业务系统纷纷上线,各类推荐、搜索调优算法应运而生。微店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
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。