技术干货 | AB测试和灰度发布探索及实践

2

传统测试方式和ABTest的区别究竟在哪里?如果一个产品功能有两个解决方案,两个方案孰优孰劣我们不清楚,那该怎么办呢?来自新浪新闻客户端的测试专家韩明豹通过传统测试方式与ABTest的对比分析为你进行解答!

1、AB Test Framework产生的背景

新浪新闻客户端视频联播页面现存两种界面,第一种是依次往下联播,另一种则是以列表的形式展示未来播放的视频。
图片描述
以上两种联播界面哪个是最好的,我们不知道。首先没有数据帮助我们进行分析,其次没有实践以及用户来论证,所以需要向用户拿数据。我们应该怎样获取用户数据呢?在不伤害用户的前提下,在小范围影响下,利用一个渠道将部分功能投向用户,然后获取统计数据,进行相关调研,再决定哪个方案更优。
普通的实现方法:第一个是分渠道包,第二个是做出服务器可配置的功能,将一部分用户灰度打开。经过客户端来判断,把代码写在客户端里面,根据时间、机型等条件部分开启灰度功能。
但是这些方法都具有弊端,第一不够灵活,技术实现复杂度比较高,成本也比较高;我们一旦将这个功能抛向市场有些是不可控,发布之后出现问题是不可能立刻将它下线的,风险比较大;再一个实验的周期比较长,至少需要一个版本才能拿到有益的数据;
基于这些问题提出了解决方案:
第一个是缩短试错周期。每个功能如果都需要两个版本反复测试,效率会很低。
第二个是减少用户的伤害。因为一旦伤害了用户,会造成用户对应用的卸载。
第三个是降低制作成本。降低开发成本,减少不必要的人力投入。
需要数据反应速度快,然后保证APP正常功能的稳定性。

2、AB Test 系统架构

AB Test系统架构主要分为以下几个方面:第一个策略的制定者即AB Test策略服务器,还有运行到我们客户端里面的AB Test SDK,它是管理整个策略对上层业务升调机制的,再有我们的数据统计机制,我们采用的是现在比较成熟的sima日志系统。主要的流程就是我们的AB Test SDK通过携带一些机型、坐标及其他类参数上报给我们的AB Test测试服务器,然后由AB Test测试服务器经过运算对指定用户产生一个指定策略,然后下发给AB Test SDK,SDK经过处理加工之后会对上层业务提供策略,上层业务根据策略执行相关的逻辑代码之后,会产生一些行为日志,通过sima来上报,我们会通过sima后台导出数据。通过数据分析得出一些结论,如果需要其它的尝试,我们可以重新配置我们的服务器,进行下一轮的灰度测试。
图片描述

3、AB Test 决策流程

AB Test决策的一般流程,首先从一个功能提出,一般会预想两个方案,经过AB Test系统决策,对小规模的用户进行分统,确定出哪个方案应用到哪些用户上。AB Test系统经过一系列的比对,综合这些后台配置信息,还有各种策略的维度,计算出对应策略,下发给SDK,SDK会通过会控制一些上层业务逻辑的执行逻辑代码统计数据,根据统计数据的收集系统初步得出结论。灰度可能在很短的时间就可以得出结论了,把这个结论直接反馈到AB系统里,然后通过后台的配置直接将全部用户切到我们已经论证过的方案上。如果对样本不太满意,可以通过动态改变后台的配置,重新分统并且重新进行第二轮的灰度实验。
图片描述

4、AB Test 策略维度

AB Test目前已可以对包括新闻信息、地理坐标、版本信息、发布渠道、城市、网络类型等进行判断,更多的维度正在持续扩充中。
图片描述

5、AB Test 生效机制

AB Test有一个生效机制,可以根据策略服务器下发的生效机制对某些策略进行生效。一般分为立即生效,在拿到服务器下发的策略后,会将策略立即生效,并通知相关策略的使用者,
立即生效主要用于用户不会及时感知的行为。
还有热启生效以及冷启生效。热启生效就是退出界面,重新进入生效(可用于调整界面,但需使用者注意业务逻辑,防止出现异常),冷启生效就是杀死进程之后,重新进入生效(用于调整界面,风险低)。两个启动之间区别不是很大,热启会比冷启实时一些;冷启会比热启更加安全一些,可以防止一些代码初始化造成异常。
图片描述
6、AB Test SDK技术实现
AB Test SDK的实现几乎不占用系统什么资源,主要包括ABTestCore,主要功能是完成策略缓存、策略读取、会根据上层对接口的实现来判断策略的有效性,再执行上层已经注册过来的对应策略的代码块;再上层是一个ABTestManager,主要用来拉取策略,上报各个维度信息,做一些策略缓存,根据不同时机进行立即、热启、冷启生效,在某些时机对策略进行生效。
再往上一层是AB Test SDK要用到的一些泛型Bean,还有APP使用者要用到的接口(Interface),这些接口是ABTestCore来使用的,主要作用是根据上层判断逻辑来判断对应策略的有效性。
图片描述

7、AB Test 后台

AB Test 后台服务器根据后台配置以及维度匹配生成对应的策略。后台配置是后台管理人员来干预的;维度匹配,当一个策略提出的时候,会明确出覆盖到哪些人,这些都会经过后台配置,包括它的范围、时间以及生效方式。当客户端带着我们的维度信息上报的时候,经过运算对相应的客户端产生相应的策略,然后策略下发到AB Test SDK,AB Test SDK进行处理再对上层的业务逻辑进行生效。
图片描述

8、数据统计(sima)

日志上报并不复杂,AB Test SDK在获取策略时会上报灰度信息到日志服务器,AB Test在执行灰度功能的时候也会进行上报,这两者的上报会汇总到sima,通过sima数据的比对分析可以大致判断每个功能的使用情况。
图片描述

9、案例分析

在新浪新闻客户端现有两个刷新功能,一个是正在上线的下拉刷新功能,还有一个是正在灰度中的刷新功能,还没有完全放开,影响范围比较小。
另一个是明日头条功能,这功能陆陆续续已经做了有100个左右,包括那些已经确定和正在线上进行灰度实验的功能。
AB Test与传统方式相比,测试、定型周期只需一个版本,比传统测试方式相比至少需要少一个版本测试;AB Test对用户的影响比较小,可以随时下线,而传统的测试方式一旦上线,将会持续一个版本; AB Test实现起来相对简化,而传统方式需要专人跟踪,实现起来比较复杂;传统方式的统计数据需要经过一个版本才会有意义,AB Test可以进行实时更改;
传统方式不支持个性化定制,一个APP对应一个用户展现不同的组合,在传统方式里无法实现的, AB测试支持个性化定制。

10、AB Test未来规划

1、加入智能的数据的算法,以及多维度的分析;
2、加入多策略分析,进行大数据的挖掘,分析各个策略之间的相互影响。
3、加入推送生效机制,通过AB Test SDK进行策略获取,实效比较低,加入推送策略机制,会推送给相关用户,实现立即生效。
4、完善AB Test平台机制,将sima日志进行上报,策略配置进行整合。

你可能感兴趣的

qiankunli · 7月15日

请问策略是以什么形式存在呢?“再执行上层已经注册过来的对应策略的代码块” 可以具体一点么?

回复

载入中...