两个团队可能以不同方式统计同一类活动，却都没有算错。例如，一个团队报告本周计划进行的预约，另一个团队报告本周已经完成的预约。在会议上，两者都可能被称为“每周预约量”。共用的指标定义可以把这种歧义转化为业务方能够审查的决策，也给数据与设计团队提供具体的实现和测试对象。
本页内容
将仪表板与业务决策关联起来
先问清谁会使用信息、需要作出什么决定，以及多久需要一次。排班需要了解未来需求，而回顾已提供的服务需要查看已完成活动。这是不同的问题，可能需要不同的指标。应规定让每个数字具有意义的比较方式，例如与另一个等长报告周期比较。同时，明确总量变化时用户需要哪些明细。这样有助于避免仪表板堆积好看的图表，却无法回答团队真正的问题。
- 明确受众与决策。
- 区分未来需求与已完成工作。
- 定义报告周期及有用的比较方式。
写出定义，并用示例记录检验
示例指标：“本周已完成预约”统计计划开始时间位于约定本地周范围内，且当前状态为已完成的预约记录。它排除取消、未到场和仍未发生的预约。如果样本有 12 条记录，其中 8 条已完成、2 条已取消、1 条未到场、1 条尚未进行，那么结果为 8。这里统计的是预约次数，而不是去重客户数。如果一位客户到访两次，独立客户数回答的就是另一个问题。应请业务负责人确认这一区别。
- 数据源：已约定的预约数据集。
- 时间规则：使用业务时区下的预约计划开始时间。
- 周边界：记录选定的起始星期，并明确采用包含开始、不包含结束的时间区间。
- 修正规则：说明后续状态变更是否更新历史总量。
检查从数据源到报告的路径
追踪预约记录如何进入报告数据集。导入是否可能产生重复？状态更新是否可能在每日刷新后才到达？哪些字段可能缺失？应约定与指标定义相匹配的检查项。在此例中，稳定的预约标识符、有效的计划时间和可识别状态都很重要。检查失败时，应决定是标记问题、附说明排除受影响记录，还是等待修正。请指定负责人，而不是默默把不完整的数据输入视为完整。
- 将样本总量与源记录核对。
- 区分真实的零值与数据不可用。
- 记录预期刷新时间，并调查延迟更新。
让界面中的数字能够被解释
为指标提供准确名称，显示报告周期和最近一次成功更新时间。在总量附近给出简短定义，并在权限允许时提供查看相关记录的方式。如果筛选器改变统计人群或记录范围，应清楚显示当前筛选条件。可以请目标用户解释示例为何得到 8，以及之后完成的预约是否会改变结果，以此测试仪表板。如果回答需要分析人员重建隐藏规则，说明指标定义或展示方式仍需改进。