group by 不能直接计算漏斗转化率，因其对各事件独立去重导致分子分母用户池不一致；正确做法是先按 user_id 去重，再用 case when 判定各环节达成情况并汇总。
GROUP BY 本身不能直接用于计算漏斗转化率——它会把每个事件独立计数，导致分子分母用户池不一致，转化率完全失真。
为什么 GROUP BY event_type 得不到正确转化率
常见错误写法：SELECT event_type, COUNT(DISTINCT user_id) FROM events GROUP BY event_type。这看似能出各环节人数，但结果是“各自去重”：比如 view 有 1000 人，add_to_cart 有 800 人，但这 800 人里可能只有 600 人来自那 1000 个 view 用户——你根本不知道分母是谁。
漏斗的核心约束是：后一步的分子，必须是前一步用户的子集。这不是分组问题，是同一用户池上的多条件判别问题。
- 直接
GROUP BY step会把每个用户锁死在一个 step 里，无法体现“同一个用户走过多个环节” - 若原始数据中
event_type有空格或大小写不一致（如'add_to_cart '），CASE WHEN将完全匹配失败 - 未加
WHERE user_id IS NOT NULL时，NULL 值会被 Hive 的GROUP BY聚成一组，虚增“未知用户”
正确写法：CASE WHEN + SUM + 用户级去重子查询
核心逻辑是：先按 user_id 去重得到干净用户池，再对每个用户判断其是否达成各环节，最后汇总计数。
示例（兼容 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
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;
-
ELSE 0必须显式写出，否则SUM会跳过 NULL，导致总数偏小 -
NULLIF(uv_view, 0)是防除零的关键，漏掉会导致整条 SQL 报错 - Hive 不支持
DISTINCT ON，需改用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time) = 1取首行 - 若漏斗依赖时间顺序（如必须先 view 再 add_to_cart），
CASE WHEN就不够用了，得上窗口函数或自连接
Hive 中 LEFT JOIN 逐层建漏斗的坑
有人用 step1 LEFT JOIN step2 ON user_id 方式建漏斗表，但容易忽略两点：
- 某用户有
step1无step2，LEFT JOIN后step2字段为 NULL，而COUNT(step2)会跳过 NULL——这看似合理，实则掩盖了“流失”事实；应改用COUNT(*) - COUNT(step2)显式算流失量 - Hive 的
GROUP BY对 NULL 默认聚成一组，若原始数据中user_id有空值，会虚增一个“未知用户组”，务必在最外层加WHERE user_id IS NOT NULL - 逐层 JOIN 在数据量大时性能差，且难以扩展到 5 步以上；单次扫描 + 多列
CASE WHEN更高效、更可控
真正难的不是写 SQL，而是想清楚：你定义的“一个用户完成某环节”，到底是以首次行为为准，还是以任意一次为准？是否要求时间顺序？这些业务语义一旦模糊，再漂亮的语法也救不了结果。别急着敲 GROUP BY，先画清楚用户路径和判定逻辑。
