数据驱动增长的核心工具——A/B测试概览

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

在硅谷，增长黑客等数据驱动的增长方法正在帮助以下规模的公司： 核心手段。 其中，A/B测试作为数据驱动增长的核心工具，可以有效提高流量的转化效率和产学研的迭代效率。 因此，作为数据团队，基于数据驱动增长的思考，我们首先构建了有赞系统。

2. A/B 测试概述

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

如下图所示，示例A/B测试将目标人群随机分为A、B两组，分别展示不同的页面，然后跟踪比较A、B组用户的转化率，以比较转化情况A页和B页的速率。效果； 显然，A组页面的转化效果要优于B组页面。

与原有的T+30等基于时间的效果比较相比，A/B测试可以消除时间、人为因素等所有外部因素的影响，保证同时场景实验相互独立、互不干扰。相互配合，使其准确、高效。 来评估实验结果。

应用场景

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

核心理念

我们参考了论文《：更多》，考虑到流量的隔离、复用和切分，引入了以下核心概念：

应用：应用是流量和系统的划分。 例如，业务详情页面可以是一个应用程序，推荐系统也可以是一个应用程序。 应用实现流量隔离，一个应用可以包含多个场景。

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

实验：实验代表场景中的策略，并通过实验配置来描述。 也就是说，一种实验配置对应一种业务策略。 同一场景下的实验是互斥的，返回该场景的拆分结果并且只返回一个实验。 实验主要配置如下图所示（示例场景为平台底部的问答提示）：

流量来源：流量来源用于指定实验流量分割的粒度和比例。 流量来源可以是上层的具体实验，也可以不指定实验，而是来自整体流量。 一项实验可以有一个或多个流量源。

生长测试迭代

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

产生实验想法。 产生实验想法是进行实验的第一步，需要提出尽可能多的有可能改善业务目标的实验想法。

评估实验优先级。 由于产品研发资源有限，不同的实验思路对于改善业务目标的效果不同。 我们需要评估实验想法的优先级，优先考虑那些产出大、置信度高、易于实施（即ICE标准）的想法去尝试。 系统通常假设实验想法已经确定，我们将在生长分析平台中实现实验想法的生成和评估（后续文章将介绍）。

设计和开发实验。 主要包括：1）确定实验变量和导流策略； 2）在平台上配置应用、场景、实验和流量来源； 3）根据示例代码完成SDK接入； 4) 测试、验证和启动应用程序和实验场景。

分析数据。 主要包括：1）确定实验评价的核心测量指标； 2）配置通用数据测量模型，或访问自定义测量数据； 3）查看平台效果报告，判断实验的有效性和意义。

应用结果。 通过100%断流上线或离线来确定最佳实验并​​应用实验结果。

3.系统设计交互流程

系统主要由平台、SDK、数据流三部分组成。 系统交互流程如下图所示：

平台

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

软件开发工具包

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

数据流

数据流负责收集相关日志并生成实时和离线报告数据，如下图所示：

主要涉及以下数据组件：

4. 可用性保证

业务侧接入有两个核心关注点，一是接入成本和易用性，二是数据价值。 即业务方希望以尽可能低的成本实现简单、可靠的接入，进而获得准确、充足的测量数据。

可用性保证解决了接入成本和易用性问题。 我们的工作主要包括提高平台的可用性、优化SDK、开发和测试解决方案支持、监控和报警等。

提高平台可用性

优化Java和Node SDK

开发和测试解决方案支持

监控和警报

5. 指标数据输出

对于业务方来说，系统的核心价值在于实验测量数据。 度量数据输出解决了业务方对数据价值的核心关注，即通过产生相关数据来科学评估实验的可行性和有效性，提高数据准确性，充分挖掘数据的意义。

系统的数据输出主要包括数据仓库数据、实时报表和监控数据、性能报表等。

数据仓库数据

数据仓库中将维护主要相关数据，包括：

实时报告和监控数据

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

监控数据由SDK上报，经过Flink处理后连接到Druid，产生监控指标供平台查询。 监控指标主要是性能数据，包括请求量、请求失败量、日志上报延迟、待上报日志量、待执行和拒绝的线程数等。平台在应用首页展示实时监控数据，并且会在后台定期查询数据。 如果发现任何异常情况，将会向应用负责人发送警报。

绩效报告

实验结果是指用来评价实验表现好坏的数据指标，即实验的评价标准。 性能报告是平台数据报告的核心，包含具体实验的评估数据，如下图所示：

我们的主要工作包括：

通用效应模型

考虑到有赞主要提供电商SaaS服务，有赞商家的主要目标是提升销量。 因此，我们实现了基于实验的请求→曝光+点击→交易的转化归因模型，用于生成实验请求/曝光/点击/支付等相关指标（如请求量、点击量、支付金额）和他们的衍生指标数据（例如点击率、转化率、每千次展示的转化量）。 这是该平台的通用效果模型，它提供了场景的默认实验指标。

效果归因模型将曝光和点击视为“因”，将交易转化视为“果”。 在计算优先级时，直接效果优先于间接效果，浏览优先于点击，曝光优先，登录用户ID优先于前端埋点识别。 ，并使用最后的归因。

埋点规格

