关于大数据:用户留存建模实践

简介：在流量剖析型产品的用户剖析模块中，留存、互访、新老客形成等数据都是无效掂量用户粘性与促活召回的关键性指标；然而，咱们发现在很多流量经营的业务场景中，留存剖析建模都显著存在着设计和计算上的诸多问题。本文将针对用户留存建模实际进行探讨。

作者 | 王富森
起源 | 阿里开发者公众号

一 问题思考

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

1、场景了解：在十分多的业务场景中，模型研发人员偏差于通过构建用户粒度的全量历史库，再去聚合用户的新老标签或历史累计次数，但关键问题是，在这些场景中基于历史行为计算的新老客标签和历史累计指标，并不适用于该业务场景下的精细化经营。比方，在用户增长畛域的散失召回等场景策略中，长周期外依然未有回访的用户显然不具备再经营的潜质（如 180 天等）；那么，相比基于历史库圈选新用户，改为基于动静滑动窗口的圈选策略，更具备可经营的潜质和解释性；并且，这种计算模式还能够无效地躲避历史库回刷与冷启动问题。

2、计算模式：在计算模型的设计和模式构建上，大多数同学广泛短少模型形象与精细化设计。就累计去重指标或周期留存指标的计算实现来讲，大抵有 4 种建典范式（想晓得第 5 种请持续看上来）：

• 历史库形式：基于 T + 1 全量和当日增量构建全量历史库，基于历史库再聚合
• 轻度聚合后再聚合：构建 T + 1 的轻度聚合模型，多周期扫描再聚合
• 历史周期计拉链：以固定工夫窗口形式构建用户标签表，计算时关联标签表再聚合
• 位图模式计算：以滑动工夫窗口形式构建用户标签表，并以位图存储窗口周期信息

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）；其次要设计好窗口滑动的更新逻辑；
• 信息形象：要害聚合信息，如新客的判断（N+ 1 的工夫窗口内，第 N 天首次拜访就是新用户）；last_date 的数值化信息保留（累计多少天未拜访，无效缩小存储）；累计拜访天数（反对拜访天数散布的人群剖析）；

2 模型组件

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

应用阐明：你只须要配置根底信息，在作业中配置好【输出表】、【输出表】、【统计日期】和【工夫窗口】4 个参数，就能够主动实现你的用户留存模型，无需定义 DDL、无需写留存模型的简单代码。

Dataworks 工作节点参考：

• 节点 ID：公布后的 ODPS 工作节点号
• 节点名称：留存模型的表名（可自定义指定）
• 节点类型：ODPS SQL

节点工作配置：

jar -classpath 云端文件 /res?id=xxx 类名.tools.OdpsCltWrapper 
"--class" < 留存模型的 jar 包 >
"--properties-file"  云端文件 /res?id=xxx 
"--conf" < spark 配置文件 > 
"--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 
云端文件 /res?id=xxx "--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 倍存储、且信息更齐备。

原文链接
本文为阿里云原创内容，未经容许不得转载。