导读：不管在精益创业还是增长黑客理论中，A/B测试作为一种成熟的数据驱动产品优化的科学方法，其核心意义并不在于某一次试验的成功或者失败，而是这种通过试验和数据驱动的产品不断进化过程。A/B测试系统就是一套能将A/B测试方法标准化的工具，通过产品化后，可以降低用户使用门槛，提高A/B测试迭代速度，规范试验流程减少人为操作过程中所犯错误，还可以沉淀不同的数据和策略。

01. A/B测试系统核心功能

虽然A/B测试可以分为界面类、功能类、人群类以及算法类，但其整体流程、核心功能基本一致，故可以设计一个通用的A/B测试系统来支持。一般而言，一个完整的A/B测试系统至少需要有试验管理、分流模块、业务接入、数据采集和结果分析这5个模块，下面来一一介绍。

1. 试验管理

试验管理就是一个A/B试验配置后台，通过页面与用户交互引导用户完成试验关键参数配置，并允许用户对试验进行管理。方便用户快捷的创建A/B测试试验，增加新的A/B测试分组，调整A/B测试方案各个组的比例，让A/B测试运行起来。试验管理模板对实时性要求最高，需要在用户操作调整确定后，实现线上试验随即变更。

2. 分流模块

也叫流量分配模块，这个模块根据试验配置信息在用户请求服务时将用户分配给不同的试验组别。可以说分流模块是A/B测试最核心的模块，一个A/B测试系统设计的好坏关键看分流算法以及策略是否优秀。好的A/B分流模块可以让流量分配的更均匀随机，同时需要具备根据用户、地域、时间、版本、系统、渠道、事件等各种维度来对请求进行分组的能力，并且保证分组的均匀性和一致性。分流模块相当于一个路由器，所有的请求进入分流模块根据用户唯一ID以及其他参数，通过系统的随机化算法按照给定的配比，将流量 ( 用户 ) 分为A/B两组 ( 或者多组 )。

① 常用用户唯一ID选择

一般来说，通用分流服务的用户唯一ID会根据不同终端采用不同的用户标识，目前通用做法为Web端 ( 含PC以及APP端内的H5 ) 采用Cookieid，APP端采用设备ID ( 设备ID不同公司有各自生成算法，一般来说IOS会用IDFA，安卓采用MAC地址+AndroidID+IMEi )，小程序端采用openID作为唯一标识符。如果需要做到多端联动，还需要通过用户的注册ID等其他信息进行IDMapping，建立平台真正的统一用户标识。

② 通用Hash算法

Hash算法即散列算法，它并不是一种算法，而是一族算法，是密码学中一种单向不可逆加密算法，目前比较通用的Hash算法有MD5、SHA、Murmur等，通过一个函数将明文随机均匀分布到算法设计的多维空间中，空间维度越多，算法越复杂也越难破解。如果有技术实力，可以根据密码学知识设计自己的Hash算法，具体可以查看密码学相关知识。

目前在A/B测试中应用比较多的是通过Murmur算法将用户的唯一标识以及试验层layerid作为参数传入进行分组。这样既保证了用户分组的随机性，同时也保证了多个层之间的正交关系。

常见的流量分配策略见表1。

表1 常见流量分配策略对比

3. 业务接入

业务接入方便在产品迭代优化的各个阶段整合A/B测试能力，对优化点做各种A/B测试。一般通过提供一个A/B测试SDK或者A/B测试Restful接口的形式供业务方使用。接入模块需要做到高效易用，最好能够适用于产品上所有类型的A/B测试优化。

业务接入目前主要有几种方式：

第一种：分离URL试验

分离URL试验最终在试验配置完成后会生成两个不同URL，通过两个不同URL最终对应两个不同版本的页面。这种接入方式的优点是实现简单，数据采集也比较容易，正常的系统日志即可实现数据采集，但是试验页面需要做两套上传不同的页面，对前端资源占用比较大。特别是如果同一个页面的多变量试验时工作量会显著增大。

第二种：编程代码试验

