SQL 如何计算漏斗转化率？
面试怎么回答
计算漏斗时，我会先确定分析主体、步骤定义、顺序规则和转化窗口。SQL 上通常按主体聚合事件时间，先找到第一步，再逐级寻找发生在上一步之后且窗口内的下一步，避免各事件独立 COUNT。最后同时输出每一步人数、逐步转化率和整体转化率，并校验身份映射、重复事件、迟到数据以及是否允许跳步。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
曝光 10 万人、点击 8 万人、下单 2 万人，能不能直接说点击到下单的转化率是 25%？
不一定。因为三步可能不是同一批用户，也可能没有按顺序发生，甚至跨了不同的转化窗口。
漏斗分析不是几类事件的独立计数，而是同一个分析主体，在规定时间内按顺序完成一组步骤。
先统一分析主体
漏斗可以按 user_id、device_id、session_id 或订单号计算。主体不同，答案就不同。
例如用户登录前用 device_id 浏览，登录后才有 user_id。如果身份映射没有处理好，同一次路径会被拆成两个人，前一步人数偏大，后一步转化偏低。
再定义步骤和顺序
严格漏斗要求第二步发生在第一步之后，第三步发生在第二步之后。宽松漏斗可能允许跳步，或者只要求目标行为发生在首步之后。
SQL 中常见的做法，是先按主体找到第一步最早时间，再用条件聚合逐级寻找后续步骤时间；每一步都以上一步时间作为下界，而不是只与当天日期比较。
转化窗口必须进入 SQL
“看到广告后7天内下单”和“同一次会话内下单”是两套完全不同的漏斗。没有窗口限制，几个月后的偶然购买也会被归到这次曝光。
窗口通常从第一步开始，也可能从相邻步骤开始。面试时最好主动说明，否则即使 SQL 语法正确，业务口径也可能是错的。
同时给出逐步和整体转化率
逐步转化率用于判断哪一环掉得最多，例如 step3 人数 ÷ step2 人数；整体转化率用于看最终结果，例如 step4 人数 ÷ step1 人数。
只输出百分比不够，还要带上每一步人数。人数太小时，百分比波动会非常大；事件延迟、重复上报和机器人流量也应该单独核对。
一个典型场景
某次活动的“提交订单”人数竟然高于“进入结算页”人数。第一反应可能是埋点丢失，但抽样后发现 SQL 分别统计了两个事件的 UV，并没有要求提交订单发生在进入结算之后。
其中一部分用户通过历史购物车直接提交，另一部分订单来自活动前就打开的页面。业务可以选择把它们纳入宽松漏斗，但不能继续叫严格顺序漏斗。
先说清楚漏斗定义，再讨论 SQL 写法。