火山引擎DataTester：小改动带来大收益，A/B实验助力幸福里APP精准优化

Posted 2023-05-22 字节跳动数据平台

 

幸福里APP是抖音集团旗下开发运营的集内容、社区、工具于一体的房产信息综合平台，基于个性化推荐引擎向用户推荐优质的房产内容房源信息。本文将介绍幸福里APP应用火山引擎A/B测试DataTester完成产品体验优化，并解决实验流量过度曝光的案例。

 

幸福里APP在整理用户反馈时，发现了一个产品使用体验上的问题：用户在浏览房源详情页时，有时会遇到「切换头图」卡顿的情况。而对于房产APP的业务开展而言，尤其在新房、租房和二手房售卖业务上，APP详情页的头图展示是重中之重，C端的使用用户一般都会通过查看头图的图片、视频等内容，来对房屋情况进行预览，进而决定是否要继续进行咨询等操作。

 

针对「切换头图」卡顿的问题，幸福里APP决定新增一项技术优化：在展示头图图片时，将预先下载下一张图片，避免用户滑动时再开始下载，导致图片展示延迟；该项优化将通过火山引擎DataTester开启A/B实验，与优化前的版本进行对比，观测技术优化上线后的效果。

 

优化方向确认后，幸福里APP还有一个问题需要解决。由于APP详情页头图的位置入口相对较深，需要多次点击和跳转，针对比较深的入口开启A/B实验，有一个A/B实验的“坑”——实验流量过度曝光(Over Exposure)需要避开。实验流量过度曝光是指在开设实验时，由于实验入口位置较深，可能导致大量并没有体验到实验版本功能的用户被计入到了实验指标的分母中，导致指标值被稀释的情况叫做实验过度曝光。

 

幸福里APP在这里接入了DataTester SDK实验设置精准曝光，将“用户在进入新房、租房、小区、户型详情页时”设置为用户进组时机，达到对用户进组时机的精确把控。

 

火山引擎DataTester设有专门能力应对A/B实验过度曝光的场景，通过 SDK 开启实验的客户端，同样会在用户启动时从DataTester平台获取实验参数。然而在用户触达实验时，SDK 会以上报 vid 的方式向DateTester平台进行确认，DataTester收到确认后才会将该用户实际纳入最终指标的计算，从而从实验流量中过滤掉了没有实际触达实验的用户。

 

接下来，幸福里APP的A/B实验的技术优化方案是：

• 在展示头图图片时，预先下载下一张图片，避免滑动后再下载导致图片展示延迟
• 在显示一个图片时，先判断该图片是否下载成功优化

 

对照组为线上原有方案，实验组为技术优化方案，各赋予50%流量，在用户进入新房、租房、小区、户型详情页时触发实验曝光。

 

最终，DataTester的A/B实验结果显示，产品数据的提升超出了幸福里APP在实验设计时的预期。在优化方案上线后，用户看到头图的时间平均会缩短一半，幸福里房源曝光和点击、APP使用时长、用户留存及活跃天数，各项核心指标均有显著提升。幸福里研发人员在采访时说：“本身是一个小的技术优化，预期是提升用户体验，减少用户看见图片的等待时间，最终发现头图加载的优化也对大盘带来了正向的收益”。

 

根据这个方案的收益情况，幸福里也将此项技术优化推广进入了幸福里所有的业务线，同时也加入了产品的基础组件中。在最后，幸福里研发人员也分享了一些应用火山引擎DataTester开A/B实验的心得和体会：

1. 开实验前要明确实验类型、实验受众、曝光时机、技术指标统计口径等，避免实验不达预期要重开。
2. 实验指标数据不达预期时不要急，可以看看MDE值，拆维度（城市、新老用户、系统等）分析，可能会有意想不到的收获。

 

DataTester是火山引擎数智平台旗下产品，能够深度耦合推荐、广告、搜索、UI、产品功能等多种行业场景需求，为业务增长、转化、产品迭代，运营提效等各环节提供科学的决策依据，让业务真正做到数据驱动。目前，火山引擎DataTester已经服务了美的、得到、凯叔讲故事等在内的上百家标杆客户，将成熟的 " 数据驱动增长 " 经验赋能给各行业。

火山引擎DataTester 私有化部署实践经验

作为一款面向ToB市场的产品——火山引擎A/B测试（DataTester）为了满足客户对数据安全、合规问题等需求，探索私有化部署是产品无法绕开的一条路。

在面向ToB客户私有化的实际落地中，火山引擎A/B测试（DataTester）也遇到了字节内部服务和企业SaaS服务都不容易遇到的问题。在解决这些问题的落地实践中，火山引擎A/B测试团队沉淀了一些流程管理、性能优化等方面的经验。

本文主要分享火山引擎A/B测试当前的私有化架构，遇到的主要问题以及从业务角度出发的解决思路。

火山引擎A/B测试私有化架构

