Copilot使用情况指标 API 不会发布单个预先聚合的团队报表。 团队级指标通过加入 用户团队 报表（其中列出了每个用户的团队成员身份为给定日期）和 每用户使用情况指标 报告（其中包含当天每个用户 Copilot 的活动）来构造。 按 team_id 对联接后的行进行聚合会生成团队级指标。
同一种联接方法支持你所需的任何团队层级切分方式：按(team, day)、按(team, day, language)、按(team, day, IDE)、按滚动窗口等。
正在获取报告
本指南中引用的两个报告分两步下载。 首先，为所需日期调用 REST 终结点。 终结点返回时间限制的签名 URL，可从中下载报表文件。 然后下载这些 URL 指向的 JSON 文件。 用户团队和每个用户对应的行都在这些 JSON 文件中；REST 端点不会以内联方式返回它们。
| 报表 | 终结点 |
|---|---|
| 组织用户团队 | GET /orgs/{org}/copilot/metrics/reports/user-teams-1-day?day=YYYY-MM-DD |
| 企业用户团队 | GET /enterprises/{enterprise}/copilot/metrics/reports/user-teams-1-day?day=YYYY-MM-DD |
| 组织的每用户使用指标 | GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD |
| 企业每位用户使用指标 | GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD |
每个端点都返回如下形式的响应：
{
"download_links": [
"https://example.com/copilot-user-teams-report-1.json"
],
"report_day": "2026-05-07"
}
在链接有效期内，从每个 URL 下载文件，以获取该报表的各行数据。
有关完整的请求和响应架构、身份验证要求和相关终结点，请参阅 用于 Copilot 使用情况指标的REST API终结点。 有关如何定义单个使用情况指标字段的概述，请参阅 Copilot使用情况指标中提供的数据。
对于多日时间窗口，每天调用一次每日端点，并汇总每天的结果。 请参阅下面的 “生成滚动窗口”团队报告 。
涉及的报告
团队级指标来自加入两个报表系列：团队成员身份的用户团队报告，以及活动的每个用户使用情况指标报告。
用户团队报告
这些报告在给定的某一天列出每个用户的团队成员身份。
| 报表 | Scope | 关键字段 |
|---|---|---|
organization_user_teams_1_day | 当天的组织团队成员身份。 仅包括组织中的团队。 | |
user_id、user_login、day、organization_id、team_id、slug | ||
enterprise_user_teams_1_day | 企业团队当天的成员身份。 包括企业团队和业务团队。 | |
user_id、user_login、day、enterprise_id、team_id、slug |
同一天属于多个团队的用户会显示为多行，每个 (user, team) 对应一行。
重要
已分配席位的用户少于 5 个的团队将被排除在用户团队报告之外。
影响：
- 在给定日期，已分配席位的用户少于 5 个的团队不会出现在当天的用户团队报告中，即使其成员有 Copilot 活动也是如此。 该活动仍显示在按用户划分的使用指标报告中，但在联接结果中没有对应的团队行。
- 在多天时段内越过阈值的团队在一段时间内存在，而其他团队则不存在。 只有团队高于阈值的天数才会计入其总数。
- 如果将团队行汇总在一起，以便与企业或组织总数进行比较，则总和低于实体总数。 这里的缺口，指的是那些仅属于未达到阈值的团队的用户所产生的活动——他们在连接结果中没有对应的团队行，因此其活动未体现在任何团队聚合结果中。
每位用户使用情况指标报告
这些报告包含给定一天每个用户 Copilot 的活动。
| 报表 | Scope | 关键字段 |
|---|---|---|
organization_users_1_day | 每个 (user_id, day, organization_id) 一行，包含该组织中用户当天的 Copilot 活动。 | |
user_id、、day、organization_id``enterprise_id活动计数器、细分数组 | ||
users_1_day | 每个 (user_id, day, enterprise_id) 一行，表示该企业中用户当天的 Copilot 活动。 | |
user_id、day、enterprise_id、活动计数器、细分数组 |
有关这些报表中可用的字段的完整列表，请参阅 Copilot使用情况指标中提供的数据。
警告
请勿将滚动 28 天的按用户划分报告（users_28_day、organization_users_28_day）与每日用户团队报告联接。 用户-团队报告反映的是某一天的团队成员归属情况，因此，如果将 28 天的活动数据与单日成员归属快照进行联接，那么这整整 28 天的活动都会被归因到该用户在联接当日恰好所属的团队。 每当窗口期间团队成员身份发生更改时，此错误将活动归咎于错误的团队。 始终先将每日活动数据与每日用户团队数据关联起来，然后再按所需的时间窗口进行聚合。
实体级报表
实体级报表（enterprise_28_day、、organization_28_day、enterprise_1_day``organization_1_day）是整个企业或组织的预聚合总计。 它们既不包含 user_id，也不包含 team_id，因此无法与用户团队报告关联以生成按团队划分的明细。 当您需要企业或组织层面的总计时，请直接使用它们；对于团队层面的总计，请使用下面所述的 daily user-teams 与 daily per-user-metrics 的关联。
示例
此最小端到端示例生成一天的组织团队指标。 对于每个输入报表，下面显示的 JSON 是一个示例，展示了从该报表的某个 download_links 下载的文件中会找到的行（请参阅上面的 获取报表）。
两个用户在组织 999 中于 2026-05-07 有 Copilot 活动：
- 爱丽丝 （
user_id=1001）当天属于两支球队：frontend（team_id=42）和backend（team_id=43）。 - 鲍勃 （
user_id=1002） 只属于frontend（team_id=42） 。
输入: organization_user_teams_1_day
{"user_id": 1001, "user_login": "alice", "day": "2026-05-07", "organization_id": "999", "team_id": 42, "slug": "frontend"}
{"user_id": 1001, "user_login": "alice", "day": "2026-05-07", "organization_id": "999", "team_id": 43, "slug": "backend"}
{"user_id": 1002, "user_login": "bob", "day": "2026-05-07", "organization_id": "999", "team_id": 42, "slug": "frontend"}
Alice 会显示两次——她所属的每个团队各占一行。
输入: organization_users_1_day
{"user_id": 1001, "user_login": "alice", "day": "2026-05-07", "organization_id": "999", "enterprise_id": "13213",
"user_initiated_interaction_count": 50, "code_generation_activity_count": 40, "code_acceptance_activity_count": 12,
"loc_suggested_to_add_sum": 200, "loc_added_sum": 88, "used_chat": true, "used_agent": true, ...}
{"user_id": 1002, "user_login": "bob", "day": "2026-05-07", "organization_id": "999", "enterprise_id": "13213",
"user_initiated_interaction_count": 30, "code_generation_activity_count": 25, "code_acceptance_activity_count": 7,
"loc_suggested_to_add_sum": 80, "loc_added_sum": 24, "used_chat": true, "used_agent": false, ...}
每 (user, day, organization)行一行。 活动总数为当天所有界面的汇总值。
连接并聚合后的结果
基于 (user_id, day, organization_id) 对两个报表执行内联接，然后按 team_id 分组并聚合。 下面的 active_users 列是聚合输出（COUNT(DISTINCT user_id)），而不是每个用户报表上的字段;其余数值列是匹配报表字段的总和。
| team_id | 鼻涕虫 | 活跃用户 | 代码接受活动数量 | loc_added_sum |
|---|---|---|---|---|
| 42 | frontend | 2 | 19 | 112 |
| 43 | 后端 | 1 | 12 | 88 |
两条团队-日期行，每个团队一条。 该 frontend 行聚合 Alice 和 Bob 的活动。 该 backend 行仅包含 Alice 的活动。
Alice 的活动对 两 个团队都做出了贡献。 12 和 88 来自她所在行的计数，并且在 frontend 和 backend 中各出现一次。 这符合团队级指标的设计意图——每个团队都能看到其成员的活动情况——但如果将这两行团队数据再汇总为单个组织总计，就会对 Alice 进行重复计数。 对于组织总数，无需用户团队加入即可直接查询 organization_users_1_day 。
如何构建团队级指标
对于任何团队层面的划分，同样适用这四个步骤。
-
选取报表对。
- 对于组织团队，请将
organization_user_teams_1_day与organization_users_1_day配对。 共享实体 ID 为organization_id. - 对于企业和业务团队，请将
enterprise_user_teams_1_day与users_1_day搭配使用。 共享实体 ID 为enterprise_id.
- 对于组织团队，请将
-
将两个报告基于
(user_id, day, entity_id)进行内连接。 这三个键必须匹配。 该联接在团队一侧是一对多关系——属于多个团队的一个用户会匹配 user-teams 表中的多行记录。 -
按
day筛选到你想要的那一天。 这两个报表具有相同day的值。 -
按
team_id分组（以及按团队的显示名称slug分组）并进行聚合。 使用：COUNT(DISTINCT user_id)用于统计独立用户数，例如活跃用户。SUM(...)用于卷计数器，例如code_generation_activity_count、loc_added_sum和user_initiated_interaction_count。
这是内联接：对于某一天，只有当某个团队中至少有一名成员在当天有活动时，该团队才会出现在结果中。 若要列出当天没有活动的团队，请从 user-teams 报表进行左连接，并将值为 null 的计数器视为零。
按语言、IDE、功能或模型划分
各维度的细分数据位于每个用户行的数组字段中（totals_by_ide、totals_by_language_feature、totals_by_language_model、totals_by_model_feature）。 若要按维度分组，请将相关数组展开为联接的一部分，将维度列添加到分组中，并聚合限定为该维度的每个元素计数器。
language 和 ide 分别位于不同的数组中，因此团队级 (language × ide) 交叉表需要两个查询，并在应用程序中将其合并。
生成滚动窗口团队报表
若要生成滚动窗口团队报告（例如，28 天汇总）：
- 在窗口中调用每天的每日终结点。
- 将每天的每位用户使用指标报告（
organization_users_1_day或users_1_day）与同一天的用户团队报告（organization_user_teams_1_day或enterprise_user_teams_1_day）按(user_id, day, entity_id)进行关联。 - 筛选
day到窗口，然后从分组中删除day。
容量计数器可跨天累加；请在该时间窗口内将其求和。 非重复用户计数必须通过 COUNT(DISTINCT user_id) 全窗口的联接行进行求值-不能在每日计数中求和。
按天关联可确保每天的活动归属给用户在当天所在的团队。 如果没有它，在该时间窗口内发生的团队成员变更会悄无声息地将活动错误地归因给错误的团队。
限制和注意事项
- 多个团队中的用户为他们所属的每个团队做出贡献。 将各团队行数据汇总回组织或企业总计时务必小心——属于多个团队的用户会被重复计算。 直接使用每用户报表（没有用户团队加入）进行组织或企业总计。
- 低于阈值的团队未显示在用户团队报告中。 在某一天拥有少于 5 名已分配席位的 Copilot 用户的团队将被排除，因此其活动不会反映在团队级别结果中，不过这些活动仍会显示在按用户划分的报告中。
- 不同用户计数不能在几天内求和。 在多日时间窗口内汇总时，应基于整个时间窗口中连接后的行来评估
COUNT(DISTINCT user_id)，而不是将每日计数相加。 - 已跟踪更多特征曲面。 总量计数器（
code_generation_activity_count、code_acceptance_activity_count和loc_*计数器）汇总了多个 Copilot 界面中的活动——包括 IDE 内联补全、聊天面板操作，以及（对于已接受行数计数器）Copilot 代理 编辑。 有关每个计数器的表面覆盖率详细信息，请参阅 Copilot使用情况指标中提供的数据。 如果你之前是在仅统计 IDE 内联补全的统计界面中查看类似指标，那么这些计数器的数值会更高，因此应重新设定基线，而不是跨切换点直接比较差异。 - 利用新维度。 在每个用户行中，均可查看按 IDE、按功能、按
(language, feature)、按(language, model)以及按(model, feature)划分的细分数据，从而支持此前团队指标界面无法提供的团队级报告。
后续步骤
- 有关每用户使用情况指标报告的完整架构和字段参考，请参阅 Copilot使用情况指标中提供的数据。
- 有关使用情况指标端点的 JSON 负载示例，请参阅 Copilot使用情况指标的示例架构。
- 有关跨仪表板、API 和导出协调指标的指导，请参阅 跨仪表板、API 和报表协调 Copilot 使用情况指标。