智能优化 &A/B 测试 实验驱动用户增长理论与技术实践

在流量红利日渐消逝的今天，如何用科学的实验方法来有效地实现用户增长，正受到越来越多的关注。A/B 测试在头条、抖音、快手等现象级应用的增长过程中发挥了极其重要的作用。本文为大家分享了几种应用场景及案例，告诉大家如何在团队中有效推进 A/B 测试。

一、A/B 测试如何助力用户增长？

增长现在越来越火，除了传统的阿里和美团点评，在新的巨头公司里面有非常典型的例子，它就是头条。头条是非常典型的数据驱动公司，在数据增长领域，可以说它的整体增长能力公认是最强的。

当年这家公司第一个产品并不是头条，当时他们的团队采取很多 A/B 测试方法，如放了很多马甲包到应用市场里面去，来看不同的标题对用户下载量和留存率的影响等，最后敲定今日头条这样的名字。其实总结一下头条本身的增长秘籍，会发现有这样几个点：

数据驱动是核心，但增长的铁三角实际上不光有数据驱动增长，它还有自己的推荐算法、商业化变现、内容生态等相关组合。实际上数据增长是一个非常基实的能力，有行业里的共识说，数据驱动是由两部分组成，第一部分是以数据分析作为基础，数据分析用来发现问题，比如说我发现登录转化率有问题，或者投放的广告转化率有问题，或者说用户的留存数据有问题，再或者用户分享率不够高、裂变效率不够好等等，那么我们通过数据分析去发现问题紧接着去解决问题，把转化率提上去，最简单的方法是进行产品的改版，传统的改版脑袋一拍直接上，但是更科学一点的方式，也就是第二部分是用 A/B 测试的方式去做，也是很多做的好的数据驱动公司采用的方式。

A/B 测试的概念非常简单，我要做产品的改版来对产品进行优化，从而把转化率提上去，那么改版是改 A 好？还是改 B 好？先来看个例子：

图 1：哪个转化率更高？

这是云测的服务合作伙伴，一个相机的拍照应用，左边版本是商店的图标加上商店的文字，右边版本是一个“+”加上更多的文案，你觉得哪个版本转化率更高？ 答案是右边，而且不是高一点点，而是直接高 80%！

这是为什么呢？你可能想到了，是那个“+‘号。产品本身的滤镜大部分都是免费的，如果用户是那种好奇心强的人，“+”加上更多的文案会激发用户的好奇心，用户自行去探索更多的滤镜列表，里面有付费的滤镜，自然也就实现了商业化变现。正是由于这个原因，右版的转化率明显高于左版。

关于这个应用，它有两种商业化变现手段，一种是付费滤镜，另一种就是 Feed 流的广告。滤镜的话，先把入口的第一层流量提上去，再去做第二层里滤镜列表列的排序、相关的产品组合、给不同地域国家的人推不同的滤镜等等，那就是后面第二步做的事情，整体大概的思路就是这样。

再来看个案例，图 2 所示，右边版本比左边转化率差了 26%。这是为什么呢？想象一下产品的整个流程，首先观察到左边原始版本的转化率不行，然后设计新的方案把购物的转化率提上去，可能会有一定的假设，比如把购物车放的更大一点，然后把价格元素放的更大一点，甚至在图片上面加上了产品的标题，各种元素都加上去，那为什么转化率变低了呢？

图 2：哪个转化率更高？

事后还是通过数据来分析的，发现真实的用户点击行为的数据和他们的设想是有偏差的，偏差就是左边产品的主色调，当时用这个 APP 的很多用户都来自于线下门店，都是老用户的转化，线上拓新做得相对差一些，因为他们是线下转线上的运营商，用户对于老 Logo 的敏感度会更高一些，这就是当时事后分析的结果。

