有赞ABTest系统：数据驱动增长实践

• ABTest SDK自动采集并上报性能数据。

• ABTest平台支持监控数据的计算和基于规则的异常检测，并接入有赞告警平台，实现异常告警。

五、ABTest的度量数据产出

对于业务方来说，ABTest系统的核心价值在于实验的度量数据。度量数据的产出解决的是业务方对ABTest数据价值的核心关切，即通过产出ABTest相关数据、提升数据的准确性并充分挖掘数据的意义，来科学地评价实验的可行性和有效性。

ABTest系统的数据产出主要包括ABTest数仓数据、实时报表和监控数据以及效果报表。

5.1 数据仓库数据

主要的ABTest相关数据都会维护到数据仓库，包括：

• ABTest元数据维度快照表，如应用、场景、实验和流量配置等

• ABTest日志，包括请求日志、自定义上报日志、曝光和点击日志等

• ABTest效果数据，包括原始效果数据和效果归因数据等

• 以上明细数据的ETL处理数据，包含中间层（dwd）、汇总层（dwa）以及产出层等粒度

5.2 实时报表和监控数据

目前实验的实时报表主要包括实验的请求、曝光和点击等的5分钟粒度汇总数据，基于Flink产出，主要用于展示ABTest场景的实时分流情况。

监控数据由ABTest SDK上报，经Flink处理后接入Druid，产出监控指标以供ABTest平台查询 。监控指标主要为性能数据，包括A BTest请求量、请求失败量、日志上报时延、待上报日志量、待执行和被拒绝的线程数等。ABTest平台在应用首页展示实时监控数据，同时后台会定时查询，发现异常则告警给应用负责人。

5.3 效果报表

实验效果是指用于评价ABTest实验表现是否好坏的数据指标，即实验的评价标准。效果报表是ABTest平台数据报表的核心，包含了ABTest具体实验的评价数据，如下图所示：

我们的主要工作包括：

通用效果模型

考虑有赞主要提供的是电商SaaS服务，有赞商家经营的主要目标是提升销售额。因此，我们实现了基于实验的请求→曝光+点击→成交的转化归因模型，用于产出ABTest实验的请求/曝光/点击/支付等相关指标（如请求量、点击量、支付金额）及其衍生指标（如点击率、转化率、千次曝光转化金额）的数据。这就是ABTest平台的通用效果模型，用于为ABTest场景提供默认的实验度量。

效果归因模型把曝光和点击视为“因”，成交转化视为“果”，优先级计算时直接效果优先于间接效果、浏览优于点击优于曝光、登录用户id优于前端埋点标识，并采用末次归因。

ABTest埋点规范

通用效果模型依赖于前端埋点的曝光和点击日志的上报，即实验场景只要执行了任意实验，都需要上报ABTest的埋点日志。这里的曝光和点击是指ABTest实验的曝光和点击，前端同学容易误解成前端组件的曝光和点击，导致ABTest返回不展示前端组件时而错误地没有上报ABTest日志。

• 事件参数：abTraceId（必填）、bcm（选填），均可从返回实验配置里直接透传到前端。

• 事件标识：曝光（事件标识包含view）；点击（推荐页面浏览事件即enterpage，参数写入URL，或者点击事件即事件标识包含click，二选一）。

对于ABTest接入的前端埋点成本，我们考虑使用无痕埋点的方式完全规避掉，大致方案是埋点SDK静默生成和上报pv_id并在后端实现透传。

支持次数和人数指标

由于曝光、点击、支付、点击率、转化率以及平均曝光转化金额等指标都涉及到次数和人数两种口径类型，不同的业务场景可能关注的指标类型各不相同。效果报表专门对次数和人数指标做出区分，并在前端支持查询。

特别地，针对人数指标，考虑到跨天去重，由于ABTest平台支持用户选定时间范围进行查询，一开始我们采用HyperLogLog的基数去重计数。采用基数去重的好处是可以基于天级增量数据进行累加，可以支持用户的灵活查询；缺点是存在一定误差，在某些场景比如算法优化下是不可接受的。因此我们做了支持精确去重计数的重构，基于查询截止日期回溯枚举30天来做精确人数计算。

区分直接和间接转化效果

直接效果指商品效果，效果归因时要求曝光&点击和支付都发生在同一个商品上；间接效果即店铺效果，效果归因只要求是同一个店铺。通常来说，店铺级的优化会关注店铺整体的影响即间接转化效果，而直接提升商品转化的优化则关注直接效果。

两类效果数据ABTest平台都有产出，并且在实验场景的设置中支持自定义选择。

