关于 Copilot 使用数据指标
Copilot 使用情况指标可帮助关键利益干系人和决策者了解其团队的采用和使用 Copilot方式。 通过跟踪企业中的使用模式，可以衡量参与度、识别增加价值的机会，以及评估 AI 辅助工作流如何影响拉取请求吞吐量和合并时间。
可通过以下方法获取指标：
- Copilot使用情况指标 API，这些 API 在企业、组织、存储库和用户级别提供详细的可导出数据。
- Copilot使用情况指标仪表板，可直观显示企业和组织 28 天的使用情况趋势。
- 代码生成仪表板可细分企业和组织中的用户和代理如何生成代码。
- 影响 Copilot 仪表板，将用户分组到采用队列中，并将该采用连接到拉取请求输出。
- Copilot 使用指标 NDJSON 导出，提供原始数据用于自定义商业智能工具或长期存储。
包括哪些用法？
Copilot 使用指标来自多个 Copilot 界面的遥测数据，包括 IDE 和 Copilot 命令行界面（CLI） 活动。 大多数指标来自客户端 IDE 遥测， 最终用户需要在其 IDE 中启用遥测 ，以获取这些指标中最丰富的数据。
此外， Copilot 使用情况指标还包含 服务器端遥测 数据，以识别客户端遥测可能错过的活动用户。 网络条件、代理配置和客户端设置可能会阻止客户端遥测数据到达 GitHub，因此服务器端信号可确保这些用户仍显示在报表中。
通过服务器端遥测显示的用户将完全计入活动用户总数（例如每日活跃用户）。 daily_active_users 如果可用，它们也可能出现在 totals_by_ide （包括每个用户报告中最近检测到的 IDE 和 Copilot 扩展版本）。 但是，其他维度细分（例如 totals_by_feature 代码行指标和代码行指标）保持为空，直到更丰富的遥测数据可供使用。 对于已通过客户端遥测采集到的用户，顶层汇总和细分数据保持不变。
数据不包括其他Copilot界面的活动，例如：
- 副驾驶聊天 上 GitHub.com
- GitHub Mobile
使用情况指标报表中不包括 Copilot 许可证和席位管理数据。 若要查看或管理许可证分配，请使用 Copilot 用户管理 API，这是许可证和席位信息的真相来源。 请参阅“用于Copilot用户管理的 REST API 终结点”。
为何 Copilot 使用指标可能因 API 资源而异
以下 API 资源公开 Copilot了相关的数据，但它们不可互换，不应直接进行比较。 每个 API 资源专为特定用例和数据模型设计，预计总计或覆盖范围的差异。 使用此表了解最适合你的报告需求的 API 资源。
注意
强烈建议使用 Copilot 使用情况指标 API 进行新的集成和分析，因为它提供了最完整和面向未来的使用情况视图 Copilot 。
| API 资源 | Scope | 关键功能 |
|---|---|---|
| 用于 Copilot 使用情况指标的REST API终结点 | 具有存储库和用户级报表的高级企业和组织范围的事件遥测 | 在各种完成、聊天和智能体模式中提供统一的遥测。 包括所有 IDE 模式、语言和模型的使用情况和代码行指标。 支持按功能、IDE、语言、模型和用户以及存储库级拉取请求活动报告的详细细分，并且是正在积极开发和维护的主要 API 资源。 |
| 用于Copilot用户管理的 REST API 终结点 | 许可证和席位分配 | 列出组织或企业分配 Copilot 的席位，包括许可证状态、用户关联和 last_activity_at。 此 API 资源是许可证和席位信息的真相来源。 |
如何跨组织归因指标？
注意
可以授予 仅限组织的可见性 至 Copilot 使用情况指标，而无需提供企业级访问权限。
为此，可以创建包含“查看组织 Copilot 指标”权限的组织自定义角色，并将该角色分配给需要了解单个组织的指标的用户。 请参阅“自定义组织角色的权限”。
组织级别的 Copilot 使用情况指标基于组织成员身份，而不是基于各个操作的发生位置。 要出现在企业指标中，用户必须在该企业内分配有活跃 Copilot 席位（属于企业的任何组织中）。 因此，单个用户的使用情况可能会出现在多个组织仪表板中，而同一用户仅计算在企业级总计中的一次。 组织级别的分析旨在了解组织中的采用和使用情况，并且不会直接与企业级总计进行比较。
从 2025 年 12 月 12 日起，组织级 Copilot 分析可用。 这是提供组织级报告的第一个日期。
用户拥有企业中的席位后，其使用情况将归咎于 他们所属的每个组织，而不考虑分配席位的位置。
这意味着：
- 如果在专用的“shell”组织中分配许可证用于企业内部的管理目的，则用户仍显示在他们所属的企业中所有其他组织的指标中。
- 如果用户在Copilot也拥有一个席位，只要他们在企业中至少有一个**** 席位，他们的活动仍包含在企业的组织级别指标中。
简言之：用户必须在企业中的某个位置获得许可才能在其指标中显示。 一旦满足条件，这些指标就会反映员工的工作地点（他们所属的组织），而不是哪个组织提供Copilot席位或活动发起的位置。
支持的 IDE
若要将最终用户包括在 Copilot 使用指标中，必须使用以下 IDE 和 副驾驶聊天 扩展版本之一。
| IDE | 最低 IDE 版本 | 最低 副驾驶聊天 扩展版本 |
|---|---|---|
| Eclipse | 4.31 | 0.9.3.202507240902 |
| JetBrains / IntelliJ | 2024.2.6 | 1.5.52-241 |
| Visual Studio | 17.14.13 | 18.0.471.29466 |
| VS Code | 1.107.1 | 0.35.3 |
| Xcode | 13.2.1 | 0.40.0 |
数据新鲜度
仪表板和 API 报表中的数据会定期更新。
预计数据将在 两天内可用。 这意味着给定日期的数据在该日期结束后的两个完整 UTC 天内处理并可用。
数据度量值是什么？
Copilot 使用情况指标可分为几个主要类别：采用、参与、接受率、代码行（LoC）和拉取请求生命周期指标。
使用情况 用于衡量有多少授权开发人员正在积极使用 Copilot。 例如，每日活动用户（DAU）告诉你给定一天与 Copilot 多少个唯一用户交互。 理想情况下，在推出期间，这些指标中会出现一致的上升趋势。 Copilot 代码评审 的采用情况单独追踪，并区分活跃用户和被动用户数量。 活跃用户是手动请求审查或应用了建议；被动用户则是 Copilot 代码评审 被自动分配来审查其拉取请求。 当用户在同一时间段内同时发出这两个信号时，它们仅算作活动状态。 为了更深入地了解采用深度，用户也会分组到采用队列中。 请参阅 了解采用队列。
参与度量值描述了开发人员在采用Copilot后如何深入使用该工具。 关键参与指标不仅显示使用频率，还显示了功能之间的广度。 例如，每个活动用户的平均聊天请求度量用户打开和交互 副驾驶聊天的频率。 你希望看到在不同语言和 IDE 中聊天的使用保持定期性并不断增加。
接受率 衡量开发人员接受 Copilot建议的频率。 这有助于了解建议是否相关且受信任。 例如，高内联建议接受率表明这些建议具有相关性和实用性。
代码行 (LoC) 指标衡量 Copilot 在编辑器中建议、添加或删除的行数，提供 Copilot 实际产出的方向性视图。 例如，“添加的行”显示实际接受并插入到编辑器中的代码量。
拉取请求生命周期指标 衡量活动与 Copilot 拉取请求结果和传递流的关系。 这些指标包括拉取请求创建和合并计数、合并中位时间以及审核建议活动。 通过将总体拉取请求活动与创建的 Copilot拉取请求进行比较，可以评估 AI 辅助工作流如何影响组织或企业级的吞吐量和周期时间。
了解采用队列
与其将采用作为单个活动用户计数来衡量采用率， Copilot 不如根据用户参与的方式将用户分组到 采用队列 中，而不仅仅是他们是否参与 Copilot进来。 平面活动用户计数将处理偶尔接受代码完成的人与全天协调多个代理驱动工作流的人员相同。 队列将这两个用户分开，因此你可以看到组织的使用情况是否随时间推移而加深，而不是在初始试用版中保持稳定。
用户分为以下阶段：
| 阶段 | 它所代表的意义 |
|---|---|
| 被动用户 | 在此期间，用户未达到某个阶段的预订阈值。 在基础数据中，此阶段标记为 No Cohort。 |
| 阶段 1：代码优先 | 用户参与代码完成和/或 IDE 代理模式。 |
| 阶段 2：代理优先 | 用户与单个 GitHub代理图面（例如 Copilot云代理， Copilot 代码评审或 Copilot 命令行界面（CLI）） 仅在此处使用计数的活动参与 Copilot 代码评审 ;自动将其分配到查看拉取请求而不进行进一步参与不会。 |
| 阶段 3：多代理 | 与两个或更多 GitHub个基于代理图面的用户，或与 GitHub Copilot 应用. |
若要分组到阶段，用户必须使用与该阶段关联的图面，在尾随的 28 天时段外至少满足两个活动天数的参与阈值。 用户只需在较高阶段的图面上需要两个符合条件的天数才能进入该阶段。 单独使用代理可以限定用户，而无需单独的纯完成天数。
阶段分配每天从尾随的 28 天窗口重新计算，因此用户阶段可以在该窗口内的活动发生更改时从一天转移到下一天。 这是预期行为，而不是数据错误。
未满足任何阶段阈值的用户将分组到 被动用户中，该用户不是非活动度量值，而是表示用户参与尚未达到可靠地分类其采用深度所需的级别。 例如，在尾随的 28 天窗口中，只有不到两个活动天数的用户，或者仅轻量地使用像上副驾驶聊天这样的GitHub.com图面的用户显示为被动用户。
由于阶段分配基于 用户参与的图面，而不仅仅是他们采取的操作数，具有高完成量但没有代理使用情况的用户保留在阶段 1 中，而跨代理图面使用较轻但更广泛的用户将进入阶段 2 或阶段 3。
有关基础架构字段，请参阅 AI 采用阶段字段。
影响仪表板的 采用乘数 将参与用户合并的拉取请求的平均量除以被动用户合并的拉取请求量（即阶段 1、2 或 3 中的拉取请求量）。
这显示了更深入采用的相对影响，与每个阶段的用户数量无关。 这是一个度量值，用于了解成为更参与的用户可以提供的潜在提升。
例如，如果参与队列中的用户平均 20 个拉取请求/用户/月和被动队列平均为 10，则公式为 20 / 10 = 2 倍乘数。
跨范围解读拉取请求的生命周期度量
拉取请求生命周期指标在组织和企业级别均可用。 比较报表时，请记住以下几点：
- 去重：企业级报告在组织间对用户去重。 组织级报告不会去重。
- 仅拉取请求数据：即使缺少 IDE 使用情况指标，拉取请求生命周期指标也可能出现，因为拉取请求数据派生自存储库活动。
- 属性计时：如果存储库或组织在所有者之间传输，则拉取请求创建、评审和合并事件可能会归因于不同的实体，具体取决于每个事件发生的时间。
如何使用这些指标？
这些指标可以一起使用来回答有关团队使用 Copilot的关键问题。
| 问题 | 使用这些指标 |
|---|---|
| 我的团队是否经常使用 Copilot ？ | 每日和每周活动用户 |
| 哪些功能提供最大的价值？ | 每个聊天模式的请求数，代理采纳情况 |
| 开发人员是否信任 Copilot输出？ | 接受率趋势 |
| 启用举措是否奏效？ | 培训或沟通活动后采用和参与度的增长 |
| 是否 Copilot 影响传递速度或拉取请求吞吐量？ | 拉取请求合并计数和合并中位时间 |
| Copilot 代码评审 目前采用情况如何？ | 主动评审与被动评审代码用户数量 |
| 我的组织的采用是否随着时间推移而加深？ | 采用队列分布和参与趋势 |
| 如何从仪表板中处理见解？ | 请参阅“解释 GitHub Copilot 的使用情况和采用指标” |
查找这些信号中的模式，而不是专注于任何单个数字。 例如，与接受率上升配对的稳定 DAU 表明信任和价值不断增加。
后续步骤
了解每个 Copilot 指标度量值及其使用方式后，可以浏览仪表板以查看这些指标的操作。
- 若要查看企业和组织中的采用和使用情况趋势，请参阅 查看 Copilot 使用情况指标仪表板。
- 若要分析用户和代理如何生成代码，请参阅 查看代码生成仪表板。
- 若要查看采用队列和采用深度，请参阅 查看 Copilot 影响力仪表板。
- 若要以编程方式访问 Copilot 使用情况指标，请参阅 用于 Copilot 使用情况指标的REST API终结点。
- 若要通过聚合每用户记录来构造团队级指标，请参阅 团队级Copilot使用情况指标。