漏斗各环节需用用户级事件序列建模：以user_id为单位，用max(case when...)标记是否完成每步，再count(distinct)统计；分母必须是上一步的分子，确保路径连续性，时间范围须统一。
漏斗各环节怎么用 SQL 一次性查出来？
直接用 WITH + 多个 COUNT 聚合是常见误区——它没法体现用户路径的连续性。真正有效的做法是用「用户级事件序列」建模：先按 user_id 分组，用条件聚合或窗口函数标记每个用户是否完成某一步，再统计每步的去重人数。
关键不是算总数，而是算「能走到这步的用户数」。比如注册后没登录的用户，不能计入登录环节分母。
- 必须以
user_id为单位做路径判定，不能只看事件表行数 - 推荐用
MAX(CASE WHEN ... THEN 1 ELSE 0 END)判定用户是否达成某环节（比EXISTS子查询更易读、更易优化） - 所有环节的时间范围要一致（比如都限定在 7 天内），否则分母不具可比性
转化率分母为什么总是不准？
漏斗转化率的分母不是上一步的总人数，而是「能进入上一步的用户中，实际走到当前步的人数」。典型错误是把 COUNT(*) 当分母，忽略了用户可能跨天、跨设备、或重复触发同一环节。
正确逻辑是：第 n 步分母 = 第 n-1 步的分子。所以必须从第一步开始逐层向下传递用户集合，不能反向倒推。
- 第一步（如「访问首页」）分母就是该时段内去重
user_id数 - 第二步（如「点击注册按钮」）分母 = 同一时段内既访问首页又点击注册的
user_id数 - 用
INNER JOIN或WHERE user_id IN (...)显式约束路径连续性，避免用OR或UNION混淆环节边界
MySQL 8.0+ 怎么用窗口函数简化写法？
如果事件表有明确时间戳和顺序，可用 ROW_NUMBER() 或 LAG() 标记用户行为序列，但要注意：窗口函数无法跨行判断「是否完成某环节」，仍需配合条件聚合。
魔搭GPT（ModelScopeGPT）是一款AI视频创作工具，阿里达摩院推出的大小模型协同的智能助手，具备作诗、绘画、视频生成、语音播放等多模态能力。
更实用的是用 MIN(event_time) 提取各环节最早发生时间，再用 CASE WHEN 判断时间先后关系：
SELECT COUNT(DISTINCT user_id) AS step1, COUNT(DISTINCT CASE WHEN reg_time = '2024-06-01' GROUP BY user_id ) t
这种写法对数据质量要求高：每个环节必须有且仅有一个有效事件时间，否则 MIN 会掩盖重复或异常行为。
ClickHouse 里 countDistinct 性能太差怎么办？
countDistinct 在大数据量下容易 OOM 或超时，尤其当用户 ID 是字符串时。ClickHouse 原生支持 uniqCombined 和 uniqHLL12，精度损失可控，性能提升明显。
- 用
uniqCombined(user_id)替代count(DISTINCT user_id)，内存占用降低 5–10 倍 - 如果允许 1% 误差，改用
uniqHLL12(user_id)，速度更快 - 避免在子查询里嵌套多层
DISTINCT，先把用户路径打平成宽表再聚合 - 注意
uniqCombined不支持NULL，需提前用COALESCE(user_id, '')处理空值
漏斗统计真正的复杂点不在 SQL 写法，而在如何定义「同一个用户」——设备 ID、手机号、登录态 token 的归因逻辑一旦模糊，后面所有转化率都会漂移。这个层面没法靠 SQL 解决，得前置在数据采集和用户打标阶段卡死。
