朝阳网站开发联系电话,网站建设广州天河,电脑云桌面下载,深圳网站建设外贸转载自 什么是ABTest 在互联网公司的业务发展过程中#xff0c;用户增长是永恒的主题#xff0c;因为没有增长也就没有发展#xff0c;所以在业务发展的早期产品迭代速度往往是越快越好#xff0c;总之一句话#xff1a;“怎么快怎么来”#xff0c;至于系统建设得是否可…转载自 什么是ABTest 在互联网公司的业务发展过程中用户增长是永恒的主题因为没有增长也就没有发展所以在业务发展的早期产品迭代速度往往是越快越好总之一句话“怎么快怎么来”至于系统建设得是否可以满足未来几年的扩展什么的往往在用户增长面前都会显得很扯淡因为慢了可能就死掉了。 而当业务发展到一定阶段后野蛮生长的红利逐渐消退用户增长空间在可见策略下变得不那么明显的情况下如何合理地规划产品迭代策略就显得尤为重要了而具体如何判断产品策略是否有效往往就需要数据进行判断其结果决定了该产品或策略的生命力以及与之配套的各类资源的调配毕竟大部分公司是不会愿意将资源浪费在无效的产品和策略上的。那么通过什么样的工具或手段才能确保数据驱动策略的有效落地和实施呢 目前硅谷的很多公司都在通过ABTest及建设与之相适配的实验基础设施平台来实现这样的目标而国内有条件的互联网公司也在逐步进行尝试。小码农目前所在的公司也在进行这样的尝试作为比较前沿的一种思路与实践虽然目前在国内的普及程度还并不是很高但是作者相信随着国内互联网ToC流量红利的消退这种工具会被越来越多的公司重视起来。本文将从基础理论及系统设计的角度与大家进行一些初步的探讨。 ABTest的目标背景
在现实的产品设计场景中我们经常会遇到多个设计方案的选择。例如App或网页端某个页面的某个按钮的颜色是用蓝色还是红色是放在左边还是右边传统的解决方案通常是集体表决或由某位Leader拍板类似的选择还有很多从概率上很难保证传统的选择策略每次都是有效的而ABTest显然是一种更加科学的方法。
ABTest简单来说就是为同一个产品目标制定两个方案比如两个页面一个用红色的按钮、另一个用蓝色的按钮让一部分用户使用A方案另一部分用户使用B方案然后通过日志记录用户的使用情况并通过结构化的日志数据分析相关指标如点击率、转化率等从而得出那个方案更符合预期设计目标并最终将全部流量切换至符合目标的方案。
上述的场景举例是比较简单的逻辑而一旦业务进入深度精细化运营阶段往往方案的比对会更加复杂需要关注的指标也会越来越多并且很多时候还需要同时验证多组策略这里我们称之为实验。例如在之前提到的UI设计策略中如果需要同时验证按钮颜色蓝色红色及位置左右的效果那么此时可组合策略有蓝色-左边、蓝色-右边、红色-左边、红色-右边需要验证的指标有页面打开次数、下单成功率等等。此外可能还有各种不同的业务逻辑需要设计不同的实验进行验证如果通过硬编码去实施这种策略会让事情变得很艰难而难以推动因为实施一次策略验证成本太高。
那么有没有一种方法和中间件系统来让事情变得简单而科学呢答案是有的。 重叠实验基础设施
事实上关于ABTest及数据驱动运营理念是被普遍接受的而关键问题是在于如何实施与落地不能落地的理论再好也是口号。Google作为全球互联网巨头同时也是一家数据驱动的公司在其产品迭代的方方面面都十分注重实验几乎任何影响到用户体验的变化、包括可见的变化如界面的改动也包括更细节的变化如不同的机器学习算法的改进等都会设计不同的实验加以验证。
这方面Google公司走在了前列而其发表的论文《Overlapping Experiment Infrastructure:More, Better, Faster Experimentation》重叠实验更多更好更快更成为各大公司建设自身实验平台的基础参考。
在该论文中提出的实验基础设施的设计目标是更多、更好、更快。因为在互联网产品迭代过程中为了更快的进行迭代产品或运营通常会要求同一个时间做N个实验并且同一份流量在不同实验之间互不干扰每个实验都能得到100%的流量。而要实现这些目标不仅需要能运行更多实验的实验平台也需要工具和持续的培训来支持更好、更快的实验从而有效加快产品迭代的正确性与速度。关于以上三点论文中的具体阐述如下 更多我们需要系统具备一定的可伸缩性以便于能够同时运行更多的实验。与此同时也需要一定的灵活性不同的实验需要不同的配置和不同的流量来衡量实验在统计意义上的效果显著性。有些实验只需要改变流量的一个子集比如日本的流量并且需要适当的调整流量大小其他实验则可能会改变所有的流量并在度量上产生较大的变化因此可以在较少的流量上运行。 更好无效的实验不应该允许在线上流量上运行。有效但糟糕的实验如线上Bug或无意中产生的非常糟糕的结果应该能很快被发现并被禁止运行。标准化的实验指标应该对所有实验都是容易获取的以便实验的比较是公平的如两个实验在计算CTR点击通过率等指标时应该使用相同的过滤器来去除机器人产生的流量。 更快建立一个实验应该既简单又快速简单到不需要专业的工程师也不需要编写任何代码就就可以做到。评价指标应该很快就能被统计出来以便快速评估实验效果。简单的迭代应该可以快速完成。此外实验平台除了支持实验进行ABTest还应该支持以易于理解的方式进行流量灰度。
那么具体应该如何构建一套实现上述目标的实验基础设施呢在讨论具体的实施方案之前我们还需要理解实验平台中几个重要的基础概念 流量即用户的访问也是实验的样本来源。对流量的切分也是实验平台首先需要解决的关键问题之一。 参数又称作实验变量一个实验可能有多种策略或者模型需要在线上进行比较这些模型或者策略就称作实验参数。
为了实现同时做更多的实验以及实现流量复用需要将实验平台按照分层模型进行设计。关于分层模型有几个比较关键的概念 域domain是指流量的一个划分流量进入后首先划分域。 层layer: 是系统参数的一个子集。 实验experiment:是由零个或多个策略参数构成的被用于改变传入请求处理方式的过程。
在以上三个关键定义中可以嵌套域和层。域包含层。层包含实验也可以包含域。为了更好的理解它们之前的关系我们可以分别看下其不同的设置关系 (a)、三层的基本重叠设置
在图a中我们简单地将参数划分为3个层。在这种情况下每个请求将最多同时出现在三个实验中每个实验都只能使用对应层的参数。 (b)、具有非重叠和重叠域的设置
在图b中将流量划分为两个域一个域是可以具有单个层的非重叠域另一个域可以是具有三个层的重叠域。在这种情况下每个请求首先被分配到非重叠或重叠域。如果请求在非重叠域中那么请求最多在一个实验中并且可以更改整个参数空间中的任何参数。如果请求在重叠域中那么请求最多在三个实验中每个实验只能使用对应层的参数。
虽然b这种嵌套方式看起来略微有点复杂但它有几个优点。首先拥有一个不重叠的域可以允许我们进行一些需要改变大量通常不会同时使用的参数的实验。其次这种嵌套可以允许我们进行不同的参数划分例如我们可以设想三个域一个非重叠的一个与参数分区重叠的一个与参数分区不同的重叠域。最后嵌套可以让我们更有效地使用空间这取决于哪些分区最常用以及哪些跨层参数实验最常用。 (c)、具有非重叠、重叠和启动域的设置 (d)、具有多个域的复杂设置
在图c/d中展示了另外一个概念-启动层。启动层与前面讨论的实验层在几个关键方面有所不同 启动层总是包含在默认域中运行所有的流量。 启动层是参数的独立分区在域中一个参数可以同时位于最多一个启动层和最多一个“正常”层。 为了使启动层与普通实验层之间的参数重叠工作启动层中的实验有略微不同的语义。具体来说启动层中的实验为参数提供了一个替代的默认值。换句话说如果正常实验层中没有实验覆盖一个参数那么在启动层实验中使用指定的替代默认值启动层实验的行为就像正常实验一样。相反如果正常实验层中的实验确实覆盖了这个参数那么这个实验就会覆盖参数的默认值不管这个值是指定为系统默认值还是在启动层实验中指定的。
以这种方式定义启动层可以允许我们在不干扰现有实验的情况下逐步向所有用户推出更新并以标准化的方式进行跟踪。启动层的一般用法是为每个启动特性创建一个新的启动层并在功能完全展开时删除该层(并将新的参数值展开为默认值)。最后因为启动层的实验通常比较大所以它们可以用来测试特性之间的交互。
看到这里大家心中是不是还充满了很多疑问呢实际上以上理论有点类似于我们在编程中学习的设计模式是对经验和实践的总结和抽象而至于采用什么样的设计模式就取决于我们系统的复杂度和希望能够支持扩展的程度。在实际设计实验平台时我们可以根据当前阶段业务的实际需要来进行分层模型的选择下面我们就以图(b)具有非重叠和重叠域的设置为例进行一些系统设计方面的讨论。 实验平台原理设计
我们以图(b)设置为系统分层模型参考将流量划分为两个域一个域只有一个单一层非重叠域和一个有三个层的重叠域。如下 上述重叠域是一个三层实验第一层UI Layer有三个实验参数Red、Blue、Green。当在实验平台配置好参数及其流量关于配置在后面的内容进行讨论会按总计100桶(bucket)给三个参数分配各自的bucket区间比如Red、Blue、Green的流量配置分别为80%、10%、10%那么它们各自对应的bucket区间分别是0-7980-89、90-99。后面Srch LayerAds Layer实验参数的配置以此类推。
在完成实验参数配置及流量设置后各个实验参数有了对应的bucketId区间范围那么对于用户访问流量又该如何进行分割这里称之为分流才能让不同的流量进入对应的bucket从而执行相应的逻辑呢
当流量进入后实验分流服务可以根据不同的终端采用不同的用户标识id来hash分流如web端采用cookieIdapp端采用设备id小程序端采用openId作为唯一分流标识符。在具体进行流量划分时为了实现实验层流量划分的正交性会将流量标识信息和实验层Layer标识一起进行试验流量bucket划分实验层标识称为离散因子。如基于用户标识uid的流量划分
bucketIdhash(uid,layer)%100
分流量原则上需要保证均匀性和一致性。均匀性是指流量唯一标识符在进行上述取模计算后均匀地落在每个区间。例如将全站流量分成100份那么uid%100的值为099必须做到每个值分配的流量几乎相同。一致性是指某个流量唯一标识符取模的值是一定的如某个流量的唯一标识符uid经过算法模块取模后的值为1那么下次再经过算法取模的值还是1。上述划分流量中采用的一致性hash算法就是为了确保上述两个特性。
通过上述内容的分析我们了解了分流的逻辑算法那么在代码层面这种划分方式具体又是怎样进行流量控制及ABTest的呢
实际上从理论上看实验平台及ABTest我们会觉得其非常复杂和深奥但从实际的代码角度看根据理论设计的模式规则、定义的实验以及为实验设计的参数指标等最终的目的只是为了给业务代码提供优雅的逻辑判断方式并在不需要业务逻辑关心的情况下按照可统计、可分析方式进行日志的输出并最终通过这些数据分析预定的指标、参数从而得出实验或ABTest的结果ABTest实际上是一种相对简单的实验大家从概念上不要有困扰。
具体来说我们在实验平台定义一个试验Exp后例如“界面实验UI Layer”会分别为其设置三组对照的实验参数这里我们可以叫实验组GroupRed组、Blue组、Green组。而为三个实验组的流量分配分别设置为80%,10%,10%,而该试验对应的层Layer的定义将全站流量划分为100bucket所以根据这个配置Red组的bucket ID的范围为0-79Blue组的bucket ID的范围为80-89Green组的bucket ID的范围为90-99而这些取值都是根据配置设置在实验组的配置数据中的。
当客户端或服务器端在进行ABTest时需要引人实验平台提供的SDK代码包并根据SDK提供的API进行实验逻辑编写SDK会以无感知的方式拉取实验平台的配置并缓存到本地进程中。在线上运行时当流量进入后会根据流量唯一标示uid并根据所要进行的试验通过配置得到层Layer的定义信息再通过hash算法计算该流量对应的bucket ID最后SDK会提供一种优雅的判断方式来匹配对应的实验组从而实现流量路由。此时业务端就可以执行对应对照组的代码逻辑了如果对照组中还设置了相应的策略参数也可以根据策略参数进行进一步的策略逻辑判断。
而SDK会根据实验逻辑向日志系统自动上报实验日志数据实验平台根据上报的数据按照实验关联的指标进行分析并进行展示。流程如下 在上述流程中我们了解了利用实验平台开启一个实验的基本步骤及逻辑。在大部分情况下简单的ABTest或流量灰度利用单层非重叠实验就可以完成了而如果业务需要进行复杂的多层重叠实验为了实现流量复用我们在客户端或服务端编写实验逻辑时需要注意不要让多个实验互相干扰。 后记
要设计好实验平台需要进行很多细致的工作功能上看需要进行实验管理、流量管理而这往往需要设计一套简单易于操作的配置界面从而允许用户对实验进行配置管理并对实验参数进行便捷的流量分配。
上报的大量实验数据需要收集和存储需要一套相对完整的日志收集系统为了方便指标分析我们还需要将实验数据存储到Hadoop集群并提供快速的数据分析体系。除此之外还有诸如配置分发客户端ABTest重启等。希望大家能在实践中处理好这些细节问题从而实现更多、更快、更好地实验目标。
