SQL 如何计算转化率？

转化率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(CA

  

  SE 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;

看起来没问题，但若数据里混了非曝光类事件（如后台日志），分母就被污染。真正该用的是：

• 分母限定为该渠道下的有效起始行为，比如 COUNT(*) FILTER (WHERE event IN ('impression', 'click'))
• 或提前用 CTE 筛出各渠道的基准用户池，再关联统计后续动作

复杂点在于：转化率不是孤立指标，它高度依赖你定义的「起点」和「终点」是否匹配业务场景。算出来数字容易，对齐口径最难。