再来个有意思的案例，去年世界杯期间，咪咕视频拿下了世界杯的转播权，它在世界杯之前做了大量的广告推广来获取用户，这里面会出现一个很细节的问题，就是在每个投放渠道里面，到底哪个版本的转化率是最优的？不同的素材，它其实有不同的着眼点，比如说有的推荐高清大屏和海量高清大片，有的是推荐个人专属影院，有的是推电视频道的同步直播，那其实事后在某个渠道里面，转化率最优的版本比原始版本提高 56.84%，它的转化率平均是 7.2%，而原始版本平均转化率是 4.6%，这实际上就是通过数据在不同版本里进行选优的典型案例。

业界其实有一套公认的 A/B 测试驱动用户增长的方法论体系，是把整个数据分析跟 A/B 测试融在一起的。这套体系业界很多人在用，最核心的一点是确认目标，这个目标一定要非常的具体，如果你说你希望把 GMV 提升 20%，那这个目标就太宏大了，它没有办法落地成 A/B 测试的实验。

如果你的目标是通过注册流程的改版把整个注册的转化率提升 20%，这就是非常具体的小目标。

基于这个小目标，我们会紧接着做几件事情，首先是分析数据，分析目前登录环节转化率是多少？或者注册环节转化率是多少？然后提出改进的想法，比方说原来注册流程可能是短信校验码，换成图片校验码是不是会更好一些？或者干脆不要校验码？

Anyway，你会在产品的改版过程中提出很多的设想，作为 B、C、D 方案，根据原始版本进行产品的数据对比。有了想法之后，我们紧接着进行重要性的排序，因为资源永远是有限的，那么基于你对这件事情的信心程度或者影响程度进行优先级的排序，最重要的且信心程度比较高的那些功能，我们会优先去做 A/B 测试，观察 A/B 测试数据，就进入到图 3 我们的右边环节，结果分成两种，一种是有效，一种是无效。

图 3：A/B 测试如何驱动用户增长？

我们曾拿过行业里几千个实验的成功率来做统计，平均来讲无效实验大概是在 70%左右，有效实验大概是在 30%左右，因为成功永远是少数，小红书姚旭老师他们做算法级别的 A/B 测试时，成功率大概是 10%，当然场景不太一样，因为他们做了大量的 Feed 流算法 A/B 测试。

其实业界来讲，实验的频率跟公司的市值基本上成正比关系，那取得的收益大概什么量级呢？比如说一周如果你能做到 30 个 A/B 测试，如果你有 10 个功能点可以提升，转化率大概可以提升 5%到 30%。注意 5%到 30%是对于已经过了产品从 0 到 1 阶段的 APP 来讲的，如果说产品本身还在从 0 到 1，那个时候 A/B 测试有没有意义还不好说，或者特别严格的 A/B 测试可能不是很有意义的，但是那种短平快的 A/B 测试可能有意义，比如说头条当时在 2013、2014 年的时候，对 APP 的名字都会做 A/B 测试。

图 4：典型公司的 A/B 测试频率（每周）

二、如何在团队中有效推进 A/B 测试？

从 A/B 测试的应用角度上来讲，它的场景是非常多的，在很多小程序、轻应用的场景下会有很多新玩法。比如说你的裂变怎么去做？你的整个引导用户裂变的环节，不管是产品、活动、流程优化，还是整个千人千面，包括后端算法，feed 流，大量场景都会用到 A/B 测试相关的东西，大厂尤为明显。因为现在 C 端的产品已经非常趋同了，大家都是信息流。另外从传统的分阶段的角度来看，也是有大量的场景可以落地的，我列了一些例子，供大家参考一下：

去年年底的时候，有三款微信的挑战者出现，其中有一款是罗永浩做的聊天宝，之前叫子弹短信。子弹短信恰好也是云测的合作伙伴，它在春节期间专门做了一次裂变活动，号称烧了一亿，主要来看下它当时做的 A/B 测试，最核心是在用户裂变的环节做 A/B 测试，为什么这么做？因为它当时的设想就是通过裂变来拉新，把用户增长给做上去。

