group by统计购物车转化漏斗的核心是按用户去重后逐层标记行为状态，再聚合各环节人数；需用cte+case为每个user_id打标是否完成各环节，配合count(distinct user_id)和严格时间窗口确保路径可追溯与数据准确。
GROUP BY 统计购物车转化漏斗的核心逻辑
电商漏斗（浏览 → 加购 → 下单 → 支付）本质是按用户行为路径分层计数，GROUP BY 本身不直接“建漏斗”，而是配合 CASE WHEN 和聚合函数完成各环节人数/订单数统计。关键不是分组字段本身，而是如何定义“同一用户在不同环节是否被计入”。
常见错误是直接 GROUP BY event_type，结果得到的是各事件总数（比如加购发生10万次），而非“从浏览进入加购的用户数”。真正要的是**去重用户数**在各环节的留存。
必须做两件事：
- 用
DISTINCT user_id或COUNT(DISTINCT user_id)避免重复计数 - 用子查询或 CTE 把用户行为打上“是否完成后续环节”的标签，再分组聚合
用 CTE + CASE 构建用户级漏斗状态
最稳妥的做法是先按 user_id 汇总每个用户走到了哪一步，再统计各层级人数。例如：
WITH user_funnel AS (
SELECT
user_id,
MAX(CASE WHEN event_type = 'view' THEN 1 ELSE 0 END) AS has_view,
MAX(CASE WHEN event_type = 'add_to_cart' THEN 1 ELSE 0 END) AS has_cart,
MAX(CASE WHEN event_type = 'order_submit' THEN 1 ELSE 0 END) AS has_order,
MAX(CASE WHEN event_type = 'pay_success' THEN 1 ELSE 0 END) AS has_pay
FROM user_event_log
WHERE event_time >= '2024-06-01'
GROUP BY user_id
)
SELECT
COUNT(*) AS total_users,
COUNT(CASE WHEN has_view = 1 THEN 1 END) AS view_users,
COUNT(CASE WHEN has_cart = 1 THEN 1 END) AS cart_users,
COUNT(CASE WHEN has_order = 1 THEN 1 END) AS order_users,
COUNT(CASE WHEN has_pay = 1 THEN 1 END) AS pay_users
FROM user_funnel;
注意：MAX() 在这里等价于“该用户至少有一次该行为”，比 SUM() > 0 更简洁；WHERE 时间过滤必须放在 CTE 内，否则可能把早期加购但近期下单的用户误判为“未加购”。
避免时间错位：漏斗必须基于同一周期内行为链
漏斗失真的最大来源是时间窗口不一致。比如统计“6月1日加购用户中，有多少人在6月7日前下单”，不能简单用两个独立 GROUP BY 结果相除。
正确做法是限定行为时间范围，并确保路径可追溯：
- 加购时间在
[t1, t2]，下单时间在[t1, t2 + 7d]，且下单user_id必须出现在加购结果中 - 用
LEFT JOIN或EXISTS关联后续行为，而不是分别GROUP BY - 若用窗口函数，
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time)可辅助识别首次加购后是否跟进下单
性能与数据倾斜问题
当用户量超千万、事件表达百亿行时，COUNT(DISTINCT user_id) 在某些引擎（如 Hive 旧版本、MySQL 5.7）会触发大内存 shuffle 或临时表爆掉。
应对方式包括：
- 用近似去重函数替代：如
APPROX_COUNT_DISTINCT(user_id)（Spark SQL / Presto / Trino 支持） - 预计算中间表：每天跑一次
user_daily_status表，存每个用户当日最高行为等级（1=view, 2=cart, 3=order…），漏斗查询直接查该表 - 加购环节若存在大量机器人刷行为，先用
WHERE is_human = 1过滤，否则has_cart虚高会拉低后续转化率
GROUP BY 都在算错数。
