指标一：新鲜度
统计从源系统产生变更到目标可用之间的时延分布，而不只是平均值。为什么看分布：平均值正常但长尾很长时，业务会在特定时点拿到过期数据，问题往往集中在月末与月初，平均值看不出来，指标口径要固定。
指标二：完整率
计算成功入库记录占应入库记录的比例，并把解析失败、字段缺失、类型异常分别计数。怎么做：异常率按数据源拆分，才能看出是哪条链路在持续掉数据，总量口径会把局部问题完全掩盖，异常要能追到源头。
指标三：口径一致率
抽取同一业务问题，比对源系统报表与接入后查询结果是否一致。为什么重要：数据都进来了但口径不同，会得出不同结论，这类问题比缺数据更难发现，也更难向业务解释清楚，比对结果要留档备查。
指标四：下游问题数
统计因数据问题导致的业务返工、误判与投诉数量，按来源归类。怎么做：把每次问题关联到具体字段与任务，形成问题、字段、修复的闭环记录，避免同类问题反复发生却无人负责，问题要有人认领并定期复盘。
基线与告警阈值
先积累自身历史数据形成中位数与波动范围，再据此设定告警阈值。边界：不同业务对新鲜度的要求差异很大，不应套用外部通用数值作为验收标准，也不应用别人的数据承诺自己的时效，阈值要定期校准。
适用与不适用
适合谁
- 数据接入已上线、需要持续运营的项目
- 数据团队要向业务证明接入价值的组织
- 下游频繁反馈数据问题的平台项目
不适合谁
- 尚未接入真实数据、仍在开发阶段
- 只做一次性导出、无持续同步的场景
典型场景
某物流企业的运单知识库接入后，运营发现月末回答经常引用过期时效。数据团队把新鲜度从平均值改为分布统计，定位到月末批量关账导致同步延迟，调整调度顺序后长尾明显缩短，问题工单随之减少，调度规则也随之调整。
可执行步骤
- 采集从源系统变更到目标可用的时延，输出分布并重点关注长尾部分。
- 按数据源拆分统计完整率，并分别统计解析失败、缺失与类型异常。
- 定期抽取同一业务问题，比对源系统报表与接入后查询结果的口径。
- 记录下游返工与误判事件，并逐条关联到具体字段与同步任务编号。
- 积累自身历史数据形成中位数与波动范围，再据此设定告警阈值与频次。
常见坑
- 只看平均时延、忽略长尾分布，月末与月初的问题反复出现却找不到原因，最后只能靠值班人经验兜底。
- 完整率按总量统计，掩盖了某个单一数据源的持续缺失，问题被平均掉，直到业务自己发现。
- 数据都接进来就认为完成，不核对口径，查询结论与业务事实相反，还以为是模型的问题。
- 套用外部通用阈值设置告警，频繁误报后团队干脆整体关闭告警，监控彻底形同虚设，恢复监控又要一轮沟通。
自检与验收清单
- 是否统计时延分布并关注长尾，而不是只看均值
- 完整率与异常率是否按数据源拆分统计并对比
- 是否定期抽取同一业务问题，核对两边的口径
- 下游问题是否关联到具体字段、任务与责任人
- 告警阈值是否基于自身历史基线设定并定期复核
常见问题
新鲜度要求多高？
由业务决定：库存与价格类通常要求分钟级，报表与档案类可按日。把要求写进接入说明并据此设计调度，而不是先接再问。要求越高，系统复杂度与运维成本越高，需要业务方明确取舍。
口径不一致以谁为准？
以业务确认过的口径表为准，并回溯修正另一方。若两边都有合理性，应保留两套口径并明确标注适用场景，避免在同一张报表里混用导致结论矛盾，也避免口径反复变动，先统一样本口径。
数据问题要不要计入考核？
可以按发现到修复的时长与复发次数考核，而不是简单统计问题数量。只考核数量会诱导隐瞒，考核修复效率才能真正推动数据质量改善，也更容易被业务方接受，并留出解释口径的余地。