用户留存建模实践

发布时间：2025-11-05 16:01:46 来源：云智核 作者：IT科技

作者 |  王富森

一、用户问题思考

在流量分析型产品的留存用户分析模块中，留存、建模互访、实践新老客构成等数据都是用户有效衡量用户粘性与促活召回的关键性指标;但是，我们发现在很多流量运营的留存业务场景中，留存分析建模都显著存在着设计和计算上的建模诸多问题，例如：各种历史库版本迭代的实践高额运维与存储成本、暴力计算、用户频繁计算、留存数据冷启动等问题。建模总结下来，实践有三个方面需要特别关注：

1.场景理解：在非常多的用户业务场景中，模型研发人员偏向于通过构建用户粒度的留存全量历史库，再去聚合用户的建模新老标签或历史累计次数，但关键问题是，在这些场景中基于历史行为计算的新老客标签和历史累计指标，并不适用于该业务场景下的精细化运营。比如，在用户增长领域的流失召回等场景策略中，免费信息发布网长周期外仍然未有回访的用户显然不具备再运营的潜质(如180天等);那么，相比基于历史库圈选新用户，改为基于动态滑动窗口的圈选策略，更具有可运营的潜质和解释性;并且，这种计算模式还可以有效地规避历史库回刷与冷启动问题。

2.计算模式：在计算模型的设计和模式构建上，大多数同学普遍缺少模型抽象与精细化设计。就累计去重指标或周期留存指标的计算实现来讲，大致有4种建模范式(想知道第5种请继续看下去)：

3.模型易用：以上模型的实现都存在一定的研发成本，需要有丰富的场景实践和经验积累。如果能够沉淀一套敏捷的标准化模型计算组件，让新人可以在分钟级就完成留存模型的智能研发，那么，就能以标准化的建模范式解决很多业务场景下的建模研发的效率问题。服务器托管

此外，丰富的场景实践和持续的技术思考对于建模范式的演进都是非常重要的。在某个节点之前，我们曾认为位图设计已经是最优实践了，但是之后又在业务实践中发现很多场景中需要计算更长业务周期的用户新老标签或留存分析。这时候，由于基于二进制bigint存储的位图只能支持到64位，在180天等长周期留存计算时就会溢出，因此，就需要更加通用且高效的模型计算抽象。总之，能够高效支撑业务是最好的实践标准，驱动我们可以在建模范式上是不断超越和颠覆。

二、用户故事

蚂蚁版生意参谋是面向支付宝商家的重要对客产品，当时在20年12月份底，我们计划在2月份全量上线B站，留给研发的IT技术网时间非常吃紧。而由于是对客产品，在架构设计、数据质量、产出时效等各个方面都有更高标准的要求。此外，我们也必须基于新的数据资产架构对蚂蚁生意参谋的产品数据体系进行全盘的重构与升级。其中，流量模块就涉及到了上文中提到的留存/互访/新老等关键指标的各类计算，我们需要在短时间内快速消化和解决存量的应用层链路中存在的很多问题。而最终我们通过用户留存的建模组件，以“重设计、快实现”的方式，在不到2天的时间内就高效完成了小程序、生活号和电子名片等整体数据链路的重构与升级，而且在模型设计、模型存储和模型治理等方面，也取得了很多核心改变。特别是，经过模型重构后，生意参谋的产品数据体系变得异常精简、收敛和高效。那么，我们是怎么做到的呢?接下来，我们就详细介绍留存建模组件的设计思路。

三 、设计实现

建模组件的设计就是将模型抽象的结果参数化与模板化实现，具体实现细节不详述。

组件名

使用场景

提效结果

核心改变

用户留存模型

生意参谋等1/7/30/180天PV-UV、留存、互访、新老、交叉留存矩阵等指标的一站式计算

研发提效提效前：0.5人日提效后：2 Min

新人也可以毫无门槛地建模研发

Dataworks任务节点参考：

节点任务配置：

jar -classpath 云端文件/res?id=xxx 类名.tools.OdpsCltWrapper

"--class" <留存模型的jar包>

"--properties-file" 云端文件/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-cluster

基于留存建模组件，基础的模型结构和计算范式都是标准且统一的，能够在一个参数化逻辑中一站式实现所有指标的计算，非常便捷;而下游相关的数据模型也变得异常精简、收敛和高效。

通过参数化视图统一封装指标的一体化计算逻辑，下游不需要关注计算中的复杂逻辑，直接面向消费，简洁易用，如：

--报表引用

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倍存储、且信息更完备。

相关文章