作者：子固

部门：数据中台

一、背景

有赞是一个商家服务公司，致力于帮助每一位重视产品和服务的商家成功。随着移动互联网的流量增长红利渐渐褪去，商家获得新的流量越来越困难，帮助商家实现更有效的流量转化与长期目标的增长是有赞SaaS服务的应有之义；同时，随着有赞SaaS功能的不断完善，服务的商家不断增多，而业务场景也越来越复杂，考虑到有限的研发资源，提升产品和技术的迭代效率成为当务之急。

在硅谷，增长黑客等数据驱动增长的方法论，正在帮助如Facebook、Google等如此体量的公司实现持续的业务高速增长；在国内，通过数据手段来驱动业务增长也取得了共识，数据成为赋能增长的核心手段。其中， A/B测试作为数据驱动增长的核心工具，可以有效地提升流量的转化效率和产研的迭代效率。 因此，作为数据团队，基于对数据驱动增长的思考，我们首先构建了有赞ABTest系统。

二、A/B测试概览

2.1 简介

A/B 测试是一种 对比分析 方法，通过对流量进行细分和随机实验，并监控和跟踪实验效果，来判断实验所代表的策略的可行性和有效性。

  • 对比：通过对流量的随机细分，来进行有效的独立随机实验，可以排除外在条件的影响，因此更加科学。
  • 分析：通过跟踪和分析实验的事实效果数据，来判断实验的可行性和有效性，因此更加精确。

如下图所示，示例 A/B 测试将目标人群随机划分为A、B两组，分别展示不同的页面，然后通过跟踪和对比A、B两组用户的转化率，来比较A、B页面的效果；显而易见的，A组页面的转化效果好于B组页面。

相比原有基于时间的如T+30的效果对比，A/B测试可以排除时间和人为因素等外在所有因素的影响，并且保障同时进行的场景实验相互独立互不干扰，可以准确而且高效地评估实验效果。

2.2 应用场景

A/B 测试解决的是策略优化的问题，即从多个可选策略里找出最优策略。常见的应用场景包括：

  • 灰度发布：技术&算法迭代
  • 功能优化：界面模块、样式风格、交互方式等
  • 内容优化：推广海报、落地页、内容模块、文案等
  • 运营优化：运营策略、沟通话术等

2.3 核心概念

我们参考了Google的论文《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》，考虑到流量的隔离、复用以及细分，引入了以下几个核心概念：

** **

应用： 应用是对流量和系统的划分，比如商详页可以是一个应用，推荐系统也可以是一个应用。应用实现对流量的隔离，一个应用下可以包含多个场景。

场景： 场景是指需要对比不同策略的业务场景，场景是进行A/B测试的业务单元，一个场景下可以包含1个或1个以上的实验（测试中的场景通常至少包含2个实验）。流量在同一应用下的不同场景之间可以被复用。

实验： 实验代表场景下的策略，由实验配置来描述，即一份实验配置对应一个业务策略。同一场景下的实验相互之间是互斥的，场景的分流结果返回且仅返回一个实验。实验的主要配置如下图所示（示例场景为ABTest平台的底部答疑提示）：

** **

流量来源： 流量来源用来指定实验流量细分的粒度和比例，流量来源可以是具体的上一层某个实验，也可以是不指定实验即来源于大盘流量。一个实验可以有一个或多个流量来源。

2.4 增长测试迭代

A/B 测试通常是一个持续的迭代过程，包含5个步骤，即产生实验想法、评估实验优先级、设计和开发实验、分析数据以及应用结果。《硅谷增长黑客实战笔记》将其视为一个数据驱动增长的标准流程，因此我们也称之为增长测试迭代流程。

  1. 产生实验想法。产生实验想法是进行实验的第一步，要求尽可能多地提出有可能提升业务目标的实验想法。
  2. 评估实验优先级。由于产品研发资源是有限的，不同的实验想法对于提升业务目标的效果也各不相同，我们需要评估实验想法的优先级，优先选择产出大、置信度高且容易实现（即ICE标准）的想法来进行尝试。ABTest系统通常假设实验想法已确定，实验想法的产生和评估我们会在增长分析平台里实现（将在后续文章中介绍）。
  3. 设计和开发实验。主要包括：1）确定实验变量和分流策略；2）在ABTest平台上配置应用、场景、实验以及流量来源；3）根据示例代码，完成ABTest SDK接入；4）测试、验证并上线应用和实验场景。
  4. 分析数据。主要包括：1）确定实验评价的核心度量指标；2）配置通用数据度量模型，或者接入自定义度量数据；3）查看ABTest平台效果报表，判断试验的有效性和显著性。
  5. 应用结果。判断最优实验，并通过实验100%切流上线或者实验下线来应用实验结果。

