第2章 原始指标体系收集：数据来源、口径记录、版本标注、责任人确认

适用场景

本章适用于以下三类典型场景：

• 从0到1搭建新指标体系：项目初期从各业务系统抽取原始指标，需要建立统一的收集规范；
• 存量指标体系治理：对现有分散在Excel、数据仓库、报表工具中的指标进行集中盘点和清洗；
• 跨部门指标对齐：多个业务方（如运营、产品、财务）对同一指标口径存在分歧时，需通过标准化收集过程达成一致。

前置条件

进入本章操作前，需满足以下条件：

序号	前置条件	验收标准
1	已完成指标需求调研，输出《指标需求清单V1.0》	文档经PM和数据负责人签字确认
2	明确各业务系统数据源的可访问性	已获取数据库只读账号或API调用权限
3	指定至少2名专职数据采集员（1名采集、1名复核）	人员名单已录入项目任务管理工具
4	准备统一的《原始指标采集模板》（Excel或在线表格）	模板字段包含：指标名称、来源系统、表名/字段、口径说明、版本号、责任人、采集时间

操作步骤

本章包含4个核心步骤，按顺序执行，不可跳步：

1. 步骤1：数据源映射（Mapping）
   针对需求清单中的每个指标，定位其最原始的数据来源系统（如MySQL、Hive、API日志），并记录系统名称、库名、表名、字段路径。若来源为多表关联，需在口径说明中注明JOIN逻辑。
2. 步骤2：口径记录与版本标注（Definition & Versioning）
   逐指标编写清晰的计算口径，包含：聚合粒度（日/周/月）、业务筛选条件（如排除测试数据）、异常值处理方式（如剔除大于99分位值）。每版口径记录必须标注 V1.0、V1.1 等版本号，并说明变更原因。
3. 步骤3：责任人确认（RACI）
   每个指标需指定1名业务责任人（定义口径）和1名技术责任人（保障数据产出）。使用RACI矩阵明确角色：
   R（执行）：数据采集员；A（审批）：数据架构师；C（咨询）：原业务系统负责人；I（告知）：下游数据使用方。
4. 步骤4：采集结果复核（Review）
   采集员与复核员背对背填写同一指标的口径，然后比对差异率。差异率超过5%的条目需发起二次讨论，并记录在《口径争议日志》中。

输入输出物

类型	名称	格式	责任方
输入	《指标需求清单V1.0》	Excel / 在线表格	需求分析师
输入	业务系统数据字典（如适用）	PDF / 数据库文档	各系统DBA
输出	《原始指标采集表V1.0》	Excel / CSV	数据采集员
输出	《口径争议日志》	Markdown / Wiki	数据架构师

责任边界

记录材料

本章执行过程中必须保留以下记录材料，作为后续审计和复盘依据：

• 采集过程日志：记录每条指标的采集时间、采集人、复核人；
• 口径版本变更表：包含版本号、变更日期、变更内容简述、审批人；
• RACI确认邮件/IM截图：标注有“确认无误”或“同意”字样的沟通记录；
• 复核比对截图：采集员与复核员背对背填写的原始表格，以及差异率汇总

示例：口径争议日志条目
---
指标ID: M2024-028
指标名称: 7日活跃用户留存率
争议点: 分母是否包含“新增且当日无行为”的用户
采集员口径: 分母 = D0活跃用户中7日后仍有登录行为的用户 / D0所有活跃用户
复核员口径: 分母 = D0活跃用户中7日后有任意行为的用户 / D0所有活跃用户（包含新增无行为）
差异率: 12.3%
仲裁结果: 采用复核员口径，要求业务责任人补签确认
---

异常处理

验收标准

本章交付物需通过以下5项验收检查，全部通过后方可进入第3章：

• 完整性：采集表中已无空白必填字段，每个指标均填写了数据来源（系统/表/字段）、口径说明、版本号、责任人；
• 一致性：随机抽取10%的指标，由不参与采集的第三方使用同一口径在源系统中重新计算，结果偏差率<2%；
• 可追溯：每个指标的口径变更历史均有版本号和对应审批记录，无断档；
• 责任清晰：各指标的RACI矩阵已全员签字或邮件确认，无“无人认领”指标；
• 文档存档：《原始指标采集表V1.0》已被上传至项目Wiki并设置禁止直接编辑权限。