做留存分析时，最怕什么？无非是每次都要从零写SQL、手动逐条计算，结果还容易出错。更头疼的是，不同团队对“留存”的定义可能都不一样，口径一乱，报表就废了。今天这篇文章，就把留存分析的标准化流程拆开来讲：从原始日志准备、首日活跃用户定义，到次日、7日、30日留存计算，再到按渠道版本下钻对比，一次性讲清楚。

准备原始行为日志表

首先，得确保你手头的数据表里，至少包含这几个字段：用户唯一ID（比如user_id）、事件时间（event_time，格式最好是'YYYY-MM-DD HH:MM:SS'或精确到秒的时间戳）、事件类型（event_name，比如'launch'就代表启动）、设备信息（device_id或os_type）、渠道来源（channel）、以及APP版本（app_version）。

有个小坑值得注意：如果event_time是字符串类型，但里面藏着毫秒（比如'2026-06-01 08:23:45.123'），那按天分组的时候，数据库会直接罢工。所以，要么提前截断成标准格式，要么转成datetime类型。

别看这步啰嗦，但绝对不能跳——如果连user_id或event_time都缺，那后续所有留存计算都是空中楼阁。

定义活跃用户与首日基准

定义首日活跃用户，通常有两种招数。

方法一：用首次启动时间作为用户生命周期起点。写SQL提取每个user_id的最小event_time（前提是event_name = 'launch'），生成一张首日表first_active。注意，一定要加WHERE event_name = 'launch'这个过滤条件，否则那些注册事件、静默推送这类跟主动启动无关的干扰数据，会污染你的首日判断。

方法二：如果产品有明确的注册闭环，也可以用注册时间register_time来替代。但前提是，这个register_time必须来自统一认证服务，且客户端没法伪造。不然，数据污染的风险又回来了。

计算次日留存（核心逻辑）

次日留存的计算，逻辑上分三步走。

第一步：以first_active表为左表，关联回原始日志表。关联条件限定两件事：一是event_name = 'launch'，二是日期正好差一天（即first_active.date + INTERVAL 1 DAY）。

第二步：按first_active.date分组，统计用户存留比例。公式就是：COUNT(DISTINCT活跃用户ID) / COUNT(DISTINCT首日用户ID)。

第三步：别忘了加一个WHERE条件，把测试账号排除出去。比如user_id以'test'开头，或者渠道来源是'internal'的。不排除的话，线上报表很可能会突然蹦出一个异常高的留存值。

这一步跑完后，你应该会得到一张表，每行一个日期，右边跟着一列retention_d1。如果发现某天retention_d1大于1.0，那说明user_id去重失效了，或者有脏数据在重复上报。

批量生成7日、30日留存

说到批量生成，这里推荐两种方式。

方法一（强烈推荐）：复用次日留存的计算结构，只是把INTERVAL 1 DAY换成INTERVAL 7 DAY和INTERVAL 30 DAY，分别跑三次，最后用UNION ALL把结果拼起来。简单直接，不容易出错。

方法二：用窗口函数加日期差做动态计算。这种玩法相当高级，但前提是数据库得支持LAG或DATE_DIFF（比如BigQuery、Spark SQL都可以）。如果你还在用MySQL 8.0以下，这条路基本走不通。

还需要特别强调一点：无论是次日、7日还是30日留存，分母必须是同一批first_active用户。千万别用“第7天活跃用户数除以第7天新增用户数”——这个算法算出来的，其实是“第7天新老用户占比”，跟留存完全是两码事。

按渠道/版本下钻对比

到了下钻这一步，操作其实很简单。你只需要在最初的first_active表里，提前把channel、app_version这两个字段保存下来。后面计算留存率时，GROUP BY后面直接加上first_active.channel就行。

数据导出后，建议用Excel或者QuickSight做一个叠加折线图：横轴是first_active.date，几条线代表不同的渠道，Y轴是retention_d1。这样一对比，哪些渠道表现不佳，一眼就能看出来。如果发现某条渠道的留存曲线，长期低于整体均值5%以上，那就要警惕了——要么是落地页跳失率有问题，要么是安装包签名被人动了手脚。

这一步基本不需要额外的清洗工作，只要first_active表里的channel字段非空、枚举值稳定（比如只有'ios_appstore'、'android_oppo'这几个），直接分组就能生效。