LEAD 和 LAG 不是归因工具，而是路径锚点；强行用它们做“归因”会把跨会话、跳步、设备切换等真实行为硬塞进线性链条里，结果失真。
直接说结论：LEAD 和 LAG 不是归因工具，而是路径锚点；强行用它们做“归因”会把跨会话、跳步、设备切换等真实行为硬塞进线性链条里，结果失真。
为什么 LAG/LEAD 不能直接用于归因
归因（如“用户从广告点击→落地页→加购→下单”）本质是识别因果链，而 LAG/LEAD 只负责按排序取相邻行——它不管两行之间是否真的存在业务逻辑关联。常见误用包括：
- 用
LAG(event_name)判断“上一步是 click”，但实际可能是 12 小时前的旧会话残留记录 - 没加
PARTITION BY user_id，导致 A 用户的末尾事件和 B 用户的开头事件被错误拼接 - 对
LEAD(event_time)做减法算停留时长，却忽略中间缺失事件（比如用户打开页面后关机，8 小时后才点击按钮）
LAG/LEAD 在路径分析中真正该干的事
它们只适合做「可验证的相邻行为标记」，前提是时间粒度够细、会话边界清晰、数据质量可控。实操要点：
- 必须用
PARTITION BY user_id, session_id（而非仅user_id），session_id 需由业务规则生成（如 event_time - prev_time > 1800 秒则新建 session） -
ORDER BY event_time, event_id是底线——毫秒级并发下只靠event_time会错序 - 用
LAG(event_name, 1) OVER (...)+LEAD(event_name, 1) OVER (...)组合判断“孤立点击”：CASE WHEN prev_event IS NULL AND next_event = 'view' THEN 'first_touch' - 避免在 WHERE 中过滤
LAG()输出值；需归因过滤应放在外层 CTE 或子查询中
替代归因的更合理做法
当路径存在跳步（如用户跳过 cart 直接下单）、跨设备（手机点击 → PC 下单）、或时间断层（>24h）时，LAG/LEAD 失效。此时应：
- 用
MAX(event_time) OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)做会话内累计状态快照 - 对关键节点（如 click、purchase）单独打标，再用自连接或
ARRAY_AGG()（BigQuery/PostgreSQL）聚合路径片段 - 归因权重计算改用确定性规则（如“最后非直链点击”）或模型（Markov 链需先清洗出有效路径序列，不是直接喂原始日志）
最常被忽略的一点：LAG/LEAD 的输出 NULL 不是缺陷，而是信号——它明确告诉你“这里没有可连的前序行为”。掩盖它（比如全填 COALESCE(..., 'unknown')）等于抹掉会话起点和路径断裂点，后续所有归因都会漂移。