架构图整套系统采用 Ansible+Bash 的方式构建，为了适应私有化小集群部署，既允许各实例对等部署，复用资源，实现最小三节点交付的目标,，又可以做在线、离线资源隔离提高集群稳定性。集群内可以划分为三部分：

1. 业务服务: 主要是直接向用户提供界面或者功能服务的, 例如实验管理、实验报告、OpenAPI、数据接入等。

2. 基础服务: 不直接面向用户,为上层服务的运行提供支撑,例如支持实验报告的计算引擎、为指标创建提供元信息的元信息服务;基础服务同时还会充当一层对基础设施的适配,用来屏蔽基础设施在 SaaS 和私有化上的差异, 例如 SaaS 采用的实时+离线的 Lambda 架构, 私有化为了减少资源开销,适应中小集群部署只保留实时部分, 计算引擎服务向上层屏蔽了这一差异。

3. 基础设施: 内部团队提供统一私有化基础设施底座 minibase,采用宿主机和 k8s 结合的部署方式,由 minibase 适配底层操作系统和硬件, 上层业务直接对接 minibase。

私有化带来的挑战

挑战 1：版本管理

传统 SaaS 服务只需要部署维护一套产品供全部客户使用，因此产品只需要针对单个或几个服务更新，快速上线一个版本特性，而不需要考虑从零开始搭建一套产品。SaaS 服务的版本发布周期往往以周为单位，保持每周 1-2 个版本更新频率。但是，在私有化交付中，我们需要确定一个基线版本并且绑定每个服务的小版本号以确保相同版本下每套环境中的交付物等价，以减轻后续升级运维成本。通常，基线版本的发布周期往往以双月为单位。

版本发布周期

由于私有化和 SaaS 服务在架构、实现、基础底座上均存在不同，上述的发布节奏会带来一个明显的问题：

团队要投入大量的开发和测试人力集中在发版周期内做历史 Feature 的私有化适配、私有化特性的开发、版本发布的集成测试，挤占其他需求的人力排期。

为了将周期内集中完成的工作分散到 Feature 开发阶段，重新规范了分支使用逻辑、完善私有化流水线和上线流程，让研发和测试的介入时间前移。

解法：

1、分支逻辑

分支管理

SaaS 和私有化均基于 master 分支发布，非私有化版本周期内不特别区分 SaaS 和私有化。

私有化发布周期内单独创建对应版本的私有化分支，发布完成后向 master 分支合并。这样保证了 master 分支在任何情况下都应当能同时在 SaaS 环境和私有化环境中正常工作。

2、发布流水线

功能上线流程

发布流水线

内部搭建一套私有化预发布环境，建设了一套流水线，对 master 分支的 mr 会触发流水线同时在 SaaS 预发布环境和私有化预发布环境更新最新 master 分支代码，并执行自动化回归和人工回归测试。这样做的好处在于：

• 推动了具体 Feature 的研发从技术方案设计层面考虑不同环境的 Diff 问题，减少了后期返工的成本

• 测试同学的工作化整为零,避免短时间内的密集测试

• 减少研发和测试同学的上下文切换成本，SaaS 和私有化都在 Feature 开发周期内完成

挑战2：性能优化

火山引擎 A/B 测试工具的报告计算是基于 ClickHouse 实现的实时分析。SaaS 采用多租户共用多个大集群的架构，资源弹性大，可以合理地复用不同租户之间的计算资源。

私有化则大部分为小规模、独立集群，不同客户同时运行的实验个数从几个到几百个不等，报告观测时间和用户习惯、公司作息相关，有明显的峰谷现象。因此实验报告产出延迟、实时分析慢等现象在私有化上更加容易暴露。

解法：

1、 实验报告体系

首先，介绍下火山引擎 A/B 测试产品的实验报告体系。以下图的实验报告为例:

从上往下看产出一个实验报告必要的输入包含:

• 分析的日期区间及过滤条件

• 选择合适的指标来评估实验带来的收益

• 实验版本和对照版本

• 报告类型, 例如:做多天累计分析、单天的趋势分析等

指标如何定义呢?

组成指标的核心要素包括:

• 由用户行为产生的事件及属性

• 预置的算子

• 四则运算符

即对于一个用户的某几个行为按照算子的规则计算 value 并使用四则运算组合成一个指标。

由此，我们可以大概想象出一个常规的 A/B 实验报告查询是通过实验命中情况圈出实验组或对照组的人群，分析这类群体中在实验周期内的指标值。

由于 A/B 特有的置信水平计算需求，统计结果中需要体现方差等其他特殊统计值，所有聚合类计算如：求和、PV 数均需要聚合到人粒度计算。

2、 模型优化

如何区分用户命中哪一组呢?

集成 SDK 调用 A/B 分流方法的同时会上报一条实验曝光事件记录用户的进组信息，后续指标计算认为发生在进组之后的事件受到了实验版本的影响。举个例子：

