前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >笔记︱一轮完美的A/B Test 需要具备哪些要素?

笔记︱一轮完美的A/B Test 需要具备哪些要素?

作者头像
悟乙己
发布2021-12-10 17:39:22
2.8K0
发布2021-12-10 17:39:22
举报
文章被收录于专栏:素质云笔记

文章目录

1 A/B Test 实验的业务意义

文章[2] 策略的改变,不是由我们随便“拍脑袋”得出,而是一种建立在数据基础上的思维方式,数据反馈会告诉我们做的好不好,哪里有问题,以及衡量可以带来多少确定性的增长。

2 相关概念理解

2.0 AB实验

为了验证一个新策略的效果,准备原策略A和新策略B两种方案。

随后在总体用户中取出一小部分,将这部分用户完全随机地分在两个组中,使两组用户在统计角度无差别。 将原策略A和新策略B分别展示给不同的用户组,一段时间后,结合统计方法分析数据,得到两种策略生效后指标的变化结果,并以此判断新策略B是否符合预期。

上述过程即A/B实验,亦被称为“对照实验”或“小流量随机实验”。 最常见的一种A/B Test方式(可见文章[7]):

其应用场景包含:

2.1 AA分组 —— 更好筛选样本

文章[2]提及,如何更好地筛选样本 首先看如何解决第一个问题:

避免因流量分配不平衡,A/B组本身差异过大造成对实验结果的误判。

为解决该问题,我们引入了AA分组:

基于实验者圈定的流量,通过AA分组将该流量分为无显著性差异的实验组和对照组。

我们这样定义无显著性差异这一约束:

首先,实验者选取的用于刻画实验流量的指标,在实验组和对照组之间无统计上的显著性(即上节所描述的基于均值的假设检验);

其次,在所分出的实验组和对照组之间,这些指标的差值最小,即一个寻找最优解的过程。

从实验者的实验流程看,在实验前,圈定进入该实验的流量,然后确定用于刻画实验流量的指标,最后调用AA分组,为其将流量分成合理的实验组和对照组。

2.2 混杂因素

文章[4]有提及:

混杂因素就是研究对象的个体差异,它们不是你试图进行比较的因素,但却最终导致分析结果的敏感度变差,比如不同城市的人,不同年龄段的人,性别……,进行实验的时候要尽量避免混杂因素对结果的影响

2.3 根据实验种类分类

根据实验种类分类

  • 水平实验:类似于Overlapping Layer中的实验,是属于同个“层”的实验,实验是互斥的,在同一“层”上实验可以理解为是同一种实验,例如:关键词“层”表示这一层的实验都是关键词相关的,该层上存在实验H1和H2,那么流量绝对不会同时命中H1和H2。
  • 垂直实验:类似于Non-overlapping Layer中的实验,分布于不同“层”之间,实验是不互斥的,例如在关键词“层”和CTR“层”上在相同的分桶上配置了实验V1和V2,那么流量可以同时命中V1和V2。
  • 条件实验:表示进入某“层”的实验需要满足某些条件,水平实验和垂直实验都可以是条件实验。

根据流量类别分类

这种分类主要了为了用户体验,使平台在操作上更加的简单、易用:

  • 普通实验:最基本的实验,根据流量类别进行配置。
  • 引用实验:流量分类是整个配置中心基础,但实际上存在一些实验是跨流量了,而引用实验则可以配置在不同的流量种类中。
  • 全局实验:可以理解为特殊的引用实验,全局实验在所有流量上都生效。 演示一个包含水平、垂直实验的案例:

2.4 互斥实验

互斥组,也称互斥层、实验层。“实验层”技术是为了让多个实验能够并行不相互干扰,且都获得足够的流量而研发的流量分层技术。

举个例子,假如我现在有4个实验要进行,每一个实验要取用30%的流量才能够得出可信的实验结果。此时为了同时运行这4个实验就需要4*30%=120%的流量,这意味着100%的流量不够同时分配给这4个实验。那么此时我们只能选择给实验排序,让几个实验先后完成。但这会造成实验效率低下。实验层技术就可以完美解决这个问题。

