美图AB Test实践：Meepo系统

感谢阅读「美图数据技术团队」的第 8 篇文章，关注我们持续获取美图最新数据技术动态。

2008 年 11 月 4 日，奥巴马在选举中胜出，出任美国第 44 任总统。这次竞选的成功离不开其个人人格魅力，但他的竞选宣传团队的作用也不可小觑。在总统竞选页面上，他的团队用 AB 实验在 16 种方案中找到了最佳方案，将竞选页面「change」的转化率提升了 40.6%。

图 1，via www.niaogebiji.com/article-17605-1.html

图 2，via www.niaogebiji.com/article-17605-1.html

他们将图 1 中的图片或视频与图 2 中的不同文案按钮任意组合，形成 4*4 共 16 种不同方案组合，每个方案都获得一定比例的流量，观察一段时间后，从中选取转化率最高的方案应用。

回到现实生活中看看这两种场景：如果一款产品更新不经过 AB 实验就直接全流量上线，那么团队成员在上线后往往都在拼命找数据证明自己正确，即便证据牵强，只要向外发布声明「指标又提升了」，众人纷纷点赞。要知道 Google、Facebook、Microsoft 做 AB 实验的经验是 90%的新设计都不如线上版本；亦或很幸运地，你的团队成员都十分活跃有想法，各抒己见、难分高下。

在这些情况下，「用实力说话」的 AB 实验或许能帮你改造团队决策的尴尬场景。AB 实验辅助决策的场景十分广：视觉设计、页面布局、文案内容、推荐算法、灰度发布等。基于以上所述需求，结合美图的业务情况，我们搭建了美图的 AB 实验系统——Meepo。

/ Meepo 系统的架构及实现 /

系统架构

图 3

如图 3 所示是美图 Meepo 系统的系统架构图，其中 Meepo 后台提供策略的制定以及数据分析结果的展示，而 Meepo 策略服务器接收 Meepo 后台的通知策略并且对外提供服务。AB Sdk 与策略服务器进行通信，获取对应策略提供上层业务处理；统计 Sdk 负责上报打点行为数据。这个过程通过日志采集分析展示在 Meepo 后台。

值得注意的是，通过 AB SDK 携带一些机型信息上报给 AB 策略服务器，根据一定的运算返回对应的用户策略信息。SDK 经过加工处理对上层业务提供策略，上层业务根据策略执行相关的逻辑代码后会产生一些行为日志，这些行为日志通过统计 sdk 上报，我们通过数据中心得到数据，并进行分析得到版本实验的结论。

分层模型

在流量有限的情况下，如果有多个实验需求通常无法同时支撑。用同一些实验对象进行多种变量同时分析常常会出现参数耦合的现象。

为了避免参数耦合的情况，我们采用了分层模型，其整体架构如图 4 所示：

图 4

• ALLUsers：即所有的流量，以选定的标识进行区分。如在美拍中定义一个 android 类实验，allUsers 等于美拍所有的 android 设备；
• Layer：层级，每个实验都会有一个层级的概念，不能耦合的参数会划分在同一层，可以耦合的参数则划分在不同层；
• Bucket：块，为了简化流量层的划分，把每个层的流量分成若干块，同一层的实验共享这若干块的流量。

在分层模型中每个分层都拥有全部流量，在同一个分层中，多个实验共用 100% 的流量，实验之间流量互斥，即同层流量互斥、分层复用流量。

例如在同一分层中，实验 1 占用了 40%流量，则 实验 2 最多只可使用 60%流量，以此类推。

图 5

当同时运行多个实验时，如果希望实验结果尽可能精确，需要确保实验之间互不干扰，则建议将实验建立在同一分层，同一个用户只会进入该分层中的某一个实验。

如果实验 1 和实验 2 使用不同的分层，则实验 1 和实验 2 均可分配最多 100%的流量。在此情况下，同一个用户将会同时进入实验 1 和实验 2。

图 6

如果需要较多的实验流量并且可以确保试验之间互不干扰，则可以选择分层实验，同一个用户有可能会进入不同层的多个试验。

