此篇文章是12月13号Testin云测直播分享会的内容，讲解了A/B测试的流程，如何进行版本分流、数据采集以及最后的展示和分析数据。
大家在日常工作生活中，可能或多或少的都听到过A/B测试，有的同学可能已经做过一些A/B测试实验了，但也有一些同学可能还是对A/B测试不那么了解，接下来让我们带大家玩转A/B测试吧！
首先围绕以上3个方面为大家讲解一下A/B测试：
A/B 测试是一种产品优化的方法，为同一个优化目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，同时另一部分用户使用 B 方案，统计并对比不同方案的转化率、点击量、留存率等指标，以判断不同方案的优劣并进行决策。
A/B测试在移动应用中的四大应用场景，分别是App、落地页、后端算法和小程序。APP端是目前移动互联网增长的主要载体，PC或H5(如常见的朋友圈刷屏活动)或者广告投放落地页面等则可以归为落地页，还有后端算法场景，如推荐算法、广告算法等等。目前增长最快的应用场景，则是小程序。
在不同的场景，A/B测试的侧重点也有不同，但最核心目标仍然都是围绕业务的增长展开，也就是大家所熟悉的「北极星指标」，或者是 DAU、MAU等在A/B测试中设定的具体目标。
我们将从以下四个方面，带领大家玩透A/B测试：
流程概述，会从A/B测试的流程入手，给大家一套国内外无数先驱总结出的最佳流程。
版本分流，我们将详细解释版本设计、流量的区分等概念，并教您如何提高流量使用率。
数据采集，我们会将埋点的是什么、为什么和怎么做讲清楚——请注意是A/B测试的埋点，与数据分析工具的埋点有着关键差别。
展示和分析数据，则会教大家如何去“看”A/B测试结果。
01 流程概述
A/B测试的流程，可分成四个步骤：
分析数据，分析现有原始版本的各项数据指标，如注册转化率等，比如说注册转化率仅有10%，针对这一转化率提出想法。
提出想法，比方说要改进注册流程，之前用户需要输入短信校验码，计划改成图片校验码，形成改进备选方案。有了该基本假设后，预估大概率可以提升转化率。
重要性排序，限于团队资源有限，无法把所有需求想法全部都去验证，这就需要做重要性排序，选择最重要的这几个改进方案去做A/B测试，接着进入第四步。
A/B测试，在这个过程中，我们要监测A/B测试数据，结果一般有两种，一是数据证明实验无效，一是证明实验有效。我们经过大量测试发现，大部分进行的A/B测试实验，1/3被证明有效， 2/3被证明无效（无效是指实验版本与原始版本效果差别不大，或者比原始版本效果还坏）。
一般来说，当这个体系被搭建、完善起来以后，A/B测试才真正有了用武之地，其数据结果能指导产品迭代，产品迭代又能反过来通过A/B测试验证数据，形成最终的良性循环。大家在使用A/B测试之前，不妨先从分析数据入手，相信您一定会发现一些值得进行实验的地方。
02 版本分流
Testin平台上将A/B测试实验分为了三个层次：应用-实验-版本。
应用的作用，便是实验的集合，一个应用里往往会包含大量的A/B测试实验。例如，一个官网，一个App，一个小程序，都只用创建一个应用，然后在应用中盛放多个A/B测试实验。这样做的好处是便于归纳和整理，避免后期实验较多时需要反复集成。大家可以看右边第一张图，就是应用列表，左侧会显示该应用的平台类型，右上角则是创建应用的入口。
实验的作用，即A/B测试实验，允许您对多个版本进行分流和数据比对，并调节控制他们的流量分配。这里需要说明一点，A/B测试并不是说真的就只有ab两个版本，你可以在实验中放入CDE乃至一堆的版本都行。毕竟，我们做A/B测试实验的目的，是为了选出转化率最优秀的版本，那么不管有多少版本，只要样本量足够，就都可以加入实验。大家可以看右下角的图，便是实验列表，有个创建实验的入口，还能对实验进行克隆，也就是原样复制一份。
版本，这个其实很好理解，就是说你设计出来的各个版本了。
有的同学可能会问，AB测试不是可以把两套方案分流给用户吗。那是不是我们需要部署两套环境？
其实是不用的。A/B测试有很多种实现方式，但分流都可以交给我们的平台来分，您只要区分好具体的不同版本即可。
这是因为，每一个实验都会包含“变量”，并且不同版本的变量值不一样，这就允许您使用变量来“控制页面显示不同版本”。
在A/B测试中，以右图为例，假设我们的A/B测试实验是针对按钮颜色进行了修改。
而与此同时，您需要让您的技术同事，对页面逻辑进行改造，确保页面会根据不同的变量值，展现不同的版本。举个例子，您可以直接在页面用if else、case这种判断语句，写好两套方案，让页面能随变量值而变化即可。
但光在平台上设置和改造页面是不够的，还需要在具体的实验页面上，将变量集成进去，才能真正发挥作用。这样，当页面集成的变量接收到平台传来的不同值后，再根据上文所说的判断语句，就能将具体版本显示出来了。
说到这里，就需要提及一下三种A/B测试的实验模式：编程-可视化-多链接。
编程模式，支持对所有控件的修改，需要先在页面上集成SDK并写好两个版本的逻辑，比如变量=a显示原始版本，=b显示新版本。开始实验后，SDK会向平台请求到一个变量值（a或b），然后页面就可以根据该变量值，显示相应版本了。大家可以看左上角的图来辅助理解这个过程。
实际上，在Testin云测的系统中，不仅有需要直接将变量写出的编程模式，还有不明写变量的可视化模式、多链接合并模式。
可视化模式，变量会变成“自动”创建，只要您选中要进行实验的具体位置，并直接修改好，系统便会记载并这个版本自动生成新版。这个模式可以给Web/H5和App使用，当实验开始后，用户访问这个页面，就会被自动分入新版版本，从而实现分流。
以最右侧图为例，您可以在集成了SDK的页面上，浮现出蓝色选中框，选中并对其中的内容进行任意修改。
改动完成后，版本一就成为了您的“新版本”。
多链接合并模式，该模式是H5特有的，其变量被默认为“链接”，您需要将数个版本的URL填入实验，作为不同变量值。系统则会将合并链接返给您。当实验开启后，用户访问合并链接，就能跳转到某个版本的URL里，从而实现分流。
区分好版本以后，如何将这些设置好的变量与页面挂钩呢，这就需要集成了。具体集成方法，大家可以前往官网查看集成文档，后续我们还会推出一些小视频方便您深入理解。这里我简单讲解一下基本的流程：大致分为三个部分，集成SDK和Appkey，集成变量，集成指标。这边简单说说SDK和Appkey。
SDK的作用，下拉变量、传输系统的“旨意”。
SDK是所有A/B测试指令的核心，涉及到样本的标记、版本的分配、实验的开关、以及各个接口的信息处理结果。SDK如此重要，所以我们对于SDK的维护也是极为关注的，更新迭代的频率比较高。因此我们强烈推荐您在实验开始前，都前往平台将SDK更新到最新。
Appkey，就相当于是一个“身份证ID”，用于区分不同的应用。
其他代码，主要是应用变量、传递指标，我们到下文再提 。
设计一个典型的A/B测试系统，需要具备哪几点能力或特征？大概是如下五点：
相似性，分割后的不同用户群，各个维度的群体特征相似，例如不同用户群的机型比例、语言比例等都会相似，以免干扰试验结果可信度。
唯一性，指通过精准且高效的Hash算法，确保单个用户每次登录应用时被分到的试验版本是唯一的。
均匀性，则是确保分流人群，各维度分配比例均匀。
灵活性，则需要支持用户随时在实验的进行过程中，调节实验版本之间的流量分配比例。
定向性，则是可以根据用户标签来实现精准定向分流，如根据用户设备标签及其他自定义标签特定分流。
受众分组，大家也可以理解为用户画像、标签，即通过给您的用户打上特定标签，将人群分割开来，从而实现精细化运营。A/B测试也可以套用您已有的用户分组体系，针对性的开展实验。
当设置好受众分组以后，就可以选用两种模式使用受众了。
定向分流到实验，它能针对特定样本属性进行的A/B测试。我们在实验级别提供了定向分流功能，这样我们可以允许实验员自己定义拥有哪些特征的用户才能参与某个实验。一种常见的用法，是基于每个产品自身的用户体系，对不同身份的用户进行不同的A/B测试。例如，在互联网金融行业，可能会对新手标的展现方式进行A/B测试，这就可以限定在新用户中进行；在电商平台，可能会对老用户的优惠政策描述进行A/B测试，诸如此类。实际上，许多A/B测试的受众群体可能有着极大的分化，如年龄、性别、地区甚至是语种，都可以用来做区分。
定向到版本，则有根本性的不同。该功能的用处是针对个性化配置进行的定向实验。在日常的运营过程中，常常需要针对特定人群提供一些定制化的产品功能，以追求利益的最大化。出于这点考虑，我们提供的定向到版本功能，可以允许您针对特定用户实施个性化的营销策略。例如，南北方案例。类似这样，虽然不是A/B测试——因为并非要对比两个版版本的优劣，转化率的高低也只是反映了不同地区的喜好——但一样可以借用A/B测试的系统来实现。
流量分层最大的作用，是实现实验并行，显著提高流量的利用率。
大家可以思考一下，如果你有多个实验需要进行， 该怎么办？如果每个实验必须让你的全量用户参加，样本量才够，怎么办？排队一个个按顺序来，显然是不行的，消耗的时间未免太久了，因此才有了流量分层的概念。
左，未开启分层分流机制；右，开启分层分流机制。
分层分流，这里重点介绍下为什么需要分层流量分割机制。如果没有分层流量机制，则存在如下限制：
每个用户最多只能参加一个A/B测试实验，多个实验无法同时使用全体用户进行测试，可能因为人群覆盖度不够高导致结果偏差。
每个实验的可用实验流量受限于其他正在进行的实验，缺乏灵活的流量分配机制。
有了分层流量分割机制，就可以很好地满足并行进行不同业务或不同场景，或者不同产品模块之间的A/B测试需求，轻松实现实验并行。
同层，当然，这种分层机制也势必会面临一个问题：如果实验相互之间需要互相排斥怎么办。举个例子，如果您进行的多个实验之间具有一定的关联性，且您希望同一个用户只能进入这些实验中的一个实验版本，而不是同时进入多个实验该如何做呢？其实也很简单，可以将这几个实验放在同一层，此时多个实验共享该层100%的流量，自然就实现了互斥。
当您在系统中，完成了A/B测试的设置，并且您的技术同事已经完成 了集成工作，那么您就可以划分流量开始实验了。
需要注意的是，在集成好SDK后，系统便会自动为您的每个客户做好标记，以确保每个样本的“独立性”。简单来说，就是可以保证实验的样本量是去重的“人数”而非“人次”。在确保了这个的前提下，便可以保证各个版本进入实验样本会大致相同了——请注意，是大致。毕竟，A/B测试必须保证样本的一致性，因此不能按照一边一个、或是某些渠道用a某些用b这种不严谨的方式来进行。因此，系统会使用算法来按比例分配每个版本的样本，如右图所示，实验会按照您设置好的比例，将来访者分别导入到各个版本中。
SDK还会为这些用户获取到不同的变量值。于是用户便能看到不同版本了，分流完成。
但还需要注意，并非所有A/B测试都需要一下子让所有用户参与。
小规模，一般来说，A/B测试需要在小规模的情况下，先校验实验是否有问题。
大规模，当实验是能跑通无bug的，就可以开始扩大样本量。
03 数据采集
还是回到关键问题上来，A/B测试的目的是区分版本优劣，而不是记载、监控页面上的各类数据。
因此，A/B测试的指标往往会聚焦在少数几个关键的、能对版本是好是坏做出决定性判断的指标身上。
这也决定了A/B测试埋点基本不可能靠外人来代工——因为外人不可能有你一样，对你的产品有那么深入的了解、研究。所以我们常说，最适合做A/B测试的正式运营人员，毕竟运营可以说是整个部门里对产品数据最关心的人之一，也是最希望提高数据的人。因此，运营往往会更明白，在何处埋点监控指标，对于产品的发展是有利的，进而确定A/B测试的关键指标。
编程模式&多链接合并模式
创建实验过程中，需要编辑指标，点击单项指标，进行编辑即可，如上图所示。
对于单项指标而言，实验处于已运行、已停止、或已发布的状态下，都不可以对其继续添加与修改。
复合指标是在基于在单项指标的基础上进行 + - * / 和 () 运算得到的。较单项指标而言，复合指标能够结合更多分析因素，反映更综合的问题内容。当使用复合指标时，需要使用者对其需要优化的内容有准确的定义与逻辑推算。
页面需要继承指标代码，具体可以点击右侧文档，进行查看http://ab.testin.cn/docs/。
可视化模式
可视化埋点就很简单了，只要点击埋设即可，如上图所示。
但缺陷是只能统计点击事件。
04 展示和分析数据
基础展示分为实验概览和指标详情。您可以进入每个实验的“概览”模块，在顶部切换实验概览和指标详情，从而从不同维度观察数据。我们先从实验概览开始，该功能主要通过柱状图、表单来呈现数据，允许您同时浏览大量指标，并可以横向比对某一类数据。例如，可以对一个流程的不同步骤统计转化率，从而横向比对整个流程的漏斗转化率。
不仅如此，您还可以通过上方Tab，轻松切换转化率、转化人数、总值、均值，从不同维度观察数据。
实验概览的底部，还有个流量走势图，可以以天或以时为单位，审查不同阶段的各版本流量。右上角的时间选择器则可以选取相应的实验时间段。
指标详情的入口在顶部Tab中。
指标详情也是通过图和表来展示，不过不一样的是，它能详细的展示某个指标的具体情况。例如，从折线图中，您可以观察到各个版本在每天的指标变化情况。您还可以从左上角的指标选择器中，切换选取不同指标，也可以从右上角，切换不同的数据展现方式，如按时或按日，并勾选您关注的实验时间范围。
指标详情下方是具体的指标列表。这里有一个关键项目：假设检验。
首先，您可以在该处，观察到每个版本的UV，也就是样本量，以及他们的具体转化人数、转化率等。
其次，通过变化度这一栏，可以看到每个版本相对于原始版本的提升或降低幅度。并且，系统会自动计算该变化度的置信区间，默认是以95%的置信水平进行计算。
最后，便是p-value和power两个假设检验结果，是用于判断假设正确与否的重要证据。虽然看过去很复杂，但实际上，大家直接根据系统给出的结果来进行判断即可：p-value中，蓝色表示效果明显优于原始版本，说明实验版本比原始版本好，并且假设检验的效果显著；红色则相反。而灰色表示实验版本与原始版本之间并无明显差别，一般意味着原始版本和新版效果相似、无需迭代。
而power则只分为两种，一个是灰色的功效不足，表示实验结果还值得商榷；一个是功效良好，表示实验结果通过第二层假设检验，结果可信。
最后要来说一个很好用的后期功能，它能允许您从更高的维度进行观察，这便是看板。
首先是第一种能力，基于实验维度的数据比对，即跨实验对比同类图表。您可以从任意一个应用中，抽调任意实验的任意图表，组成看板。这就允许您多个同类实验。以一个落地页的A/B测试位列，该实验在不同月份分别进行了A/B测试，如何将两个实验放在一起对比呢？看板便是为此而生的，如右图，选中第一个月份的实验，再选中第二个月份的，就可以并列观察了。
除了跨实验比对之外，看板也能在同一个实验中，对比不同图表。如图，您可以将某指标的所有图表统一放置在一起，不论是截图用作实验报告，还是研究产品的用户兴趣变化，都可以发挥很大作用这个功能，您可以在顶部的导航栏中找到。
A/B测试在国内的推进速度还是相对较慢的，其中的一个关键原因，便是大家并未意识到A/B测试数据的意义所在。
结合公开数据和行业深度调查，我们整理了行业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测试，有三点建议给到大家：
从最简单的文案A/B测试开始，比如说测试关键按钮中不同文案的转化率。
多做团队间的经验分享，多分享你的成功经验，有效果的事情大家都愿意尝试；不要天天去分享失败的经验，如果过多分享失败经验，会让你包括你的团队对A/B测试产生质疑，影响团队士气。
可以优先使用第三方免费的A/B测试工具，比如Testin A/B测试，目前支持App、Web/H5、小程序。
此次分享到此结束，希望能帮助到各位小伙伴更好的了解A/B测试哦！
网友评论