当时裂变大概做了三套不同的方案，一种是通过这种短信聊天的方式来做微信的流量增长，第二种是通过海报的方式，发海报给好友来裂变，第三个就是发 H5，通过三种方式来做 A/B 测试，看哪一种方式转化率会更高一些。那么产品什么时候需要做 A/B 测试？这是非常关键的问题，因为对任何团队来讲，哪怕像 BAT、TMB 这种级别的，团队的资源永远是有限的，所有的产品需求都需要做 A/B 测试吗？实际上是不需要的，当你面临的问题是影响大，同时选择又很困难，那这种情况是最适合做 A/B 测试的。

给大家举两个反例，有两种情况下没有必要做 A/B 测试，一个是影响很大、选择不困难的情况，比如我们做了新 APP，要不要加上微信登录、QQ 登录这种功能？它的影响非常大而且选择不困难，因为它直接影响到用户是不是能够被识别，是不是能有更多比例进入到登陆状态；另外一个就是影响不大、选择很困难的情况，比如说我们有细致的犄角旮旯里的功能，你作为非常强调完美主义产品的负责人，你可能会很纠结，到底上 A 还是不上 A，要不要上 B、C 方案等等，这个场景下做 A/B 测试也不是很必要，因为你会浪费你的研发资源。

三、案例分享

图 5

通过与几百个客户合作与交流，我们发现 A/B 测试做到落地有三大关键要素：

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

• 业务流程，就是增长工作流程。

• 工具

这样才能够把你的数据完全驱动。

都会遇到哪些具体的坑？

好不容易做了一个实验，却没效果

在团队里没人听你的，推不动

研发资源紧张，做一个都费劲，咋做 2 个版本甚至 4 个 8 个？

随机分流，结果看上去挺好，上线后发现不是那么回事

A/B 测试咋做啊？不会

结果统计不显著，咋整？

做实验的用户量不够咋办？

给没做过 A/B 测试团队的建议

• 从最简单的文案 A/B 测试开始，测试关键按钮中不同文案的转化率。如果你之前没有做过，可以先从这个方向开始。

• 多做团队之间的经验分享，哪怕是失败的经验也是非常好的，把失败的经验积累起来，你下次就知道哪个是坑，慢慢你就学会如何更好地进行产品转化率优化了。

• 一把手工程。增长这件事情，从各种成功失败的案例来看，绝大多数都是一把手工程，像淘宝、美团点评、链家、小红书等等，大部分增长做得好的团队都是一把手驱动的。

• 从技术角度上来讲，可以使用第三方的免费 A/B 测试工具，比如 Testin AB 测试，实际上是第一个能做到动态的可视化的 A/B 测试，你的 APP 里面嵌了我的 SDK 之后，非技术人员也可以动态地进行文案、图标、字体的修改，像透明度、背景颜色这些都可以做，而且不需要发版就可以实时更新。

图 6：可视化 A/B 测试

实际案例分享

这里给大家分享一个完整的实际案例。模拟下刚刚讲过的流程，假设我们的目标是分享按纽的点击量提升 5%，这是我们完整的 A/B 测试具体的目标。分析问题，发现现在这个按纽的人均点击次数是 0.24。设想，如果对文案进行修改，是不是能够把这个转化率给提上去？大家可以提几个不同的想法，比如说马上分享、分享有奖等相关的备选方案，紧接着我们对所有的需求进行优先级的顺序，会有个产品排序，我们可能现在 H5 或者小程序这种特别轻量级的这种场景下去做，当然小程序也要审核的，H5 可能相对轻松一些，然后 A/B 测试，我们进行流量的分配，

图 7

