专业做公司网站的机构,百度平台营销,桂园精品网站建设费用,北京做网站建设多少钱简介#xff1a;在流量分析型产品的用户分析模块中#xff0c;留存、互访、新老客构成等数据都是有效衡量用户粘性与促活召回的关键性指标#xff1b;但是#xff0c;我们发现在很多流量运营的业务场景中#xff0c;留存分析建模都显著存在着设计和计算上的诸多问题。本文…简介在流量分析型产品的用户分析模块中留存、互访、新老客构成等数据都是有效衡量用户粘性与促活召回的关键性指标但是我们发现在很多流量运营的业务场景中留存分析建模都显著存在着设计和计算上的诸多问题。本文将针对用户留存建模实践进行讨论。 作者 | 王富森 来源 | 阿里开发者公众号
一 问题思考
在流量分析型产品的用户分析模块中留存、互访、新老客构成等数据都是有效衡量用户粘性与促活召回的关键性指标但是我们发现在很多流量运营的业务场景中留存分析建模都显著存在着设计和计算上的诸多问题例如各种历史库版本迭代的高额运维与存储成本、暴力计算、频繁计算、数据冷启动等问题。总结下来有三个方面需要特别关注
1、场景理解在非常多的业务场景中模型研发人员偏向于通过构建用户粒度的全量历史库再去聚合用户的新老标签或历史累计次数但关键问题是在这些场景中基于历史行为计算的新老客标签和历史累计指标并不适用于该业务场景下的精细化运营。比如在用户增长领域的流失召回等场景策略中长周期外仍然未有回访的用户显然不具备再运营的潜质如180天等那么相比基于历史库圈选新用户改为基于动态滑动窗口的圈选策略更具有可运营的潜质和解释性并且这种计算模式还可以有效地规避历史库回刷与冷启动问题。
2、计算模式在计算模型的设计和模式构建上大多数同学普遍缺少模型抽象与精细化设计。就累计去重指标或周期留存指标的计算实现来讲大致有4种建模范式想知道第5种请继续看下去
历史库方式基于T1全量和当日增量构建全量历史库基于历史库再聚合轻度聚合后再聚合构建T1的轻度聚合模型多周期扫描再聚合历史周期计拉链以固定时间窗口方式构建用户标签表计算时关联标签表再聚合位图模式计算以滑动时间窗口方式构建用户标签表并以位图存储窗口周期信息
3、模型易用以上模型的实现都存在一定的研发成本需要有丰富的场景实践和经验积累。如果能够沉淀一套敏捷的标准化模型计算组件让新人可以在分钟级就完成留存模型的智能研发那么就能以标准化的建模范式解决很多业务场景下的建模研发的效率问题。
此外丰富的场景实践和持续的技术思考对于建模范式的演进都是非常重要的。在某个节点之前我们曾认为位图设计已经是最优实践了但是之后又在业务实践中发现很多场景中需要计算更长业务周期的用户新老标签或留存分析。这时候由于基于二进制bigint存储的位图只能支持到64位在180天等长周期留存计算时就会溢出因此就需要更加通用且高效的模型计算抽象。总之能够高效支撑业务是最好的实践标准驱动我们可以在建模范式上是不断超越和颠覆。
二 用户故事
蚂蚁版生意参谋是面向支付宝商家的重要对客产品当时在20年12月份底我们计划在2月份全量上线B站留给研发的时间非常吃紧。而由于是对客产品在架构设计、数据质量、产出时效等各个方面都有更高标准的要求。此外我们也必须基于新的数据资产架构对蚂蚁生意参谋的产品数据体系进行全盘的重构与升级。其中流量模块就涉及到了上文中提到的留存/互访/新老等关键指标的各类计算我们需要在短时间内快速消化和解决存量的应用层链路中存在的很多问题。而最终我们通过用户留存的建模组件以“重设计、快实现”的方式在不到2天的时间内就高效完成了小程序、生活号和电子名片等整体数据链路的重构与升级而且在模型设计、模型存储和模型治理等方面也取得了很多核心改变。特别是经过模型重构后生意参谋的产品数据体系变得异常精简、收敛和高效。那么我们是怎么做到的呢接下来我们就详细介绍留存建模组件的设计思路。
三 设计实现
目标抽象用户留存模型的建模抽象与组件构建支持超过64位图的1/7/30/180天等周期性PV-UV、留存、互访、新老客等指标的一站式计算
解决问题存在大量的暴力扫描、低效计算、高昂历史回刷成本、数据冷启动等问题而高效的留存模型的设计和研发门槛高位图计算方式等、缺少标准化的模型沉淀
解决方案提炼窗口滑动计算的建模范式、沉淀留存建模组件显著提升研发效率0.5人日支持留存/互访/新老客等一站式计算
1 模型抽象
维度抽象用户留存模型是典型的轻度聚合模型DWS显然要有聚合维度列。设计抽象滑动窗口设计首先需要记录时间窗口内的用户行为分布UV或PV并通过某种数据结构来保存如bit的Long值存储或者是Array其次要设计好窗口滑动的更新逻辑信息抽象关键聚合信息如新客的判断N1的时间窗口内第N天首次访问就是新用户last_date的数值化信息保留累计多少天未访问有效减少存储累计访问天数支持访问天数分布的人群分析2 模型组件
建模组件的设计就是将模型抽象的结果参数化与模板化实现具体实现细节不详述。 使用说明你只需要配置基础信息在作业中配置好【输入表】、【输出表】、【统计日期】和【时间窗口】4个参数就可以自动实现你的用户留存模型无需定义DDL、无需写留存模型的复杂代码。
Dataworks任务节点参考
节点ID发布后的ODPS任务节点号 节点名称留存模型的表名可自定义指定 节点类型ODPS SQL 节点任务配置
jar -classpath 云端文件/res?idxxx 类名.tools.OdpsCltWrapper
--class 留存模型的jar包
--properties-file 云端文件/res?idxxx
--conf spark配置文件
--conf spark.executor.extraJavaOptions-Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8
--conf spark.driver.extraJavaOptions-Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8
--master yarn-cluster
云端文件/res?idxxx --rTable 输入表的表名 --wTable 输出表的表名: 即构建的留存模型 --stat_date ${bizdate} --window 180;
3 下游使用
基于留存建模组件基础的模型结构和计算范式都是标准且统一的能够在一个参数化逻辑中一站式实现所有指标的计算非常便捷而下游相关的数据模型也变得异常精简、收敛和高效。 通过参数化视图统一封装指标的一体化计算逻辑下游不需要关注计算中的复杂逻辑直接面向消费简洁易用如
--报表引用
insert overwrite table 留存矩阵_接口表 partition (dt${bizdate})
select spm,date_row,date_col, retn_vst_uv_1d
from 留存矩阵分析_参数化视图(留存模型table_name,20211208)
where spm XXX
;
--计算引用
insert overwrite table 留存概览_接口表 partition (dt${bizdate})
select vst_uv_1d,vst_uv_7d,vst_uv_30d,fst_uv_1d,retn_vst_uv_matrix,...
from 基础留存分析_参数化视图(留存模型table_name,20211208)
where spm XXX
;
四 简要总结
核心改变基于模型组件可高效构建用户留存模型0.5人日降低至2分钟且支持超过64位图的留存/互访/新老指标的标准化计算、避免下游多周期扫描与重复计算尤其相比历史库表可减少4倍存储前62字节 vs 后后16字节。
建标准构建了基于滑动窗口实现的标准化留存模型实现模型设计和数据计算上的改进有效解决了历史库版本迭代的高额运维与存储成本、下游的多周期扫描、频繁计算和历史库冷启动等一系列问题。提效率研发效率显著提升分钟级实现用户流量模型的标准化构建让我们在及实现。提效率30min左右即可完成100亿的留存模型计算。降存储相比历史库设计可有效降低4倍存储、且信息更完备。
原文链接
本文为阿里云原创内容未经允许不得转载。
