GitHub Copilot app metrics changed what your trend line counts

GitHub changed the meaning of several Copilot usage totals on July 28, 2026. Copilot app activity now contributes to active-user counts, code-generation and acceptance totals, lines added and deleted, and model, language, and feature breakdowns. An existing report may keep the same field names while measuring a broader set of activity.

That creates a practical problem for anyone comparing this week with last week or building a six-month adoption trend. A higher value after the change may reflect more use, a newly counted surface, or both. This article shows where the definitions moved, what the fields actually measure, and how to preserve a trustworthy comparison without discarding the history you already have.

Copilot app activity now flows into existing totals

The GitHub announcement adds two app-specific fields to enterprise-user and organization-user reports. used_copilot_app records whether a user was active in the Copilot app on a given day. totals_by_copilot_app reports sessions, requests, prompts, output tokens, prompt tokens, and average tokens per request for that user.

The change reaches beyond those new fields. A copilot_app value can now appear in feature, model-feature, language-feature, and language-model rollups. Top-level code generation, code acceptance, lines added, and lines deleted also include Copilot app activity. daily_active_users now counts people who were active only in the Copilot app.

The scope differs by report. The user-level app fields are available in enterprise-user and organization-user reports for both one-day and 28-day windows. The broader feature and top-level changes apply to enterprise, organization, and user reports for those windows. Access still depends on the required enterprise or organization role, the relevant metrics permission, and an enabled Copilot usage metrics policy.

GitHub calls the update backward compatible. That is accurate at the schema level: existing fields retain their shape, and entities without app activity omit the app-specific data. It does not mean that a value before July 28 has the same measurement boundary as the same field after July 28.

Parser compatibility does not preserve trend continuity

A pipeline can keep running while its interpretation becomes wrong. If your code already accepts daily_active_users, code_generation_activity_count, or loc_added_sum, the new records may load without an error. The absence of a parsing failure is not evidence that the time series stayed comparable.

Consider daily_active_users. Before this expansion, someone who worked only in the Copilot app was not included in that total. Now that person is. A rise can therefore come from a broader measured population even if use of the previously counted surfaces remains flat.

The same problem applies to output totals. When Copilot app activity starts contributing to generation, acceptance, and editor line-change fields, an apparent jump can combine two changes: people doing more work and GitHub counting work from another surface. A pre/post percentage built on that mixed definition cannot isolate either cause.

This is a measurement boundary, not a reason to throw away the data. Keep the older history, but label the definition change and avoid fitting one uninterrupted trend through both periods as if nothing changed.

The fields describe activity, not delivered value

GitHub's usage metrics reference is precise about what several fields count. code_generation_activity_count records distinct Copilot output events, including comments and docstrings. One prompt can produce several code blocks, and each can count as a separate generation, so generation count is not directly comparable with prompt count.

code_acceptance_activity_count counts built-in acceptance actions such as applying code to a file, inserting it at the cursor or terminal, and using the Copy button. A manual operating-system copy action is not counted. Acceptance shows that a user took an interface action; it does not establish that the code was merged, deployed, correct, or useful.

The line fields also need a careful label. loc_added_sum and loc_deleted_sum describe lines changed in the editor through accepted completions, applied blocks, and agent or edit modes. They do not describe the final repository diff, merged output, production throughput, defect rate, or business value.

Report coverage adds another caveat. GitHub says active-user counts can include people found through client-side and server-side telemetry, while users visible only through server-side telemetry may be absent from dimensional breakdown arrays. A total and its breakdown can therefore have different coverage even within the same day.

These boundaries extend the argument in our earlier article on Copilot adoption cohorts. Cohorts and activity totals help a team find where behavior may be changing. Delivery, review, quality, and incident evidence are still needed before the team claims an outcome.

A trustworthy comparison keeps the definition visible

Start by recording the first date your export includes Copilot app activity in existing totals. Store the source URL and the definition you used beside the dataset or dashboard. That note should be visible to anyone reading a chart, not buried in pipeline history.

Next, preserve the app-specific fields instead of flattening them away. Keep used_copilot_app and totals_by_copilot_app, along with the copilot_app rows in feature, model, and language breakdowns. This lets you report the broader total while also showing how much of the movement came from the newly included surface.

Then rerun any conclusion that crosses the boundary. Compare the same surfaces on both sides when the data permits, or begin a new baseline for the broadened total. If you compare users, hold the population definition steady. If you compare code activity, keep generation, acceptance, editor changes, pull requests, merges, and production outcomes as separate measures.

Finally, test the interpretation against delivery evidence. Pull-request cycle time, review work, test failures, reverts, incidents, and developer feedback can show whether a usage change corresponds with a workflow change. Use the same discipline described in our production AI evaluation guide: define the unit, population, window, and success condition before reading the result.

Keep the old history, but stop pretending the definition stayed still

The July 28 update makes Copilot app activity more visible. Teams can identify app users and inspect app requests, prompts, tokens, models, languages, features, and code activity through report shapes they may already consume. That is useful coverage.

It also means the familiar totals no longer describe exactly the same activity boundary. The honest response is small: mark the date, retain the app-specific dimensions, separate activity from delivery outcomes, and restart comparisons that depend on a stable definition. A chart remains useful when its measurement boundary is visible.

BaristaLabs helps teams connect AI activity data to the workflow and business decision it is meant to support through process automation and integration. If a Copilot report now mixes old and new definitions, request a focused measurement review before the next adoption or productivity claim.