分配算法

我们存在着 imei、idfa、gid 多种用户标识可以用来确认实验，那它们是如何分配流量的呢？如图 7 所示，每一个用户标识在 Meepo 系统中都是独立的，它们各自占有 10000 份流量，互不影响，并且每一个用户标识都有不同的随机算法。

图 7

数据分析

若短时间内的数据正常，实验将继续运行至预定的结束时间，接着就可以分析和解读实验数据进而做出决策了。一般情况下 AB 实验的周期至少 1-2 周，才能保证得出较为准确的结果。接下来介绍三种数据分析方式：

• 置信区间

我们主要通过某个指标的试验版本（均值）变化值以及置信区间来判断，在这个指标上，试验版本是否比对照版本（原始版本）表现得更好。

如果置信区间同为正或同为负，说明试验结果是统计显著的。如果置信区间为一正一负，说明试验结果是非统计显著的。可以根据图 8 的实例感受一下～

图 8

• P 值显著性水平

原假设：即实验版本和对照版本数据表现无区别 备择假设：即实验版本和对照版本数据表现有显著区别

显著性水平 p 是指在原假设为真的条件下，样本数据拒绝原假设事件发生的概率。例如，我们根据某次假设检验的样本数据计算得出显著性水平 p = 0.04，这个值意味着如果原假设为真，我们通过抽样得到样本数据的可能性只有 4%。

那么，0.04 这个概率或者说显著性水平到底是大还是小，是否足够用来拒绝原假设呢？这时就需要把 p 和采用的第 I 类错误的小概率标准 α 来比较确定。假设检验的决策规则：

若 p ≤ α，那么拒绝原假设； 若 p > α，那么不能拒绝原假设。

图 9

如图 9 所示公式，如果 α 取 0.05 而 p = 0.04，说明如果原假设为真，则此次试验发生了小概率事件。根据小概率事件不会发生的判断依据，我们可以反证认为原假设不成立。

• 公式推算

/ Meepo 系统模块解析 /

图 10

Meepo 后台

AB 实验后台服务器根据后台配置以及维度匹配生成对应的策略，后台配置是由管理人员干预指定进入到哪个流量层，并确定排除参数耦合的互相影响。它的操作主要分为三大部分：配置实验、数据分析、实验操作，具体功能如图 11 所示：

图 11

SDK

SDK 模块分为客户端 SDK 与服务端 SDK，功能细节如图 12 所示：

图 12

客户端 SDK 与服务端 SDK 的区别主要分为两点：获取方式不同、获取数据不同。在获取方式上，客户端 SDK 在 app 启动的时候会判断是否为冷启动，若为冷启动会请求一次 ab 策略；而服务端启动时同步启动守护线程，1 分钟获取 1 次。在获取数据上，客户端SDK 获取到的是某个实验的某个版本的 code，即该设备可以进入的版本的 code；而服务端 SDK 获取到的是 Meepo 策略服务器中该应用的所有的实验以及该实验的分流信息，服务端可以自行分配 code。

/ 案例分析 /

接下来根据案例更加形象地感受 Meepo 系统，美图自拍应用 BeautyPlus 在修改应用墙位置的时候通过 Meepo 系统决定放在左侧还是右侧，实验过程如图 13 所示：

图 13

实验效果如图 14 所示，可以看出实验版本 2 中数据是可信的，并且提升率有4个点，可以作为新版本发布。

图 14

/ 未来展望 /

美图还在持续对 Meepo 系统进行不断优化，接下来我们主要往这个方向发展：

• 发布后数据跟踪 之后我们将会在产品发布完成后进行数据跟踪处理，项目方可以实时观察到数据变化做相应的策略变换。
• 智能化实验 目前 Meepo 需要人工创建实验，调整流量以及后续的操作同样需要人工操作。美图接下来将采用智能化处理，实现自动分配流量、判断版本的好坏以及自动发布效果较优的版本。
• 加入智能数据算法，多维度分析 同时我们也将在数据分析方面增加更多种类的算法，对数据进行多维度分析，发现更细节的变化。

（完）