窗口函数按来源+时间排序还原用户路径，需先过滤无效事件，再用ROW_NUMBER()或LAG/LEAD按user_id和毫秒级event_time排序；拼接路径须用STRING_AGG或GROUP_CONCAT，配合COALESCE处理NULL，并避免ROWS BETWEEN误用。
窗口函数怎么按来源+时间排序还原用户路径
直接用 ROW_NUMBER() 或 RANK() 按 user_id 分组、按 event_time 排序，是还原单用户行为序列的基础。但关键在于：必须先过滤掉无效事件（如重复埋点、测试账号、非目标页面），否则路径会被污染。常见错误是直接对原始日志开窗，结果发现某用户路径里突然冒出一个 '/admin/test' 页面——这根本不是真实转化漏斗的一部分。
实操建议：
- 先用
WHERE筛出目标流量来源（如source IN ('wechat', 'baidu', 'direct')）和有效事件类型（如event_type = 'page_view'且url NOT LIKE '%test%'） - 排序字段必须包含秒级或毫秒级时间戳，避免同一秒内多个事件导致
ROW_NUMBER()结果不稳定 - 如果存在跨天会话，建议额外加
session_id字段分组，而不是只靠user_id—— 否则凌晨和上午的行为会被连成一条超长路径
如何用 LAG/LEAD 提取上一步/下一步来源和页面
LAG() 和 LEAD() 是拼接转化路径的核心。但很多人忽略参数顺序和默认值处理，导致路径断裂或误判。比如用 LAG(url) 却没指定 OFFSET，结果默认取前1行，但实际想对比的是前2步（如从首页→商品页→下单页）。
实操建议：
-
LAG(url, 1) OVER (PARTITION BY user_id ORDER BY event_time)获取上一页，LAG(source, 1)获取上一来源，两者必须用相同ORDER BY条件，否则错位 - 显式指定
DEFAULT NULL，避免数据库默认填 0 或空字符串干扰后续WHERE判断（例如WHERE prev_url IS NOT NULL） - 不要在
WHERE中直接过滤LAG()字段——窗口函数在WHERE之后执行，需套一层子查询或 CTE
怎么统计「微信→搜索页→商品页→下单」这类路径的频次
路径统计不是简单 COUNT(*)，而是要把每条用户路径抽象成固定格式字符串再聚合。难点在于：不同长度路径无法直接比较，且需排除中途跳出的短路径（比如只走到第二步就离开）。
实操建议：
- 用
STRING_AGG()（PostgreSQL/SQL Server）或GROUP_CONCAT()（MySQL）拼接路径，注意指定分隔符（如'->'）和排序依据（必须和开窗时一致） - 加条件过滤完整路径：比如要求路径长度 ≥ 4 步，可用
HAVING COUNT(*) >= 4配合GROUP BY user_id - MySQL 8.0+ 支持
WINDOW命名复用，避免重复写PARTITION BY user_id ORDER BY event_time，提升可读性和执行效率 - 路径中混入
NULL值会导致整个STRING_AGG结果为NULL，务必提前用COALESCE(url, 'unknown')处理
为什么用 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 会出错
这个范围定义常被误用于“累计路径构建”，但它只适合求和/计数类累积，不适合拼路径。因为 ROWS BETWEEN 是物理行偏移，而用户行为序列依赖逻辑时间顺序——若排序字段有重复值，物理行序和事件时序不一致，拼出来的路径就是乱的。
实操建议：
- 路径拼接必须依赖
ORDER BY event_time的逻辑序，而不是行号；ROWS模式下即使加了ORDER BY，窗口帧仍按物理存储顺序切片 - 真要逐层扩展路径（如 step1 → step1+step2 → step1+step2+step3），得用递归 CTE 或应用层迭代，SQL 窗口函数本身不支持动态长度字符串累积
- 如果硬要用窗口聚合字符串，PostgreSQL 可用
STRING_AGG(url, '->') OVER (PARTITION BY user_id ORDER BY event_time ROWS UNBOUNDED PRECEDING)，但 MySQL 不支持该语法，别盲目移植
真正卡住多数人的不是语法，而是没意识到：路径分析本质是图遍历问题，SQL 窗口函数只是线性近似。一旦路径含环（比如用户反复回到首页）、或需跨会话关联（如微信进→三天后直接访问下单页），就得补设备指纹或归因模型，纯 SQL 很难兜底。
