Copilot 用量接口新增数据缺失诊断

Copilot 报表里有活跃用户，却缺少代码行数、功能或模型使用明细，未必是用户没用。GitHub 为 usage metrics API 新增了遥测和版本诊断字段，帮助企业定位数据缺口。

这次更新解决的是「报表为什么不完整」。对维护团队 Copilot 看板的人来说，关键是能分清缺数据、版本不达标和真实的零使用，避免统计口径出错。

用户活跃，为什么还会缺少使用明细

Copilot 能识别到用户活动，不代表编辑器里的使用事件已经送达。缺少客户端遥测的用户仍计入活跃用户，但报表会缺少代码行数、功能分类和模型分类等细节。

新增的两个用户字段分别回答不同的问题：

• client_telemetry_present 表示当天是否收到该用户的客户端遥测。false 表示 Copilot 看到了用户活动，但没有收到编辑器发来的使用事件。
• usage_metrics_requirements 列出用户各个 IDE 和 Copilot 扩展是否达到使用指标要求的最低版本，状态为 met、unmet 或 unknown。

常见原因包括编辑器或扩展过旧、IDE 遥测被关闭，以及代理或防火墙阻断事件上报。

版本达标和遥测送达是两个独立信号。

一个用户的所有版本都符合要求，仍可能因代理问题缺少遥测。因此，不能看到 met 就认定报表完整，也不能看到遥测缺失就直接要求升级。原文没有给出具体最低版本号，需要另行查阅对应要求。

新增人数能定位范围，但不能直接相加

API 同时增加了两个每日计数：

• missing_client_telemetry_user_count：当天 client_telemetry_present 为 false 的用户数。
• below_usage_metrics_minimum_user_count：当天至少有一个 IDE 或扩展低于最低版本要求的用户数。

它们用于判断影响范围，用户字段则帮助找到需要跟进的人。这样，管理员可以先自行排查，不必一开始就提交支持工单。

但有两个统计陷阱。同一个用户可能同时进入两个计数，相加会重复统计；同一个用户也可能连续多天出现，所以把每天的人数相加，得不到跨天去重人数。

字段覆盖范围也有区别。用户字段出现在企业和组织的 1-day、28-day 用户报表中；人数计数出现在企业和组织的 1-day 报表，以及 28-day 报表的每个 day_totals 条目中。28 天报表里的这些计数依然按天计算。

null 或字段缺省表示数据不可用，不能当成 false 或 0。

此次发布之前的日期没有这些值。若把历史空值补成零，图表就会制造出一段并不存在的「没有异常」时期。

我的判断

这次更新的价值在于，让使用量报表多了一层数据完整性诊断。分析代码行数或模型使用分布之前，先确认事件有没有送达，比直接解释数字高低更可靠。

不过，这些字段提供的是排查线索。遥测缺失并不能单独证明是代理、设置还是版本导致的，版本不达标也不能直接证明它造成了全部数据缺口。原文没有提供排查效率的对照数据，也没说明新增字段能找回多少缺失明细，因此不能把「可以自行定位」理解成「能够自动修复」。

访问也有前提：必须启用 Copilot usage metrics policy。可访问者包括企业所有者、企业账单管理员、组织所有者，以及拥有 View Copilot Metrics 权限的自定义组织或企业角色。普通团队成员未必能直接获取这些信息。

能拿来做什么

• 维护前端或全栈团队的 Copilot 看板时，把每日使用指标和遥测缺失人数一起展示；明细下降时，先检查数据是否完整，再讨论使用行为变化。
• 在 Node 数据处理脚本中保留 null、字段缺省和明确布尔值的区别，避免用默认值把「未知」变成「正常」。
• 排查个人报表缺失时，同时检查版本状态和遥测状态，再核对 IDE 遥测设置、代理及防火墙；跨天统计受影响人数时，应基于可用的用户级数据去重，不能累加每日人数。