编程代码试验是通过在同一个页面，但是会通过代码控制页面的展示，这种方式对系统要求复杂度会明显提升，在试验配置完成后，需要生成相应的控制和埋点代码，需要将代码复制埋入试验页面，由于是通过代码控制页面展示，故数据采集需要有所调整，将试验参数也作为埋点采集的数据点。

第三种：可视化试验

可视化试验是前面两种方式的结合，最主要的是降低了设计门槛，可视化试验在生成基础页面后，通过可视化页面编辑修改变量并保存后就可以生成不同试验版本，试验的参数通过URL参数带入。

4. 数据采集

行为数据打点和数据收集通过记录用户在A/B测试模块的行为，将用户的行为收集到数据中心，为最终确定新的优化点是否有效提供原始数据。这一块可以参考本书中埋点和行为数据采集相关章节，这里不作详细讲解，只需要在其中增加用户试验名称、组别以及试验变量参数等相关信息就行，不需要再为A/B测试单独再设计一套专门的数据采集系统，如果没有现成的SDK采集系统基于日志也是可以的。因为在一段时间或者在同一时间整个产品中会有多个A/B测试在运行，只有记录了对应的试验和策略，我们在数据分析时才能更好地分析试验结果。

5. 结果分析

对上传的日志进行数据清洗和数据分析，最后通过报表的形式进行展示。将采集的数据通过报表或可视化的形式展示出来，并给出效力、置信区间等指标 ( 如果有样本选取过小，还提示最小样本量 )，另外最好支持好各类效果评估指标扩展，可以将指标计算通用化、模块化，方便试验人员快速上线A/B测试，根据不同产品及A/B测试案例选择合适的指标。具体效果评估指标的定义需要读者根据自己公司行业特点、产品形态、功能点等来定义，指标能够方便量化，并能够直接或者间接跟产品体验、用户增长、商业变现联系起来。

以上就是A/B测试最重要的五大模块，这其中试验管理、分流模块、业务接入是构建完整A/B测试体系必须具备的模块，数据采集和结果分析是配合A/B测试能够更好的得出可信结论必须具备的支撑模块。其他的类似于用户创建、权限管理等不是特别涉及A/B测试功能的本书就不做详细介绍了。

02. A/B测试系统设计方案

我们介绍完A/B测试的基本概念和核心模块后，知道了每个模块的作用和价值，那么在实际构建A/B测试系统时，这些模块是怎么组织起来提供服务的呢？下面我们就搭建互联网金融公司的实际应用为例，设计一个A/B测试系统。

1. 背景介绍

这是一家以互联网理财产品销售为主营业务的互联网金融公司，对A/B测试系统需求主要为APP以及针对对外投放H5页面的测试，而且由于合规要求，很多展示需要用户完成三要素鉴权或者满足合格投资者认定才能向其推送，因此策略需要针对用户进行一致性体验，而且用户只有在完成注册且登录的情况下才能购买相应的产品，所以需要打通用户多端ID，我们通过统一的PassportID代表用户的唯一ID，出借率作为其核心关键目标。

2. 流程设计

根据A/B测试的一般流程设计出A/B测试系统的流程，因为A/B测试系统其实就是将A/B测试固化的工具，它的基本步骤如图1所示，下面来详细介绍。

图1 A/B测试系统流程图

① 系统登录：这个是系统的通用模块，需要有用户以及权限管理，可以基于公司的OLAP或者公用的统一权限平台接入，一般企业内常用的为公司邮箱账户作为登录名，以免导公司内部账户和权限管理不一致，特别是员工离职或换岗的权限变换，这一部分有成熟的解决方案，可以参考RBAC ( 用户角色权限控制 )，如果前期项目用户较少可以采用白名单机制也是可以的。

② 填写项目信息：包含项目名称、试验的目的以及试验假设等相关信息。项目信息一定要清晰填写，以保证其他用户能通过项目信息全面了解试验的目的以及试验的方案，一般来说在线下沟通确定完业务的需求后才填写相关信息。

③ 选择OEC指标：在系统设计OEC指标一定要跟业务方多沟通，确定当前业务最核心的目标是什么，一定要将业务最为关心的指标包含在内，而且指标模块一定要有扩展性，系统设计时留出接口，为后期扩展提供帮助。

