同一个"日活"三个数：DAU 口径分裂的 4 类根因与一份 30 行指标字典模板

作者许砚舟-810

指标体系数据口径DAU指标字典数仓

结论先行：同名指标在不同报表里跑出 3~5 个不同的数，90% 不是 SQL 写错，而是「口径」没对齐。本文以一个真实的电商 App DAU 案例，给出 4 类根因、一份 30 行指标字典模板，以及 3 段可直接复用的 SQL。

一、现象与背景

去年 Q3，我们接手一个日活约 130 万的电商 App，做了一次指标盘点，结果非常尴尬：

运营周报的 DAU：128 万
增长团队的 DAU：142 万
算法离线评估的 DAU：135 万
财务给董事会的 DAU：119 万

同一个词，四个数，最大差 19%。更糟的是——每个数背后的业务动作都不一样：运营按 128 万排活动预算，增长按 142 万算拉新 ROI，算法按 135 万算模型覆盖度，财务按 119 万报 ARPU。任何两个团队开一个对齐会，都会先花 40 分钟吵「到底哪个数是对的」，最后谁都不改，各算各的。

日志侧的规模：App 端埋点日志日增 4.3 亿行，活跃用户表 dws_user_active_di 约 5800 万行/日，一次全表 COUNT(DISTINCT user_id) 在 MaxCompute 上要跑 42s——口径一旦改错，返工成本不只是「重跑一下」，而是「重跑一下 + 重开一次会 + 重报一次数」。

二、根因分析：DAU 口径分裂的 4 类来源

把 4 份报表的 SQL 拉出来 diff，差异全部落在 4 个维度上，没有一处是模型或数据源本身的问题：

活跃定义不同（登录 vs 访问 vs 下单） 运营口径是「当日调用过 /user/login 或 /user/profile」；增长口径是「当日有任意埋点事件」；财务口径是「当日有支付或浏览商品详情」。活跃定义不同，DAU 天差地别，这是 80% 口径分裂的根因。
去重键不同（user_id vs device_id vs utdid） 一个用户换机、一个设备多账号，COUNT(DISTINCT user_id) 和 COUNT(DISTINCT device_id) 差 3%~7%。我们实测：user_id 口径 132 万，device_id 口径 141 万，差 90 万。
时区与「日」的边界不同 App 端 SDK 用 UTC 上报，服务端按 UTC+8 落库，日志里 event_time 是 UTC，log_time 是 UTC+8。用哪个字段切「日」，DAU 会差 2%~4%，跨零点前后 2 小时的流量是重灾区。
测试 / 机器人 / 灰度账号是否剔除 增长团队默认不剔除（要看到「全量拉新效果」），财务默认剔除（要看到「真实业务」），算法默认保留（要看到「全量样本」）。这一项在我们案例里贡献了 3.8% 的差异（约 5 万账号）。

机制层面：这四类差异本质上是「指标的三要素——分子、分母、时间窗」在团队间没有对齐。SQL 只是把口径翻译成代码，口径没定义，代码写得再对也是错的。

三、具体做法：一份 30 行的指标字典模板 + 3 段 SQL

3.1 指标字典模板（Markdown，可直接贴到 wiki）

metric_name: DAU
business_owner: 增长负责人
data_owner: 数仓 A 组
version: v1.3        # 口径变更必须升版本
effective_date: 2025-04-01

definition:
  numerator: 当日（UTC+8）内，App 端产生 ≥1 条「有效事件」的去重 user_id 数
  denominator: null  # 比值型指标才填
  time_window: 自然日 00:00:00 - 23:59:59 (UTC+8)
  dedup_key: user_id # 明确写死，不写「用户」
  event_scope:
    include: [app_start, page_view, click, order_create]
    exclude: [test_event, debug_event]
  filters:
    - is_test_account = 0
    - is_bot = 0
    - client_version >= '2.4.1'   # 老版本埋点丢失率高，剔除

data_source:
  table: dws.dws_user_active_di
  partition: ds='${bizdate}'
  note: 已按 user_id 去重，字段 active_cnt 表示当日事件数

