平台架构设计

　　本文以一次性设计好ABtest功能架构为目的，对ABtest的使用场景与功能模块进行了分析。
　　最近在考虑一个产品的小功能改进，目前我们的产品列表按照产品带来的收益排序，如果用户点击了产品之后，那再点击这个产品可能就无法带来很大的收益，于是我们想到，那把用户点过的产品放在产品列表底部怎么样呢？
　　当然团队内部也有不同的声音，用户点击产品之后，可能由于网速、或者手滑，并没有实际上注册到第三方产品中去，那么放在产品列表底部可能会给用户造成困惑，也失去了用户第二次点击的机会。
　　内部讨论过后，我们认为这是个值得做的尝试，但应该以ABtest的方式去实现。根据数据，来决定是否要全量覆盖该功能。
　　ABtest的概念大家并不陌生，被广泛应用于快速迭代的互联网产品中。同时在以前的迭代过程中，我们也以其他方式进行过ABtest。
　　但是ABtest带来的问题是，单个功能的ABtest是很容易做的，但与此带来的数据统计拆分，每次都会带来重复的工作量。因此比较节约的方式是，一次性设计好ABtest功能架构，支持未来的持续ABtest，降低单次测试带来的边际成本。
　　一、ABtest的使用场景
　　从技术上讲，AB测试存在两种场景：纯页面交互AB和功能AB。这两种场景的区别仅在于是否需要向后端申请不同的服务。
　　二、功能模块
　　ABtest功能模块大概有以下三个：用户分流服务、ABtest配置、数据统计。整个流程如下：
　　用户访问后，根据用户属性，调取用户分流服务，根据用户分流服务返回结果调取相应ABTEST配置。
　　前端业务侧做数据埋点，在用户访问时，前端做数据上报。同时自动生成数据报表，处理原始数据后给出是否采信方案的结论。
　　2。1用户分流服务
　　用户分流服务用于将访问用户分流进入对应客群。
　　这里我做设计的时候有一个部分很后悔，就是我曾经做了一个版本是将用户分类展示不同产品列表的功能。本质上就是一种设定客群然后分流的服务，当时没有考虑到后来这个功能有这样的拓展，所以与产品列表与运营位配置耦合度很高。在做ABtest的分流服务时，只能独立再做一套。
　　事实上不仅用户分流服务是一个应该与各功能模块解耦的部分，客群服务（包括用户信息、用户画像建设）也应该解耦。这两个服务结合起来可用于：为不同用户做定制化展示、ABtest、黑白名单等功能应用。
　　2。1。1分层分流
　　说回用户分流服务来，大型系统会遇到一个问题，我们总是希望以小范围的测试来验证足够多的的假设。可如果多个部门多实验并行，实验之间又相互互斥的话，流量会不足。这里我们产生一个域的概念，不同域之间互斥，同一个域的不同层正交，正如下图所示（图片引用，具体见文末参考文章，之后不再赘述）：
　　不同域之间共享100流量，例如域1分流了30，那域2就分流70；
　　同一个域的不同层之间，会重复使用这个域中的流量，但不同层之间，每次进入流量会重新打散，保证互相不影响；
　　同一个层之间配置ABtest的实验ABN，共同分享这个域中的流量，不同实验组之间相互互斥共享100该域流量；
　　2。1。2如何对用户分流
　　用户分流方式有三种，一般使用的是以用户维度分流，这样可以保证单一用户每次进来看到的是相同实验，不会造成体验上的不一致：
　　以用户维度；
　　以分类维度；
　　完全随机；
　　哈希因子：实验的Hash因子有设备ID、策略ID、流量层ID，根据具体需求，可以选择其中的几个因子组合后Hash，。
　　HashIDHash（设备ID，策略ID，流量层ID）1001
　　这样每个用户会得到唯一的HashID，同时会落在〔1，100〕的范围内，让用户随机均匀散落在这个范围内。如果需要将流量控制的更精准，可以对1000甚至10000取余，这个根据实际情况灵活做选择就好。
　　在配置实验时，根据实际需求，为各个版本均匀切分流量。譬如A版本划分10的流量，则HashID从010的用户被划分到A版本，以此类推。
　　2。2ABtest设置
　　ABTEST设置用于配置实验，做实验的增删查改，同时对线上的实验做管理，及时上下线。
　　管理员在ABTEST配置系统中，新建实验，并设置分流规则。完成后实验配置入库，当用户访问产品时，根据分流规则调取ABTEST实验版本。
　　2。2。1新建编辑实验
　　step1：新建实验
　　step2：输入实验信息（实验的基本信息、生效时间）等
　　step3：选择分流服务
　　step4：选择后端服务
　　step4：选择数据指标
　　2。2。2管理实验
　　管理实验模块主要用于上下架实验。
　　2。3数据统计
　　ABtest最重要的一部分是统计和分析数据。在建立实验时，同步选择需要关注的数据指标。以实时或T1的方式，展示数据报表。在新建实验时，可以在现有的埋点指标中做选择，选择出用于分析实验效果的关键漏斗指标，生成报表。在技术实现上，埋点的数据上报，需增加分流服务ID。
　　2。4数据分析
　　在数据统计完成后，更重要的部分是我们如何根据数据报表来判断各个版本的优劣。由于其他因素的扰动，譬如流量质量、级别等因素，同一个实验的多个版本会有微小数据差别，在一定程度内的数据差别是正常波动，并不能说明某个版本更优。因此大部分的ABtest系统采用了T检验。
　　为什么要T检验或者其他检验呢，是因为样本参数总体参数机会误差偏差，现在我们手里有样本，可以计算样本参数，但是我们想知道的是总体参数，但是这个样本参数能不能代表总体参数呢？T检验在这里就是用来判断是否是机会误差这个因素造成，通俗点说就是样本得到的参数值可不可能由于是抽取的时候的随机造成的。
　　2。4。1P值（Pvalue）
　　P值检验用于验证假设。在ABtest里，原先的版本可以称它为H0（原假设），新的版本称为H1（备择假设），假设就是我们认为H1版本是优于H0的。若P值落在置信区间里，那我们的假设成立，若P值没有落在置信区间，就认为P值推翻了我们的假设。
　　P值越小，我们认为H1这个备择假设越靠谱。P值越大，H1越不靠谱。置信区间是我们自行定义的靠谱区间。
　　以上我们计算出了T值，通过查询界值表，可以获取到P值。
　　2。4。2置信区间
　　刚才说置信区间是人工定义的，值你可以定义为0。05、0。1，这个根据实际情况去做选择，1就是置信区间，除此以外的就是拒绝域。
　　若p，那么拒绝原假设；
　　若pamp；gt；，那么不能拒绝原假设。
　　推荐阅读（即参考文献）
　　1。【ABtest在OpenSearch上的设计与实现】
　　https：yq。aliyun。comarticles672758？spma2c4e。11153940。0。0。74981c4aY0BCsgamp；amp；type2
　　https：help。aliyun。comdocumentdetail89958。html
　　2。【推荐系统衡量：ABtest框架】
　　https：cloud。tencent。comdeveloperarticle1450557
　　3。【马蜂窝ABTest多层分流系统的设计与实现】
　　https：my。oschina。netu4084220blog3053499？fromtimelineamp；amp；isappinstalled0
　　4。【美图ABTest实践：Meepo系统】
　　https：my。oschina。netleejun2005blog302500
　　5。【Netflix推荐系统模型的快速线上评估方法Interleaving】
　　https：www。jianshu。comp40eb1b7d6932
　　6。【携程机票的ABTest实践】
　　https：zhuanlan。zhihu。comp25685006
　　7。【沪江ABTest测试平台实践】
　　https：www。itcodemonkey。comarticle5227。html