OPPO互联网技术

A/B实验是很多公司的标配,在OPPO也不例。它是提供科学的数据决策的方式,帮助深入分析用户行为,支持个性化策略,同时降低产品迭代风险,达到业务快速验证、快速迭代的效果。

但在Galileo实验分析平台建设完成前,公司A/B实验的平台能力处在发展初期,功能不完善,制约业务发展,主要存在以下问题:

  1. 不支持分层实验,目前仅支持单层分桶
  2. 不支持全流程实验,多数仅支持服务端
  3. 没有统一的实验平台,流量不统一,人力浪费
  4. 缺乏灵活性,操作不方便,没有专门的分析平台,需要通过人力做各种实验指标的报表开发
  5. 结果置信度低、周期长

基于此,OPPO拉通各业务关于A/B实验方面的需求,进行抽象化和通用化,构建出了内部的Galileo A/B实验的平台,从而减少重复的资源消耗,统一流量和指标口径,并服务业务进行算法和产品的快速迭代和优化。本文主要介绍Galileo A/B实验平台在OPPO的建设和实践之路。

1. A/B系统的核心能力

从A/B实验的形态上来看,可以分为算法类、产品功能类、页面展示类等实验。从集成端看,可以分为服务端、客户端、网关等。OPPO的Galileo实验分析平台是要构建平台级的A/B能力,所以需要做一些通用化的设计和抽像,从而更好的满足不同的业务接入和场景覆盖。

站在实验生命周期的角度考虑,一个完整的实验流程一般是创建实验 —> 做实验 —> 实验效果分析 —> 调整实验的闭环,流程的示意图如下。

整个核心流程主要涉及三个阶段,创建实验和调整实验可归结为同一阶段,不同的阶段各自可以相互独立又相关,每个阶段需要提供的能力如下:

  1. 创建/编辑实验需要提供实验相关的管理,如参数、变量、版本控制、回滚,流量占比配置等一系列能力,可以抽取出一个实验管理模块;
  2. 做实验阶段主要涉及分流和埋点数据上报,分流主要通过SDK来实现,同时还需要一些服务化的能力提供些外部接口以及SDK的数据交互,埋点数据主要是实验数据的回收;
  3. 实验效果分析主要涉及指标体系的构建和实时表报的开发等一整套olap的能力。

基于整个核心的能力下面会按实验管理、分流服务、实验效果分析三大模块进行说明。

2. 实验管理

实验管理可以理解为A/B实验配置的一个web系统,因为是要构建一个通用平台,所以除了实验的相关配置,还有业务线管理、账号管理、权限管理等常规的辅助性功能。实验管理主要涉及以下部分:

  • 应用:是管理所有实验的单元体,一个应用中可以创建多个A/B测试实验。应用与iOS APP、Android APP并不一定是一一对应的关系,一个APP也可以创建多个应用管理该APP的实验,这里的应用更多的是定义特定的流量集合,比如对于OPPO的软件商店来说,可以在平台创建一个搜索流量的应用,也可以创建首页推荐、排行榜相关的流量的应用。
  • 层:是应用内流量的横向划分,可以创建多层,每层是相同的流量,通过算法实现层与层的流量正交,层中包含实验,创建实验需要指定实验层。
  • 指标:在每一个A/B测试实验中,用于对比不同实验组优劣的数据就是指标。指标是基于事件创建的,分析点击按钮的次数时,需要上报注册按钮的点击事件,可以用单个事件创建单一指标,也可以在单一指标基础上进行 + - * /和()运算得到组合指标。
  • 实验:为了验证一个新策略的效果,准备原策略A和新策略B两种方案。随后在总体用户中取出一小部分,按照预定好的算法将用户分在两个组中,使两组用户在统计角度无差别,每进行一个A/B测试时,都需要创建一个独立的实验。
  • 实验组:实验组和对照组是一组相对的概念,A/B实验通常是为了验证一个新策略的效果。假设在实验中,所抽取的用户被随机地分配到A组和B组中,A组用户在产品中体验到新策略,B组用户在实验中体验的仍旧是旧策略。在这一实验过程中,A组便为实验组,B组则为对照组。

说了实验管理涉及的各种名词概念,那么是如何将这些串联起来,完成一个实验的创建,这里使用一个完整的流程简要的描述,如下图:

除了上述的主流程功能,还有版本控制,增加版本控制,主要为了稳定性的保障和实验的快速回滚,以及可以更好观测实验在全生命周期内,参数的变化情况。

3. 分流服务

分流服务主要解决流量控制和切分,主要参考2007年谷歌发表的论文《Overlapping Experiment Infrastructure:More, Better, Faster Experimentation》确定了流量模型,划分了放量域、非重叠域、重叠域,重叠域支持分层,具体的流量模型如下图。

确定流量模型后,还需要解决如何分流的问题,即一个用户发起一个请求,如何命中实验?这涉及到分流算法、用户标识、标签、流量比例等一系列因素,这里为了突出分流的过程,结合分流算法和用户标识,抽象出了分流树。

如下图,如图示的灰绿色箭头为一次请求的完整分流过程,即一次分流,可能命中多个实验或者一个实验,也可能没有任何命中。图中的hash属于一种分流算法,目前除了支持Hash算法、还支持随机算法,也可让业务方自定义分流算法。

服务主要以SDK的方式提供服务,接入方只需要集成相应语言的SDK即可,这样可以避免不必要的网络请求,保障分流的稳定性和响应延迟。目前分流支持集成在客户端、网关和服务端,这需要业务方根据不同的使用场景,决定将分流能力集成在何处,也可以同时集成在客户端、服务端,对同一流量做分流。

4. 实验效果分析

实验效果分析在实验后,需要提供对比A、B实验差别的可视化能力,为了方便业务团队简单快速的分析,需要构建基础指标体系,各种实验指标可以基于基础指标配置,无需业务人员进行SQL层面的编写,降低使用门槛,同时为了满足算法或产品功能的快速迭代,需要支持实时看数,这就要求保障埋点数据的实现性,端到端的时延要达到1分钟内,这就涉及实验数据回收和OLAP实时分析。

指标体系

目前除了支持PV、UV、人均次数、渗透率、分位数、去重等基础指标外,还支持根据表达式进行自定义的组合指标,无论是基础指标还是组合指标均可以进行多维条件过滤自由选择,指标趋势的汇聚粒度支持五分钟级、小时级、天级方便业务灵活看数。此外,还支持实验置信度分析、留存分析等复杂分析。

数据回收与分析

实验数据的回收,主要使用公司的统一埋点SDK实现,有客户端将实验ID映射带埋点事件,随埋点上报到数据中心,然后使用flink从kafka消费入库到分析引擎ClickHouse,为了达到数据延迟在1分钟以内,数据在flink完成hash分片,然后直接写到ClickHouse本地表。

**5. 总结与展望 **

本文主要通过介绍A/B实验的三个阶段,讲述了A/B实验在OPPO的平台化、产品化的建设和实践。

目前,平台已接入公司十多个业务,上线了200多个实验,覆盖业务90%以上A/B测试场景