三、ABTest系统设计

3.1 交互流程

ABTest系统主要包括三个部分，分别为ABTest平台、ABTest SDK以及数据流。ABTest 系统交互流程如下图所示：

3.2 ABTest平台

ABTest平台是用户（管理员）与ABTest系统的主要交互接口，主要提供以下功能：

  • ABTest元数据管理。用户可以在ABTest平台上完成完备的元数据管理操作，包括应用、场景与实验的创建、编辑和删除以及配置的发布等。
  • ABTest接入的开发和测试支持。用户可以方便地查看完整可用的接入示例代码，可以输入分流用户标识进行测试，以及查询实时日志等。
  • 实时报表和离线效果报表。实时报表包含实时请求、曝光和点击等数据，效果报表支持实验的请求/曝光/点击/转化等相关指标的对比，同时支持点击率、转化率、千次曝光转化等指标的显著性判断。
  • 异常监控和告警。平台实时监控 SDK 上报的 ABTest 请求数、失败数和延迟时间等数据，一旦发现异常即发出告警。

3.3 ABTest SDK

考虑到目前有赞的技术栈现状，ABTest系统提供了Java和Node两种客户端SDK。ABTest SDK主要实现以下3种能力：

  • 实验配置动态分发。SDK实现了针对场景标识+用户分流标识的一致性哈希算法，根据场景的实验流量配置，进行实验配置的动态分发。
  • 上报ABTest请求日志、业务自定义日志以及监控日志。
  • 基于ABTest埋点规范生成前端埋点标识。SDK 生成包括abTraceId（请求唯一标识）和bcm（请求结果标识）等追踪标识，用以透传到前端埋点来追踪用户行为。

3.4 数据流

数据流负责收集ABTest相关的日志并产出实时和离线报表数据，如下图所示：

主要涉及以下数据组件：

  • NSQ：收集SDK上报的ABTest后端请求日志和自定义上报日志
  • Kafka：收集前端埋点日志和NSQ后端日志
  • Flink：实时数据处理，产出实时报表数据
  • Hive/Spark：离线数据处理，产出实验效果数据和评价数据
  • HBase：存储实时报表和离线报表的数据，并支持ABTest平台查询
  • Druid：存储ABTest实时监控数据和抽样日志，并支持ABTest平台查询

四、ABTest的可用性保障

业务方接入ABTest会有两个核心关切，包括 ABTest接入成本与易用性、 ABTest数据价值，即业务方希望以尽量低的成本简单可靠地接入ABTest，然后获取准确且充分的ABTest度量数据。

可用性保障解决的是ABTest接入成本与易用性的问题。我们的工作主要包括提升平台易用性、优化SDK、开发和测试方案支持以及监控和告警等方面。

提升平台易用性

  • 支持完备的ABTest元数据管理，实现较好的用户体验
  • 实现应用级的角色和权限
  • 支持场景修改配置的发布和审批
  • 支持实验的商家id或者用户分流标识的白名单

优化Java和Node SDK

  • 优化SDK性能。考虑到商详页Node端的场景等对CPU性能比较敏感，我们使用了很多方法来优化计算性能，包括基于推送来更新配置、使用多级缓存、简化计算链路和逻辑、后端日志批量上报等（对于极端性能敏感场景，可以使用前端分流的方案）。
  • 实现客户端配置自动化和透明化。例如NSQ的配置和上报日志的开关等，均通过ABTest平台推送来配置和更新，用户（开发）在代码层面不用关心。SDK因此也不依赖于用户的配置而可以实现一些对用户透明的能力，比如监控日志上报等。
  • 优化一致性哈希算法。实验流量配比基于权重值计算，支持最细粒度为 1/16384 的流量划分，基于MurmurHash和模数映射实现一致性哈希，并尽量降低因流量切换带来的体验不一致的影响。

开发和测试方案支持

  • 支持分别针对Java和Node端的示例代码，包括引入代码库、初始化、获取实验配置以及前端埋点等。
  • 支持daily、QA、预发、生产等4种应用环境。
  • 支持输入分流用户标识获取实验配置，以测试和还原A/B分流结果。
  • 支持实时日志明细查询，查询条件包括日志类型、实验以及以及分流用户标识等。

监控和报警

  • 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平台查询。监控指标主要为性能数据，包括ABTest请求量、请求失败量、日志上报时延、待上报日志量、待执行和被拒绝的线程数等。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效果的影响，单个用户的极端行为，如大量的曝光与支付、大金额订单，都可能会给实验的评价指标带来决定性的变化。因此实验评价数据有必要对异常用户的数据进行过滤。

我们