Skip to main content

Adoption Analytics

Concepts

The Adoption page (Productivity → Adoption) answers a simple question for engineering leadership: out of everyone provisioned to use AI tools, how many actually are?

Active Users​

Active Users counts distinct human identities with at least one session in the selected time window, out of the number of provisioned users (active personal access token holders, falling back to all-time unique session identities if no PATs exist yet). Non-human identities are excluded from this count:

  • Anonymous agents (anon:*) — identities that are not tied to a developer. Authenticated global passthrough no longer synthesizes anonymous identities from raw credentials; it requires an authenticated identity. Local deployments with validationMode: none can still create synthetic unverified identities; other unverified identities are rejected when requireVerifiedIdentity is enabled. All anonymous activity, including retained legacy rows, is excluded from human adoption counts.
  • Service accounts (sa:*) — machine identities that authenticate with a service-account token.
  • Agents that own their sessions — a Kubernetes agent (its k8s-cluster://… key), and any other registered agent, such as a virtual-key or machine-to-machine agent, whose agent ID owns the session. An agent is recognized from its entry in Inventory → Identities, so it is excluded whatever its ID looks like. An email address is always treated as a person, and a person with no Identities entry is still counted.

Excluding them keeps automated traffic from inflating the human adoption number (issue #875). (The ratio can still exceed 100% for other reasons — see Adoption Rate below.)

Non-human activity in the same window isn't hidden — it's shown as a separate sub-label below the Active Users count ("N humans · M non-human identities", where M is the distinct count of active non-human identities listed above), so you can see automated usage without it distorting the human adoption number.

Every human-facing figure on the page uses this same human-only population — Adoption Rate, New Adopters, Churned, the weekly trend, the per-team table, the per-developer breakdown, and the activity heatmap — so no two views of "active users" disagree. The seat-limit enforcement counter (Community/Team plans) counts the same human-only population.

Numbers shift on upgrade

Because service accounts (sa:*) were previously counted, upgrading to this behavior retroactively lowers historical Active Users, New Adopters, and Churned figures for any org that ran service-account sessions — and, where the provisioned-user denominator was itself derived from session identities, the adoption rate can move as well. This is a one-time correction, not data loss; the underlying sessions are unchanged.

Adoption Rate​

Active Users divided by provisioned users, as a percentage. An org-wide headcount override can be set in Settings → Organization if the provisioned-user count (PAT holders) undercounts real headcount — for example, when some developers authenticate via OIDC without ever issuing a PAT.

New Adopters and Churned​

  • New Adopters — developers whose first-ever session falls inside the selected window.
  • Churned — developers who had sessions in the prior window of equal length but none in the current window.

Adoption by Team​

The team breakdown table rolls up active users, sessions, and cost per OIDC group, using the same team assignment used for cost and policy attribution elsewhere in the product.

See also​

  • Sessions — per-session detail behind the Active Users count, and how concurrent sessions are measured
  • Outcomes — PR-level AI adoption (a different, code-review-based adoption metric)
Last updated on