我们把总体流量“复制”无数遍,形成无数个流量层,让总体流量可以被无数次复用,从而提高实验效率。各层之间的流量是正交的,你可以简单理解为:在流量层选择正确的前提下,流量经过科学的分配,可以保证各实验的结果不会受到其他层实验的干扰。

互斥实验:互斥组中的所有实验都不会共享用户,如果一个用户/设备命中了实验A,就不会命中该互斥组中的其他实验。

举例,你要同时按钮颜色和按钮形状的实验,就需要将两个实验加入到一个互斥组列表。

2.5 流量正交&正交实验

可见文章[11],本篇火山引擎的文档,描述的蛮清晰。

互斥组=互斥层=实验层

每个独立实验为一层,一份流量穿越每层实验时,都会随机打散再重组,保证每层流量数量相同。

举个例子。假设我现在有2个实验。

  • 实验A(实验组标记为A1,对照组标记为A2)分布于实验层1,取用该层100%的流量;
  • 实验B(实验组标记为B1,对照组标记为B2)分布于实验层2,也取用该层100%的流量。 (要注意,实验层1和实验层2实际上是同一批用户,实验层2只是复用了实验层1的流量)

如果把A1组的流量分成2半,一份放进B1组,一份放进B2组; 再把A2组的流量也分成2半,一份放进B1组,一份放进B2组。

那么两个实验对于流量的调用就会如下图所示。

此时实验A和实验B之间,就形成了流量“正交”。

流量正交有什么意义呢?

我们可以发现,因为A1组的一半流量在B1中,另一半流量在B2中,因此即使A1的策略会对实验B产生影响,那么这种影响也均匀的分布在了实验B的两个组之中;

在这种情况下,如果B1组的指标上涨了,那么就可以排除B1是受A1影响才形成上涨。这就是流量正交存在的意义。

对与分层实验有个很重要的点就是每一层用完的流量进入下一层时,一定均匀的重新分配。

整个流量有一个分散,合并,再分散的过程,保证第二层中的每个实验分配的流量雨露均沾,这就是所谓的流量正交。

文章[8]中的另外一个例子,来表达流量正交:

2.6 分层原则

同一层存在多个互斥实验,层与层之间,流量是正交的

也就是说流量在穿越每一层实验时候,都会被再次随机打散,经过上层实验一的流量可能会经过下层的任何一个实 验,可能是实验一,也可能是实验二。如图:

2.7 灰度发布

是指在黑与白之间,能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式,让一部分用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。

灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。(百度百科)

灰度实现思路:

当某个实验效果非常好时,可以动态调整该实验的流量占比,从而迅速得到收益,并且在大流量上验证该实验的有效性。一旦确认该实验效果非常良好,便可以在全流量上线。

灰度发布的应用场景:

比如开发完成一个新功能,但线上用户量很大,不确定全量发布后功能效果或者反馈如何,担心会存在潜在的问题。

此时,您可以使用灰度发布,逐步发布1%、5%、30%、50%、100%流量,在增量发布的过程中根据用户反馈来进行实时调整流量大小,或者回滚。

比如已通过A/B实验决策出优胜版本,可以直接将优胜版本全量固化至Feature,即通过Feature的方式立即实现全量发布。

比如您想在十一假期期间针对线上用户做一个活动,需要提前完成准备工作,那么您可以设置定时发布,如每天发布10%流量,共发布7天。

2.8 留存率

实验报告中的留存率指的是“按进组时间拆分的留存率”,是根据【用户首次进实验组的时间】作为起始,用户回到App作为回访,计算用户n日留存。 统计方式如下:

举个例子说明:

第一天实验组A的用户数为:10000,第一天base_user为10000。

第二天实验组A的用户数为:10400,其中9200用户是第一天便已经在A中的用户,1200用户为当天新进组用户;第二天base_user为1200,第一天的次日留存为9200/10000=92%。

第三天实验组A的用户数为:10200,其中8000用户为第一天便已经在A中的用户,1100用户为第二天进入A中的用户,1100为第三天进入A的用户;第三天的base_user为1100, 第一天的2日留存为8000/10000=80%, 第二天的次日留存为1100/1200=91.67%。

然后分别把每个进入实验日期的指标用base_user进行加权平均,得到次日留存率、第2天留存率等。

