直接写 sum(case when...then 1 else 0 end) 算不出转化率，因它仅得分子；分母须用 count(*) 或 count(column) 并配 nullif 防除零，再乘 1.0 和 round 保精度。
为什么直接写 SUM(CASE WHEN ... THEN 1 ELSE 0 END) 算不出正确转化率？
因为转化率是「成功数 / 总数」，而 SUM(CASE WHEN status = 'success' THEN 1 ELSE 0 END) 只能算分子。如果直接除以另一个 SUM 或硬写 COUNT(*)，容易在分组或空值场景下出错——比如某天没数据，COUNT(*) 为 0，会导致除零错误；或者漏掉 NULL 状态的记录，让总数偏小。
实操建议：
- 分子用
SUM(CASE WHEN condition THEN 1 ELSE 0 END)，确保逻辑清晰、可读性强 - 分母必须用
COUNT(*)（含所有行）或COUNT(column)（只计非 NULL），根据业务定义选——转化率通常基于全部请求，所以优先用COUNT(*) - 加
NULLIF(..., 0)防止除零：SUM(...) * 1.0 / NULLIF(COUNT(*), 0)，乘1.0是为了触发浮点运算，避免整数截断
如何按日期/渠道分组计算转化率并保留小数？
常见场景是看每天或每个渠道的转化表现。关键不是套公式，而是控制好分组粒度和类型转换。
实操建议：
- 用
GROUP BY date, channel明确分组维度，别漏掉SELECT中出现的非聚合字段 - 结果用
ROUND(..., 4)控制小数位，避免数据库默认截断（如 MySQL 的DIV或整数除法会丢小数） - 示例语句：
SELECT date, channel, ROUND( SUM(CASE WHEN event = 'pay_success' THEN 1 ELSE 0 END) * 1.0 / NULLIF(COUNT(*), 0), 4 ) AS conversion_rate FROM events GROUP BY date, channel;注意：PostgreSQL 和 SQL Server 对
* 1.0更敏感，不加可能返回整数；BigQuery 支持SAFE_DIVIDE(numerator, denominator)，更简洁
CASE WHEN 里该用 = 还是 IS NOT NULL 判断转化事件？
取决于事件字段的存储方式。很多日志表用一个 event_type 字段存字符串（如 'checkout', 'payment_failed'），也有些用布尔字段（如 is_converted）或状态码（如 status = 200）。
实操建议：
- 字符串匹配用
=，但要加TRIM()和大小写处理，避免隐式失败：CASE WHEN UPPER(TRIM(event_type)) = 'PAY_SUCCESS' THEN 1 ELSE 0 END - 布尔字段直接用
CASE WHEN is_converted THEN 1 ELSE 0 END，更安全 - 状态码慎用
=，优先用IN匹配合法成功值：CASE WHEN status IN (200, 201) THEN 1 ELSE 0 END，避免漏掉新接入的状态 - 永远检查
NULL是否算作失败——大多数业务要求把NULL归入分母但不进分子，所以ELSE 0是对的；如果NULL表示“未知”，可能需要单独统计，不能简单归为 0
在 WHERE 中提前过滤会影响转化率计算吗？
会影响，而且很隐蔽。比如加了 WHERE event_type IS NOT NULL，会让分母变小，导致转化率虚高。
实操建议：
- 除非明确排除脏数据（如测试账号、爬虫流量），否则不要在
WHERE里筛转化相关字段 - 想排除特定渠道但又不影响总数？用条件聚合里的
CASE做二次判断，而不是WHERE - 真正要过滤的，应是时间范围或基础有效标识（如
app_version IS NOT NULL），且需确认这些字段与转化逻辑正交 - 调试时可临时补一列：
COUNT(*) AS total_rows和SUM(CASE ...) AS success_count，肉眼核对是否匹配预期分母
实际跑的时候，最容易被忽略的是分母的语义一致性——它必须严格对应你嘴上说的“转化率”定义。是“点击→下单”的转化？那分母得是所有点击；是“下单→支付成功”？分母就得是所有下单记录。字段来源、时间窗口、去重逻辑，任何一个没对齐，数字就不可信。
