ABTest

在倡导数据驱动的公司中，会通过大量的数据分析来了解产品业务的进展以及做相关的决定。一个较大的产品或者策略改进上线以后，需要进行一段时间的abtest，以决定这个产品或者策略改进是否符合预期，是否要扩大流量，或者需要中止实验。

ABTest系统背景

互联网与传统软件行业的开发最大区别就是快速迭代,新增一个业务或者新增一个基于老业务的算法更新也许只是某个工程师一天的结果。在这种代码高速发布过程中, 必然存在结果和期望符合的情况,也存在不怎么符合的情况, 当然更多的是存在结果与期望不相符的情况。正是由于这个原因, 小流量上线测试是比较合理的上线方法, 上线之后必须对这份测试流量进行效果追踪,根据追踪效果做出后续决定,是继续加大流量呢,还是保持观察,或者是回滚代码。所有上述操作需要有一个系统辅助高效地解决,我理解的AbTest系统就是基于上述需求产生的。

我做ABTest的背景介绍

我所在的团队是搜索业务团队,简而言之就是把搜索引擎的匹配结果和算法的排序结果通过产品经理的意愿呈现给用户,当然除了这个基本业务还有一些和搜索相关的小业务,比如搜索提示,导航,相关词推荐等。
我在接上述业务需求的时候,可以归纳成以下两个维度的需求:

• 产品经理提出的需求一般会从业务层面上对比效果(比如搜索提示新功能上线后对搜索的影响 )
• 算法层面上的效果对比(还是上面这个例子, 搜索提示功能分流量上线之后,后面有其他人需要优化搜索提示算法，那么算法工程师就需要对比这两种算法的效果)

为了满足产品经理和算法工程师快速切换功能,快速看到效果,ABTest系统就开始逐步规划了。

设计故事

我以搜索提示ABTest举例,解释整个ABTest系统工作流程。我一开始接触搜索业务时,搜索的功能就是接受关键词,结果是匹配关键词的商品。基本业务如下图表示,方框表示功能模块走的流量范围,此时表示没有分流量测试全部走搜索基本业务。

分流量简单介绍

分流量原则上需要保证均匀性和一致性。均匀性指的是流量唯一标识符取摸后均匀地落在每个区间。举个例子,使用cookid通过标识符生成算法模块生成一个唯一标识符(uuid),我对全站流量分成100份,那么uuid%100的值0~99,必须做到每个值分配的流量几乎相同。一致性指的是某个流量生成uuid后再取摸的值是一定的,比如某个cookid经过算法模块后取摸的值为1,那么下次再次经过uuid生成算法取摸后值还是为1。大家可以百度一下保证这两个特性的算法。

50%使用搜索的用户会有搜索提示这个功能,其余只能直接搜商品。这个层次结构正好解决了搜索提示分流量上线的需求。效果追踪稳定后,搜索提示改造算法出现了,我会在原先结构上新增一份对比测试流量。