当日"已进组用户" 表示当日曝光进组的总用户数,包括之前已进组的老用户和初次到访的"新进组用户"。

2.9 统计 假设检验

文章[11] 涉及统计假设检验的一些解释:

第一类错误&显著性水平(α) 第一类错误,指原假设正确(真),但是我们假设检验的结论却显示原假设错误。这一过程中我们拒绝了正确的原假设,所以第一类错误是“弃真”。 第一类错误在实际操作中表现为:实验结论显示我的新策略有用,但实际上我的新策略没有用。 在统计学中,我们用显著性水平(α)来描述实验者犯第一类错误的概率。 当某个实验组的指标是显著的,说明这个实验结果大概率是可信的。 这个概率是95%,也就是说,系统有95%的信心确认这个实验结果是准确的。

显著性水平存在的意义是什么?

一个按钮从蓝色改成红色,一个窗口从左边移到右边,到底用户体验会变好还是变差呢?

我们并不确定,因此我们试图使用A/B实验的办法,帮助我们转化这种“不确定”——观察小流量实验中新旧策略的表现,从而确定新旧策略的优劣。

但是,这样就能完全消除不确定性了吗?答案是不能,因为存在抽样误差。

举个例子,假设瑞士人均收入为中国的十倍,那么随机抽三个瑞士人和三个中国人,能保证样本里这三个瑞士人的平均收入是三个中国人的十倍吗?万一这三个中国人是马云,王健林和一个小学生呢?

反过来想,假设在1%的流量下,组A(按钮呈红色)比组B(按钮呈现蓝色)购买率高,将流量扩大至100%,能保证策略A的表现仍旧比策略B出色吗?显然,我们还是不确定。

抽样误差带来的不确定性,使得我们在做小流量实验时,永远没法保证结论是完全正确的。

幸运的是,对于抽样的不确定性,在统计学中,我们有一套方法来量化这种不确定性到底有多大,这便是显著性水平(α)存在的意义。

置信水平/置信度/置信系数

置信水平(也称置信度、置信系数、统计显著性),指实验组与对照组之间存在真正性能差异的概率,实验组和对照组之间衡量目标(即配置的指标)的差异不是因为随机而引起的概率。

置信水平使我们能够理解结果什么时候是正确的,对于大多数企业而言,一般来说,置信水平高于95%都可以理解为实验结果是正确的。因此,默认情况下,「A/B 测试」产品将置信水平参数值设置为95%。

在A/B实验中,由于我们只能抽取流量做小样本实验。样本流量的分布与总体流量不会完全一致,这就导致没有一个实验结果可以100%准确——即使数据涨了,也可能仅仅由抽样误差造成,跟我们采取的策略无关。在统计学中,置信度的存在就是为了描述实验结果的可信度。

第二类错误( β )&统计功效(statistics power):

在统计学中,统计功效 = 1 - 第二类错误的概率,统计功效在现实中表现为:我的新策略是有效的,我有多大概率在实验中检测出来。

中心极限定理

显著性水平的理论依据便是中心极限定理。我们可以量化抽样误差的根基在于中心极限定理的存在。

什么是中心极限定理?

由于存在抽样误差,我们每次实验所得到的指标结果,都可能与我们期望得到的真正结果有误差。假设我们从总体中抽取样本,计算其指标的均值,每一次计算,样本均值都会受抽样误差影响。

假如我们做无数多次实验,那么理论上,这无数多个样本均值中,总应该有一个是“真的”,不受抽样误差影响的,这个值在统计学里被称为“真值”。

中心极限定理定告诉我们,如果我们从总体流量里不断抽取样本,做无数次小流量实验,这无数次抽样所观测到的均值,近似呈现正态分布(就是下图这样的分布)。

这个分布以真值为中心,均值越接近真值,出现的概率就越大;反之均值越偏离真值,出现的概率就越小。

2.10 p-value

即概率,反映某一事件发生的可能性大小,主要在 abest 中说明实验的提升的显著性,并且往往与假设检验相挂钩。

统计学根据显著性检验方法所得到的 P 值,一般以 P < 0.05 为有统计学差异, P<0.01 为有显著统计学差异,P<0.001 为有极其显著的统计学差异。

