GitHub is patching a quiet blind spot in its Copilot reporting: client-side telemetry (usage data emitted by IDEs and developer tools) has always been the foundation of enterprise Copilot metrics, but network conditions, proxy configurations, and client settings have routinely caused active users to go missing from reports. The updated Copilot usage metrics API<\/a> now layers in server-side telemetry to surface those users, with GitHub’s own example suggesting an enterprise might see DAU counts jump roughly 5 percent immediately, with richer per-feature breakdowns to follow in later releases.<\/p>\n Any organization that has built ROI calculations or adoption dashboards on top of the Copilot metrics API should expect their headline user counts to move upward without any change in actual behavior. That’s not a problem, but it will require communication. A team that benchmarked 1,000 DAU last quarter and now sees 1,050 didn’t suddenly improve adoption. The gap was always there. Treating the increase as real growth would corrupt the trend line you’re using to justify seat expansions.<\/p>\n The more important signal is structural. GitHub is explicitly describing this as the first step in a broader migration toward server-side telemetry, which means the metrics architecture itself is changing, not just the numbers. Enterprises that have productized their Copilot data by piping the API into BI tools or engineering scorecards need to version their pipelines now. The dimensional breakdowns like The recurring failure mode in enterprise developer tooling adoption is measuring what the tool reports rather than what engineers actually do. GitHub is correcting for exactly that here, which is the right call. The question worth holding: as server-side telemetry becomes the authoritative signal, what privacy and data residency implications does that carry for enterprises in regulated industries or operating under strict EU data localization requirements?<\/p>\n Client-side telemetry is usage data generated and transmitted by the software running on a developer’s machine, the IDE plugin, the browser extension, the local agent. It’s rich in detail but fragile: firewalls, VPNs, and proxy configurations can silently drop it. Server-side telemetry is collected by GitHub’s own infrastructure when a request hits their servers, so it’s immune to client environment issues but carries less granular context. Think of it as the difference between a store’s receipt printer (can fail) and the bank recording the card transaction (always happens). GitHub is now cross-referencing both.<\/p>\nWhat this means for your business<\/h2>\n
totals_by_ide<\/code> and totals_by_feature<\/code> will show a rising share of unattributed activity in the near term, which will look like data quality regression to anyone who isn’t watching for it.<\/p>\nConcept deep-dive: Client-side vs. server-side telemetry<\/h2>\n