用户留存建模实践

作者 |  王富森,在流量分析型产品的用户分析模块中，留存、互访、新老客构成等数据都是有效衡量用户粘性与促活召回的关键性指标;但是，我们发现在很多流量运营的业务场景中，留存分析建模都显著存在着设计和计算上的诸多问题，例如：各种历史库版本迭代的高额运维与存储成本、暴力计算、频繁计算、数据冷启动等问题。总结下来，有三个方面需要特别关注：,1.场景理解：在非常多的业务场景中，模型研发人员偏向于通过构建用户粒度的全量历史库，再去聚合用户的新老标签或历史累计次数，但关键问题是，在这些场景中基于历史行为计算的新老客标签和历史累计指标，并不适用于该业务场景下的精细化运营。比如，在用户增长领域的流失召回等场景策略中，长周期外仍然未有回访的用户显然不具备再运营的潜质(如180天等);那么，相比基于历史库圈选新用户，改为基于动态滑动窗口的圈选策略，更具有可运营的潜质和解释性;并且，这种计算模式还可以有效地规避历史库回刷与冷启动问题。,2.计算模式：在计算模型的设计和模式构建上，大多数同学普遍缺少模型抽象与精细化设计。就累计去重指标或周期留存指标的计算实现来讲，大致有4种建模范式(想知道第5种请继续看下去)：,3.模型易用：以上模型的实现都存在一定的研发成本，需要有丰富的场景实践和经验积累。如果能够沉淀一套敏捷的标准化模型计算组件，让新人可以在分钟级就完成留存模型的智能研发，那么，就能以标准化的建模范式解决很多业务场景下的建模研发的效率问题。,此外，丰富的场景实践和持续的技术思考对于建模范式的演进都是非常重要的。在某个节点之前，我们曾认为位图设计已经是最优实践了，但是之后又在业务实践中发现很多场景中需要计算更长业务周期的用户新老标签或留存分析。这时候，由于基于二进制bigint存储的位图只能支持到64位，在180天等长周期留存计算时就会溢出，因此，就需要更加通用且高效的模型计算抽象。总之，能够高效支撑业务是最好的实践标准，驱动我们可以在建模范式上是不断超越和颠覆。,蚂蚁版生意参谋是面向支付宝商家的重要对客产品，当时在20年12月份底，我们计划在2月份全量上线B站，留给研发的时间非常吃紧。而由于是对客产品，在架构设计、数据质量、产出时效等各个方面都有更高标准的要求。此外，我们也必须基于新的数据资产架构对蚂蚁生意参谋的产品数据体系进行全盘的重构与升级。其中，流量模块就涉及到了上文中提到的留存/互访/新老等关键指标的各类计算，我们需要在短时间内快速消化和解决存量的应用层链路中存在的很多问题。而最终我们通过用户留存的建模组件，以“重设计、快实现”的方式，在不到2天的时间内就高效完成了小程序、生活号和电子名片等整体数据链路的重构与升级，而且在模型设计、模型存储和模型治理等方面，也取得了很多核心改变。特别是，经过模型重构后，生意参谋的产品数据体系变得异常精简、收敛和高效。那么，我们是怎么做到的呢?接下来，我们就详细介绍留存建模组件的设计思路。,建模组件的设计就是将模型抽象的结果参数化与模板化实现，具体实现细节不详述。,
,Dataworks任务节点参考：,节点任务配置：,基于留存建模组件，基础的模型结构和计算范式都是标准且统一的，能够在一个参数化逻辑中一站式实现所有指标的计算，非常便捷;而下游相关的数据模型也变得异常精简、收敛和高效。,通过参数化视图统一封装指标的一体化计算逻辑，下游不需要关注计算中的复杂逻辑，直接面向消费，简洁易用，如：,核心改变：基于模型组件，可高效构建用户留存模型(0.5人日降低至2分钟)，且支持超过64位图的留存/互访/新老指标的标准化计算、避免下游多周期扫描与重复计算，尤其相比历史库表可减少4倍存储(前：62字节 vs 后后：16字节)。,建标准：构建了基于滑动窗口实现的标准化留存模型，实现模型设计和数据计算上的改进，有效解决了历史库版本迭代的高额运维与存储成本、下游的多周期扫描、频繁计算和历史库冷启动等一系列问题。,提效率：研发效率显著提升(分钟级实现用户流量模型的标准化构建)，让我们在及实现。,提效率：30min左右即可完成100亿的留存模型计算。,降存储：相比历史库设计可有效降低4倍存储、且信息更完备。