其含义是样本间的差异由抽样误差所致的概率小于 0.05 、0.01 、0.001 。

实际上,P 值不能赋予数据任何重要性,只能说明某事件发生的几率。在实践中建议,运行 A / A 测试,并同时也关注相关指标及 p-value 。

A / A 测试中度量的 P-value 分布应该是统一的,进行 1,000 次 A / A 测试,并检查分布是否均匀,当我们得到异常信息时,则需要纠正一些事情。

2.11 校验灵敏度MDE

  • MDE是什么:Minimum Detectable Effect (MDE),最小可检测单位,即检验灵敏度,是实验在当前条件下能有效检测的指标diff幅度。当前条件,指当前样本量,指标值和指标分布情况,并假设样本方差与总体指标方差足够接近。有效检测,指检出概率大于等于80%(type II error小于等于20%)。
  • MDE可以用来做什么:通过比较指标MDE与指标的目标提升率,来判断不显著的指标结论是否solid,可以避免实验在灵敏度不足的情况下被过早作出非显著结论而结束,错失有潜力的feature。
  • 如何设置:MDE越小,意味着您要求测试的灵敏度越高,所需的样本量也越大。如果MDE设置过于精细,不仅会浪费不必要的流量,同时实际收益可能不能弥补新策略的研发和推广成本。灵敏度不足(比如预期1%就达标,但实验灵敏度仅能检测5%及以上),可能会导致错失有潜力的feature。

3 AB test完整流程

3.1 完美的 ABTest的流程是什么?

参考文章[4]

  • 1、确定对照组和实验组,最好是做单变量的实验,一次只改变一个变量。
  • 2、分流时尽量排除混杂因素,一般情况下采用随机分流即可。
  • 3、检查流量是否达到最小样本量要求,达不到要求则没法进行后续的分析,实验结果不可信。
  • 4、确定本次实验的对比指标,就是如果方案之间存在差别需要通过什么来衡量?
  • 5、准确收集用户行为数据,这就要求埋点必须正确。
  • 6、分析指标的显著性,如果指标不显著则表示实验无效。
  • 7、确定引起显著性的根本原因,排除混杂因素导致实验结果的显著性。
  • 8、最终给出实验结论:有效 or 无效。

参考文章[9] 利用灰度发布形成一套结合AB测试的开发上线流程:需求评审-建立试验方案-新功能开发-灰度发布-小流量AB测试-发布成功的功能,关闭失败的。

参考文章[10] 工作中进行完整的AB测试流程包括以下几个步骤:

  • 分析现状:针对当前产品情况,根据业务数据,提出优化方案(一般由数据分析师和产品经理确定)。
  • 确定评估指标:确定衡量优化效果的指标(如:CTR,停留时长等)。
  • 设计与开发:确定优化版本的设计原型,并完成技术实现(通常与数据分析师无关)。
  • 分配流量:确定实验分层分流方案,以及实验需要切分多少流量,一般根据最小样本量确定。
  • 确定实验有效天数:实验的有效天数即为实验进行多少天能达到流量的最小样本量。
  • 采集并分析数据:提取实验数据,对实验结果进行分析。

根据试验结果,确定是否推广到全量或者是调整之后继续实验。

3.2 样本量选择

理论上,样本量越多越好:

从直观上看,当样本数量很少的时候,实验容易被新的样本点带偏,造成了实验结果不稳定,难以得出确信的结论。 相反的,样本数量变多,实验则有了更多的“证据”,实验的“可靠性”也就越强。 在现实操作中,样本量应该越少越好,这是因为:

  • 流量有限:大公司因为用户数量足够多,不用过于精打细算,同时跑几十个甚至上百个实验也没问题。但小公司一共就那么点流量,还要开发这么多新产品。在保证不同实验的样本不重叠的情况下,产品开发的速度会大大降低。
  • 试错成本大:假设我们拿50%用的户来跑实验,但不幸的是,一周后结果表明实验组的总收入下降了20%。算下来,你的实验在一周内给整个公司带来了10%的损失。这个试错成本未免高了一些。

