写点什么

实验引爆用户增长:A/B测试最佳实践

2020 年 4 月 08 日

实验引爆用户增长:A/B测试最佳实践

嘉宾介绍

陈冠诚,Testin副总裁、Testin A/B测试业务负责人。师从欧洲科学院院士Per Stenstrom教授,发表过6篇大数据国际论文和8项国际专利,为美图、宜人财富等企业搭建了A/B测试驱动增长的数据体系。


在互联网下半场竞争中实现科学增长,切实让 A/B 测试发挥增长引擎的作用是应有之义。在本文中,陈冠诚将为我们分享 A/B 测试对业务转化率提升带来的价值,以及如何在团队中有效推进 A/B 测试及 A/B 测试系统科学设计实践等内容。


今日头条增长秘籍:A/B 测试驱动


抖音可以说是现在增长最火热的公司,流行于大街小巷行走的人们手机之中,它让腾讯感到深深的危机感,被迫应对,从 2017 年下半年开始,抖音就呈现出现象级爆发式增长。其母公司字节跳动,估值 750 亿美元,本身就是一个非常讲究实验、以 A/B 测试驱动科学增长的公司。A/B 测试对头条系产品来讲是很自然的事情,整个公司从最高管理层张一鸣开始就非常注重。36Kr 曾在一篇报道中写道,“头条发布一个新 APP,其名字都必须打 N 个包放到各大应用市场进行多次 A/B 测试而决定,张一鸣告诉同事:哪怕你有 99.9%的把握那是最好的一个名字,测一下又有神马关系呢?”


今日头条从起名字开始就运用了数据思维,创始团队没有头脑风暴,没有投票,没有老大拍板儿,而是采用科学实验的方式,通过数据观测确定了头条的名称。他们将 App Store 上各类免费榜单的前 10 名整理出来,然后根据名字归类(朗朗上口白话类,内涵情怀类,模拟特殊声音类,公司名+用途类等),分析那各类数量占比。分析结论是朗朗上口的大白话效果最好。其次,分渠道 A/B 测试,确定先验效果类似的发布渠道,分别投放,界面功能 logo 完全一样,统计各个渠道的用户下载和活跃等核心数据指标,最后测得《今日头条》效果最好。


什么是 A/B 测试?


A/B 测试是一种产品优化的方法,为同一个优化目标制定两个方案(比如两个页面),让一部分用户使用 A 方案,同时另一部分用户使用 B 方案,统计并对比不同方案的转化率、点击量、留存率等指标,以判断不同方案的优劣并进行决策。



上面图示就是一个典型的 A/B 测试范例。在 A/B 测试比较成熟的公司中,可能并不局限于只有 A、B 两个版本,可能会有 ABC 测试、ABCD 测试,甚至是 ABCDE 测试。有一些情况,可能会出现比较特殊的 A/B 测试,比如说 AAB 测试,因为需要验证整个 AB 测试系统的准确度,需要设置两个对照组,所以叫 AAB 测试。不管同时运行几个实验,我们都可以将它们统称为 A/B 测试,英文为 ABtest 或 ABtest。



结合公开数据和行业深度调查,我们整理了行业 A/B 测试频率概览图,其中可以看到,公司市值或体量与 A/B 测试频率呈正相关关系。像谷歌等大体量公司,它本身具有较为成熟的 A/B 测试系统与数据分析平台,平均每周 A/B 测试就多达 2000 个 A/B 测试,其中包括一些相对复杂的实验,如推荐算法 A/B 测试,也有相对简单的 A/B 测试。至于国内 BAT 等一线互联网公司,它们每周也会进行上百个 A/B 测试。


