发布时间：2022-09-23 12:00:01源自：https://www.it-th.com作者 ：it谈话网阅读(291)
上篇文章《数据应用系列（1）-ab测试》我们讲述了一些ab测试的基础概念以及对市场上一些第三方平台进行了简单的对比分析。 如有平台使用的需求，各家公司可以根据自身业务情况选择一些厂商进行ab服务的购买，但一般情况下，选择服务厂商都会存在以下问题：
1.公司数据有泄漏风险
2.平台功能并不完全符合公司业务发展和变动，后期改造成本较大
3.选用服务成本不低，但是收效却不尽人意等。
所以部分公司权衡后便决定组织人力着手搭建平台，那么一个ab平台究竟要如何搭建，搭建的ab平台如何在业务中应用，实验过程中出现的异常如何应对等一系列问题便会接踵而至。
下面我将从平台的前期准备，业务场景、平台建设以及异常处理四个方面来讲述一下整个搭建的过程。
所谓前期准备就是立项前的一个评估，评估在什么“前提”下公司可以开始投入人力搭建ab平台。
这里的用户量级不仅仅是指app本身、还包括具体功能使用的人数量级，再具体点来说就是进入实验的用户量级，ab测试之所以有科学性主要是引用了统计学的评估原理，根据z检验的公式：
可以很直观的看出：如果样本量很小，单个用户的行为表现就具有极大的影响力，极易造成两个版本的差异变大，无法客观的评估实验结论是具有统计学意义的。
ab实验的原理上一章我也有所描述，整体流程类似于控制变量法，那既然是控制变量，就要通过对已知变量的控制来减少误差对实验的影响，即实验过程中只对某一变量因素进行控制，因此需要在功能切分上做到相对精细化的控制，避免引入其他影响因素造成实验结果不具备参考价值。
ab测试前期需要投入较大的研发成本，而实验过程平均周期也需要2-3周，最终得到的结果却不一定符合预期，甚至不一定是正向表现，需要反复的进行实验探究。一次实验从开始到最终结论产出的这个煎熬过程和”损失“需要我们能理性的接受。
ab测试并非是解决决策“分歧”的唯一依据，我们要以思辨的角度先去评估用户反馈的功能是否是产品的主功能或者影响了主流程的使用，毕竟在实验过程中要投入大量的人力和时间成本。
笔者在ab测试问题复盘的过程中，经常发现很多无故的放大用户需求的案例，最终的实验结果达不到最初的预期。所以在实验设计阶段或实验评审阶段大家尽量做到”三思而后行“。
上述列举的几点是笔者认为几个比较重要的因素，大家也可以结合自身业务特性进行其他角度的思考和补充。有了搭建ab平台的一些前置要素。下面我们进入第二篇内容，看一下公司中都有哪些业务场景需要进行ab测试：
36Kr曾在一篇报道中写道，“头条发布一个新APP，其名字都必须打N个包放到各大应用市场进行多次A/B 测试才能决定。
张一鸣告诉同事：哪怕你有99.9%的把握那是最好的一个名字，测一下又有什么关系呢？那互联网行业中都有哪些场景需要ab测试呢？下面我简单整理了一下不同角色工作中适用ab测试的业务场景：
列表中的是否发版用以判断实验变量控制位置，需要发版一般版本id要在客户端进行版本判断，不需要发版一般可通过服务端进行判断，按需则根据具体功能实现方式来选择。
数据来源是作为实验效果评估的主要数据依据。例如客户端实验主要以sdk采集的用户行为数据为主，服务端实验若无法全面的获取用户数据，则以服务端日志为主要依据，例如push实验，用户不点击push打开，则无法统计到用户行为数据，只有服务端记录的push下发相关的数据。
上面我们描述了一下平台搭建的前期准备和适用的业务场景。本章我们拆解一下平台如何进行建设，在开始这部分前，我选用上面一个流程优化的场景，通过一段”日常“对话来描述一下平台的需求都有哪些，方便大家进行理解：
业务产品经理：最近收到一批忠实用户的反馈，内容创作的入口应该从「我」中拿到主页面，我们想调整一下看不同入口位置哪种效果最好，目前已经设计了3个方案想搞个ab实验，选一个最优版本来代替当前版本上线。
平台产品经理：你们新版本大概什么时间开发好？实验需要运行多久？
业务产品经理：大概2021年1月1号能开发完，实验周期的话预计2周时间
平台产品经理：你需要提前想一下实验的名字，不然这么多实验列表里不好找你的实验。哦对了，你们这次实验大概要用多少用户？
业务产品经理：3个方案的话加上当前对照组，怎么也得用至少总体的20%的用户去验证效果
平台产品经理：那下次发版时间大概什么时候？
业务产品经理：预计过完年后，2月底了，这个版本功能比较多，所以如果数据效果好，看能不能通过平台直接全量到线上，过年大家是大家分享的黄金时间，所以来不及等下次发版功能代码开发了
平台产品经理：好滴!我们平台马上也要上线了，到时候可以直接在平台操作，不会耽误你们进度的。
从对话中我们提取几个关键词（红字标记）：
通过简单的一个场景描述，我们可以看到，一个ab系统的核心模块至少包括以下四个：
该模块主要是记录实验业务信息方便方便解读和查询，最少需要记录以下信息：
该模块用以确定变量版本，方便逻辑控制。同样，需要的字段和每个字段的意义我以表格形式进行了整理：
该模块下需要提供版本个数的增删操作，方便用户进行临时版本的增加和删除操作
实验流量管理模块应该是ab平台的核心功能之一，承载着确定变量流量，保证各版本分配的用户成分相似。但在互联网行业每天可能进行众多的实验，为了解决实验流量不够的问题，现通过引入流量层的方式来解决，所以实验流量就会出现正交&互斥的特性，那我在这里再简单描述一下相关知识点：
所谓互斥是指同层同时运行多个实验，彼此占用的用户不会被其他实验所占用，详见下图：
正交是指，相同的用户在不同层都会被随机打散，以便以足够离散的支持不同的实验，详见下图：
那我们如何实现的流量的控制（离散和圈定），主要有三个方面：哈希算法、哈希因子以及流量确认。
业界比较常用的算法是murmurhash，共有三个版本（murmurhash、murmurhash2、murmurhash3），这种算法是一种非加密型哈希函数，适用于一般的哈希检索操作，其优点如下：
1）简单（就生成的汇编指令而言）。
2）良好的分布（通过几乎所有键集和存储桶大小的卡方检验）
3）良好的雪崩行为（最大偏差为0.5％）。
4）良好的抗碰撞能力（通过了鲍勃·詹金的frog.c**测试。4字节密钥不可能发生冲突，差异不大（1至7位）。
5）在Intel / AMD硬件上具有出色的性能，在哈希质量和CPU消耗之间进行了很好的权衡。
当然还可以根据设备id的尾号进行分流，常用的分流算法有 crc_32、sha_256等，但是使用场景具有一定局限性：需要用户量足够大、设备id分布足够均匀、实验组数量不宜过多。
所谓的哈希因子，通俗的来讲就是被哈希的对象，一般情况下设备id（deviceid）、流量层id（layerid）就够了、还有一些统一测试平台还会涉及应用key或应用id（appid）、美团的业务场景下还会引入区域的id（areaid），所以一个哈希因子就变成了appid_areaid_layerid_deviceid。
通过哈希算法和哈希因子可以最终确定一个1-n的位置，假设是1-100，则某一层的总流量就是1-100，业务方通过平台上操作的实验版本个数和版本流量，来确定这个实验1-100的位置如何分配，就完成了一次实验的流量确认的过程，下图就展示了正交&互斥的完整流量确认的流程。
通过实验信息配置、版本和流量分配、实验周期的控制，最后一步就是通过实验数据来验证版本效果好坏，那我们要关注哪些数据呢？
1）北极星指标
所谓北极星指标就是业务核心发展的重点指标，换句话说今年kpi就全靠他了，所以实验版本的效果提升，都是采用对北极星指标正向的影响
2）业务相关指标
是指业务人员关注对策略改版本身有所影响的指标以及其他辅助指标的波动情况，从时效性上可分天级、小时级、分钟级
3）统计相关信息
除了以上指标，还可以观测ab测试版本中功能后续使用的留存情况，进一步去评估本次实验效果是真的好，还是偶然的好
上面根据业务场景和需求讲述了ab平台搭建需要的一些基本模块，下面我们就来将这些模块开始有机的组装和流转：
页面参考：
1）创建实验
2）指标查看
除了上述页面还应该提供一些管理页面，包括：用户管理、角色管理、应用管理（如果有多app的话）、元数据管理、流量层管理、指标管理等，这些页面这里就不作样例展示了，大家可根据自身业务特性来发挥想象。以上页面展示仅为参考，为方便大家便于理解上述所描述的内容。
业务处理流程：
上图中蓝色线代表了以客户端为逻辑判断的主要流程，红色线代表以服务端为逻辑判断的主要流程，不同的逻辑判断位置即代表了业务架构的差异性也影响数据获取的方式。
除了abtestsdk请求策略层获取版本id用以app端逻辑判断或传递给服务端进行逻辑判断外，还有通过业务服务端直接请求策略层进行逻辑判断的方式，如push实验，本身特性是无论是否有用户点击app，都需要根据push平台进行策略下发。第二节业务场景中所描述的是否发版和数据获取来源直接决定了ab的接入方式和效果评估的数据来源
功能框架参考：
通过前期评估、业务场景、系统流转以及平台功能的框架，基本一套完整的ab平台就已经初具雏形，下面我们就可以按照以下的操作流程开始进行ab实验，对每次策略进行效果评估：
在本文的第一章节有提及，我们要理性的接受ab测试过程中得出的结论可能无效甚至与预期相悖的，不过这些也不一定是实验本身策略的问题，那么有哪些因素会导致实验“无效”并且怎么去解决呢？
很多童鞋在做实验时特别着急的想去看结果，甚至迫不及待的实验开启几天就已经开始决定要上线，这样的做法显然是不可取的，实验周期的长短影响主要有以下几个方面：
a.影响样本量的大小样本量决定了样本的代表性和实验的可参考性
b.用户行为习惯影响数据指标，比如节日效应，或者例如有些工具类app工作日使用会较频繁，周末会下降
c.影响进入实验的用户情况，因每天用户活跃情况不同，若观测时期较短，可能会因一天的数据问题导致整体数据指标很大或者很小
d.科学的实验周期应该在2-4周范围内。尽量涵盖到目标样本量以及所有时间维度上（工作日、节假日）
辛普森悖论是指当人们尝试探究两种变量（比如新生录取率与性别）是否具有相关性的时候，会分别对之进行分组研究。然而，在分组比较中都占优势的一方，在总评中有时反而是失势的一方，我们可以通过下面的例子简单理解一下：
上面可以直观的看到，单看商学院和法学院都是男生录取率比较高。但是总体情况确实女生录取率（42%）是男生录取率（21%）的两倍。映射到ab实验上，实验版本和对照版本其实分别就对应的是女生和男生的录取率，辛普森现象的本质是通过加权平均引起的，而且样本量越大越容易出现这种情况。
所以如果要规避这个问题主要采用：
1）策略上线前，要尽可能的进行多维度分析，找出可能会影响的因素
2）实验分流前尽量选取合适的样本量，避免因样本量过大造成的反结果
3）实验方案设计时，要在相同量级的维度下进行实验。例如为了节省成本，将一个策略同时在双端进行实验，但本身android的用户量会大于ios，实验结论从整体看效果是正向的，但实际ios可能完全与其相悖
“幸存者偏差”是指，当信息来源，仅来自于幸存者时（因为死人不会说话），这个信息可能会存在与实际情况不同的偏差。所以大家在实验结果分析过程中，不仅仅要看用户行为数据与有版本id用户（即进入实验的用户）产生的指标情况，还应看有版本id的用户中具体触发这些用户数据的表现情况，综合来评判版本实验效果。
为了保证实验能在客户端稳定运行，避免造成实验组和对照组来回波动的情况，一般会采用缓存策略。但在实际进行ab实验时，存在对已经结束的实验进行重新开启的情况，此时这个”新实验“会受到之前实验分桶流量的影响同时还要考虑每次启动app时请求分桶流量的时机，尽量保证实验组和对照组在没有波动的情况下获取到最新的分流策略。
样本量的大小影响显著性水平、统计功效等。样本量太小，不具代表性，得出的结论不可信样本量太大，容易导致辛普森悖论，需要的实验周期长，同时流量有限又不能无限扩大，那多少样本量合适，我们可以根据公式进行反推，也可以用样本量测算工具（https://www.evanmiller.org/ab-testing/sample-size.html）计算。
在实际测试操作中，很多童鞋也会有这样的问题就是，既然我们统计的都是转化率这种相对指标，是不是我们实验组和对照组的样本量可以不相等，比如对照组1000人，实验组5000人，针对于这种问题，我们可以进行个假设：若实验组的流量是最小样本量，那证明对照组样本不够，极容易导致实验不可科学
若对照组是最小样本量，那”过载“的用户样本，会导致用户数据偏移、样本数据“浪费”以及辛普森等问题。所以大家在实验过程中要尽量保证不同版本的样本量一致。
业务童鞋在使用我们搭建好的平台，无论实验做的如何：可能是实验结果不符合他们预期，也可能是因业务接入问题导致实验失败，即使ab平台没问题也会先被质疑一番。
而分流是否合理便是第一个被质疑的对象，所以作为平台方我们即使用了当前最牛的分流算法，在平台功能上也要提供：分流数据实时、小时的进入流量的情况以及不同画像特征维度下实验组和对照组的数据分布情况，如果十分有必要甚至可以让业务每次实验都应该进行aab实验，用aa实验结果的准确性来保障平台的可信度。
虽然aa实验是验证ab平台数据准确性的有效手段，原则上aa实验（实验组和对照组的策略一模一样）的数据表现应该是一致的，但是有时候却发现两组指标竟然出现了差别，即使反复验证也会出现这种情况，这种情况就是aa实验的波动性。
导致这个问题的主要原因就是抽样的随机性，举个简单的例子：即使同样性别的双胞胎，经过相同条件下培训，最终答题的分数也不一定是一模一样的。所以如果要解决这个问题，可以考虑适当提升aa实验样本量的大小，在一定程度上可以抵消这种波动性。
A/B测试作为当前互联网领域用户增长、精细化决策的核心技能，越来越多的被各家公司作为基础能力所要求。
本文我们简单总结了一下ab平台系统搭建以及大家在平台使用过程中会遇到的一些问题，如果是此时你正需要搭建一个ab平台，希望读完后能起到一定的启发作用。
如果是平台的使用方，希望可以让大家加深对ab测试的理解。通过异常处理章节中的内容我们也可以看到，想做好一个科学的ab实验并非一件容易的事，需要大家积极拆解业务，理解ab测试原理和流程，以及统计学的相关知识。
希望大家可以在工作中灵活运用这一技能，为企业带来更大的增长效益。
-END-
欢迎分享转载→ 数据应用系列（2）——A/B平台搭建
上一篇：社群运营是用户运营吗？