文章[14]提到一个问题:满足样本量就可以停止实验了吗 答案是否定的,原因有三: 新奇效应,在统计学上指的是对于概率事件的结果,随着试验次数的增加,结果往往趋近于均值。在AB测试中,试验早期用户因为新奇会关注新改动,但是往往前期显著的提升在之后几天或者几周的测试中会逐渐消失。

周内效应,一个实验至少需要一周,避免指标的周期性效应,比如工作日与周末之间的差异较大而导致误判。

以偏概全,实验周期不够,不能满足指标测算或随机分组的目的。与时间限制有关的实验应该考虑长期转化情况。如「限时优惠」一类的与时间相关的设定。如果实验时间跑的太短,没有让高频用户和低频用户都包含在实验里,那么实验结果就只考虑了高频用户的行为。

3.3 如何确定实验需要多少天?

在文章[10]中,实验的有效天数的确定需要考虑两个因素:

(1)试验进行多少天能达到流量的最小样本量

(2)同时还要考虑到用户的行为周期和适应期

用户的行为周期

部分行业用行为存在周期性,例如电商用户购买行为,周末与工作日有显著差异。故实验有效天数应覆盖一个完整的用户行为周期。

用户适应期

如果进行的样式改版一类的实验,新版本上线用户会因为新奇效应而存在一定得适应期。故应考虑适应期在实验有效天数内,然后再分析实验结果。适应期的长短通常以足量用户流量参与试验后的2到3天为宜。

在文章[13]也有一些描述:

试验的周期一般是7天,覆盖周末和周中的用户行为。 对于复杂一些的测试,可以跑2周甚至1个月。

还有一个办法,就是看试验结果的置信区间的收敛速度,如果置信区间达到3%-5%已经可以决策了,就可以停止试验了。

正常情况下,我们需要大流量试验来验证大型新功能,比如新推荐算法,新学习模型,新聊天功能。

然后我们可以同时用流量分层的方法做很多很多小试验,比如改UI改文案,看看有什么改变能带来用户转化的提升。

同时跑10个以上的试验很正常,这种并行决策实际上大幅度提高了产品优化效率,而不会延缓迭代。

文章[14][17]都提到,Uber 和 Netflix 采用的成组序贯检验方法(GST)实现实验早停。

GST表现最好且最具实用价值。它通常被广泛的应用到临床实验中,样本随着时间逐渐积累增多,这非常适用于我们的案例。

它的思路大致是这样的:

在测试开始之前,我们先确定所需的最短运行时间和中期分析的次数。

然后,GST将所有可容许的I类错误总数(例如0.05)分配到所有中期分析中,以使I类错误加和起来为I类错误总数。这样,每个中期测试都比定期的peeking更为保守。

一旦统计学上足够显著,我们就可以立即停止实验。当观察到效果明显大于预期时,通常就是这种情况。

假设我们要监控特定实验的关键业务指标:

图6.序贯检验方法表明,在图B中确定了我们的处理组与对照组之间的显著差异。

相反,在图A中未发现显着差异。

随着时间增加,我们会累积更多的样本,并且置信区间会变窄。在图B中,从给定日期(在本例中为11月21日)开始,置信区间始终从零开始偏离。可以检测到指标下降在特定日期后在统计上和实际上都具有重要意义。相比之下,图A的置信区间会缩小,但始终包含0。

因此,对于图A我们没有检测到任何差异。

红线图A和B表示我们的处理组和对照组之间观察到的累积相对差异。红线带是

累积相对差异的置信区间。

4 A/B TEST 合理的分组

4.1 CR - 完全随机分组

CR(Complete Randomization)完全随机分组:

业界在进行实验对象分组的时候,最常用的是随机分组方式。这也是滴滴诸多实验中占比最大的分组方式。随机分组的做法可以实现为对实验对象的某个ID字段进行哈希后对100取模,根据结果值进入不同的桶,多个不同的组分别占有一定比例的桶。

实验对象在哈希取模之后,会得到0 ~ 99的一个数,即为该实验对象落入的桶。这个桶所属的组就是该实验对象的组。

弊端:

进行一次CR,能将一批实验对象分成对应比例的组。但是由于完全随机的不确定性,分完组后,各个组的实验对象在某些指标特性上可能天然就分布不均。