总体效果模型依赖于前端隐藏点的暴露和点击日志的上报。 也就是说，只要在实验场景中执行任何实验，都需要上报隐藏点日志。 这里的曝光和点击指的是实验的曝光和点击。 前端同学很容易对前端组件的曝光和点击产生误解，导致前端组件返回无显示，有时会误报日志。

至于访问的前端埋点成本，我们考虑使用无痕埋点的方式来彻底避免。 总体方案是埋点SDK静默生成并上报pv_id，并在后端实现透明传输。

支持次数和人数指标

由于曝光、点击、付费、点击率、转化率、平均曝光转化金额等指标都涉及到次数和人数两类口径，不同的业务场景可能会关注不同类型的指标。 绩效报告专门区分了次数和人数指标，并支持前端查询。

特别是对于人数指标，考虑到跨日去重，由于平台支持用户选择时间范围进行查询，所以我们最初使用了基础去重计数。 使用基础重删的优点是可以基于日级增量数据进行积累，可以支持用户灵活的查询； 缺点是存在一定的误差，在算法优化等某些场景下是不可接受的。 因此，我们重构支持精确去重和计数，并根据查询截止时间，回溯并枚举30天，做精确的人头计数计算。

区分直接和间接转换效果

直接效果是指产品效果，效果归因要求曝光、点击、付费均发生在同一个产品上； 间接效果指的是店铺效果，效果归属只需要同一个店铺即可。 一般来说，店铺层面的优化会注重店铺的整体影响，即间接转化效果，而直接提升产品转化的优化则会注重直接效果。

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

访问自定义归因绩效数据

在实际应用场景中，不同的场景可能对转化效果的口径和归因的口径有不同的要求。 例如，营销插件（如优惠券）的转化效果定义为插件核销金额，产品推荐的转化效果定义为点击进入推荐后的交易金额产品详情页面。

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

还有一类重要的转化效果数据，即实验引导的用户行为事件。 平台计划开放隐藏积分系统，让用户可以指定任意用户行为事件作为转化目标，从而产生用户行为转化效果。

防作弊过滤器

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

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

重要性判断

它本质上是一个抽样实验，性能数据反映了实验当前覆盖的用户的性能状况。 考虑到样本量和随机性，仅仅因为实验组的绩效指标优于基准组并不一定意味着实验组更好。

显着性判断是基于统计假设检验方法，科学地判断同一场景下两次实验之间的优劣。 同类场景的样本量比较大，因此我们采用Z检验方法进行假设检验。 根据检验统计：

计算 z 分数及其相应的显着性水平 p 值； 通过将 p 值与指定的显着性水平（例如 95%）进行比较，我们可以确定实验组是否显着优于基准组。

6. 系统评估

它解决了选择最优策略的问题。 当我们不知道众多可用策略中哪种策略最好时，它可以帮助我们：1）选择更好的策略； 2）避免选择更糟糕的策略。 因此，价值包括两个方面，即较好策略的价值增量和较差策略的风险规避。 考虑到有赞的业务场景，我们采用极限提升的GMV指标作为系统的北极星指标。

极限改进GMV的定义是：在有两个或两个以上实验的场景中，平均请求转化量最好的实验相对于最差实验的改进量是场景中整个请求量的改进GMV之和，那是：

其中，i是具有两个或多个实验的场景，(i,j)是场景i中的实验j，Gmv是归因于该实验的互斥GMV，Req是实验请求量。

最大提升 GMV 是衡量系统价值的理想指标。 更全面、系统的评价指标包括：

要努力提高覆盖面，重点关注GMV提升较大、影响力较大的实验场景。

七、展望及总结展望

目前，该系统还远未达到完全成熟的状态。 我们将持续投入，继续努力，提高系统的可用性和数据价值。 主要任务包括：

实现无痕前端埋点，消除前端埋点接入成本。 增长分析接入平台实现数据的自助分析和数据洞察，帮助业务方更好地理解数据并优化实验。 更丰富的自定义转化目标，包括与跟踪系统集成、支持自定义转化目标等。上线评估报告功能，通过自动生成实验评估报告，对场景实验进行全面、充分的评估。 我们努力提升系统在公司的影响力，让数据驱动增长成为合作伙伴的共识。总结

A/B 测试是数据驱动增长的核心工具。 我们希望通过搭建一个系统，能够帮助我们的产学研伙伴更好的迭代产品技术，帮助商家实现更好的增长，这也为我们下一步数据驱动的增长铺平道路。 探索并奠定基础。 本文主要介绍A/B测试的概念、系统的设计以及我们所做的一些工作和思考。 由于篇幅所限，很多细节没有详细阐述。 欢迎有兴趣的同学联系我们一起讨论。 如果演示中有任何错误，欢迎指正。

对于系统没有涵盖的数据驱动增长的部分，包括基于数据的增长思路的产生，我们会基于增长分析来解决，尽量弥合数据分析与业务实施之间的差距； 包括用户行为数据的收集和挖掘等，我们会基于增长分析来解决。 我们通过跟踪采集平台来解决这个问题，构建有赞用户行为的核心数据资产。 系统、增长分析平台、跟踪采集平台共同构成了数据增长团队的“增长三剑客”。 我们的实践成果将在后续文章中继续介绍。

最后，有赞数据中心长期招募数据增长、数据仓库、数据产品、算法、基础组件和平台系统方面的人才。 欢迎加入我们，一起享受。 如果您有兴趣，请联系我们。