如图 7 所示上方是饼状图，进行流量的分配，三个版本各放 33%的真实流量，下方是用户流量的真实趋势图，你会发现三个不同颜色的版本，流量是均分的。当然它会有高峰低谷，因为用户有这个高峰低谷的周期性，观察两周，然后看整个实验数据，发现在不同的日期，不同版本的转化率优胜是有变化的，这个实际上在一些变化不明显的场景下是非常常见的，当然有一些场景里有些版本是持续性地比某版本好。

版本如果会出现交叉的话，我们怎么去解读这种数据？这时就会用到一些统计的算法，比如说置信区间、变化度、Power、Pvalue 等等统计显著性相关的指标，相对来讲比较专业性一些。那这个例子里面，其实很具体，版本一，就是绿色的版本，整个变化度比原始版本提升了 7.14%，它的 95%置信区间是 1.25%到 13.07%，意思就是说，这个版本如果推广到全量用户，在 95%的概率下，至少比原先版本提升 1.25%，至多提升 13.07%，它的整个统计显著性明显优于原始版本，所以这个版本可以放心地放到全量用户上去的。

再给大家看另外一个例子，它是客服按纽的改版，左边是它的原始版本，客服按纽放在右上方，相对来讲不是那么明显，新版本把联系客服这个按纽放到了结账页面的左下方，结果持续性的好，在 95%置信区间上大概是比原始版本提升了 37.66%。

图 8：客服按钮改版

其实这个改版当时起到了一箭三雕的作用，第一是提升了转化率，第二是很多用户原来反馈说找不着客服投诉的按纽，现在客户比较容易找着跟客服沟通的渠道了，第三是他们在苹果应用市场的投诉率下降了，因为很多用户原来在评论的时候说，连客服按纽都找不着，然而通过这个改版，差评减少了，不得不说是一个惊喜。

四、基于强化学习和 Druid 的智能优化 & A/B 测试系统技术实践。

下图是我们 A/B 测试系统的架构图，我们本身有 SAAS 公有云的模式，也有这种私有化部署方式，整体架构还是非常类似的。我们最核心的 OLAP 引擎用了两套，一套是 Druid 的，Druid 在 OLAP 这个引擎场景下，非常适合做这种多维组合查询，它的数据是实时摄入的，可以做到秒级响应，另一个是 Presto，因为我们希望支持一些比较复杂的多维组合查询，可能会出现比较复杂的事件跟时间序列的组合。当然还有一些有意思的地方，比如说我们可以支持基于强化学习的智能优化。

图 9：Testin 云测 A/B 测试整体系统架构

给大家讲一些技术细节，像这种流量分割，我知道有一些不小的公司在流量分割的时候，遇到过很多的 Bug，比如不能保证唯一性，什么叫唯一性？比如说我今天有用户 ID 进来，识别完这个用户，然后明天他再进来的时候，就跳到另外的版本上了，后天再进来的时候跳到第三个版本去了，它的版本之间前后不能保持一致，这个是有问题的，不能用所谓随机分流的方式去做，你会给用户造成困扰，因为今天进来是 A，明天进来是 B，后来进来是 C，同时对你的结果准确度是有影响的，因此唯一性是非常重要的。

另外还有均匀性，我们分流的人群应该可以按各个纬度进行类比的，比如说你分了三组人群，不能是 A 组人群里面 iPhone7 的用户特别多，B 组人群 iPhone9 的用户特别多，C 组人群 iPhoneX 的用户特别多，这个结果就很不准确，应该保证从各个纬度，ABC 三组人群整体的特征都是比较接近的。此外，灵活性因为我们需要支持秒级的流量动态调整，定向性是说我们在做很多 A/B 测试的时候，希望对特定人群进行 AB 测试，比如一线城市的 VIP 用户，或者最近三个月没有产生过购买行为的非 VIP 用户等等。

还有就是分层分流，为什么要有分层分流？如果有大量的业务需要并行做 A/B 测试的话，如果你没有分层机制，假设你的用户就是那一层，有十个亿用户或者一个亿用户，你有两个实验把用户都占满了，剩下的实验可能就得排队了，那如果有分层分流，对于那些相互独立的实验， 就可以并行展开。

