窗口函数配合时间序列识别流失起点需用lag()计算相邻登录间隔，结合业务阈值标记首次超限日；错误做法是直接取max(event_time)，正确路径是case when+min()获取最早断层日。
窗口函数怎么配合时间序列识别流失起点
用户流失不是某天突然发生的，而是行为断层逐渐累积的结果。用 LAG() 或 LEAD() 比较相邻登录日期，再结合业务定义的“流失阈值”（比如 30 天未活跃），就能定位首次超阈值的那天——这才是真正的流失起点，不是最后一次活跃日。
关键不是查“最后一次”，而是查“第一次断层”。常见错误是直接 MAX(event_time) 找最后登录时间，这只能告诉你用户停在哪天，不能说明他从哪天开始算流失。
-
LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time)得到上一次活跃时间 - 用
DATEDIFF(CURRENT_DATE, LAG(...)) > 30判断是否首次超过阈值 - 必须加
WHERE过滤出满足条件的第一条记录，否则会返回所有断层日
为什么 ROW_NUMBER() + WHERE 不能替代 FIRST_VALUE() 的写法
有人想用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time DESC) 找最后一条，再 WHERE rn = 1，但这只锁定最后一次行为，无法回溯断层起点。而 FIRST_VALUE(event_time) OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) 本身不解决流失问题，真正有用的是 MIN() 配合条件窗口：先标记每条记录是否构成流失起点，再取最小的那个。
- 错误思路：
ROW_NUMBER() ... WHERE rn = 1→ 只得最后活跃日 - 正确路径：用
CASE WHEN DATEDIFF(...) > 30 THEN event_time END生成流失候选集，再MIN()取最早那个 - 注意
MIN()必须在子查询或 CTE 中计算，不能直接放在窗口里和OVER混用
MySQL 8.0 和 PostgreSQL 在 DATEDIFF 行为上的坑
MySQL 的 DATEDIFF(a, b) 返回天数差（a - b），但 PostgreSQL 没有内置 DATEDIFF，得用 a::date - b::date；更麻烦的是，如果字段含时分秒，MySQL 默认截断，PostgreSQL 却保留精度，可能导致同一条记录在两边判断结果不一致。
- 统一做法：全部转成
DATE类型再相减，例如(CURRENT_DATE - DATE(last_active)) > 30 - 避免用
NOW() - last_active，因为时区和小数秒会让跨天判断飘移 - 测试时用固定日期如
'2024-01-01'::date替代CURRENT_DATE，确保可复现
如何验证你找出来的“流失日”真能反映业务意图
技术上算出的“首次断层日”未必等于业务认可的流失日。比如用户每月 5 号固定充值，那 30 天规则就不适用；又比如 B2B 客户按合同周期活跃，不能简单套用 C端标准。所以必须把窗口结果和业务规则表做 JOIN，动态加载每个用户所属的流失判定策略。
- 建一张
user_retention_policy表，含user_id、churn_days_threshold、active_event_type - 在主查询中
LEFT JOIN该表，把硬编码的30换成字段引用 - 上线前用小批量用户抽样比对：窗口结果 vs 客服标记的流失工单时间，偏差 > 2 天就得查逻辑
最易被忽略的是“流失”本身需要业务定义，不是数据库能自动理解的概念。窗口函数只是工具，它不会替你决定 30 天合理还是 7 天合理——那个数字得从客户行为数据里反复试出来，不是拍脑袋定的。