在与我们合作的大部分公司当中,行业分布广泛,比如互联网金融、电商、O2O 等厂商,它们自身没有能力和精力自研一套成熟的 A/B 测试平台,所以他们选择与 Testin A/B 测试合作,将 A/B 测试服务快速应用到业务中。比如,某互联网金融用户,在使用 Testin A/B 测试前,每周只能做 0.1 个 A/B 测试,使用了云测 A/B 测试服务后,大大提升了 A/B 测试频率,每周跑大概 30 个 A/B 测试实验。当然,在其每周 30 个实验中,约有 1/3 的实验会取得转化率指标提升 5%-30%的效果,剩余 2/3 的实验效果并不理想,未取得较好的数据指标提升。


通过这个例子,我们可以看出,大概 2/3 的产品设想并不符合预期,就是说转化率其实没有原始版本好。这个也是为什么需要 A/B 测试的根本原因,凭借产品直觉去做产品决策,但 2/3 的改进并不是最优解。



上述图表展示的是微软必应搜索引擎 A/B 测试增长曲线,覆盖 Bing 从 2008 年到 2015 年的时间的 A/B 测试实验增长情况。可以看到,在 Bing 产品初期,每周 A/B 测试频率维持在 10~50 个,到 2012 年之后,Bing A/B 测试每周频率进入快速增长。图表右下角绿色曲线,是 Bing 移动端的 A/B 测试频率增长曲线。通过该图表,我们可以看到,Bing 非常看重并认真实施 A/B 测试实验,以驱动数据增长,促进业务发展。


A/B 测试应用场景及案例



我们先看下 A/B 测试在移动应用中的四大应用场景,分别是 App、落地页、后端算法和小程序。APP 端是目前移动互联网增长的主要载体,PC 或 H5(如常见的朋友圈刷屏活动)或者广告投放落地页面等则可以归为落地页,还有后端算法场景,如推荐算法、广告算法、千人千面等等。目前增长最快的应用场景,则是小程序。


在不同的场景,A/B 测试的侧重点也有不同,但最核心目标仍然都是围绕业务的增长展开,也就是大家所熟悉的「北极星指标」,或者是 DAU、MAU 等在 A/B 测试中设定的具体目标。


案例一:相机拍照类应用



以 Camera360 为案例,它选用 Testin A/B 测试服务帮助其进行产品优化决策。该案例是其产品商业化过程中的一个尝试,希望提升商店中表情包或道具的付费比例,但要完成付费指标,首先要提升商店入口点击率。所以,他们设定了多个商店入口方案(更改图标样式、文案),通过 A/B 测试来验证哪个方案可以最大化提升商店入口点击率。在验证过程中,他们也针对人群目标做了相关定向测试,如日本、中国、韩国等区域,最终他们针对这一入口同时上线 7~8 个测试版本,通过 A/B 测试,将整体点击率提升了 80%左右。


案例二




本案例为互联网理财行业的 App,他们期望通过更改签到按钮的文案提高签到人数,从而提高留存率,按钮文案由「签到」改为「签到赚钱」,并进行 A/B 测试,为 A、B 版本分配了各 5%的流量,在经过测试后发现新版本的签到次数比原始版本签到次数提高 4.17%,其中 95%置信区间结果显示小范围人群的试验结果推广到全量用户之后,有 95%概率获得 1.7% 至 6.6%的提升;p-value 小于 0.05,显示新老版本有显著统计差异,Power 为 100%,说明统计功效显著。通过这次简单的 A/B 测试,就极大提升了 App 留存率。本次测试,也借助 Testin A/B 测试的可视化功能,直接修改相关元素属性就实现了对照功能,无需开发人员介入。


那产品什么时候需要 A/B 测试呢?我们知道进行 A/B 测试需要成本,比如需要开发多套版本,需要搭建可用的 A/B 测试及数据分析平台等。从投入产出比考虑,进行 A/B 测试平台有 2 个必要条件,一是产品决策影响大,二是产品方案选择困难。如果某决策对产品影响很大,但选择不困难,则没有必要进行 A/B 测试,比方是否决定给 App 增加微信及第三方登录方式,这对产品影响很大但决策并不困难,因为业界已有常见的解决方案。再比方说,添加某很细小的功能,且该功能入口极深、用户量不大,那么 A/B 测试优先级也并不高。只有当一个产品决策同时满足影响大和选择难这两个条件的时候,才最适合进行 A/B 测试。