图 10：分层流量分割

比如上图右边是按照需要虚拟出了 5 个流量层，也可以按需创建十个、一百个都没问题，相当于把你的用户固定的流量按需要给虚拟出多份，业务不相关的实验可以放在不同的流量层里面并行展开，比如说首页改版和个人中心改版，这两个实验之间业务没有依赖关系，你就可以把它放到不同的流量层里面去，当然这里面还要保证随机独立性的问题，同一个设备在第一层，进到首页改版实验里面，每个版本跟同一个设备在第二层进到这个实验，甚至是不进这个实验，是两个随机独立事件，要不然你就会形成依赖关系。如果这个实验两个本身就有依赖关系了，比如最后一层分享按纽文案实验和分享按纽图标实验，从业务角度上来说，业务方一般不希望同一个用户能同时进这两个实验，他希望这两个实验只能二选一，这时候你把这两个实验放到同一层里面去，可以形成同层互斥的关系，对于任何设备来讲，一次只能进其中一个，这是核心技术点。

还有就是跟统计算法相关东西，无非就是统计显著性、统计功效、去掉噪音数据、区间估计等等，这些就是算法上的一些东西了，就是为了避免以偏概全，因为在 A/B 测试是在小样本、非全量样本里得出的统计结果，你希望有值来判定小样本里得出的结果是不是在全量用户里也可信的，这就是整个统计算法起到的作用。

不管是大家自己去实现 AB 测试，还是说用第三方的 AB 测试系统，核心技术点分 5 大部分，分流的准确性、统一结果的可信度、可视化的这种编辑买点、SDK 的稳定性、数据后台的稳定性等。

图 11

如果你要优化的版本特别多，真实的客户有这么多落地，一年可能要换两三百套体验，到底怎么去选？而且这还只是你的素材纬度，实际上还有渠道纬度，因为对于大的投放来讲，你可能会有几十上百个渠道去进行投放，那么到底如何在每个渠道里面选出最优的版本，这是个非常复杂的问题，靠人去盯是非常费劲的，怎么去解呢？其实这个问题有非常经典的解法，就是去做所谓的智能优化，核心点就基于强化学习，算法细节就不细讲了，它的核心理念就是把更多的流量奖励给那些在小流量里面转化率更优的版本，对于那些在小流量里面验证转化率不够好的那些版本，就不给它增加新的流量了，这就是奖励优胜者的奖励机制。

基于这种方式，我们整个使用流程是这样的，一开始假设有三四个版本，给这些版本分一些流量，比如 1%、2%。然后随着时间推移，我们系统会不断检测不同版本在小流量里边转化率的数据情况，我们基于这个数据情况再进行这种流量的二次分配、三次分配、四次分配，这种流量再分配是基于 PV 浏览的行为这种级别，一个 PV 你就可以重新做一次流量的概率的重新组合，基于这种流量，你可以去把没有分配的流量分配给那些在小样本里面转化率更优的版本，如果有某个版本的转化率能够持续性地在流量增加时持续提升，你就可以通过这种强化学习的方式选出来转化率最优的版本，这就是智能优化做的事情。

作者介绍

陈冠诚，Testin 云测 CTO，原 IBM 研究院高级科学家。师从欧洲科学院院士 Per Stenstrom 教授，在 Supercomputing，IEEE BigData 等顶级会议上发表过 6 篇大数据机器学习相关论文，拥有 8 项国际专利。10 年大数据产品技术经验。曾为众多企业搭建了智能优化 & A/B 测试驱动产品优化的数据体系。国内最大的 Druid 开源大数据技术社区发起人。在 Testin 云测负责与应用相关的测试、安全、推广、产品优化，流量变现及 AI 大数据解决方案产品技术研发，服务了全球超百万的开发者和企业。