GitHub has extended the Copilot impact dashboard to report how many active users engage with each key feature on at least two days within a rolling 28‑day window, and the same data is now exposed through the enterprise and organization aggregate report APIs. Practitioners gain a quantitative view of feature adoption, which can inform training focus, capacity planning, and compliance monitoring without exposing individual user identities.
New Dashboard and API Fields
The dashboard now displays a count of active users per feature, defined as users who interacted with the feature on two or more days during the 28‑day period. Corresponding API objects have been added:
copilot_feature_engagement: aggregates the active‑user total and per‑feature counts.totals_by_feature: breaks the engagement down bycode completion,agent edit,passive Copilot code review,active Copilot code review,Copilot cloud agent,Copilot CLI, andCopilot app.users_in_phase_28d: reports the full rolling 28‑day population for each AI adoption phase as of the report day.
The existing total_engaged_users field remains unchanged, still reporting only the users active on the specific day. Feature engagement data is limited to enterprise and organization aggregate reports; it does not appear in user‑level reports, and a single user may be counted under multiple features.
Operational Impact
With concrete adoption numbers, platform and DevOps teams can build automated alerts or dashboards that surface low‑adoption features, prompting targeted enablement or documentation updates. The 28‑day rolling view smooths daily spikes, giving a more stable signal for capacity forecasting—e.g., estimating load on Copilot‑backed CI pipelines or cloud agents. Because the data is aggregated, it can be safely stored in existing telemetry pipelines without additional privacy safeguards.
Security and Access Considerations
Access to the new metrics is gated by the View Copilot Metrics permission, which is granted to enterprise owners, billing managers, organization owners, and any custom role that includes that permission. The underlying Copilot usage metrics policy must be enabled before the fields appear, and the copilot_feature_engagement object may be absent or null if the calculation cannot be performed. Since the reports provide only aggregate counts, they do not expose individual user activity, reducing the risk of inadvertent data leakage.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
Enable the Copilot usage metrics policy in your enterprise settings and verify that the appropriate roles include the View Copilot Metrics permission. Update any internal reporting scripts to ingest copilot_feature_engagement, totals_by_feature, and users_in_phase_28d from the 28‑day aggregate endpoints. Use the new visibility to prioritize training on under‑used features, adjust resource allocations for high‑adoption components, and monitor adoption trends as part of your regular health checks. Keep an eye on future releases for possible expansion of these metrics to user‑level reports or additional feature categories.
