转化率为什么不能直接求平均：简单平均、加权平均、先汇总再除三种口径的取舍
结论先行：比率型指标（转化率、ARPU、客单价、人均时长）不可加——"对每日转化率取算术平均"和"先汇总分子分母再相除"算出来的不是同一个数，且前者在流量波动越大时偏得越狠。本文把三种口径的机制、边界和可复现 SQL 一次讲清。
一、现象与背景
去年 6 月，我接手一个电商增长看板，第一周就撞上一堵墙：
- 产品同学在周报里写「近 30 天支付转化率 4.12%」，这个数字是他对 30 个每日转化率做了
AVG()； - 数据同学用「总支付订单 / 总支付 UV」算出来是 4.36%；
- 两个数都出自同一张
daily_metrics表、同一套埋点，差 0.24pp，相对偏差约 5.6%。
更糟的是，这个差距不是均匀的：我们按「是否含周末」拆开看，含 4 个周末日的区间，两个口径差 0.31pp；纯工作日的区间只差 0.09pp。也就是说——流量结构越不均匀，"求平均"这个动作偏得越远。一个 5.6% 的相对偏差，足以让"环比是涨是跌"的结论翻转，而这恰恰是增长周会最关心的判断。
二、原理或根因分析：比率为什么不可加
关键在数学结构上。转化率这类指标是两个量的商：
rate = 分子(支付订单) / 分母(支付UV)
"加"这个操作只对可加量（订单数、GMV、UV 本身）有意义；对商做算术平均，等价于假设"每一天的分母权重都相同"。但现实里：
- 工作日：UV 高（大盘流量），转化率低（逛的人多、目的性弱）；
- 周末/节假日：UV 低，但转化率高（来的多是目的性购买、客单更高）。
"对每日转化率求算术平均"等于给「UV=120 万的工作日」和「UV=28 万的周末日」各配了 1/N 的权重，而真实的业务贡献里，工作日的分母占大头。于是高转化的低流量日被过度放大，低转化的主力日被低估，整体被拉偏。
而"先汇总再除" SUM(分子)/SUM(分母)，数学上恰好等于按分母（UV）加权的平均——它让每一天的权重自动等于它的流量占比，这才是"整个区间的真实转化率"。
一句话：比率是"两个可加量的商"，聚合时必须回到分子分母各自先加、再除，不能对商直接加。
三、具体做法（可复现）
下面用一张 daily_metrics(dt, uv, pay_cnt) 表演示，窗口取 2024-05-01 ~ 2024-05-30。
-- ❌ 错误：对日转化率求算术平均（等价于每天等权）
SELECT AVG(pay_cnt / uv) AS avg_rate
FROM daily_metrics
WHERE dt BETWEEN '2024-05-01' AND '2024-05-30';
-- ✅ 正确：先汇总分子分母，再相除（= 按 UV 加权）
SELECT SUM(pay_cnt) / SUM(uv) AS real_rate
FROM daily_metrics
WHERE dt BETWEEN '2024-05-01' AND '2024-05-30';
-- ✅ 等价的显式加权写法（便于在指标平台里声明口径）
SELECT SUM((pay_cnt / uv) * uv) / SUM(uv) AS weighted_rate
FROM daily_metrics
WHERE dt BETWEEN '2024-05-01' AND '2024-05-30';
三个口径的适用边界，建议直接写进指标字典：
| 口径 | 公式 | 适用 | 不适用 |
| --- | --- | --- | --- |
| 简单平均 | AVG(rate) | 各期流量量级接近、仅作粗略趋势 | 流量波动大的区间汇总、KPI |
| 加权平均 | SUM(rate·w)/SUM(w) | 区间 KPI 汇总、同比/环比 | 需要显式权重时优先用分子分母法 |
| 先汇总再除 | SUM(分子)/SUM(分母) | 所有区间汇总的默认口径 | 需要"每一天一个点"的折线趋势 |
一个容易忽略的点：折线趋势图保留每日比率是对的——那是"观察一个时间序列"，不是"聚合"。错误只发生在"把多个日子的比率合并成一个数"的时刻。
四、踩过的坑与反直觉之处
- 同比/环比的"变化率"要建立在加权口径上。 别用"简单平均的差"去算环比，否则你比较的两个基线本身就偏了。正确做法是两个区间各自
SUM/SUM，再算(本期-上期)/上期。 - 下钻维度后不能简单平均回大盘。 拆到「渠道 × 地域」再想汇总回大盘时，对每个格子求转化率、再对格子做
AVG()，会二次失配。正确做法是回到全局分子分母：SUM(所有格子分子)/SUM(所有格子分母)。 - 分母接近 0 的日子，简单平均会被极端值放大。 冷启动日、故障恢复日 UV 很小、转化率可能爆表，简单平均里它照样占 1/N 的权重；而
SUM/SUM天然把它按低分母降权，更稳健。 - ARPU、客单价、人均时长全是同一个坑。 它们都是"可加量/可加量"的商，聚合时一律回到"先加分子、先加分母、再相除"，别对人均值求平均。
- 反直觉的一点：很多人以为"数据越多越准"，于是把 30 天每天一个点取平均显得"用了 30 个样本"。其实简单平均的 30 个样本里，每个样本的权重是错的——样本量多不补偿权重错。
五、结论与可复用清单
比率型指标的聚合，本质是"权重要交给分母"。可复用清单：
- 凡是"X 率 / 人均 / 客单 / ARPU"，区间汇总默认用
SUM(分子)/SUM(分母)，不要用AVG(比率)。 - 简单平均只在"各期分母量级接近"时近似成立，且只能用于粗略趋势，不能进 KPI。
- 折线趋势图保留每日比率（观察序列），KPI 卡片用加权/汇总口径（聚合）——两者并存、各司其职。
- 同比/环比：两个区间各自加权后再算变化率，别用简单平均的差。
- 下钻再汇总：回到全局分子分母相加，禁止对子格子比率求平均。
- 指标平台层面：把"聚合方式（SUM/SUM vs AVG）"做成指标的显式字段，别藏在某个人的 SQL 里——口径漂移十有八九出在"藏在代码里、没人知道"。
最后一句可背的判据：能相加的量才能直接加，商不能加；要给商聚合，就回到分子分母各自先加、再除。