第1章：指标口径的定义与分类
1.1 用户场景：口径混乱引发的数据信任危机
某中型电商平台的数据产品团队每天早上都会收到业务部门的质疑：“DAU为什么又对不上？”。运营看板显示日活用户 126 万，管理驾驶舱却只有 98 万，而数据服务 API 返回的数值是 135 万。三个数字都声称来自“DAU”，但口径完全不同。产品经理被迫在每日数据巡检中花费 2 小时核对口径定义，数据产品的信任度持续下滑。
场景痛点：同一指标名称对应多个数值，业务方不知道该信哪个；数据产品原型（看板、报表、API）之间的口径无法追溯；口径变更后没有通知机制，下游消费方被动发现差异。
1.2 业务问题：无口径管理的数据产品是“空中楼阁”
从业务视角看，指标口径是数据产品的“契约”。当契约不透明或频繁变更时，数据产品就会丧失决策支撑能力。核心问题包括：
- 定义缺失：指标仅保留名称，没有业务含义、计算逻辑、数据来源的书面记录；
- 多版本混用：同一个指标在周报、月报、实时看板中使用不同口径；
- 变更无记录：口径调整后不通知消费方，导致历史数据与当前数据不可比；
- 责任不清：口径归属业务部门还是数据部门无明确界定。
业务后果：某出行平台因“订单取消率”口径在运营看板与财务看板不一致，导致补贴策略误判，单季度损失超 2000 万元。口径问题不是技术债，而是业务债。
1.3 需求拆解：三类口径的定义与区别
指标口径不是单一概念，而是从业务产生到数据呈现的三层映射。产品经理在设计原型前，必须区分三类口径：
| 口径类型 | 定义 | 所有者 | 变更频率 | 示例（DAU） |
|---|---|---|---|---|
| 业务口径 | 业务方对指标的业务含义和统计规则的描述，不涉及技术实现 | 业务产品经理 | 按季度 / 按活动周期 | “当日登录 APP 且完成至少一次页面浏览的去重用户” |
| 技术口径 | 将业务口径翻译为具体的字段、过滤条件、聚合逻辑的 SQL / 代码规则 | 数据开发 / 分析工程师 | 按迭代周期 | WHERE action='login' AND page_views >= 1 GROUP BY device_id |
| 数据口径 | 数据在存储、ETL、分层中的实际落地规则，包括数据源、时区、去重键、异常值处理 | 数据仓库工程师 | 按版本 / 数仓重构周期 | “ODS层 event_time 取 UTC+8，去重键为 device_id + date，过滤爬虫流量” |
产品经理须知：业务口径是“需求”，技术口径是“设计”，数据口径是“实现”。数据产品原型（看板、报表、API）的每个指标都必须同时挂载这三层口径，缺一层都可能导致数据歧义。
1.4 方案表达：三层口径管理框架
为解决口径混乱问题，数据产品原型设计需前置引入“三层口径管理框架”，作为需求文档的标准组成部分：
- 口径注册：每个指标在元数据平台注册时，必须同时填写业务口径、技术口径、数据口径三张卡片；
- 口径映射：原型中的每个可视化元素（卡片、图表、KPI 块）都挂载指标 ID，通过 ID 关联口径声明；
- 口径变更通知：任意一层口径变更后，自动推送影响分析报告给所有消费方原型的产品经理。
关键动作：产品经理在撰写数据产品需求文档（PRD）时，不再只写“显示 DAU”，而是写“显示 DAU（口径 ID：DAU-2025V1，业务口径见附录 A，技术口径见附录 B，数据口径见附录 C）”。
1.5 指标验证：口径一致性检查清单
在原型交付前，产品经理应使用以下清单验证口径一致性：
| 检查项 | 检查方法 | 通过标准 |
|---|---|---|
| 业务口径清晰度 | 随机抽取 3 名业务人员阅读口径描述 | 3 人对指标覆盖范围的理解完全一致 |
| 技术口径可执行性 | 开发人员按照口径独立编写查询 | 查询结果与口径描述的逻辑自洽 |
| 数据口径可追溯性 | 从数据产品反查 ETL 血缘 | 数据源、清洗规则、聚合粒度 100% 匹配 |
| 口径变更历史 | 查看口径管理平台的变更记录 | 每次变更都有业务方审批和消费方通知 |
1.6 验收标准
- 每个数据产品原型中的指标均有唯一口径 ID，且三类口径声明齐全；
- 口径文档通过业务方、数据开发、数仓三方会签；
- 口径变更后 24 小时内，所有下游原型收到影响范围报告；
- 原型上线后口径一致性抽检通过率 ≥ 95%。
1.7 交付物模板：指标口径定义卡
以下模板作为数据产品原型需求文档的必备附件，每指标一卡：
| 字段 | 内容要求 | 示例（DAU） |
|---|---|---|
| 指标名称 | 业务通用名称，避免技术缩写 | 日活跃用户数 |
| 口径 ID | 命名规则：指标英文名_版本号 | DAU_2025V1 |
| 业务口径 | 业务定义、统计对象、排除规则 | 当日登录 APP 且浏览 ≥ 1 页面的去重用户，剔除内部测试账号 |
| 技术口径 | 数据源表、过滤条件、聚合字段 | SELECT COUNT(DISTINCT device_id) FROM app_log WHERE action='login' AND page_views >= 1 AND is_test=0 |
| 数据口径 | 数据层级、时区、去重键、异常处理 | ODS 层，UTC+8，去重键 device_id+date，过滤爬虫 user_agent |
| 变更记录 | 日期 + 变更内容 + 审批人 + 通知范围 | 2025-04-01 增加爬虫过滤规则，审批人：张三，通知：运营看板/管理驾驶舱 |
使用建议：在原型设计工具（如 Figma、Axure）中，将口径 ID 作为元数据字段绑定到每个 KPI 组件上。原型导出时自动生成口径清单，无需手工维护。
1.8 案例简介：电商 DAU 口径之乱
本课程以“某电商平台 DAU 口径不一致”为贯穿案例展开。该案例的背景是：
- 运营团队定义 DAU 为“当日启动 APP 的所有设备去重”（业务口径）；
- 数据分析团队在 SQL 中额外过滤了“未登录用户”（技术口径与业务口径偏离）；
- 数仓团队在 ETL 层去重时误用了 device_id + session_id 作为联合键（数据口径错误）；
- 最终导致运营看板、管理驾驶舱、数据 API 三个原型产出的 DAU 值分别相差 15%~28%。