3.更便捷快速地完成配置
指使用者能够有较低的使用和学习成本，A/B测试本身需要比较专业的背景知识，在互联网企业内部往往是增长团队和产品经理等角色负责，但笔者所设计的系统面向传统企业以及一些有IT部门的企业，企业内是否有配置专业的人员来实施，是否有对A/B测试比较了解的人都是问题，所以产品设计上一方面需要考虑易用性，另一方面也需要考虑让交付同事能更好地理解以便引导客户使用
05系统架构
结合笔者调研的结果，目前会涉及到AB测试系统的公司主要有以下几类：
1.AB测试服务saas软件供应商
以saas 化形式提供AB测试能力，客户基于简单对接后即可基于平台能力进行 AB测试，能够有效降低企业自己的开发投入，企业体量没达到一定规模时或相应的团队建设没到位的情况下往往可采取这种方案，这些供应商可能同时也会提供其他数据分析平台等其他数据服务，针对的目前客户以有互联网相关业务、有 IT研发能力的企业为主
2.提供 AB测试能力的其他saas 平台
比如营销 saas 产品主要针对的营销场景下的 ab 测试能力提供、用户运营 saas产品主要针对消息推送场景下的 ab 测试能力提供
3.需自建 AB测试系统的企业
这类企业的公司体量基本都到了一定的规模，并且有专业的增长团队
在产品形态上，目前在不同类型产品上看到的总共有 3 种形态：
但抛开具体的产品形态，由于系统背后的原理、业务流程和目标都相同的，所以经过抽象后的系统架构其实是差不多的，仅在一些细节方案上有差异
1.业务层
这一层是AB测试的核心功能模块，用于支持用户创建 A/B 测试试验
1.1 样本设置
用于设置进入试验的客户，主要涉及 2 点：
1.样本筛选
可筛选特定类型的客户参与试验，可与CRM、用户画像系统相结合，可针对某一特定人群进行试验
2.样本量设置
可设置客户进入试验的占比或数量，样本量对于试验有效性有着重要影响，大部分系统都会提供一个样本量计算公式，结合用户设置的预期提升效果，告知用户较合适的样本量是多少、试验应该进行多久，让用户确保试验有足够的流量（也看到一些产品会提供一些经验值给到用户，比如让用户确保样本数量应该大于 1000）
1.2 流量分配
主要作用是决定客户命中哪个试验、命中的是试验的哪个版本，这块跟试验的管理结构有关系，分流模块需要满足以下要求：
1.随机均匀分流
分流规则是系统中比较核心的模块，有几个核心的点：
2.必须确保样本一致性
确保分配到不同试验方案的用户样本特征是一致的，在统计上控制单一变量原则，即所谓“随机均匀”
3.确保分流一致性
在分配到不同版本时应确保随机均匀分布，并且确保分流一致性（即同一客户多次进入同一 个试验，访问的试验版本相同）；
4.分层分流
当需要同时进行多个试验，且避免试验间会互相干扰时，需要通过分域的形式把一些会互相干扰的试验区隔开，用户只能命中其中某个试验，通过分层的形式把不会互相干扰的试验区隔开，用户可以同时命中不同层的试验，通用的 A/B 测试工具都会支持用户自定义层级规则和试验所处层级，但也并非必需，需要结合自身系统场景看是否有并发多个试验的场景，可查看下方分流模型示意：
分流模型图
1.3 试验配置
1.版本设置
可添加不同的试验版本，与对照组版本进行对比，不同类型试验版本设置会有所不同，同时设置方式也与具体的 A/B测试场景有关，比如：
这一块也是需要具体考虑，需结合业务场景和自身平台的情况考虑用户配置版本的方式
2.流量设置
即设置分配给各个版本的流量，总和需为100%，需要支持在试验中进行调整，方便使用者结合试验情况灵活调整流量分配（一般会先给试验版小流量试跑，然后再进一步加大流量）；
3.指标设置
设置指标后可在数据统计中看到不同版本对应的指标数据，用于评估不同版本的效果：
4.分层分域
本质上是为了解决流量在多个试验的分配问题，考虑的是如何尽可能地分配流量确保每个试验都有足够的样本，以及如何避免试验之间互相干扰，这些层和域需要结合自身情况去做划分，常见的可划分为启动层、UI层、算法层等，比如对于页面中同一个区域进行试验，如果现在在进行 2 个试验，分别对文字颜色、文字背景做测试，假设不把这 2 个试验分配在不同域，那可能出现文字颜色和文字背景都是同一颜色，会导致在前端完全不可见，进而影响试验
2.数据统计层
这一层会展示试验数据，包括试验设定的各个指标数据以及统计数据，使命是帮助用户更准确和快速地进行决策，选择最优的方案，其中统计类指标主要提供 2 个指标，一个是置信区间，通常采用的是置信度为 95%的区间，用于帮助用户科学评估方案效果，另外一个是统计显著性指标，用于告诉用户当前统计得到的结论在统计学上是否是显著有效的，提升决策科学性。
当然，有时候会需要去细分到不同人群去看效果，可以进一步评估方案在不同人群中的效果是如何的，在产品上只需增加一个客户筛选即可
3.数据接入层
这一层主要解决试验指标统计的问题，与 AB测试系统的应用场景相关，要拓展系统使用场景，肯定是得垂直地从数据埋点、试验设置都进行拓展，通过同步外部数据，可以大大拓宽使用场景，比如笔者设计的是营销 saas 系统，如果能对接交易数据，场景可以进一步拓展为“验证通过更低的优惠券折扣是否可促进交易转化率”
4.服务接入层
当企业内部有多个客户端、多个系统、多个场景需要对接 AB测试能力时，通过标准接口可快速完能力的部署，有助于可以提升系统的扩展开放性
06业务场景
当我们对系统要做的事情以及系统的整体逻辑有所理解后，就需要因地制宜结合自己负责系统的业务场景、客户特点等因素设计产品的能力分布和形态。
当然，场景肯定是没法遍历完的，但可以记下一句话：“当你无法衡量它时，你就无法优化它”，结合上文对系统架构的介绍，我们知道A/B测试系统底层需依赖数据埋点这一基础设施，当我们能埋的点，能统计到的数据越多，能调控的变量更多，系统能支撑的场景也就越丰富。
但笔者还是对常见的AB测试场景做个简单总结，方便大家参考：
其中 AB测试saas 产品无可置疑肯定基本都可满足上述场景，营销saas产品中则会围绕活动内容、消息触达、权益策略、活动流程等营销相关的场景做优化，垂直类场景仅支持自身产品场景的优化，比如“某策”能进行触达与否是否影响最终转化的 ab 测试。
07落地细节注意
1.分流模块
分流算法的实现方法网络上大把，推荐大家可以参考一下 的论文，具体实现上就是通过一致性哈希算法计算用户 id 、层 id 后进行取模即可，这样既可实现上文我们提到对于分流需要注意的关键点，但这里需要注意的是要结合我们设计出的产品形态，与上文的产品架构进行对应，考虑需要加什么因子加入哈希算法因子中。当然，一些平台为了确保样本的一致性也提出了一种验证性的方法，比如微博广告系统提到的一个解决方案：
在广告系统中，用户是通过多维的画像向量（a,b,c,…,n）来进行刻画的，如果流量划分是均匀的，意味着用户的每一个画像向量分量在该流量划分条件下是均匀，更进一步，多个画像向量分量的组合在该流量划分条件下也是均匀的。通过进行用户画像向量单个分量和若干个画像向量分量的组合的均匀性验证，即可来反映该流量的划分的均匀性
2.试验指标模块
这块目前也比较成熟，在代码上有一些已经封装好的计算方法可直接供开发去调用，目前 adobe 产品使用的是 t 检验的方式来计算置信区间和 P 值（p 值小于 0.05即证明本次试验是统计显著的），具体不成问题，问题主要在于公司内部目前是否一套比较完善的数据采集处理机制
08总结
结合全文，相信读者对于 AB测试系统已经有了比较完整的认识，大的原理和逻辑基本不变，变的是大家需要结合自身业务场景、自身内部系统情况去因地制宜，尤其是要做好业务场景的梳理，即可从目前已经拥有的数据进行反推，也可从业务需求进行正推。
但是，需要提醒的是，至此我们也只是设计出了一个能用的系统而已
AB测试的落地还需要依赖使用的组织和人，公司组织层面上是否有数据驱动的意识、执行人员层面是否具备 做AB测试的专业知识、支持做AB测试的场景是否有足够的价值吸引力、是否具备足够的数据量来做 AB 测试，这些因素都会影响到最终系统的落地效果。
如果碰巧你做的是 saas 系统，面向的客户可能是传统企业或传统银行这类有研发能力但数据驱动意识不强的企业，更是由于考虑清楚上面提到的几点，好好评估客户是否有落地A/B测试的能力。
———END———
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，永久会员只需109元，全站资源免费下载 点击查看详情
站 长 微 信： nanadh666