进入实验版本 1 的事件 A 的 PV 数是 2，UV 数是 1，转化为查询模型是:

上述模型虽然最符合直觉，但是存在较多的资源浪费:

• 曝光事件和普通事件存储在一张事件表中量级大

• 曝光事件需要搜索第一条记录，扫描的分区数会随着实验时间的增加而增加

• 曝光事件可能反复上报，计算口径中仅仅第一条曝光为有效事件

针对上述问题对计算模型做出一些优化，把曝光事件转化为属性记录在用户表中，新的模型变化为:

这么做带来的优点是:

• 用户表不存在时间的概念,数据增长=新用户增速,规模可控

• 用户表本身会作为维度表在原模型中引入,这类情况下减少一次 join 运算 模型优化后经测试 14 天以上实验指标多天累计报告查询时长减少 50%以上，且随实验时长增加提升。

3、 预聚合

私有化部署实施前会做前期的资源预估，现阶段的资源预估选择了“日活用户”和“日事件量”作为主要输入参数。这里暂时没有加入同时运行的实验数量是因为：

一是，我们希望简化资源计算的模型。

二是，同时运行的实验数量在大多数情况下无法提前预知。

但是该公式会引入一个问题：相同资源的集群在承载不同数量级的实验时计算量相差较大。实验数量少的场景下，当下数据处理架构轻量化，计算逻辑后置到查询侧,，指标计算按需使用，大大减轻了数据流任务的压力。

但是假设集群中同时运行 100 个实验，平均每个实验关注 3 个指标加上实验的进组人数统计，在当前查询模型下每天至少扫描事件表 100*(3+1)次，如果再叠加使用自定义过滤模板等预计算条件，这个计算量会被成倍放大,直到导致查询任务堆积数据产出延迟。

重新观察实验报告核心元素以及指标构成能发现:

• 指标、报告类型、实验版本是可枚举且预先知晓的

• 实验命中和人绑定,版本对比先划分出进入对照组和实验组的人,然后做指标比较

• 基于假设检验的置信水平计算需要按人粒度计算方差

• 现有的指标算子均可以先按人粒度计算（按....去重除外）

是否能够通过一次全量数据的扫描计算出人粒度的所有指标和实验版本？

答案是可以的：扫描当天的事件数据,根据实验、指标配置计算一张人粒度的指标表 user_agg。

通过 user_agg 表可以计算出指标计算需要的 UV 数、指标的统计值、指标的方差。如果对 user_agg 表的能力做进一步拓展,几乎可以代替原始表完成实验报告中 80%以上的指标计算,同时也很好地支持了天级时间选择切换、用户属性标签过滤等。

修改后的指标计算模型

通过经验数据，一个用户平均每天产生的事件量在 100-500 条不等，聚合模型通过少数几次对当天数据的全表扫描得到一张 1/100-1/500 大小的中间表，后续的指标计算、用户维度过滤均可以使用聚合表代替原始表参与运算。当然考虑到聚合本身的资源开销，收益会随着运行实验数增加而提高，而实验数量过少时可能会造成资源浪费，是否启用需要在两者之间需求平衡点。

挑战3：稳定性

私有化服务的运维通道复杂、运维压力大，因此对服务的可用性要求更加严格。A/B 测试稳定性要求最高的部分是分流服务，直接决定了线上用户的版本命中情况。

分流服务本身面向故障设计， 采用降级的策略避免调用链路上的失败影响全部实验结果，牺牲一部分实时性使用多级缓存保障单一基础设施离线的极端情况下分流结果依然稳定。

分流服务总体架构

我们将分流服务作为一个整体，一共使用了 3 级存储，分别是服务内存、Redis 缓存、关系型数据库。实验变动落库的同时，将变动消息写入消息队列，分流服务消费消息队列修改内存和 Redis 缓存中的实验配置，保证多节点之间的一致性和实时性。同时分流服务开启一个额外协程定期全量更新实验配置数据作为兜底策略，防止因为消息队列故障导致的配置不更新；将 Redis 视作 Mysql 的备组件，任意失效其中之一，这样分流服务即使重启依然可以恢复最新版本的分流配置，保障客户侧分流结果的稳定。

总结

火山引擎 A/B 测试（DataTester）脱胎于字节跳动内部工具,集成了字节内部丰富的业务场景中的 A/B 测实验经验；同时它又立足于 B 端市场,不断通过 ToB 市场的实践经验沉淀打磨产品来更好为内外部客户创造价值。

本文是火山引擎 A/B 测试（DataTester）团队在当前面向 ToB 客户的私有化实践中的实践分享，文中所遇到的私有化问题的破解过程也是这一产品不断打磨成熟，从 0-1 阶段走向 1-N 阶段的过程。

扫码进入「字节跳动数据平台」官方交流群，领取更多A/B测试学习资料。

点击“阅读原文”立即试用火山引擎DataTester↓