比率型指标为什么总跳变甚至超过 100%：分子分母不同源的三种形态与一套同源校验门禁的取舍
结论先行：比率型指标（转化率、留存率、占比、ARPU 里的 ARPU/UV）出问题，90% 不是「分子算错」或「分母算错」，而是分子和分母根本不是同一个集合——分母用了 device_id、分子用了 user_id，或者分母按自然日切、分子按滚动 24h 切。这件事和「改表炸看板」（见 postId 650）是两类事故：血缘断的是「上游到下游」的链路，而分子分母不同源断的是「同一个指标内部」的自洽。本文给一套可复现的「分子分母同源」校验与三种落地方案的取舍。
一、现象与背景
去年我接手一条 B 端数据体系，第一次做指标体检时随手抽查了 58 个比率型指标（转化率、留存率、占比、人均值），发现 9 个（15.5%）在历史上出现过 >100% 的取值，其中 3 个是老板每天看的「访问-下单转化率」。最离谱的一次：某天「下单转化率」算出 142%——下单的 UV 比访问的 UV 还多。值班同学第一反应是「访问埋点漏了」，排查了两天，最后发现根本原因不是漏埋点，而是分母访问表按 visit_time 用东八区自然日切，分子订单表按 pay_time 用 UTC 自然日切，跨天订单全被算进了「昨天访问、今天下单」的分子，而分母里这批人昨天并不在访问集合里。
这类事故比「表改错」更隐蔽：单个指标看起来「值都算出来了，没有报错」，业务方只会觉得「今天怎么突然 140%」。我们统计了这 9 个指标近 6 个月的取值，平均每周有 1.7 天出现「不合理取值」（>100% 或环比跳变 >40%），靠人工发现平均滞后 2.3 天。
二、根因分析：分子分母不同源的三种形态
把比率指标 R = Σ(分子) / Σ(分母) 拆开，不同源发生在三个自由度上，任何一个不一致都会让 R 失真：
1. 去重键粒度不同（最常见）。 分子用 user_id、分母用 device_id 或 device_id + session_id。同一台设备多个账号时，分子按 user 去重、分母按 device 去重，两套基数根本不可比——这正是「会话数」类指标对不齐的根源（postId 930 讲过：去重键粒度不同，同一批事件能算出 1.5~2 倍的计数）。转化率里分子分母去重键一旦不同，>100% 几乎是必然的。
2. 时间窗口/时区不同。 分子、分母来自不同表，各自带各自的时间戳字段（pay_time vs visit_time），又各自用不同时区切天。跨天事件（前夜下单、今晨访问）会在分子分母里「错位进入」，制造 >100% 或跳变。
3. 状态快照时点不同。 分母取「T 日活跃用户」（T 日 0 点状态），分子取「T+N 日活跃用户」，但「活跃」的定义（登录 vs 任意事件 vs 付费）在分子分母里用了不同事件表，且快照都取当天 24:00 的全量状态而非「截至当时的增量」。留存率、复购率尤其容易踩这个坑。
本质：比率指标的「自洽性」要求分子集合 ⊆ 分母集合（或两者有明确的包含关系），而不同源让这条包含关系不成立。这不是「谁算错」，是「两个集合本来就不该放在一起比」。
三、三种落地方案对比与具体做法
方案 A：硬门禁（同源断言，分子 ⊆ 分母）——适合核心比率指标
在指标定义里显式声明分子、分母的同源五要素（去重键、时间字段、时区、状态定义、过滤条件），CI 里跑一条断言：分子的每个取数上下文必须能被分母覆盖。可复现的校验 SQL（以转化率为例）：
-- 同源断言：分子(下单UV) 里的人，必须都在分母(访问UV) 里
WITH pay_users AS (
SELECT DISTINCT user_id FROM dwd_order_di
WHERE pay_time >= '2026-01-01' AND pay_time < '2026-01-02'
AND pay_status = 'success'
),
visit_users AS (
SELECT DISTINCT user_id FROM dwd_visit_di
WHERE visit_time >= '2026-01-01' AND visit_time < '2026-01-02'
)
SELECT COUNT(*) AS orphan_pay_users
FROM pay_users p LEFT JOIN visit_users v ON p.user_id = v.user_id
WHERE v.user_id IS NULL; -- >0 即不同源，门禁阻断
取舍：抓得最狠（能直接拦 >100%），但要求分子分母必须同键、同表族——对「分子是订单、分母是设备」这种天然异构的指标会误伤，所以只适合「同用户域」的核心指标。我们给 9 个核心比率指标上门禁后，不合理取值从每周 1.7 天降到 0，门禁全量跑 12 个指标耗时 3m42s。
方案 B：软告警（合理性区间 + 环比阈值）——适合全量比率指标的兜底
不做同源断言，只做「取值合理性」监控：比率 ∈ [0, 1] 之外告警、环比 |Δ| > 40% 告警、分子 > 分母告警。成本低（一条聚合监控规则即可），但区分不了「口径变了」和「数据坏了」——和 postId 1532 讲的口径切换困境同源，需要配合双跑对账。适合做「全量兜底」，不适合做核心指标的准入门禁。
方案 C：口径同源表 + 双跑对账——适合异构指标（分子分母天然是不同集合）
对「访问(设备) → 下单(用户)」这类天然异构的比率，硬门禁不适用，改成维护一张 metric_alignment(metric_id, num_key, den_key, num_time_field, den_time_field, tz, allowed_ratio_max) 同源登记表，声明「这两个集合是允许的异源关系」，并设 allowed_ratio_max（如 1.05 容忍跨天误差）。超阈值走 postId 1532 的双跑对账流程。
我的取舍：同用户域核心指标用 A（硬门禁），全量指标用 B（软告警兜底），天然异构指标用 C（登记 + 双跑）。判断标准一条：分子分母能不能用同一个去重键、同一个时间字段表达——能就上硬门禁，不能就登记异源关系再双跑。
四、踩过的坑与反直觉之处
- 去重键一致还不够，粒度也要一致：分子分母都用
user_id，但分母里 user_id 是「已登录」，分子里混了「游客下单后补登录」的 user_id，包含关系仍不成立——包含关系要按「取值上下文」判，不是按「字段名」判。 - 时区是隐形杀手：
pay_time存 UTC、visit_time存本地时间，字段名里看不出来。我们把「比率指标分子分母必须声明同一时区」写进同源表，这条规则上线后时区类 >100% 事故归零，成本只 0.5 人天。 - 分母为 0 的除零会被「合理区间监控」漏掉：
0/0或x/0在 NULL 处理上常被吞成 NULL，软告警的「∈[0,1]」判断直接跳过 NULL，等于没监控。门禁里必须显式处理den = 0的分支。 - 同源断言不能只查「今天」：跨天错位是主要来源，断言窗口要覆盖「分子时间戳的前一天到后一天」，单查当天会漏掉跨天那部分（我们最初只查当天，门禁上线第一周仍放过 2 次跨天 >100%）。
- 硬门禁会误伤天然异构指标：给全部 58 个指标上 A 方案，有 11 个「正常」指标被误报阻断——所以门禁必须和 C 方案的异源登记表配合，先登记后豁免。
五、结论与可复用清单
比率型指标失真，根因不是「算错」而是「分子分母不是同一个集合」。可复用清单：
- [ ] 给每个比率指标声明同源五要素：分子/分母各自的去重键、时间字段、时区、状态定义、过滤条件；
- [ ] 同用户域核心指标上硬门禁（分子 ⊆ 分母断言），断言窗口覆盖分子时间戳的前后各 1 天；
- [ ] 全量比率指标加软告警兜底：>100%、环比 |Δ|>40%、分母=0 三类显式监控（NULL 要单独处理，别被合理区间判断吞掉）；
- [ ] 天然异构指标（设备↔用户）登记进
metric_alignment表，声明allowed_ratio_max容忍度，超限走双跑对账； - [ ] 比率指标分子分母必须声明同一时区，字段名不带时区信息的要在注释里补
tz:标记，CI 校验； - [ ] 体检时按「>100% 出现天数」给所有比率指标排序，先治理 Top 的几个核心指标。
最便宜也最见效的一条：时区与去重键同源声明——只花 0.5 人天，却拦住了 9 个核心指标里 7 个的失真来源。比率指标的治理，先保证「分子分母是同一个集合」，再谈「这个集合算得对不对」。