拿我们自身进行的测试来说,我们会基于功能影响大小、选择困难程度,对要做测试的功能做好优先级排序,然后判断哪些功能要做 A/B 测试。


A/B 测试落地三要素


通过与我们的合作伙伴,如自如、36 氪、子弹短信或 51 信用卡等众多增长团队交流,我们发现 A/B 测试做到落地有三大关键要素:


  • 第一,人的因素,或者说整个团队的思维习惯、思维方式。

  • 第二,业务流程,就是增长工作流程。

  • 第三,工具。



展开来说,在「人」的角度上,要求整个团队具备数据驱动增长、A/B 测试驱动决策的思维习惯,这是最重要的事情。同时,如果增长或产品团队负责人本身不具备这种意识,认为 A/B 测试无关紧要,比较依赖经验进行产品优化决策,那么 A/B 测试做起来也很困难。


对 APP 也好,包括现在的小程序也好,新型产品层出不穷,产品面对的竞争也异常激烈。加之目前互联网流量红利期逐渐结束,获客成本增加,如果想继续获得业务增长,目前最有效的办法就是落地 A/B 测试、以数据驱动增长这一路径。行业发展趋势决定所有团队都会慢慢迁移到用科学的实验进行增长这条路上来,即使你现在的团队推进 A/B 测试困难,但是我相信不远的将来,A/B 测试将是最重要的产品增长驱动力。


作者曾与较多欧美增长同行进行过深入交流,有一个很深感受就是他们的互联网企业中 A/B 测试氛围更强,主要因为美国人工成本相对较高,他们特别注重投入产出比,所以他们很早进入到精细化运营阶段。


在业务流程上,第一需要注意你的产品是什么形态,是依托 APP、小程序、公众号还是 Web 网站。不同的业务场景,A/B 测试落地方案也会不一样。第二,要考虑 A/B 测试是否很好融入到了产品迭代或增长团队工作流程中去,最佳实践就是做到将整个产品优化迭代流程、发版节奏与 A/B 测试紧耦合,形成流水线作业,这也是 BAT 等公司能够把 A/B 测试每周频率做到那么高的原因。


在工具方面,一种是自研,另外一种是使用第三方服务。自研的话,在可控性、业务耦合方面有一定的优越性,但对一般企业来讲,其研发成本、人力成本很高,开发 A/B 测试服务还涉及到较为严格的数据统计,需要配置专业的数据分析师。如果使用目前市面上的第三方工具,比如 Testin A/B 测试服务,可以最大化降低成本、加速业务落地 A/B 测试服务。比如,某小程序用户当天接入 Testin A/B 测试服务后,当天就运行起三个 A/B 测试实验。无论是自研还是使用第三方工具,关键在于适合自身团队。


A/B 测试最佳流程实践


A/B 测试最佳流程,可分成四个步骤:



  • 分析数据:分析现有原始版本的各项数据指标,如注册转化率等,比如说注册转化率仅有10%,针对这一转化率提出想法;

  • 提出想法:比方说要改进注册流程,之前用户需要输入短信校验码,计划改成图片校验码,形成改进备选方案。有了该基本假设后,预估大概率可以提升转化率;

  • 重要性排序:限于团队资源有限,无法把所有需求想法全部都去验证,这就需要做重要性排序,选择最重要的这几个改进方案去做A/B测试,接着进入第四步;

  • A/B测试:在这个过程中,我们要监测A/B测试数据,结果一般有两种,一是数据证明实验无效,一是证明实验有效。我们经过大量测试发现,大部分进行的A/B测试实验,1/3被证明有效, 2/3被证明无效(与原始版本效果差别不大,或者比原始版本效果还坏)。