均值,标准差等差异较大。如果分组不均,则将会影响到第四步的实验效果分析的进行,可能遮盖或者夸大实验的效果。

4.3.2 RR(Rerandomization)

RR是在每次跑CR之后,验证CR的分组结果组间的差异是否小于实验设定的阈值。当各组的观察指标小于阈值或者重新分组次数大于最大允许分组次数后,停止分组。

相比于CR,RR通过牺牲计算时间,能在一定概率上得到符合要求的分组。重分组次数与输入的实验对象样本大小相关。样本量越大,需要进行重分的次数一般较少。

但是RR分组能得到符合要求的分组有一定的概率,且需要花更多的时间。所以,我们希望通过对分组算法的改进,在一次分组过程中分出观察指标均匀的分组结果,如下图所示。

4.3 自适应分组

文章[5]中,Apollo实验平台实现了滴滴AI LAB团队设计的Adaptive(自适应)分组算法。

Adaptive分组方法可以在只分组一次的情况下,让选定的观测指标在分组后每组分布基本一致,可以极大的缩小相对误差

5 一些厂子工程化实践

5.1 58招聘推荐系统 AB Test

参考文章[1],58招聘介绍了他们的AB实验框架,目前,推荐策略配置及AB实验框架支撑着我们每天80多个推荐位,线上20多个AB实验的日常迭代。

推荐的整体步骤清晰,层次分明,为了快速高效验证离线分析成果,策略算法同学经常会在不同层级并行迭代实验。

因此要求实验不互相干扰,每层的实验流量正交,评估效果准确有效,框架需要支持分层实验的功能。

纵向来看,流量域分为独立实验区和分层实验区。独立实验区不支持分层实验,针对单一变量进行实验。而分层实验区根据推荐流程分为多层:召回层、补足层,过滤层、排序层、资源控制层。每一层均可配置多组实验,层与层之间互不干扰。

其中召回层我们会整合多个数据源的职位数据,通过实验标识回传我们以简单轻量的方式支持下游服务的AB实验需求。

通过我们的可视化平台配置AB实验参数(推荐位,实验号等)即可实时监控各个常用核心数据指标的实验效果。

下图中可以清晰得看到一个实验从开始到AA验证的整体数据变化情况。

5.2 美团 A/B平台

在实验配置模块,用户可以基于实验前提出的假设、定义的成功指标快速创建实验,并基于特定的分流策略完成分流配置;

分流以及埋点上报模块,提供JAR包接入的形式,异步获取实验配置进行本地分流计算和埋点上报;

在线分析模块,依据用户在实验配置管理模块选取的用于说明实验效果的指标、分流埋点上报模块记录的日志,自动地产生各实验的实验报告,供实验观察者使用,然后根据实验效果帮助他们作出正确的决策。

具体流程如下图所示:

传统A/B实验的分流方式,无法保证分出的两个群组实验组和对照组的流量都是无差别的,无法避免因流量分配不平衡而导致的A/B群组差异过大问题,很容易造成对实验结果的误判。

为满足不同业务场景的诉求,我们的A/B平台建设采取了多种分流策略,如下图所示:

针对策略之间的相互影响、请求不独立场景下的A/B实验,我们采取限流准入的分流方式,针对不同的实验,选取不同的分流因子。

在实验前,我们通过AA分组,找出无差别的实验组和对照组,作为我们实验分流配置的依据,这种分流方式要求我们要有一套完整刻画流量因子的指标体系,只要刻画流量因子的指标间无统计显著性,我们就认为分出的实验组和对照组无差别。

5.3 AB实验平台在贝壳找房的设计与实践

AB实验平台架构与实现:

ab平台架构主要包括web层、api层、数据层、存储层,核心分流服务构成。

将流量的实验分组信息与用户行为日志做关联,分析实验的指标数据。实验效果分析包括实时数据分析和离线数据分析:

5.4 火山引擎 a/b 测试平台

字节的火山引擎已经开放了比较完整的a/b 测试平台,可参考: https://www.volcengine.cn/docs/6287/66993

可以体验15天的demo实验:

整理分为实验管理、指标管理、feature管理、系统管理。

实验管理模块

指标管理模块

