OPPO在A/B实验分析平台的建设与实践

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

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

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

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

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

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

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

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

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