这里需要大家注意,不是所有的实验都会被证明对指标增长有显著效果,如果是这样,我们就没有必要进行实验了。如果遇到这种情况,需要告诉自己的团队成员不要灰心,正因为某些实验被证明无效,我们才会找到有效的增长方式。实验失败是大概率事件,我们最好的办法就是增加测试频率、持续测试,而非浅尝辄止,又回到经验主义决策的老路上。


如果你的团队从来没有做过 A/B 测试,有三点建议给到大家:


  • 第一,从最简单的文案A/B测试开始,比如说测试关键按钮中不同文案的转化率;

  • 第二,多做团队间的经验分享,多分享你的成功经验,有效果的事情大家都愿意尝试;不要天天去分享失败的经验,如果过多分享失败经验,会让你包括你的团队对A/B测试产生质疑,影响团队士气;

  • 第三,可以优先使用第三方免费的A/B测试工具,比如Testin A/B测试,目前支持App、Web/H5、小程序。


企业 A/B 测试成熟度模型



上面介绍了落地 A/B 测试的三大关键因素,以及 A/B 测试的最佳实践流程。在这部分,为大家分享企业 A/B 测试成熟度模型。我们把企业 A/B 测试分成四个阶段,分别是起步阶段、成长阶段、成熟阶段和大规模应用阶段。该能力的成熟度最核心指标,就是每周能做多少个 A/B 测试。


处于起步阶段,平均每周能做 0~1 个 A/B 测试,整个组织架构处于开始尝试 A/B 测试阶段,但内部没有成型的 A/B 测试实验平台,仍使用最简单的分流方式和数据分析方法进行实验。此时的 A/B 测试并不是一个标准的 A/B 测试,从实验评价体系角度来看,已经设定一个最基本的指标,比如说转化率,但仍没有体系化。何为体系化指标?也就是从单一指标演进为多维度指标体系,系统跟踪实验对产品的多方面影响。


第三个阶段就是相对比较成熟的阶段,这个时候每周能做到 3~10 个测试,A/B 测试已经成为产品迭代流程的一部分,并需要可视化 A/B 测试,后端 A/B 测试等高级功能,以便满足多样的 A/B 测试需求。


在成熟和大规模应用阶段,提到了一个名词 OEC。OEC,可以理解成综合评价指标,可能是复合型指标,在很多单项指标通过加权平均后得到。 通过 OEC 的设定,指导整个组织的业绩发展。


A/B 测试系统设计能力


上面分享了如何落地 A/B 测试。接下来,跟大家分享下设计一个典型的 A/B 测试系统,需要具备哪几点能力或特征:


  1. 科学流量分割:包括唯一性、均匀性、灵活性、定向性及分层分流。唯一性是指通过精准且高效的Hash算法,确保单个用户每次登录应用时被分到的试验版本是唯一的;均匀性,则是确保分流人群,各维度分配比例均匀;灵活性,则需要支持用户随时在实验的进行过程中,调节实验版本之间的流量分配比例;定向性,则是可以根据用户标签来实现精准定向分流,如根据用户设备标签及其他自定义标签特定分流;分层分流,则可以满足并行进行大量A/B测试需求。



左:未开启分层分流机制;右:开启分层分流机制


这里重点介绍下为什么需要分层流量分割机制。如果没有分层流量机制,则存在如下限制:


  • 每个用户最多只能参加一个A/B测试实验

  • 多个实验不能同时使用全体用户进行测试,可能因为人群覆盖度不够高导致结果偏差

  • 每个实验的可用实验流量受限于其他正在进行的实验,缺乏灵活的流量分配机制


有了分层流量分割机制,就可以很好地满足并行进行不同业务或不同场景,或者不同产品模块之间的 A/B 测试需求。


  1. 科学统计算法:


  • 科学统计,使用科学的统计分析方法来对实验数据进行分析,并给出可靠的试验结果;

  • 区间估计,给出95%置信区间,避免点估计带来的决断风险;

  • 统计显著性判断,通过p-value来判断不同实验版本之间差异显著性;

  • 统计功效判断,通过Power来判断不同实验版本统计功效是否充足;

  • 精益分析,对实验数据进行去噪音处理,去除噪音数据,以提高统计结果的质量



