东莞公司企业设计网站建设,公关公司的主要业务,网站推广的途径,怎么做网站缩略图1 AB 平台简介
AB 实验平台这几年在互联网公司得到了越来越广泛的应用#xff0c;采用 AB 实验来评估产品和技术迭代效果也成为主流的业务新功能效果评估方式#xff0c;数据驱动的文化在这几年得到了不少公司的广泛的认同#xff0c;通过数据和指标来说明产品效果也得到了…1 AB 平台简介
AB 实验平台这几年在互联网公司得到了越来越广泛的应用采用 AB 实验来评估产品和技术迭代效果也成为主流的业务新功能效果评估方式数据驱动的文化在这几年得到了不少公司的广泛的认同通过数据和指标来说明产品效果也得到了越来越多的公司的认可和应用。 AB 实验在其中就是一种很常见的产品效果数据评估工具在各大公司的产品迭代过程中也得到了越来越广泛的应用。
2 1.0 时代 从无到有
在 AB 实验刚开始的时候需要解决的问题很简单 通过某种用户流量分组方式将不同的用户划分到不同的流量组在不同的流量组通过控制变量的方式应用不同的产品策略随后观察两个组的产品效果差别。 这种非常朴素的实验思路就是最基本的 AB 实验的分流需要注意的是在过程中需要保证控制变量和稳定的流量比例。
2.1 一个基本 AB 实验实例 一个基本的 AB 实验需要有以下要素 1.实验目标和实验假设 a.实验目标决定到达到什么样的效果实验才算成功举个例子我希望付款率提升 5%这就是目标其中的实验指标是付款率做实验之前一定要有实验目标没有实验目标没办法确定实验是否成功实验目标包含指标和变化幅度两个要素。 b.实验假设是猜想通过控制哪些因素来达到实验目标比如我们假设付款按钮的颜色会影响用户的付款意愿进而影响付款率那这里的实验假设就是付款按钮颜色会影响用户付款意愿。 2.实验对象实验对象是可以用来应用策略的用户或者请求或者其他对象 a.实验对象并不是仅仅指用户用户的每一次请求也可以单独做实验甚至每一次用户请求的每一个曝光位置都可以看做一个实验流量这个对象取决于具体的业务。 3.对照组和实验组AB 实验的核心要求是控制变量做效果对照所以至少有一个或多个对照组策略和实验组策略 a.对照组一般是没有任何策略的组代表了现在的实验效果。 b.实验组一般是应用了新策略的组代表了新策略的实验效果。 c.统计功效在进行实验组和对照组的流量分配的时候要注意因为我们的 AB 实验是从整体用户中取一部分进行实验然后采用统计学方式进行效果评估所以无论是实验组还是对照组样本量要满足最基本的统计功效后续的实验才有意义而统计功效无法在实验之后计算需要我们在实验进行之前就做充足的调研。
2.2 算法的 AB1.0 主要功能
1.通过控制变量的方式进行 AB 分流实验并通过离线的模拟分流规则提供用户实验分组信息使得数据分析可以计算实验的指标报表。 2.打通基本的工程实验链路可以让算法通过实验配置自主的控制实验流量和实验策略。
2.3 1.0 AB 实验的策略生效流程
在早期的实验过程有以下链路 1.通过配置中心配置约定好的 AB 实验配置信息线上的服务通过配置中心的变更信息实时变更实验配置从下次分流开始应用新的分流策略同时记录实验日志。 2.报表计算方式将实验配置信息同步到 ODPS第二天用前一天的实验配置对昨天的用户进行重新分流计算获得昨天的用户实验分流信息之所以这样是因为实验变更是以天为单位离线计算可以比较方面的支撑后续的实验分析。 算法和普通业务的 AB 分流由于业务特性原因有较多的需求不同的地方针对两者区别我们也进行了一些特殊的算法实验优化设计。具体如下 早期的 AB 实验设计解决了基本的实验分流问题也提供了一套配套的实验指标和实验置信度计算方案支撑了早期的简单业务可以通过 AB 实验的方式比较科学的观测算法模型效果。
3 2.0 时代 从有到全支持复杂业务功能
3.1 新的业务需求
随着公司业务发展和各个系统迭代优化用户对于基础的 AB 实验系统开始衍生出了一些新的更细化更复杂的业务需求用户也希望 AB 系统可以帮助支撑更高效的实验迭代。 1.流量饥渴更丰富的流量需求在 1.0 版本的 AB 实验中已经解决了基本的实验分流和配置的问题但是由于一个场景中总用户流量有限可能会有多种业务实验同时进行实际实验运行时需要在同时运行的实验数量和每个实验的流量大小之间做一个取舍业务高速发展时期经常会有用户希望提高同时运行的实验数量同时保证每个实验有充足的流量于是我们扩展了原来的实验流量分流模型设计采用分层分域的正交的业务实验划分方式来支撑上述的流量需求。 2.更实时更准确的实验报表在早期的实验中通过第二天的配置重算的方式得到前一天的用户实验分组数据这种方法可以支撑非常巨大的用户和实验数量但是时效性上比较难以保证。随着业务快速迭代算法的实时实验效果监控的需求也逐渐增加离线的实验报表计算反馈需要等到至少 1 天后才能观测实验反馈周期太长。于是我们调整了实验分流和报表的计算链路采用实时实验日志埋点通过 flink 等实时计算平台实时计算实验效果这种做法可以实时捕捉实验流量的变化情况对于验证实验分流效果有较大的效率提升。 3.复杂实验形式联合实多集群实验 指定用户实验需求随着算法工程链路的规范化业务链路中的一些业务层之间开始进行联合调优实验催生出了多参数跨层联合实验的需求需要在分层实验的基础上支持联合参数的生效机制这在一般的分层实验设计中是很难支撑的。随着工程链路稳定性项目的进展大部分业务同时都具有多个不同集群此时又需要 AB 系统也可以针对不同集群提供同场景不同实验配置的功能支撑。还有随着精细化运营的展开越来越多的实验只针对更精准的特定用户群才能生效这给原来的实验分流和实验分析都带来了不小的需求和挑战。
3.2 更大更通用的分流模型
为了满足更丰富的流量分配需求我们设计了一套比较灵活通用的实验分流模型 这套模型经过多个公司的业务验证可以确保在未来较长的一段时间内充分支撑我们所有业务的个各种 AB 实验分流需求。同时根据我们自己的业务发展需求也支持了条件层自定义分流机制等为更复杂业务设计的一些分流机制。 多层正交的实验流量模型 上述的分流模型将一个场景流量分为层和域两种嵌套结构通过层来隔离不同业务配置通过域来隔离不同用户群。用户在该模型进行分流的过程采用从外到内从上到下的逐步命中每一次进入一个业务层都会触发一次选桶逻辑命中桶以后读取桶上的配置如果桶内还有层配置继续依次命中层触发内部的选桶逻辑。 该模型可以支持如下主要特点 1.分层分域互相嵌套的流量设计支持业务域分层的正交流量每一层都是一个单独的业务解决流量饥渴问题同时支持自由的流量域划分流量域和流量层可以互相嵌套实现极其灵活的流量划分方式。 2.每一个流量层采用 hash 模板流量槽层内实验通过圈槽的形式决定实验在该层的流量比例允许算法用户自定义实验分流的规则支持根据用户的用户特征信息进行分流同时支持灵活的跨层流量对齐机制。这种方式可以实现极为灵活的分流方式支持各种对象和分流方式比如用户分流请求分流设备分流作者分流按地区分流等。 3.支持白名单允许用户绕开分流机制指定用户的固定实验链路用于在线上进行特殊用户的实验验证。 4.支持条件层允许符合某种条件的用户单独进行特定实验比如只针对新用户进行的实验。 从该模型上线以来2 年多的时间内已经完美支撑了算法 300 多个场景的 AB 流量分配需求经过了充分的业务验证从分流层面解决了许多有特殊需求的分流业务遇到的问题。 具体层中的分流规则如下 每一个流量层根据层中的分流配置信息和用户信息计算命中的流量槽然后根据流量槽命中圈选了流量槽的实验实验通过拥有的流量槽数量决定实验流量比例。
3.3 标准实验的工程链路 通过 AB 实验的后台改造我们重新思考并调整了整个实验链路的工程设计在新的工程设计中相对于上一个版本主要有以下几个方面需要改进 1.采用实验分流日志而不是离线的实验配置来计算用户的实验分组信息。 a.实验日志可以捕获每一个时刻的用户的实验分流情况可以较为敏感的捕捉到实验变更的情况。 b.实验日志可观测性强用户配置完实验以后可以立刻通过日志观测实验的命中情况。 c.可以在日志中附加更多的实验环境相关信息做更丰富的实验分析可以简化离线的实验分组计算逻辑。 2.线上应用增加实验信息的具体埋点信息 埋点分为两部分: a.一部分透传给客户端其中包含用户命中的实验信息称之为 ACM 埋点客户端在用户进行点击曝光等操作时上报信息中回传服务端下发的 ACM 字段这样我们可以通过神策上报的行为日志清楚的知道每个实验曝光几次被点击几次,可以及时得到实验的线上表现这部分行为日志还可以帮助我们实时的计算实验策略效果报表。 b.另一部分作为应用的后台日志记录记录了每一次请求中用户命中的实验相关信息用于计算实验分组信息。 3.设计了 AB 实验的后台操作管理界面不用再通过手动修改配置中心的配置来进行实验配置。并将实验发布实验修改实验配置回滚等功能做成具体的按钮功能极大地提高了用户的实验操作使用体验。 4.拆分了实验参数和代码执行链路抽象出了 AB 参数和代码链路运行方案两种概念将 AB 变成一个弱依赖降低实验参数配置错误对线上业务的影响。 Ps: 为什么要同时采用两种实验信息反馈链路原因是第一种 ACM 上报的用户实验信息依赖于用户上报,如果用户遇到应用 crash 或者延迟上报或者网络情况突然不好我们没办法获得未上报的这部分信息第二种很明显没办法知道发放下来的带有实验信息的内容的后续反馈情况。两种链路都没办法完全的覆盖全部用户只有互相配合才能完整的覆盖全量用户至于为什么采用离线日志来做实验报表ACM 来做实时报表纯粹是工程效率方面的考虑。 ACM 通用埋点标准为了解决实验的实时效果观测问题 我们需要想办法将后台的实验命中标识信息传递给客户端。考虑到其他业务场景也会有类似的埋点需求为了埋点通用性考虑我们规划了一个算法的埋点标准主要想简化算法埋点流程和对算法的埋点信息进行统一的治理。 ACM 埋点主要是通过算法与客户端约定一个固定的埋点内容字段 ACM后端算法在开发时候通过提供的 SDK 工具将需要埋点的信息和内容通过 SDK 采用特定的规范形成一串可识别的字符串内容客户端同学对 ACM 这个约定好的字段进行事件曝光点击等上报后端就可以根据上报的用户行为日志通过实时计算工具快速的获得某个实验的后续用户反馈信息。 ACM 埋点规范例子 版本.业务域.内容资源类型.资源位.实验.自定义值版本标记本条 ACM 的遵循的规范版本不同版本具有不同的解析规则方便 udf 解析。 业务域业务系统代称尽量简短比如 搜索 srh。 内容资源类型内容类型或资源比如 user_10098, cspu_1020,spu_771 等。 资源位广告位榜单位。 实验资源本次采用的 AB 实验策略多个实验用-隔开。 自定义值 允许应用方进行扩展的字段比如 chan_latest-pos_3 代表 channel 为 latestpos 为 3。 特殊要求自定义字段中不能出现 .,-,_等字段其他部分无此要求。 埋点示例 acm: 1.srh.spu_1009.sh.kka3b.10089-1929-100.channel_hot-position_2acm: 2.srh.spu:1009.sh.kka3b.10089;1929;100.channel:hot;position:2埋点场景 request 维度覆盖所有搜索和推荐场景 埋点动作 request 维度 下面是一个带有 acm 信息的后端返回示例 { code: 200, data: { total: 3730, start: 0, hits: 10, searchId: 161113175619737242413163, searchTime: 0.024447, items:[ { spuId:xxx, acm: 1.ms.prd-10092.v1ss.exp-1.kka.12, } ], facet:[], cache: false }, requestId: f2ca7c08693acd54, cost: 0, time: 1611131759}3.4 实时的实验指标监控
实时实验指标的计算流程 1.后台服务日志实验分流信息需要透传给客户端 2.客户端用户行为及时上报 3.行为日志被 flink 等实时计算平台及时处理 4.制定明确且可计算的实时指标规范。 有了上面四个基础流程就可以计算实时的实验反馈指标但是要注意实时的指标计算往往只能反映一段时间的实验趋势变化在部分复杂指标上很难实现精确的实验指标计算所以一般用来观察实验指标变化趋势不作为最终决策依据。 实时数据处理链路
打通了数据链路并且在用户的行为日志中包含了 ACM 埋点以后算法就可以基于行为日志通过 flink 等工具实时算计算用户的各种指标信息。 具体的监控链路流程如下图绿色链路所示 具体实时实验监控效果
最终可以达到秒级的实验效果反馈极大的加快了算法对实验策略的反馈效率具体效果如下图用户可以自己选择关注的实验信息对比不同实验在同一时间区间内的指标变化情况。可以非常迅速的得到线上的新实验的效果反馈信息极大地缩短了算法对实验指标的策略调整反馈周期。 4 3.0 时代 从全到优提升用户体验和实验效率
2.0 时代主要是从各种机制和功能方面尽量满足业务需要业务功能满足以后我们进行了业务与扩展将算法的推荐业务场景也囊括进来推荐业务接入以后虽然在基本功能上也可以满足需求但是推荐和搜索的业务特点还是有点不同于是我们针对实验平台的实验操作用户体验和稳定性方面进行了较多的优化。
4.1 实验操作易用性的建设
业务场景铺开以后使用的业务团队和人员也变得更为复杂于是我们在针对特定场景的使用和业务人员使用习惯方面做了不少的功能改进和优化。根据我们收集的算法人员的参数配置白名单配置流量调整等功能使用痛点我们进行了针对性的优化。 实验参数的易用性工具
实验参数配置是 AB 实验的最主要的功能为了优化用户体验在实验参数使用方面的体验我们收集了一些常见的用户在使用参数配置时候经常遇到的问题并针对性做了功能和体验的优化。 场景 1随着业务发展算法配置的业务层越来越多由于约定的参数规范是同一层的可配置实验参数应该一致同一个实验参数配置也应该出现在同一层但是随着层数增多和部分参数使用不规范估算某个实验参数的实际生效流量就变得很困难参数有后覆盖前面的规则。有可能出现你给 a 实验配置了 10%流量的 recallSize 20 但是后续该参数被别人的同名参数覆盖导致实际参数生效流量不符合预期的情况。 参数流量着色分析
使用参数流量的着色分析可以清楚的知道某个实验参数都在哪些实验中有配置这些实验如果同属于一个业务层则无流量覆盖如果有些实验不属于同一个业务层有可能出现参数覆盖的情况。流量着色就是通过程序一键计算某个参数最终的流量结果分布情况可以方便的看到某个参数最终的线上真实流量比例。 包含某参数配置的所有实验查询 某参数的实际生效流量分布 场景 2实验参数越来越复杂同一个参数往往有多个不同的版本需要同时观测实验的效果这种时候可能由于时间久远或者实验变更频繁或者参数过多很多时候在进行实验观测和调整的时候需要确认实验中的参数配置信息特地为这些需要对比参数的场景制作了便捷的实验参数对比的功能。 实验参数对比可以比较清晰的对比同一个实验参数在同一层其他实验中分别是什么值可以大幅度提高实验流量调整期间需要进行的实验信息核对工作效率。 实验布局的操作和展示优化 为了满足灵活的实验流量划分我们设计了一套通用的实验流量模型但是该流量模型的可视化方面一直是一个不小的难题最基本的我们希望能直观的展示层与层层与桶用户域之间的布局结构和用户流量的命中顺序关系。 我们进行了一些更能直观体现实验布局的探索目前我们采用一个标准的树状结构来表示个实验分流模型。实验模型中的业务层和用户桶我们都会用图标进行区分由于层桶结构可以嵌套多次我们通过将结构关系进行拆分将桶页面主视图和层页面主视图进行了分别设计。 层页面主视图可以便捷的观察到当前层内的不同流量桶和子桶内的其他子业务层主要是用于寻找自己的业务层位于某一个用户桶内观察某些桶的流量比例和参数等。子业务层内的流量桶信息不予显示。 桶页面主视图桶页面的主视图可以同时观察到该桶内的各个子业务层和业务层内部的子实验桶信息可以用来直观的对照具体的实验命中链路从上往下核对实验命中路径。 界面显示如下测试数据 通过将层桶结构进行主要的功能拆分可以在复杂场景的视图布局清晰度和易用性上达到一个比较好的平衡。 实验信息的完善 算法的实验在进行实验分析报表的时候往往需要对比多个指标综合观察实验效果之前都是算法人员跟分析人工对齐某个实验什么时候开始什么时候结束需要观察哪些指标等信息。为了方便后续自动化的进行实验效果分析我们完善了实验的实验时长核心指标辅助指标等功能方便用户进行实验的分析信息管理后续通过自动化功能依赖这种信息可以实现实验报表指标流程的自动化计算。 4.2 服务稳定性的改进
1.动态白名单功能优化 白名单操作是一个使用频次较高的 AB 实验操作功能 实验参数配置好以后往往需要通过白名单来小范围的验证策略效果。但是早期的白名单设计时候考虑到白名单会影响用户的分流所以白名单信息和实验布局配置信息一起被用户感知这也导致每一次的白名单变更都需要重新发布实验配置给线上的配置稳定性造成了威胁。 解决方案 基于白名单的设计和生效流程我们尝试通过流程和配置格式改进优化使得白名单的配置可以实时生效同时又不影响原来的实验配置如下图所示 动态白名单功能改动相当于将白名单的配置信息独立出来在白名单有修改的时候独立加载同时不触发配置信息本身的更新。但是考虑到兼容性问题我们每次配置信息改动也会额外触发白名单的重新更新描述配置更新相当于一次全量更新配置和白名单都会更新。白名单更新相当于实时只更新新增的白名单信息。 2.并发操作 Ark 发布实验的优化 由于 AB 实验的配置下发方式是通过 Ark 配置中心提供的配置通知功能实现的目前后台操作 Ark 进行配置发布的时候是通过 http 接口进行了使用接口同时操作同一个 Ark 配置集的时候大量操作容易产生并发并发问题会导致 Ark 操作直接失败这种情况极大地阻碍了实验配置发布过程的流畅性。 解决的办法有如下方案 经过仔细评估和方案选择我们决定方案 2,3,4 同步进行最终完全解决了实验操作时候的并发问题。
4.3 实验效果分析的探索和优化
在过去 2 年的 AB 实验的实践和改进过程中我们也十分注重实验效果方面的分析和问题归因根据遇到的实际实验分析问题和情况总结了一部分常见的实验分析相关经验文档其中涉及实验流程标准化实验指标选取实验指标的统计功效分析实验指标的 p 值和置信度分析以及常见的实验中遇到的问题等。 常见的实验分析问题我们总结了一些实验效果分析中常见的问题和可能的原因可以帮助排查 AB 实验中遇到的常见问题。具体如下表 实验中的辛普森悖论辛普森悖论英语Simpsons paradox是概率和统计中的一种现象其中趋势出现在几组数据中但当这些组被合并后趋势消失或反转。这个结果在社会科学和医学科学统计中经常遇到当频率数据被不恰当地给出因果解释时尤其成问题。当干扰变量和因果关系在统计建模中得到适当处理时这个悖论就可以得到解决。辛普森悖论已被用来说明统计误用可能产生的误导性结果。落实到我们的 AB 实验中就是 如果一个实验 A 在一个较长的实验周期内每天指标都高于实验 B实验 A 的整体周期指标未必高于实验 B。 本图想说明一个问题如果一个实验周期跨很多天每天观测实验效果的情况下如果某个实验组用户数量或者某个指标长期每天稳定高于另一个实验组不能说明分流不均匀。 第一天 因为刚刚重新分流所以所有用户对实验来说都是新用户a 组 505 万b 组 495 万 1%的正常误差。 第二天 因为老用户要保持分流一致组内用户新用户次留老用户 新用户会重新分组老用户沿用之前的分组此时有两种情况 情况 1 合理 老用户按原来的分流 新用户分流误差 1%。 情况 2 不合理 老用户按原来的分流新用户必须要保证误差 2%才能逆转第二天的分组误差情况但是此种情况下第二天的新老用户比例会严重不均匀同时没办法保持分流策略的一致性理论上不可能实现。
5 未来改进的方向
未来我们会希望借助数仓部门的 AB 平台的指标计算和可视化通用能力希望可以逐步增强 AB 平台的数据可视化能力在实验分流情况的可视化分析实验的用户特征的分布可视化分析实验的指标变化原因排查等方面与分析同学一起合作提升 AB 实验的指标报表问题分析效率。 在 AB 实验平台本身的实验信息操作和性能稳定性方面我们也有一些新的想法希望将来可以打通开发环境测试环境生产环境实现一个界面可以跨环境操作降低算法同学使用不同环境 AB 需要在不同系统切换的问题同时在将来还希望借助 sidecard 的形式增强 AB 实验的分流能力和分流稳定性兼顾分流性能和分流平台功能迭代效率。 *文 / 开阳 本文属得物技术原创更多精彩文章请看得物技术官网 未经得物技术许可严禁转载否则依法追究法律责任