④ 确定试验方式：确定试验用来探索哪个因素会对目标产生影响，比如目标是提升出借率，那么可能就短信营销、PUSH推送、优惠券活动、也可以是文案的情况、页面素材的颜色、按钮大小，这些可能都是，你需要确定这次试验是就哪个变量测试，之所以要按这个做分类，是为了分析中可以对同一类试验进行对比。

⑤ 设置各组占比：根据选择的变量，创建变量的变化，并分配各组用户比例。比如控制变量是按钮的颜色，我们就可以设计红色按钮、蓝色按钮等多种颜色按钮的变化。在这里颜色就是要测试的变量，而红色、蓝色等对应是变量值。值得注意的是，A/B测试并不是说一次只能测试一个方案，如果你的用户量足够多，能满足试验需求，完全是可以针对一个变量的多个变化同时测试。我们创建的这些变化要确保它们符合我们的预期目标。

⑥ 控制试验：在试验创建成功后，对试验进行控制，可以修改未启动的试验，启动创建的试验，停止异常试验，克隆其他试验等。试验控制相当于开关直接控制分流模块，决定是否让用户参与试验。开启试验后，我们网站或APP的用户会被随机分配到控制组和试验组，用户每一步的操作都会被记录采集，计算和比较，以确定对照组和试验组在每一项改变上的表现。

⑦ 采集试验数据：试验开始后我们需要持续的采集各个版本的访问用户的行为，这一块可以参考本书的埋点统计，目前前后端埋点采集系统都可以得到相应的数据，只是需要注意的是需要把不同实验iD等信息作为埋点信息项采集。

⑧ 分析试验结果生成试验报告：完成之后就是结果分析。将行为数据以及业务数据相关联，最终是为了针对OEC进行分析或者其他信息挖掘，A/B测试会显示试验数据，并告诉我们两个版本的用户行为是否存在显著差异。

⑨ 持续迭代：如果试验组的行为达到了我们的预期目标，那么我们就可以继续根据A/B测试结果进一步改进产品。反之，也不必气馁，我们可以把此次测试作为经验并且生成新的假设然后继续测试。需要再次强调，A/B测试不是一次性的试验，是一个反复迭代优化的过程，不管测试结果如何，我们都要根据测试经验来实现产品优化的闭环并持续不断的提升用户体验。

如果利用的是分层模型，可以设计针对人群定向的功能，白名单功能以及增加根据试验结果动态分配不同组别流量的自动化发布工具等，但这些都是在A/B测试系统中改进，在此不再一一介绍。

3. 原型设计

① 试验概览试验概览类似系统的dashboard，方便试验人员快速了解系统目前运行状态，主要包括试验概览、流量的概览，如图2所示。

图2 试验概览设计范例

试验概览模块是让实验者或分析师快速了解系统全息信息的地方，类似网站的首页，首先要让用户了解到目前进展的实验有哪些，实验中用户情况，一般可以包括以下数据指标。

昨日试验数：昨天开始运行的试验数。
累计试验数：所有运行过的试验数，等于运行中的试验数+已结束的试验数。
运行中试验数：状态为运行中的试验数。
未运行试验数：所有未运行过的试验数。
试验中用户数：参与试验的bucket中的用户数。累计试验人次：所有运行过的试验的用户数之和。

建议可以更多的使用展示图形，可以用柱形图、折线图等，可以根据各自要展示的信息选择相应的图表，比如上图用的饼图和面积图：

饼图：为当前时间，系统中实验中用户和可用用户以及占用用户的占比情况。
面积图：最近7天系统中，实验中用户和可用用户以及占用用户的构成情况。

图中左下角有"运行中"、"最近结束"和"最近创建"这三个列表，单击字段名均可自动排序，默认均按照试验的创建时间降序排列，最新的在最前面，单击可以升序排列。

运行中：是使用状态为运行中的所有试验的列表。
最近结束：是结束时间为当前时间前30天内的所有已结束的试验的列表。
最近创建：是创建时间为当前时间前30天内的所有的试验的列表。

