app动效网站,wordpress 文章概要,北京seo案例,青岛网络推广的有哪些公司点击关注“有赞coder”获取更多技术干货哦#xff5e;作者#xff1a;子固部门#xff1a;数据中台一、背景有赞是一个商家服务公司#xff0c;致力于帮助每一位重视产品和服务的商家成功。随着移动互联网的流量增长红利渐渐褪去#xff0c;商家获得新的流量越来越困难… 点击关注“有赞coder”获取更多技术干货哦作者子固部门数据中台一、背景有赞是一个商家服务公司致力于帮助每一位重视产品和服务的商家成功。随着移动互联网的流量增长红利渐渐褪去商家获得新的流量越来越困难帮助商家实现更有效的流量转化与长期目标的增长是有赞SaaS服务的应有之义同时随着有赞SaaS功能的不断完善服务的商家不断增多而业务场景也越来越复杂考虑到有限的研发资源提升产品和技术的迭代效率成为当务之急。在硅谷增长黑客等数据驱动增长的方法论正在帮助如Facebook、Google等如此体量的公司实现持续的业务高速增长在国内通过数据手段来驱动业务增长也取得了共识数据成为赋能增长的核心手段。其中A/B测试作为数据驱动增长的核心工具可以有效地提升流量的转化效率和产研的迭代效率。 因此作为数据团队基于对数据驱动增长的思考我们首先构建了有赞ABTest系统。二、A/B测试概览2.1 简介A/B 测试是一种对比分析方法通过对流量进行细分和随机实验并监控和跟踪实验效果来判断实验所代表的策略的可行性和有效性。对比通过对流量的随机细分来进行有效的独立随机实验可以排除外在条件的影响因此更加科学。分析通过跟踪和分析实验的事实效果数据来判断实验的可行性和有效性因此更加精确。如下图所示示例 A/B 测试将目标人群随机划分为A、B两组分别展示不同的页面然后通过跟踪和对比A、B两组用户的转化率来比较A、B页面的效果显而易见的A组页面的转化效果好于B组页面。相比原有基于时间的如T30的效果对比A/B测试可以排除时间和人为因素等外在所有因素的影响并且保障同时进行的场景实验相互独立互不干扰可以准确而且高效地评估实验效果。2.2 应用场景A/B 测试解决的是策略优化的问题即从多个可选策略里找出最优策略。常见的应用场景包括灰度发布技术算法迭代功能优化界面模块、样式风格、交互方式等内容优化推广海报、落地页、内容模块、文案等运营优化运营策略、沟通话术等2.3 核心概念我们参考了Google的论文《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》考虑到流量的隔离、复用以及细分引入了以下几个核心概念应用应用是对流量和系统的划分比如商详页可以是一个应用推荐系统也可以是一个应用。应用实现对流量的隔离一个应用下可以包含多个场景。场景 场景是指需要对比不同策略的业务场景场景是进行A/B测试的业务单元一个场景下可以包含1个或1个以上的实验(测试中的场景通常至少包含2个实验)。流量在同一应用下的不同场景之间可以被复用。实验 实验代表场景下的策略由实验配置来描述即一份实验配置对应一个业务策略。同一场景下的实验相互之间是互斥的场景的分流结果返回且仅返回一个实验。实验的主要配置如下图所示(示例场景为ABTest平台的底部答疑提示)流量来源 流量来源用来指定实验流量细分的粒度和比例流量来源可以是具体的上一层某个实验也可以是不指定实验即来源于大盘流量。一个实验可以有一个或多个流量来源。2.4 增长测试迭代A/B 测试通常是一个持续的迭代过程包含5个步骤即产生实验想法、评估实验优先级、设计和开发实验、分析数据以及应用结果。《硅谷增长黑客实战笔记》将其视为一个数据驱动增长的标准流程因此我们也称之为增长测试迭代流程。产生实验想法。产生实验想法是进行实验的第一步要求尽可能多地提出有可能提升业务目标的实验想法。评估实验优先级。由于产品研发资源是有限的不同的实验想法对于提升业务目标的效果也各不相同我们需要评估实验想法的优先级优先选择产出大、置信度高且容易实现(即ICE标准)的想法来进行尝试。ABTest系统通常假设实验想法已确定实验想法的产生和评估我们会在增长分析平台里实现(将在后续文章中介绍)。设计和开发实验。主要包括1)确定实验变量和分流策略2)在ABTest平台上配置应用、场景、实验以及流量来源3)根据示例代码完成ABTest SDK接入4)测试、验证并上线应用和实验场景。分析数据。主要包括1)确定实验评价的核心度量指标2)配置通用数据度量模型或者接入自定义度量数据3)查看ABTest平台效果报表判断试验的有效性和显著性。应用结果。判断最优实验并通过实验100%切流上线或者实验下线来应用实验结果。三、ABTest系统设计3.1 交互流程ABTest系统主要包括三个部分分别为ABTest平台、ABTest SDK以及数据流。ABTest 系统交互流程如下图所示3.2 ABTest平台ABTest平台是用户(管理员)与ABTest系统的主要交互接口主要提供以下功能ABTest元数据管理。用户可以在ABTest平台上完成完备的元数据管理操作包括应用、场景与实验的创建、编辑和删除以及配置的发布等。ABTest接入的开发和测试支持。用户可以方便地查看完整可用的接入示例代码可以输入分流用户标识进行测试以及查询实时日志等。实时报表和离线效果报表。实时报表包含实时请求、曝光和点击等数据效果报表支持实验的请求/曝光/点击/转化等相关指标的对比同时支持点击率、转化率、千次曝光转化等指标的显著性判断。异常监控和告警。平台实时监控 SDK 上报的 ABTest 请求数、失败数和延迟时间等数据一旦发现异常即发出告警。3.3 ABTest SDK考虑到目前有赞的技术栈现状ABTest系统提供了Java和Node两种客户端SDK。ABTest SDK主要实现以下3种能力实验配置动态分发。SDK实现了针对场景标识用户分流标识的一致性哈希算法根据场景的实验流量配置进行实验配置的动态分发。上报ABTest请求日志、业务自定义日志以及监控日志。基于ABTest埋点规范生成前端埋点标识。SDK 生成包括abTraceId(请求唯一标识)和bcm(请求结果标识)等追踪标识用以透传到前端埋点来追踪用户行为。3.4 数据流数据流负责收集ABTest相关的日志并产出实时和离线报表数据如下图所示主要涉及以下数据组件NSQ收集SDK上报的ABTest后端请求日志和自定义上报日志Kafka收集前端埋点日志和NSQ后端日志Flink实时数据处理产出实时报表数据Hive/Spark离线数据处理产出实验效果数据和评价数据HBase存储实时报表和离线报表的数据并支持ABTest平台查询Druid存储ABTest实时监控数据和抽样日志并支持ABTest平台查询四、ABTest的可用性保障业务方接入ABTest会有两个核心关切包括ABTest接入成本与易用性、ABTest数据价值即业务方希望以尽量低的成本简单可靠地接入ABTest然后获取准确且充分的ABTest度量数据。可用性保障解决的是ABTest接入成本与易用性的问题。我们的工作主要包括提升平台易用性、优化SDK、开发和测试方案支持以及监控和告警等方面。提升平台易用性支持完备的ABTest元数据管理实现较好的用户体验实现应用级的角色和权限支持场景修改配置的发布和审批支持实验的商家id或者用户分流标识的白名单优化Java和Node SDK优化SDK性能。考虑到商详页Node端的场景等对CPU性能比较敏感我们使用了很多方法来优化计算性能包括基于推送来更新配置、使用多级缓存、简化计算链路和逻辑、后端日志批量上报等(对于极端性能敏感场景可以使用前端分流的方案)。实现客户端配置自动化和透明化。例如NSQ的配置和上报日志的开关等均通过ABTest平台推送来配置和更新用户(开发)在代码层面不用关心。SDK因此也不依赖于用户的配置而可以实现一些对用户透明的能力比如监控日志上报等。优化一致性哈希算法。实验流量配比基于权重值计算支持最细粒度为 1/16384 的流量划分基于MurmurHash和模数映射实现一致性哈希并尽量降低因流量切换带来的体验不一致的影响。开发和测试方案支持支持分别针对Java和Node端的示例代码包括引入代码库、初始化、获取实验配置以及前端埋点等。支持daily、QA、预发、生产等4种应用环境。支持输入分流用户标识获取实验配置以测试和还原A/B分流结果。支持实时日志明细查询查询条件包括日志类型、实验以及以及分流用户标识等。监控和报警ABTest SDK自动采集并上报性能数据。ABTest平台支持监控数据的计算和基于规则的异常检测并接入有赞告警平台实现异常告警。五、ABTest的度量数据产出对于业务方来说ABTest系统的核心价值在于实验的度量数据。度量数据的产出解决的是业务方对ABTest数据价值的核心关切即通过产出ABTest相关数据、提升数据的准确性并充分挖掘数据的意义来科学地评价实验的可行性和有效性。ABTest系统的数据产出主要包括ABTest数仓数据、实时报表和监控数据以及效果报表。5.1 数据仓库数据主要的ABTest相关数据都会维护到数据仓库包括ABTest元数据维度快照表如应用、场景、实验和流量配置等ABTest日志包括请求日志、自定义上报日志、曝光和点击日志等ABTest效果数据包括原始效果数据和效果归因数据等以上明细数据的ETL处理数据包含中间层(dwd)、汇总层(dwa)以及产出层等粒度5.2 实时报表和监控数据目前实验的实时报表主要包括实验的请求、曝光和点击等的5分钟粒度汇总数据基于Flink产出主要用于展示ABTest场景的实时分流情况。监控数据由ABTest SDK上报经Flink处理后接入Druid产出监控指标以供ABTest平台查询。监控指标主要为性能数据包括ABTest请求量、请求失败量、日志上报时延、待上报日志量、待执行和被拒绝的线程数等。ABTest平台在应用首页展示实时监控数据同时后台会定时查询发现异常则告警给应用负责人。5.3 效果报表实验效果是指用于评价ABTest实验表现是否好坏的数据指标即实验的评价标准。效果报表是ABTest平台数据报表的核心包含了ABTest具体实验的评价数据如下图所示我们的主要工作包括通用效果模型考虑有赞主要提供的是电商SaaS服务有赞商家经营的主要目标是提升销售额。因此我们实现了基于实验的请求→曝光点击→成交的转化归因模型用于产出ABTest实验的请求/曝光/点击/支付等相关指标(如请求量、点击量、支付金额)及其衍生指标(如点击率、转化率、千次曝光转化金额)的数据。这就是ABTest平台的通用效果模型用于为ABTest场景提供默认的实验度量。效果归因模型把曝光和点击视为“因”成交转化视为“果”优先级计算时直接效果优先于间接效果、浏览优于点击优于曝光、登录用户id优于前端埋点标识并采用末次归因。ABTest埋点规范通用效果模型依赖于前端埋点的曝光和点击日志的上报即实验场景只要执行了任意实验都需要上报ABTest的埋点日志。这里的曝光和点击是指ABTest实验的曝光和点击前端同学容易误解成前端组件的曝光和点击导致ABTest返回不展示前端组件时而错误地没有上报ABTest日志。事件参数abTraceId(必填)、bcm(选填)均可从返回实验配置里直接透传到前端。事件标识曝光(事件标识包含view)点击(推荐页面浏览事件即enterpage参数写入URL或者点击事件即事件标识包含click二选一)。对于ABTest接入的前端埋点成本我们考虑使用无痕埋点的方式完全规避掉大致方案是埋点SDK静默生成和上报pv_id并在后端实现透传。支持次数和人数指标由于曝光、点击、支付、点击率、转化率以及平均曝光转化金额等指标都涉及到次数和人数两种口径类型不同的业务场景可能关注的指标类型各不相同。效果报表专门对次数和人数指标做出区分并在前端支持查询。特别地针对人数指标考虑到跨天去重由于ABTest平台支持用户选定时间范围进行查询一开始我们采用HyperLogLog的基数去重计数。采用基数去重的好处是可以基于天级增量数据进行累加可以支持用户的灵活查询缺点是存在一定误差在某些场景比如算法优化下是不可接受的。因此我们做了支持精确去重计数的重构基于查询截止日期回溯枚举30天来做精确人数计算。区分直接和间接转化效果直接效果指商品效果效果归因时要求曝光点击和支付都发生在同一个商品上间接效果即店铺效果效果归因只要求是同一个店铺。通常来说店铺级的优化会关注店铺整体的影响即间接转化效果而直接提升商品转化的优化则关注直接效果。两类效果数据ABTest平台都有产出并且在实验场景的设置中支持自定义选择。接入自定义归因效果数据在ABTest的实际应用场景里不同场景可能对转化效果的口径和归因的口径等要求各不相同比如营销插件(如优惠券)的转化效果定义为插件的核销金额商品推荐的转化效果定义为点击进入推荐商品详情页后的成交金额。因此ABTest效果数据除了提供默认的通用效果模型还支持了自定义归因效果数据的接入允许业务方提供定制的归因数据口径而对于重要场景的归因数据定制我们也可以提供支持。还有一类重要的转化效果数据即实验引导的用户行为事件。ABTest平台计划打通埋点系统使用户可以指定任意用户行为事件作为转化目标从而产出用户行为转化效果。反作弊过滤考虑爬虫和刷单等行为及其近似行为对ABTest效果的影响单个用户的极端行为如大量的曝光与支付、大金额订单都可能会给实验的评价指标带来决定性的变化。因此实验评价数据有必要对异常用户的数据进行过滤。我们主要结合绝对值规则和分布3σ原则对前端日志数据和支付数据进行用户过滤ABTest平台默认展示过滤后数据同时也支持原始数据的查询。显著性判断ABTest本质上是抽样实验ABTest效果数据反映的是当前实验覆盖的用户的表现现状考虑到样本量和随机性实验组的效果指标比基准组好不一定能说明实验组就更好。显著性判断就是基于统计学的假设检验方法来科学地判断同一场景下的实验两两之间到底孰优孰劣。有赞ABTest场景的样本量较大我们采用Z检验法来做假设检验。根据检验统计量来计算z-score及其对应的显著性水平p-value通过对比p-value与指定显著性水平如95%来判断实验组是否显著好于基准组。六、ABTest系统的评价ABTest解决的是选择最优策略的问题当我们在诸多可选策略里并不清楚哪个策略是最优的时候ABTest可以帮助我们1)选择更优的策略2)避免选择更差的策略。因此ABTest的价值包含两个方面即更优策略的价值增量和更差策略的规避风险。考虑到有赞的业务场景我们将极限提升GMV指标作为ABTest系统的北极星指标。极限提升GMV的定义为在拥有两个及以上实验的场景中平均请求转化金额最好的实验对最差实验的提升量相对于场景全部请求量的提升GMV之和即其中i为拥有两个及以上实验的场景(i,j)为场景i中的实验jGmv为归因到实验的互斥GMVReq为实验请求量。极限提升GMV是一个理想的指标度量了ABTest系统的价值。更全面的ABTest系统的评价指标包括我们应该努力提升ABTest的覆盖面并且重点投入到GMV提升量更大、影响力更高的实验场景中去。七、展望和总结7.1 展望目前ABTest系统还远没达到完全成熟的状态接下来我们会持续投入继续努力提升ABTest系统的可用性和数据价值。重点工作包括实现ABTest前端无痕埋点以消除前端埋点的接入成本。增长分析接入ABTest平台实现ABTest数据的自助分析和数据洞察帮助业务方更好的理解数据并优化实验。更丰富的自定义转化目标包括与埋点系统打通以及支持自定义转化目标等。上线评测报告功能通过自动化产出实验评测报告来给场景实验做全面充分的评价。努力提升ABTest系统在公司的影响力让数据驱动增长成为小伙伴们的共识。7.2 总结A/B 测试是数据驱动增长的核心工具我们希望通过构建ABTest系统来帮助产研小伙伴更好地做产品技术迭代和帮助商家更好地实现增长从而也为我们接下来的数据驱动增长的探索奠定基础。本文主要介绍了A/B测试的概念、ABTest系统的设计以及我们做的一些工作与思考。由于篇幅所限很多细节没有完整表述欢迎有兴趣的同学联系我们一起探讨有表述错误的地方也欢迎指正。对于数据驱动增长中ABTest系统没有覆盖到的部分对于基于数据增长想法的产生我们会基于增长分析来解决尝试跨越数据分析与业务落地的鸿沟对于用户行为数据等的采集和挖掘我们基于埋点与采集平台来解决并构建有赞用户行为核心数据资产。ABTest系统、增长分析平台以及埋点与采集平台共同构成了数据增长团队的“增长三剑客”我们的实践成果会继续在后续文章中介绍。扩展阅读有赞埋点实践有赞埋点质量保障Flink 滑动窗口优化基于时间加权的用户购买类目意愿计算有赞推荐系统关键技术有赞数据中台建设实践数据资产赞之治理SparkSQL在有赞大数据的实践(二)HBase Bulkload 实践探讨Vol.320最后打个小广告有赞数据中台团队长期招人期待你的加入如果你是数据增长、数据仓库、数据产品、算法、基础组件以及平台系统等方面的人才如果你也是聪明、皮实、有要性的小伙伴如果你对电商、SaaS有更多想法欢迎投递简历ziguyouzan.com加入我们一起enjoy!
