第4章 指标口径定义规范：六要素模型
指标口径是产品数据分析的“宪法”——同一指标名称，若口径不一致，不同团队的计算结果可能相差数倍，导致决策偏差。本章构建六要素口径定义规范，确保指标可复现、可追溯、可对齐。
4.1 六要素一览
| # | 要素 | 定义 | 典型输出 |
|---|---|---|---|
| 1 | 业务定义 | 用业务语言描述指标含义、用途、边界 | “日活跃用户：当天至少打开App一次的用户，去重计数” |
| 2 | 技术口径 | 明确数据采集、ETL、聚合的精确规则 | 埋点事件名、字段映射、过滤条件 |
| 3 | 计算逻辑 | 算法公式、窗口函数、去重键 | COUNT(DISTINCT user_id) WHERE event='app_open' |
| 4 | 数据源 | 原始表、中间层、数据仓库路径 | dw.dws_user_act_di |
| 5 | 更新频率 | 数据产出周期与有效期 | T+1 每天凌晨2点刷新 |
| 6 | 责任人 | 数据生产方与业务方回访联系人 | @李四（数据组），@王五（产品组） |
4.2 业务定义：让非技术人员也能理解
业务定义必须回答：“这个指标衡量什么？在什么场景下使用？排除哪些情况？”。避免模糊表述，例如“活跃用户”可拆分为“启动时活跃”、“页面停留>5秒的活跃”、“有视频播放行为的活跃”，口径必须唯一。
示例：DAU业务定义
“日活跃用户（DAU）：在自然日 00:00:00-23:59:59（UTC+8）内，用户通过手机号或微信账号登录后，至少完成一次任意页面浏览（不包括后台启动或静默状态），且用户ID有效（非测试号、内部白名单）。”
“日活跃用户（DAU）：在自然日 00:00:00-23:59:59（UTC+8）内，用户通过手机号或微信账号登录后，至少完成一次任意页面浏览（不包括后台启动或静默状态），且用户ID有效（非测试号、内部白名单）。”
4.3 技术口径：埋点与ETL规则
技术口径将业务定义翻译为可执行的工程规范：
- 事件名：
app_page_view、app_launch - 属性过滤：排除
is_debug=1、platform='postman' - 会话窗口：30分钟无操作则切断session
- 幂等性：同一event_id重复上报时去重方案
4.4 计算逻辑：SQL/代码样板
计算逻辑必须可复现。以下为DAU的标准SQL示例：
-- 表名称：dw.dws_user_act_di
-- 分区：dt = '2026-04-01'
SELECT COUNT(DISTINCT user_id) AS dau
FROM dw.dws_user_act_di
WHERE dt = '2026-04-01'
AND event_name IN ('page_view', 'app_launch')
AND is_valid_user = 1
AND user_id NOT IN (SELECT test_id FROM dim.test_users);
4.5 数据源与更新频率
| 数据层 | 表名 | 更新频率 | 数据延迟 |
|---|---|---|---|
| ODS（原始数据） | ods.app_event_log_di | 实时+离线T+1 | ≤10min（实时）；凌晨3点全量 |
| DWD（明细） | dwd.app_user_act_di | T+1 | 凌晨4点 |
| DWS（聚合） | dw.dws_user_act_di | T+1 | 凌晨6点 |
4.6 责任人：指标治理的闭环
每个指标必须指定两个角色：数据生产者（保证数据质量和时效）和业务负责人（定义口径变更的最终审核）。当指标出现异常时，由业务负责人启动复盘流程，数据生产者提供技术根因。
常见陷阱： 口径变更不通知、历史数据不回刷、责任人过期。建议每季度进行一次口径审计，在数据字典中记录变更日志。
最佳实践： 将六要素录入数据字典工具（如Confluence、Notion或Airbnb的Dataportal），每个指标卡片均包含上述6项，并支持版本回溯。团队应每月开展“口径对齐评审”，确保新指标上线时无误。
本章定义的六要素规范是后续维度拆解（第5章）和看板结构（第6章）的基础。每个看板指标都必须在数据字典中维护完整的六要素卡片，否则不允许多团队共享使用。