如果当前没有任何记录，则显示，您没有"运行中、最近结束、最近创建"的试验，请创建试验，单击方框区域，直接跳转到试验设计页面。

点击表格上的新建试验，同样直接跳转到试验设计页面。

点击表格上的查看全部，直接跳转到试验管理页面。

② 试验管理

如图3所示，点击页面上部导航条中的不同选项卡，可以切换到不同的表格，默认为"全部试验" ( 包含未运行试验 )。点击"未运行"选项卡，则表格筛选出状态为未运行的所有试验；单击"我的试验"选项卡，则只显示该登录用户创建的试验。

图3 试验管理设计范例

表格右上角：搜索框为模糊匹配表格中的测试名称或者描述与搜索框输入的文字匹配的记录。

当试验还未运行时，操作有以下几个：删除、开始

当试验正处于运行中时，可以查看、结束

当试验已经结束时，操作有以下几个：查看、数据统计

只有创建该试验的用户能对试验的状态进行修改，即只有创建者才能启动、修改、删除和结束试验等操作。

③ 创建试验

首先填写试验名称，试验名称只允许包含英文字母数字和下划线，建议命名规则为英文名称_日期，字符长度为16字符。

试验描述：填写试验的目的、假设以及特殊操作，可以填写中文字符，不超过256字符。

图4 试验创建设计范例-1

如图4所示，点击下一步进入指标选择。每次点击下一步，将保持所填写信息，返回上一步，会显示所填写的信息，可以修改。

图5 试验创建设计范例-2如图5所示，试验类型为，为下拉选项，选择试验是修改哪一类变量，比如PUSH、营销活动、文案素材等。评判指标 ( OEC )，目前出借端定义为出借率=出借人数/参与试验人数*100%。

图6 试验创建设计范例-2

如图6所示，默认生成2个组，第一个组为控制组，第二个为试验组，组别名称默认为试验名称_数字，可以修改，变量描述是填写对各组所做的差异性控制。试验组别名称不超过20个字符，变量描述不超过50个字符。

试验用户分配的百分比最小区隔是1% ( 由系统分桶的最小颗粒决定，我们用户按100分桶，故最小用户群为1% )，可以直接填写数值也可以拖动滚动栏，占比必须是整数个百分点，在表格上面有当前可用用户百分比，各组试验用户分配百分比之和不得大于该数值。

单击增加试验组，表格增加一行，组别名称认为试验名称_数字，数字往下不断增加，试验类别只允许为试验组，最后一列为操作，可以对组别进行删除，控制组不能被删除。且每个试验中试验组可以有多个，但是控制组只能有一个。

图7 试验创建设计范例-3

如图7所示，人群定向可以针对IP地址、浏览器或者根据用户标签进行人群定向。点击添加受众条件可以选择相应的字段，根据字段的类型，条件不一样。

主要比较运算有：>，<，=，！=，>=，<=、包含、不包含 ( in not in )

后续逻辑连接：是该条件与下一个条件的关系 ( 与或非 )

图8 试验创建设计范例-4

如图8所示，设置开始和结束时间，开始时间必须大于当前系统时间，如果选择了其他时间，则为预约的开始时间。结束时间默认为开始时间+30天，也可以自由选择，试验到结束时间后自动结束，也可以人工手动结束，到时结束时间以手动结束为准。在试验创建成功后根据试验平台的设计会提供URL连接或者代码，需要将这些配置到要试验的页面或功能中，需要技术同事接入。

④ 试验执行

点击开始试验后，进入代码以及URL验证阶段，验证通过后根据反馈即进入试验执行阶段，用户正式被分配给不同方案，同时数据采集系统或者日志系统会记录用户的后续行为，包含业务行为和操作行为。如果验证没有通过需要重新验证代码或者URL的配置是否正确。

⑤ 试验报告

如图9所示，试验报告展现试验的进展情况，包括试验的基础信息，多少用户参与试验，各组占比，运行天数，开始时间、各组的指标情况以及结论。试验分析模块如果有技术实力可以做到实时更新，但实在没有相应资源通过T+1更新也是能接受的。

