其他
火山引擎 A/B 测试的思考与实践
The following article is from 火山引擎开发者社区 Author 康康
本文整理自火山引擎开发者社区 Meetup 第四期同名演讲,主要为大家介绍了为什么要做 A/B 测试、火山引擎 A/B 测试系统架构及最佳实践。
为什么要做 A/B 测试
先选定目标受众,比如一线城市的用户。 A/B 测试不可能对所有用户都进行实验,所以要进行科学抽样,选择小部分流量进行实验。 抽样之后需要对样本进行分组,比如 A 组保持现状,B 组的某一个因素有所改变。 分组之后在同一时间进行实验,就可以看到改变变量后用户行为的变化。 再根据对应实验目标的指标,比如点击率的高低,来评估实验的结果。
风险控制:小流量实验可以避免直接上线效果不好造成损失。其次,实验迭代的过程中,决策都是有科学依据的,可以避免系统性的偏差。 因果推断:我们相信 A/B 实验中的优化和改变最终能影响到线上数据以及用户的行为。在这个前提下,A/B 测试就是最好的因果推断工具。 复利效应:A/B 测试是可以持续不断进行的实验,即使一次实验提升的效果不大,但是长期下来复利效应的积累会产生很大的变化和回报。
A/B 测试系统实现
运行环境层:在最底层,服务可以运行在容器内,也可以运行在物理机上。 基础设施层:会用到关系型数据库和键值对。因为 A/B 测试要处理很大的数据量,这一层也会使用离线和实时的大数据组件。 服务层:包括实验所需的分流服务、元信息服务、调度服务等。在 A/B 测试中我们也需要标识用户,因此这一层有设备服务。为了提供多种数据查询,还有 OLAP 引擎。 业务层:包括实验管理、指标管理、Feature 管理、评估报告等。 接入层:包括 CDN、网络防火墙、负载均衡。 应用层:提供管理后台控制实验、查看报告等,SDK 调用。
业务方开发策略,确定实验内容; 枚举策略中的映射关系并在客户端实现映射关系; 创建并开启实验; 客户端已经集成了火山引擎 A/B 测试系统的 SDK,向 A/B 测试系统请求分流服务,判断用户命中哪些实验哪些版本,下发参数; 客户端从 SDK 取到参数,进行相对应的流程完成实验。
设计实验; 服务端实验的 SDK 是跟业务系统比如服务端集成在一起。客户是从其他 C 端用户直接请求业务的服务端,该服务端会在本地 SDK 做决策; 决策完之后将参数下发到下游,使策略生效。
统计分析实践
确定业务的指标体系:可以从宏观/微观、长期/短期、横向/纵向三个角度建设指标体系。 分类检验:对指标进行置信度计算的时候,并不会每次都用同一套方法,而是针对不同的指标类型(包括转化类、人均类、CTR 类等)进行不同的建模采用不同的方法。 统计修正:如果一个实验开了多个组,可能犯了多重比较的错误。还有时开完实验之后每天都会查看结果,这就犯了连续观测的错误。所以在实践中需要有一些统计修正的方法来修正行为。 基于叶贝斯体系的探索:区别于经典的假设检验,我们也在探索基于叶贝斯体系,如何评估实验效果,降低面向用户使用时候的理解门槛。在智能流量调优、模型超参数搜索等场景下有具体落地。
避免过度曝光:A/B 实验中有一个很关键的点是决策哪些样本应该进入实验。如果所有打开应用的人都能命中实验,实验结果就不会很明显。 进组和出组:假设我们对北京的用户进行了实验,有些人出差或者旅游离开北京之后还能命中实验吗?我们可以把这个决策留给实验者,让实验者自己决定是进组还是出组。 和 Feature Flag 的珠联璧合:实验之前可以把能进行实验的内容抽象成 Feature Flag,简单理解成功能开关。实验完成之后的上线或者重复实验,也可用 Feature Flag 进行管理。
字节跳动 A/B 测试最佳实践
产品本身的价值主张是什么?比如一款打车 APP 的价值主张是通过共享经济实现社会的效率提升,这个产品有没有很好地体现价值主张?可以从这一方面产生一些实验想法。 推动因素 相关性:同一个页面中如果有不相关的功能,用户大概率也不会点击,这样的设计就没有效果。 清晰度:要表达的内容(比如命名)是否足够清晰。 紧迫性:对于有时间周期的活动,可以设计一些事件营造紧迫感。 阻碍因素: 注意力分散:避免在一个页面放五花八门的信息让用户找不到重点。 焦虑性:有的地方可能给了用户很多选择,也会造成选择困难,不自觉地形成一种焦虑感,不如简单一些只设计一个选择。
正向显著:说明当前样本容量条件下,实验版本优于对照版本,实验结果和假设一致; 负向显著:说明当前样本容量条件下,实验版本不优于对照版本,实验结果和假设不一致; 不显著: 确实不显著:可以参考 MDE 指标是否符合预期,如果符合,则说明结果确实不显著。 其他原因导致的不显著:比如样本容量小,指标对应的用户行为渗透率低,实验时长较短等。在这些情况下,如果实验效果不显著,可以进一步优化实验,比如增大样本量,扩大流量、再观察一段时间积累更多进组用户等。
头部色值饱和度 字号 字重 上下间距 左右间距 底部 tab icon 结合用户调研(结果显示:年轻用户和女性用户对新 UI 更偏好)
展望
认知率和普及率在高速提升:我们之前做过一个调研,发现 A/B 测试在国内整体认知度较低,可能低到一个难以想象的数字。我们认为在未来 5-10 年内,A/B 测试的认知度可能会有 50-100 倍的提升,这个市场还是一片蓝海。 从 nice-to-have 到 must-have:现在很多人认为 A/B 测试是一个锦上添花的工具,但在数据驱动越来越重要的今天,A/B 测试是必须要掌握的工具,是企业开展业务过程中的刚需,否则在行业竞争中就会失去优势。 破圈:我们也发现 A/B 测试正在破圈。大家的印象中 A/B 测试只有互联网公司会用,但是我们在交流的过程中发现,很多传统企业虽然没有线上业务,但如果能解决数据收集的问题,A/B 测试也能满足传统企业优化的诉求。
智能化:A/B 测试目前还处在早期阶段,一些实验结论或实验洞察对数据和用户属性的利用还不是很充分。如果 A/B 测试能和统计方法、算法模型相结合,很可能提高整个行业的水平。 场景化:很多场景还没有开始使用 A/B 测试,未来更多的行业场景能和 A/B 测试相结合,让 A/B 测试更易用。 被集成:目前我们的 A/B 测试平台可以一站式管理实验、查看报告,但是一些用户的业务已经很成熟,希望 A/B 测试能够走入业务和系统,更顺滑地使用。所以 A/B 测试技术也需要提高自身被集成的能力,无缝地和各种业务、系统结合起来。
推荐阅读
《关键迭代:可信赖的线上对照实现》线上对照实验教父领衔撰写,A/B测试领域圣经之作,亚马逊、谷歌、微软和领英等公司互联网产品成功的秘诀!
扫码关注【华章计算机】视频号
每天来听华章哥讲书
书讯 | 9月书讯 | 秋天的第一本书,来了资讯 | DB-Engines 9月数据库排名:SnowFlake坐上了火箭书单 | 送你一份入门前端学习路线图干货 | 微服务设计:去中心化的技术治理与数据管理收藏 | 5G时代音视频开发利器WebRTC究竟长啥样?上新 | 【新书速递】你需要掌握的架构之道:系统设计+项目设计赠书 | 【第73期】全面拥抱 Go 语言!