接入自定义归因效果数据

在ABTest的实际应用场景里，不同场景可能对转化效果的口径和归因的口径等要求各不相同，比如营销插件（如优惠券）的转化效果定义为插件的核销金额，商品推荐的转化效果定义为点击进入推荐商品详情页后的成交金额。

因此，ABTest效果数据除了提供默认的通用效果模型，还支持了自定义归因效果数据的接入，允许业务方提供定制的归因数据口径；而对于重要场景的归因数据定制，我们也可以提供支持。

还有一类重要的转化效果数据，即实验引导的用户行为事件。ABTest平台计划打通埋点系统，使用户可以指定任意用户行为事件作为转化目标，从而产出用户行为转化效果。

反作弊过滤

考虑爬虫和刷单等行为及其近似行为对ABTest效果的影响，单个用户的极端行为，如大量的曝光与支付、大金额订单，都可能会给实验的评价指标带来决定性的变化。因此实验评价数据有必要对异常用户的数据进行过滤。

我们主要结合绝对值规则和分布3σ原则，对前端日志数据和支付数据进行用户过滤，ABTest平台默认展示过滤后数据，同时也支持原始数据的查询。

显著性判断

ABTest本质上是抽样实验，ABTest效果数据反映的是当前实验覆盖的用户的表现现状，考虑到样本量和随机性，实验组的效果指标比基准组好不一定能说明实验组就更好。

显著性判断就是基于统计学的假设检验方法来科学地判断同一场景下的实验两两之间到底孰优孰劣。有赞ABTest场景的样本量较大，我们采用Z检验法来做假设检验。根据检验统计量：

来计算z-score及其对应的显著性水平p-value； 通过对比p-value与指定显著性水平如95%，来判断实验组是否显著好于基准组。

六、ABTest系统的评价

ABTest解决的是选择最优策略的问题，当我们在诸多可选策略里并不清楚哪个策略是最优的时候，ABTest可以帮助我们：1）选择更优的策略；2）避免选择更差的策略。因此，ABTest的价值包含两个方面，即更优策略的价值增量和更差策略的规避风险。考虑到有赞的业务场景，我们将 极限提升GMV指标 作为ABTest系统的北极星指标。

极限提升GMV的定义为：在拥有两个及以上实验的场景中，平均请求转化金额最好的实验对最差实验的提升量相对于场景全部请求量的提升GMV之和，即：

其中， i 为拥有两个及以上实验的场景， (i,j) 为场景 i 中的实验 j ， Gmv 为归因到实验的互斥GMV， Req 为实验请求量。

极限提升GMV是一个理想的指标，度量了ABTest系统的价值。更全面的，ABTest系统的评价指标包括：

我们应该努力提升ABTest的覆盖面，并且重点投入到GMV提升量更大、影响力更高的实验场景中去。

七、展望和总结

7.1 展望

目前ABTest系统还远没达到完全成熟的状态，接下来我们会持续投入，继续努力提升ABTest系统的可用性和数据价值。重点工作包括：

1. 实现ABTest前端无痕埋点，以消除前端埋点的接入成本。

2. 增长分析接入ABTest平台，实现ABTest数据的自助分析和数据洞察，帮助业务方更好的理解数据并优化实验。

3. 更丰富的自定义转化目标，包括与埋点系统打通以及支持自定义转化目标等。

4. 上线评测报告功能，通过自动化产出实验评测报告，来给场景实验做全面充分的评价。

5. 努力提升ABTest系统在公司的影响力，让数据驱动增长成为小伙伴们的共识。

7.2 总结

A/B 测试是数据驱动增长的核心工具，我们希望通过构建ABTest系统来帮助产研小伙伴更好地做产品技术迭代和帮助商家更好地实现增长，从而也为我们接下来的数据驱动增长的探索奠定基础。本文主要介绍了A/B测试的概念、ABTest系统的设计以及我们做的一些工作与思考。由于篇幅所限，很多细节没有完整表述，欢迎有兴趣的同学联系我们一起探讨，有表述错误的地方也欢迎指正。

对于数据驱动增长中ABTest系统没有覆盖到的部分，对于基于数据增长想法的产生，我们会基于增长分析来解决，尝试跨越数据分析与业务落地的鸿沟；对于用户行为数据等的采集和挖掘，我们基于埋点与采集平台来解决，并构建有赞用户行为核心数据资产。 ABTest系统 、 增长分析平台 以及 埋点与采集平台 共同构成了数据增长团队的“增长三剑客”，我们的实践成果会继续在后续文章中介绍。