图9 试验报告设计范例

03. A/B测试系统设计要点

上面已经以互联网金融为例简单设计了一个A/B测试系统，但由于不同业务的差别也有一些差别，但总体来说一个合格或者优秀的A/B测试系统要做好以下几个方面：

1. 科学的流量分配

很多人在设计A/B系统时会发现系统在本身就存在偏差，导致系统根本没法使用。A/B测试系统又叫随机试验系统，其核心在于随机，故在系统设计完成后，需要进行多次A/B测试，以验证系统随机算法。原则上通过分桶方式的随机算法，每一个桶中用户与全体用户的用户特征属性等保持一致，即统计中的样本与总体保持一致。故通过分组人群特征分析以及A/B试验结果验证。

2. 足够的用户数据

A/B测试的结果需要大量数据支撑，试验用户越多的得出结果越准确。因此在不影响其他试验的前提下，尽可能为每个试验分组提供更多的用户数据，对提高试验准确率有很大帮助，但由于任何公司的用户都是有限的，所需要进行的试验却很多，分配用户越多其成本越大。

一个有效方式就是通过多层试验模型，让用户可以一次参加多个变量试验。在多层试验中，每一层都包含了全部用户，通过多层叠加可以放大用户数，每一层可以是一个变量试验，但一般需要通过转化率计算出试验最低所需的试验用户数。

另外，要让A/B测试得出可信服的结论，A/B测试需要经历一定的周期，才能得出比较有价值的结论。如果只测试较短时间，有些时候是用户存在周期性或者用户对新的事物的偏好，导致数据与真实情况会存在偏差。这时最好的做法是让A/B测试运行一个足够长的时间段，让结果稳定下来，再来比较核心指标。具体选用多长的时间需要根据行业及经验来定，并且在在计算核心指标时，可以剔除掉初期的数据，避免初期的新鲜感影响最终评估结果。

3. 严谨的结果分析

需要根据研究的统计推断知识做出结论，而不能仅仅根据不同组别之间的数据差别的经验直接得出结论，在数据采集不够或者不够显著的情况并不能得出相应的结论。因此不能只根据某个指标几日来的平均值作为试验好坏的参考和依据，而需要采用专业的统计学方差分析或T检验等手段，对试验数据进行评估。这能够有效的规避大部分由时间和分组随机性带来的数据波动，得到最准确的评估结果。

4. 持续的迭代更新

A/B测试本身是一个开放的不断循环迭代的进化过程，因此系统也要满足其不断迭代的变化，首先测试目标是多样的，系统要支持定义和增加新的评价指标，其次，对多种场景应用的支持，文中虽然只写了用户界面类试验的设计方案，但其他类似模块是可以快速接入的。另外在用户操作上减少用户重复，提高试验效率，因此类似克隆功能等都是不错的改进点。

至此，A/B测试系统实现问题就介绍完了，其他算法类的A/B测试也类似。希望读者从中学到怎么落地A/B测试系统。

以上章节，选自：《数据产品经理：实战进阶》

新书推荐：

本书鲜读专栏价：89元=电子书（提前三个月看到）+纸质书+12个作者维护的付费知识星球。如果转发链接，还可以拿到更大优惠：可以得到成交返利的40%。（具体操作方法，可识别文末海报二维码，获得详细教程，以及知识星球加入方式。）

以下为作者杨楠楠老师对本书的介绍：

1. 为什么要写这本书：

本书诞生于数据产品经理社群。

四年前，我在知乎上开始写数据产品经理的专栏，几个月间，有几千名读者关注我，加我微信，于是我就建立了数据产品的微信群。

很多人都在群里问，有没有一本可以让数据产品经理系统学习的书？

世上本没有这样的书，问的人多了，我决定自己写一本。

考虑到个人的经历，始终只是数据产品的众多种类中的一部分，于是我在群里召集大家一起写。

响应者众，有20多名数据产品经理，报上来的章节有30章。超过了我的预期。而我挨个聊下来，发现每个人手里，都有足够好的项目，在自己的领域，也有足够的资历来传播经验。

