当前位置: 首页 > 科技观察

用户留存建模实践

时间:2023-03-18 01:06:15 科技观察

作者|王福森1.问题思考在流量分析产品的用户分析模块中,留存、互访、新老客户构成等数据是有效衡量用户粘性和召回率的关键但是我们发现,在很多流量运营中业务场景,留存分析建模显然存在很多设计和计算问题,比如:各种历史数据库版本迭代的高运维和存储成本,暴力计算,频繁计算,数据冷启动等问题。总结起来,需要特别注意三个方面:1.场景理解:在很多业务场景中,模型开发者更喜欢以用户粒度构建一个完整的历史库,然后聚合用户的新旧标签或历史累计时间。但关键问题是,这些场景下根据历史行为计算出来的新老客户标签和历史累计指标,并不适合在这种业务场景下进行精细化运营。比如在用户增长领域的流失、召回等场景策略中,用户经过很长一段时间还没有回来,显然不具备再次运营的潜力(比如180天);那么,相对于基于历史数据库的新用户选择,改变基于动态滑动窗口的圈子选择策略更具可操作性和解释性;而且这种计算方式还可以有效避免历史库刷新和冷启动的问题。2、计算模型:在计算模型设计和模型构建方面,大部分同学普遍缺乏模型抽象和精细化设计。就累积去重指标或周期保留指标的计算和实现而言,大致有四种建模范式(如果想了解第五种,请继续阅读):历史库法:构建全量历史基于T+1全量日增量库,基于历史库重新聚合轻聚合后聚合:构建T+1轻聚合模型,多周期扫描重聚合历史周期计量拉链:构建一个固定时间窗口的用户标签表,计算时关联标签表再重新聚合聚合位图方式计算:通过滑动时间窗口构建用户标签表,将窗口周期信息存储在位图中3.模型易用性:以上模型的实现都有一定的研发成本,需要丰富的场景实践和经验积累。如果能沉淀出一套敏捷的标准化模型计算组件,让新人分分钟完成留存模型的智能研发,那么标准化建模范式就可以解决很多业务场景下建模研发的效率问题.此外,丰富的场景实践和持续的技术思考对于建模范式的演进非常重要。在某个节点之前,我们认为位图设计已经是最佳实践,但后来在业务实践中发现,在很多场景下,需要进行业务周期较长的新老用户标签计算或留存分析。此时由于基于二进制bigint存储的位图只能支持64位,在180天等长期保留计算时会溢出。因此,需要一种更通用、更高效的模型计算抽象。总之,能够高效支撑业务是最佳实践标准,驱使我们不断超越和颠覆建模范式。2.用户故事蚂蚁版商务顾问是支付宝商户面向客户的重要产品。2020年12月底,我们计划2月份全面上线哔哩哔哩,留给研发的时间非常紧迫。并且由于是面向客户的产品,在架构设计、数据质量、输出时效性等各方面都有更高的标准。此外,我们还必须基于新的数据资产结构,对蚂蚁商务顾问的产品数据体系进行全面重构和升级。其中,流量模块涉及到前面提到的留存/访问间/新旧等关键指标的各种计算。我们需要在短时间内快速消化和解决现有应用层链路中的许多问题。最终,我们通过用户保留的建模组件,以“重新设计、快速实现”的方式,在不到2天的时间内高效完成了小程序、生活账户、电子名片等整体数据链路的重构。它还在模型设计、模型存储和模型治理方面进行了许多核心变化。尤其是经过模型改造后,业务顾问的产品数据体系变得极为精简、收敛和高效。那么,我们是怎么做到的呢?下面详细介绍保留建模组件的设计思路。3、设计实现目标抽象:用户留存模型的建模抽象和组件构建(支持1/7/30/180天等周期PV-UV、留存、互访、新老客户等指标超过64位图一站式计算);解决问题:暴力扫描、计算效率低、历史刷新成本高、数据冷启动等问题较多,高效留存模型设计开发门槛高(位图计算方式等),缺乏标准化模型沉淀;解决方案:细化窗口滑动计算的建模范式,存留建模组件,显着提升研发效率(0.5人日),支持留存/互访/新老客户等一站式计算;1.模型抽象维度抽象:用户留存模型是典型的轻度聚合模型DWS,显然必须有一个聚合维度列。设计抽象:滑动窗口设计:首先需要记录时间窗口内的用户行为分布(UV或PV),并通过某种数据结构(如bitLong值存储或Array)保存;其次,设计滑动窗口更新逻辑;信息抽象:关键聚合信息,比如新客户的判断(在N+1的时间窗口内,第N天首次访问为新用户);last_date数值信息保留(一共多少天没有访问过,有效减少存储量);累计访问天数(支持访问天数分布人群分析);2.模型组件建模组件的设计是对模型的抽象结果进行参数化和模板化,具体实现细节不再赘述。组件名称使用场景效率提升结果核心变化用户留存模型业务人员等1/7/30/180天PV-UV、留存、互访、新老、交叉留存矩阵等指标一站式计算研发效率提升改造前:0.5man-days效率提升后:2Min新人也可以无门槛建模开发Dataworks任务节点参考:节点ID:发布后的ODPS任务节点数节点名:保留模型的表名(可自定义)节点类型:ODPSSQL节点任务配置:jar-classpathcloudfile/res?id=xxxclassname.tools.OdpsCltWrapper"--class"<保留模型的jar包>"--properties-file"cloudfile/res?id=xxx"--conf""--conf""spark.executor.extraJavaOptions=-Dfile.encoding=UTF-8-Dsun.jnu.encoding=UTF-8""--conf""spark.driver.extraJavaOptions=-Dfile.encoding=UTF-8-Dsun.jnu.encoding=UTF-8""--master"yarn-clustercloudfile/res?id=xxx"--rTable"<输入表Tablename>"--wTable"<输出表的表名:构建的保留模型>"--stat_date"${bizdate}"--window"180;3、下游采用基于留存的建模组件,基础模型结构和计算范式标准统一,非常方便在一个参数化逻辑中实现所有指标的一站式计算;而下游的相关数据模型也变得极其精简、收敛和高效。通过参数化视图,统一封装索引的综合计算逻辑,下游无需关注计算中的复杂逻辑,直接面向消费,简单易用,如:--reportreferenceinsertoverwritetablepartition(dt='${bizdate}')从保留矩阵分析_参数视图中选择spm,date_row,date_col,retn_vst_uv_1d(retentionmodeltable_name,'20211208')wherespm='XXX';--计算参考insertoverwritetablepartition(dt='${bizdate}')selectvst_uv_1d,vst_uv_7d,vst_uv_30d,fst_uv_1d,retn_vst_uv_matrix,...fromBasicretentionanalysis_parametricview(retentionmodeltable_name,'20211208')其中spm='XXX';4.简单总结一下核心变化:基于模型组件,可以高效构建用户留存模型(0.5人天减少到2分钟),支持更多的留存/访问间/新旧指标的标准化计算比64位图,避免了下游的多周期扫描和重复计算,尤其是和历史库表相比,可以减少4倍的存储空间(front:62bytesvsback:16bytes)。构建标准:构建基于滑动窗口的标准化留存模型,实现模型设计和数据计算的改进,有效解决历史数据库版本迭代、下游多周期扫描、频繁计算和历史的高运维和存储成本库冷启动等一系列问题。效率提升:研发效率显着提升(用户流量模型标准化构建分分钟实现),及时实现。提高效率:100亿保留模型计算可在30分钟左右完成。减少存储:相比历史库设计,有效减少4倍存储,信息更全。