核心指标,用来决策实验功能是否符合预期的「直接效果指标」 也叫「成功指标」。只可以设置一个指标为某个实验的核心指标,可在实验报告里面查看实验数据。

一般常见的核心指标,如下:

①转化率、uv/au类,如留存率;

②人均次数类,如pv/au、pv/uv、sum/au、sum/uv;

③平均值类,如sum/pv;

feature管理模块

Feature列表为您呈现所有Feature的列表页,展现Feature各个版本的公共信息。如下图:

系统管理模块

5.5 伴鱼技术:从 0 到 1 搭建技术中台之 A / B Testing 平台实践

平台整体架构示意图:

1、平台接入方(即实验代码实现的位置),我们提供服务端和客户端两种接入渠道。

2、平台内部实现,分为「分流」和「管理」两个部分。分流模块主要是供在线业务调用,通过分流模型,得出分流结果。管理模块则是实验元数据、实验效果数据等信息的管理后台,提供可视化的操作界面。

3、周边数据配套设施,包括实验分流数据的上报、采集,指标数据的聚合计算。涉及指标库以及数据处理等系统。

一条实验流量从进入系统到最终分配方案需要经历三个阶段:流量过滤、同层实验分配、实验内部方案分配。这些阶段应当在平台内部分流模块中闭环实现。

参考文献:

1 58招聘推荐系统介绍——AB实验框架 2 美团配送A/B评估体系建设与实践 3 推荐系统衡量:ABtest 框架 4 如何做一次完美的 ABTest? 5 AB实验在滴滴数据驱动中的应用 6 干货 | 携程是如何做AB实验分流的 7 美团点评效果广告实验配置平台的设计与实现 8 AB-TEST 9 AB实验平台在贝壳找房的设计与实践 10 统计学(4)|AB测试—实验流程 11 火山引擎:A/B 名词解释 12 从 0 到 1 搭建技术中台之 A / B Testing 平台实践 13 灰度发布和AB test 14 数据分析36计(14):A/B测试中的10个陷阱,一不注意就白做 15 数据分析36计(15):这个序贯检验方法让 A/B 实验节约一半样本量 16 数据分析36计(23):长期转化率 A/B 实验的问题,用边际结构模型纠正后结论反转 17 数据分析36计(17):Uber的 A/B 实验平台搭建

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021/12/10 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 文章目录
  • 1 A/B Test 实验的业务意义
  • 2 相关概念理解
    • 2.0 AB实验
      • 2.1 AA分组 —— 更好筛选样本
        • 2.2 混杂因素
          • 2.3 根据实验种类分类
            • 2.4 互斥实验
              • 2.5 流量正交&正交实验
                • 2.6 分层原则
                  • 2.7 灰度发布
                    • 2.8 留存率
                      • 2.9 统计 假设检验
                        • 2.10 p-value
                          • 2.11 校验灵敏度MDE
                          • 3 AB test完整流程
                            • 3.1 完美的 ABTest的流程是什么?
                              • 3.2 样本量选择
                                • 3.3 如何确定实验需要多少天?
                                • 4 A/B TEST 合理的分组
                                  • 4.1 CR - 完全随机分组
                                    • CR(Complete Randomization)完全随机分组:
                                    • 4.3.2 RR(Rerandomization)
                                  • 4.3 自适应分组
                                  • 5 一些厂子工程化实践
                                    • 5.1 58招聘推荐系统 AB Test
                                      • 5.2 美团 A/B平台
                                        • 5.3 AB实验平台在贝壳找房的设计与实践
                                          • 5.4 火山引擎 a/b 测试平台
                                            • 5.5 伴鱼技术:从 0 到 1 搭建技术中台之 A / B Testing 平台实践
                                            • 参考文献:
                                            相关产品与服务
                                            微服务引擎 TSE
                                            微服务引擎(Tencent Cloud Service Engine)提供开箱即用的云上全场景微服务解决方案。支持开源增强的云原生注册配置中心(Zookeeper、Nacos 和 Apollo),北极星网格(腾讯自研并开源的 PolarisMesh)、云原生 API 网关(Kong)以及微服务应用托管的弹性微服务平台。微服务引擎完全兼容开源版本的使用方式,在功能、可用性和可运维性等多个方面进行增强。
                                            领券
                                            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档