sla:
  ready_time: 09:30 (UTC+8)
  latency_p99: 42s   # 一次 COUNT 全表耗时

change_log:
  - v1.0 2024-11  初版，含测试账号
  - v1.1 2025-01  剔除 is_bot=1
  - v1.3 2025-04  明确时区为 UTC+8，dedup_key 固定 user_id

要点：dedup_key、time_window、event_scope、filters 四项是必写项，任何一项模糊，指标就注定分裂。

3.2 用字典生成 DAU 的标准 SQL（MaxCompute 语法）

-- 口径 v1.3：DAU = 当日有效事件去重 user_id
SELECT
    ds,
    COUNT(DISTINCT user_id) AS dau
FROM dws.dws_user_active_di
WHERE ds = '${bizdate}'
  AND is_test_account = 0
  AND is_bot = 0
  AND client_version >= '2.4.1'
  AND event_name IN ('app_start','page_view','click','order_create')
GROUP BY ds;

3.3 口径 diff 诊断 SQL（找出 4 类根因贡献度）

-- 一次跑完，看每个口径差异贡献多少
SELECT
    COUNT(DISTINCT user_id)                                          AS dau_all,
    COUNT(DISTINCT IF(is_test_account=0, user_id, NULL))             AS dau_no_test,
    COUNT(DISTINCT IF(is_bot=0,        user_id, NULL))               AS dau_no_bot,
    COUNT(DISTINCT IF(client_version>='2.4.1', user_id, NULL))       AS dau_new_sdk,
    COUNT(DISTINCT IF(event_name IN ('app_start','page_view','click','order_create'),
                      user_id, NULL))                                 AS dau_scope
FROM dws.dws_user_active_di
WHERE ds = '${bizdate}';

我们实测这段 SQL 跑一次约 55s，输出 6 个数，团队对齐会 15 分钟就能定位到「差异来自哪一项」，比之前 40 分钟吵架快得多。

四、踩过的坑与反直觉之处

「活跃」这个词最危险——它不是指标，是口径的占位符。任何指标字典里出现「活跃用户」而不写清「活跃 = 什么事件」，等于没写。
时区坑最隐蔽：event_time 和 log_time 差 8 小时，WHERE event_time >= '2025-04-01' 和 WHERE log_time >= '2025-04-01' 结果差 2.7%。必须只允许一个字段做时间切片，字典里写死。
老版本 SDK 是隐形分母：v2.4.1 之前埋点丢失率约 12%，如果不剔除，DAU 会被「虚高」（事件少→去重后反而低？不，是事件少→部分用户当天 0 事件→被漏计）。剔除老版本 SDK 后 DAU 反而上升 1.3%，这个反直觉结果我们踩了两个月才发现。
字典必须带版本号与生效日期：一次口径变更没升版本，导致 3 周后回看历史数据时对不上，返工 2 人日。
COUNT(DISTINCT) 不是免费的：5800 万行全表跑 42s，一个 BI 看板 8 个卡片就是 8 次全表扫描，必须走物化视图或预聚合表，否则口径再对，看板也打不开。

五、结论与可复用清单

结论：指标分裂不是「数据问题」，是「口径问题」；口径问题的本质是三要素（分子 / 分母 / 时间窗）没有唯一、版本化、可追溯的定义。字典 + 版本号 + 标准 SQL 三件套，能把 90% 的口径冲突挡在会议之外。

可复用清单（可直接抄）：

[ ] 每个对外指标必须有：name / version / effective_date / owner
[ ] 必写四项：dedup_key、time_window、event_scope、filters
[ ] 时区只允许一个字段做切片，字典里写死
[ ] 每次口径变更必须升版本 + 记 change_log
[ ] 配一段「标准 SQL」和一段「diff 诊断 SQL」，让口径可执行、可验证
[ ] 大表指标走物化视图，别在 BI 里裸跑 COUNT(DISTINCT)
[ ] 对齐会前先跑一次 diff SQL，15 分钟定位根因，别靠嘴

一句话：指标字典不是文档，是口径的合同。合同没签，后面所有数都是吵架的燃料。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。