上面就是基本的分享内容,限于篇幅,更多 A/B 测试后面有机会再与大家分享。


2020 年 4 月 08 日 19:37185

评论

发布
暂无评论
发现更多内容

本文帮你在Unix下玩转C语言

MySQL从删库到跑路

unix C语言

架构师训练营第三周作业

Geek_xq

公安大数据分析系统开发方案,情报研判系统建设

WX13823153201

公安大数据分析系统开发

区块链BaaS应用平台开发

13828808769

甲方日常 66

句子

工作 随笔杂谈 日常

海量数据架构下如何保证Mycat的高可用?

冰河

分布式事务 分布式数据库 分布式存储 mycat 数据库集群

DeFi流动性挖矿系统开发详解方案

系统开发咨询1357O98O718

defi流动性挖矿系统开发

阿里架构师经验分享!啃完999页Android面试高频宝典,面试心得体会

欢喜学安卓

android 程序员 面试 移动开发

架构词典:工程

lidaobing

架构 工程能力

架构师训练营第 1 期第12周作业

业哥

新思科技最新报告显示开源安全是首要考虑因素

InfoQ_434670063458

刚入职,就被各种 Code Review,真的有必要吗?

xcbeyond

方法论 研发管理 编程习惯

架构师训练营第八周作业

李日盛

算法

四币连发平台系统开发详解丨四币连发源码(案例)

系统开发咨询1357O98O718

四币连发系统开发案例详解

超详细讲解!Android面试真题解析火爆全网,搞懂这些直接来阿里入职

欢喜学安卓

android 编程 程序员 面试 移动开发

Redis Sentinel-深入浅出原理和实战

Linux服务器开发

redis 中间件 底层应用开发 web服务器 Linux服务器开发

架构师训练营W08作业

Geek_f06ede

修一座安全的广厦,庇护赛博世界的流浪者

脑极体

合伙开公司、借款变工资 | 法庭上的CTO(7)

赵新龙

CTO 法庭上的CTO

Github 2020 年度报告:你以为新冠击溃了开发者?不!他们创造了更多代码...

阿里巴巴云原生

开源 Serverless 程序员 代码 开源代码

生产环境全链路压测建设历程之五 针对稳定性矛盾, 从目标、流程、组织体系发力

数列科技杨德华

CTO与COO联手接了公司的外包项目 | 法庭上的CTO(6)

赵新龙

CTO 法庭上的CTO

DeFi流动性挖矿系统开发(案例源码开发)

系统开发咨询1357O98O718

defi流动性挖矿系统开发

EPBC环保生态链系统开发案例丨环保生态链EPBC源码平台

系统开发咨询1357O98O718

环保链APP系统开发案例

DeFi借贷质押系统APP开发|DeFi借贷质押软件开发

开發I852946OIIO

系统开发

20分钟带你掌握JavaScript Promise和 Async/Await

Geek_Willie

Java

用60行代码实现一个高性能的圣诞抽抽乐H5小游戏(含源码)

徐小夕

Java 前端 H5游戏 H5

天下武功,唯”拆“不破| 技术人应知的创新思维模型 (4)

Alan

思维模型 技术人应知的创新思维模型 MECE 组合创新 28天写作

滴滴开源小桔棱镜:一款专注移动端操作行为的利器

滴滴技术

开源 滴滴 移动端

挖矿矿池系统开发详情丨挖矿矿池源码案例

系统开发咨询1357O98O718

挖矿矿池系统开发案例 旷工系统开发功能

SGY奇点交易所系统软件开发|SGY奇点交易所APP开发

开發I852946OIIO

系统开发

实验引爆用户增长:A/B测试最佳实践-InfoQ