于是跟华章的总编辑杨福川老师商量，我们决定出两本书，一本讲专业知识：《数据产品经理进阶》，一本讲案例：《数据产品经理实战》。

在三四年处理众多问题和咨询的过程中，我发现数据产品经理随着成长，主要分成以下几个阶段：

初级/中级阶段：自己怎么样可以在团队中发挥更大作用。很多产品经理要么是执行业务的需求，要么执行老板的需求，要么是在帮算法RD标数据，价值感不足；
中级/高级阶段：怎么让数据对公司业务产生价值；

我们的每个作者，都已经超越了上述两个阶段。

他们是这个行业的中坚力量，也愿意给这个行业留下自己的痕迹。

《数据产品经理实战》书，主要回答了第二个问题，每个案例在业内都属于非常好的项目，给公司带来了较大的收益。

而《数据产品经理进阶》（以下简称《进阶》）这本书，主要笃实数据产品经理的知识结构，帮助读者度过第一个阶段，包括以下内容：

① 为了让你可以进一步了解数据产品经理，我们提供了：数据产品的行业视野、产品经理自身的能力要求、以及面试和招聘；

② 为了让你hold住全场，成为团队的驱动力，我们提供了通用能力模块，包括数据分析能力、产品经理的项目运转能力；

③ 只有数据部门能使用数据，没法做到数据驱动。让公司的每个部门、每个人，都能方便快捷的使用数据做决策，才算是数据赋能，才能够极大的提升整个公司的数据水平。

这需要良好的数据建设能力。

所以，我们提供了数据采集、治理、应用、能力输出的整个链条的内容：

数据采集：埋点体系
数据治理：数据中台、指标体系、数据管理；数据治理是数据建设的基础，所以这一步共提供了三章内容。
保证数据良好的应用：ab测试系统；
数据能力输出，把数据赋能于各个部门：数据服务。

④ 策略产品可以直接将数据变现，是非常重要的一个数据产品的方向，我们提供了搜索、用户画像等常见的策略产品的知识。

不同的公司对数据的要求不同，有些公司会更关注可以直接进行数据变现的能力，有些公司会更关注数据建设的能力。

那对于一个新手，要不要了解这么多内容？

这里提供一个做事思路：不要给自己设限。你先留意了这些内容，才会对公司的数据现状进行思考和认知积累，才能知道公司的数据有哪些机会。

产品管理的主动权，应该是产品经理自己争取来的，而不是等待别人给你。

在你去争取之前，我们希望，我们提供的这些章节，是你最好的武器。

2. 读者对象：

数据产品经理：完善自己的数据知识体系和职业成长。
企业领导者：了解数据团队在数据、产品、运营、市场等多个方面如何产生价值。
想要转行数据产品经理：了解数据pm具体的工作内容。

3. 致谢

非常感谢12名作者，在工作的百忙之中，牺牲自己的休息时间，辛苦撰写文章。

感谢机械工业出版社华章公司的编辑杨福川老师：在这半年多的时间中始终支持我的写作，对书的架构和写作提出宝贵意见。

感谢项目经理徐湲策：同时协调两本书的20位作者，是一件非常辛苦和琐碎的事情。在项目开始的前半个月，我几乎都在协调，没有时间写书，可见这份工作实在是占用时间和精力。于是我在群里招项目经理，小徐主动站出来承担了这个责任，并展现了他在项目管理方面的专业性。

有十余名志愿者参与了本书的试读，并提出宝贵意见，对本书的质量有很大帮助。他们是：黄宇、梦婷、范昱辉、王资涵；

感谢数据产品群千余名群员的活跃和分享。

谨以此书献给数据产品经理路上的前行者！

PS：如果您喜欢本书，可 识别下方二维码购买，并可参与活动邀请好友 获得40%返利~~

本文来自 DataFunTalk

原文链接：

https://mp.weixin.qq.com/s/VfKfyTbhF56ORd6FQ7EH3w

创作场景

如何构建 A/B 测试系统，其核心功能有哪些？