漏斗统计必须基于去重用户池而非事件行数，正确做法是先DISTINCT user_id和event_type，再用CASE WHEN+SUM统计各环节用户数，确保分母一致；需用NULLIF防除零，TRIM清理空格，Hive中改用ROW_NUMBER()，路径顺序验证需LEAD窗口函数。
漏斗统计不能只用 GROUP BY event_type
直接 GROUP BY event_type 得到的各环节人数，分母不一致——比如 view 有 1000 人、add_to_cart 有 800 人，但这 800 人里可能只有 600 人来自那 1000 个 view 用户。漏斗要求“后一步用户必须是前一步用户的子集”，而 GROUP BY 是独立统计，完全违背这个前提。
常见错误现象包括：add_to_cart 人数 > view 人数（说明没去重或没限定用户池）、转化率突变无业务解释、同一用户因多次行为被重复计入多个步骤。
- 必须先按
user_id去重，锁定干净用户池 -
CASE WHEN要配合SUM判断每个用户是否达成某环节，而非统计事件行数 -
ELSE 0必须显式写出，否则SUM会跳过NULL，导致总数偏小 - 用
NULLIF(uv_view, 0)防除零，漏掉会整条 SQL 报错
正确写法：单次扫描 + DISTINCT + CASE WHEN + SUM
核心逻辑是：先取唯一用户和其任意一次有效行为（去重），再对每个用户判别是否满足各环节条件，最后汇总计数。这样所有环节共享同一用户池，分母天然一致。
PostgreSQL / MySQL 8.0+ 示例：
SELECT
SUM(CASE WHEN event_type = 'view' THEN 1 ELSE 0 END) AS uv_view,
SUM(CASE WHEN event_type = 'add_to_cart' THEN 1 ELSE 0 END) AS uv_cart,
SUM(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) AS uv_purchase,
ROUND(100.0 * uv_cart / NULLIF(uv_view, 0), 2) AS rate_view_to_cart,
ROUND(100.0 * uv_purchase / NULLIF(uv_cart, 0), 2) AS rate_cart_to_purchase
FROM (
SELECT DISTINCT user_id, event_type
FROM events
WHERE user_id IS NOT NULL
AND event_type IN ('view', 'add_to_cart', 'purchase')
) t;- 子查询中
DISTINCT user_id, event_type表示“该用户至少发生过该事件”，不是取首行也不是取最新 - 如果原始数据中
event_type有空格（如'add_to_cart '），CASE WHEN完全匹配失败，务必提前TRIM(event_type) - Hive 不支持
DISTINCT多列去重，得改用ROW_NUMBER() OVER (PARTITION BY user_id, event_type ORDER BY event_time) = 1
需要验证路径顺序时，必须用窗口函数
上面的方法只回答“用户有没有做过 A、B、C”，不回答“是否按 A→B→C 顺序完成”。一旦业务要求路径有效性（比如 view 后必须在 1 小时内 add_to_cart），就得升级方案。
关键动作是给每个用户的每条行为打序号，再用 LEAD 匹配紧邻步骤：
SELECT user_id
FROM (
SELECT
user_id,
event_name,
LEAD(event_name, 1) OVER (
PARTITION BY user_id
ORDER BY event_time, event_id
) AS next_event
FROM events
WHERE event_name IN ('view', 'cart')
) t
WHERE event_name = 'view' AND next_event = 'cart';-
PARTITION BY user_id和ORDER BY event_time, event_id缺一不可；只排event_time可能因时间重复导致跨用户匹配 -
event_id作为二级排序字段，解决毫秒级时间重复问题 - 过滤应放在窗口函数外层（即先
WHERE再OVER），否则排序开销剧增 - 若需三步路径（A→B→C），可嵌套两次
LEAD或改用自连接，但性能明显下降
性能与兼容性容易被忽略的点
漏斗 SQL 看似简单，但在千万级用户表上很容易跑崩。真正卡住的往往不是逻辑，而是执行计划和隐式类型转换。
- 确保
user_id和event_type字段有联合索引，顺序为(user_id, event_type)，否则子查询DISTINCT全表扫描 - MySQL 5.7 不支持子查询中
DISTINCT+ORDER BY混用，需改写为 CTE 或临时表 - 如果
event_time是字符串类型，ORDER BY event_time会按字典序排，导致时序错乱——必须转成TIMESTAMP或DATETIME - 当漏斗阶段超过 5 步，
CASE WHEN嵌套过深易读性差，建议拆成 CTE 分步定义各环节用户集合
最常被跳过的一步：没确认原始行为日志里是否存在脏数据（如测试账号、爬虫流量、event_type 拼写不统一）。漏斗结果失真，90% 源于输入数据没清洗，而不是 SQL 写得不够“高级”。
