转化率SQL表达式为“成功事件数/总事件数”,需用SUM(CASE WHEN...)或COUNT配合条件聚合,分母用NULLIF避免除零,乘100.0转浮点并ROUND取精度,各环节须同用户、同时间范围且口径一致。

转化率的 SQL 表达式怎么写?
转化率本质是「成功事件数 / 总事件数」,用 COUNT() 或 SUM() 配合条件聚合最稳妥。别直接用 COUNT(*) 除以 COUNT(*)——分母为 0 会报错,且没过滤逻辑。
- 分子建议用
SUM(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END),比 COUNT(CASE WHEN ... THEN 1 END) 更安全(后者会忽略 NULL,但语义不如 SUM 直观)
- 分母必须明确范围,比如
COUNT(*) FILTER (WHERE event_type IN ('view', 'click', 'add_to_cart'))(PostgreSQL)或通用写法 COUNT(CASE WHEN event_type IN ('view', 'click', 'add_to_cart') THEN 1 END)
- 记得转成
DECIMAL 或乘 1.0,否则整数除整数在 MySQL/SQL Server 中结果为 0
不同数据库对除零和小数精度的处理差异
MySQL 和 SQL Server 默认整数除法截断小数;PostgreSQL 会按操作数类型推导,但 INT / INT 仍是整数。常见翻车点:
- MySQL:写成
COUNT(purchase) / COUNT(all) → 结果恒为 0 或 1
- 正确写法:
ROUND(COUNT(purchase) * 100.0 / NULLIF(COUNT(all), 0), 2)
-
NULLIF(COUNT(all), 0) 是关键,避免除零错误;100.0 强制浮点运算
- SQLite 不支持
NULLIF,得用 IIF(COUNT(all) = 0, NULL, COUNT(purchase) * 100.0 / COUNT(all))
漏斗转化率要分步 JOIN 还是单表条件聚合?
单表聚合更高效、更可控,除非涉及跨时间窗口或用户状态强依赖。典型错误是用多次 LEFT JOIN 子查询算各环节人数,导致笛卡尔积或重复计数。
- 推荐用一个查询 + 多个
SUM(CASE WHEN ...):SELECT
SUM(CASE WHEN step = 'page_view' THEN 1 ELSE 0 END) AS views,
SUM(CASE WHEN step = 'add_to_cart' THEN 1 ELSE 0 END) AS carts,
SUM(CASE WHEN step = 'purchase' THEN 1 ELSE 0 END) AS purchases,
ROUND(SUM(CASE WHEN step = 'add_to_cart' THEN 1 ELSE 0 END) * 100.0 / NULLIF(SUM(CASE WHEN step = 'page_view' THEN 1 ELSE 0 END), 0), 2) AS view_to_cart_rate
FROM user_events;
- 如果必须按用户去重(如“看过商品的独立用户中,多少人加购”),则分子分母都得套
COUNT(DISTINCT user_id),不能只在分母去重
- 时间范围必须统一,比如所有步骤限定在同一天或同一会话内,否则转化率无业务意义
为什么 GROUP BY 后的转化率经常不准?
因为漏掉了「分母应是当前分组内的总数」这个前提。例如想看每个渠道的购买率,却写了:
SELECT channel,
COUNT(*) FILTER (WHERE event = 'purchase') / COUNT(*) AS rate
FROM events
GROUP BY channel;
SUM(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END),比 COUNT(CASE WHEN ... THEN 1 END) 更安全(后者会忽略 NULL,但语义不如 SUM 直观)COUNT(*) FILTER (WHERE event_type IN ('view', 'click', 'add_to_cart'))(PostgreSQL)或通用写法 COUNT(CASE WHEN event_type IN ('view', 'click', 'add_to_cart') THEN 1 END)
DECIMAL 或乘 1.0,否则整数除整数在 MySQL/SQL Server 中结果为 0INT / INT 仍是整数。常见翻车点:
- MySQL:写成
COUNT(purchase) / COUNT(all)→ 结果恒为 0 或 1 - 正确写法:
ROUND(COUNT(purchase) * 100.0 / NULLIF(COUNT(all), 0), 2) -
NULLIF(COUNT(all), 0)是关键,避免除零错误;100.0强制浮点运算 - SQLite 不支持
NULLIF,得用IIF(COUNT(all) = 0, NULL, COUNT(purchase) * 100.0 / COUNT(all))
漏斗转化率要分步 JOIN 还是单表条件聚合?
单表聚合更高效、更可控,除非涉及跨时间窗口或用户状态强依赖。典型错误是用多次 LEFT JOIN 子查询算各环节人数,导致笛卡尔积或重复计数。
- 推荐用一个查询 + 多个
SUM(CASE WHEN ...):SELECT
SUM(CASE WHEN step = 'page_view' THEN 1 ELSE 0 END) AS views,
SUM(CASE WHEN step = 'add_to_cart' THEN 1 ELSE 0 END) AS carts,
SUM(CASE WHEN step = 'purchase' THEN 1 ELSE 0 END) AS purchases,
ROUND(SUM(CASE WHEN step = 'add_to_cart' THEN 1 ELSE 0 END) * 100.0 / NULLIF(SUM(CASE WHEN step = 'page_view' THEN 1 ELSE 0 END), 0), 2) AS view_to_cart_rate
FROM user_events;
- 如果必须按用户去重(如“看过商品的独立用户中,多少人加购”),则分子分母都得套
COUNT(DISTINCT user_id),不能只在分母去重
- 时间范围必须统一,比如所有步骤限定在同一天或同一会话内,否则转化率无业务意义
为什么 GROUP BY 后的转化率经常不准?
因为漏掉了「分母应是当前分组内的总数」这个前提。例如想看每个渠道的购买率,却写了:
SELECT channel,
COUNT(*) FILTER (WHERE event = 'purchase') / COUNT(*) AS rate
FROM events
GROUP BY channel;
SUM(CASE WHEN ...):SELECT SUM(CASE WHEN step = 'page_view' THEN 1 ELSE 0 END) AS views, SUM(CASE WHEN step = 'add_to_cart' THEN 1 ELSE 0 END) AS carts, SUM(CASE WHEN step = 'purchase' THEN 1 ELSE 0 END) AS purchases, ROUND(SUM(CASE WHEN step = 'add_to_cart' THEN 1 ELSE 0 END) * 100.0 / NULLIF(SUM(CASE WHEN step = 'page_view' THEN 1 ELSE 0 END), 0), 2) AS view_to_cart_rate FROM user_events;
COUNT(DISTINCT user_id),不能只在分母去重SELECT channel, COUNT(*) FILTER (WHERE event = 'purchase') / COUNT(*) AS rate FROM events GROUP BY channel;
看起来没问题,但若数据里混了非曝光类事件(如后台日志),分母就被污染。真正该用的是:
- 分母限定为该渠道下的有效起始行为,比如
COUNT(*) FILTER (WHERE event IN ('impression', 'click')) - 或提前用 CTE 筛出各渠道的基准用户池,再关联统计后续动作
复杂点在于:转化率不是孤立指标,它高度依赖你定义的「起点」和「终点」是否匹配业务场景。算出来数字容易,对齐口径最难。










