Cursor Analytics vs Engineering Analytics: What's the Difference?

TL;DR: Cursor's native analytics track adoption, token spend, and usage patterns inside Cursor, including how much committed code Cursor generated. That answers "what are we spending on AI." Engineering analytics platforms such as minware join that usage to version control and ticketing data. The join is what lets them measure value delivery outcomes: roadmap value delivery and on-time delivery rate. Bug rate and cycle time act as guardrails. A linear regression of each outcome against token spend answers what Cursor can't: whether higher spend is buying more delivery or just a bigger bill. That regression is the basis of a defensible AI return on investment (ROI) story.

Token spend climbing month over month with no answer to what it bought is the pattern that starts a board conversation. Cursor's own analytics answer the first half of that question. Engineering analytics answers the second.

The two categories blur because Cursor's own dashboard now reports code-level figures, such as the share of committed code it generated. Cursor's native analytics measure input and code output, such as adoption, token consumption, or AI-written lines. Engineering analytics measures outcomes: whether AI usage correlates with more roadmap value delivered on time, with quality and efficiency holding steady. Cursor's reports stop at the commit. A general engineering analytics platform that ingests Cursor data can follow that code through to completed tickets and roadmap items.

This article covers where one category ends, what each measures, and how to avoid building an AI ROI story on adoption metrics.

What Cursor analytics measures

Cursor exposes analytics through its web dashboard and the Admin API, both included on Teams plans. Enterprise plans add the Analytics API and the AI Code Tracking API. All of them report on usage and code output.

The analytics dashboard

Cursor's analytics dashboard shows active users, messages sent, and Tab suggestions shown versus accepted. It reports at both team level and user level. It also shows the share of committed code that Cursor generated, plus pull requests opened and merged by cloud agents.

The dashboard answers operational questions: Are licenses being used? Which teams have adopted the tool? How much of the committed code did AI write? The commit-level views belong to the throughput category, since they show how much code AI produced. Whether any of that code moved roadmap items or due dates is a question for data outside Cursor.

The Admin API and AI Code Tracking API

Cursor's Admin API returns event-level detail with the model, request kind, token usage, and charged cost of each request, filterable by user, service account, or cloud agent. A second endpoint returns per-user daily aggregates: tabs shown, tabs accepted, lines added, composer requests, chat requests, and agent requests.

The Enterprise-only AI Code Tracking API, currently in alpha, goes further, attributing the lines in each commit to Tab, Composer, or non-AI work. This data supports cost tracking, usage analysis, and a view of how much code AI wrote. Connecting it to delivery outcomes still means joining it with pull requests, tickets, and roadmap items from other systems.

What engineering analytics measures

Engineering analytics platforms connect data across your entire software development lifecycle (SDLC). That means your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps, and your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues. It also covers CI/CD pipelines like GitHub Actions, GitLab, or Azure Pipelines, plus AI coding tools such as Cursor, Claude Code, GitHub Copilot, or Codex.

The comparison below shows where Cursor's native analytics stop and where an engineering analytics platform such as minware picks up.

Feature	Cursor native analytics	minware
Data sources	Cursor usage and commit attribution	Cursor plus version control, project management, and CI/CD
Key metrics	Active users, token spend, Tab acceptance, AI share of committed code	Token spend regressed against roadmap value delivery, on-time delivery rate, and overhead cost. Bug rate, PR lead time, and ticket cycle time as guardrails
Answers this question	How much are we spending on Cursor? Who is using it? How much code did it write?	Is higher Cursor spend buying more roadmap value delivered on time?
Cannot answer	Whether usage improves delivery outcomes	Org-specific questions until a metric is configured, usually by customer success
Best for	Cost tracking, license optimization	Proving AI ROI to a board with a defensible methodology

Outcome and guardrail metrics

Engineering analytics tracks value delivery outcomes first, with quality, efficiency, and predictability metrics acting as guardrails:

• Value delivery:

  • Roadmap value delivery (the expected value of completed work items)

  • On-time delivery rate (estimated roadmap item duration divided by actual duration, capped at 100% per item)

• Quality:

  • Bug rate (bugs created divided by pull requests merged)

  • Change failure rate (highest-priority bugs divided by pull requests merged by default, reconfigurable to production deployments for the DORA definition)

  • Bug lead time (time from bug report to fix)

• Efficiency:

  • PR lead time (time from a pull request's first commit to deployment, which defaults to merge into a main branch)

  • Ticket cycle time (time from when a ticket is first marked in progress until it is done)

• Predictability:

  • Sprint completion (story points completed each sprint divided by the original commitment, capped at 100%)

Most of these need data from more than one system, and none of them come from an AI tool's dashboard.

DORA metrics in context

DORA (DevOps Research and Assessment) defines five delivery metrics: deployment frequency, lead time for changes, change failure rate, failed deployment recovery time, and deployment rework rate. These metrics measure delivery speed and stability, so they need a value delivery metric alongside them to show impact.

Engineering analytics platforms report DORA metrics alongside value delivery metrics, so you can see whether faster deployment correlates with more roadmap items completed on time. DORA metrics are efficiency and quality signals that explain why a value delivery trend is moving. When a board asks what AI bought, lead with roadmap value delivery or on-time delivery rate and let the DORA metrics follow as supporting signals.

Where input metrics end and outcome metrics begin

Input metrics measure tool usage, while output metrics measure delivery results. Understanding this distinction clarifies which platform answers which question.

Metric category	Example metrics	What it measures	What it cannot prove
Input (activity)	AI usage, agent sessions, token spend, suggestion acceptance rate	Tool usage	Whether usage improves delivery
Throughput	Pull requests merged, commits, lines of code, AI share of committed code	Code output volume	Whether output delivers business value
Outcome (value)	Roadmap value delivery, on-time delivery rate	Value delivered	The cause, without regression against token spend
Outcome (quality)	Bug rate, change failure rate	Quality trends	Whether delivery improved, on its own
Outcome (efficiency)	PR lead time, ticket cycle time	Flow speed	Whether delivery improved, on its own

Cursor analytics covers the input row and part of the throughput row. Engineering analytics covers the outcome rows. Throughput sits in between: it shows how much code shipped, while value delivery shows whether that code mattered.

Why throughput metrics are not proof of value

Pull requests merged is the metric many teams still reach for as AI ROI evidence. Throughput metrics (pull requests merged, commits, lines of code) measure code output. If code volume increases but roadmap value delivery stays flat, the team is generating more inventory without shipping more value.

AI coding tools make this trap worse. A coding agent may produce a large volume of code quickly, and Cursor's AI share of committed code will rise with it. If that code does not connect to completed tickets or shipped roadmap items, the throughput gain is an illusion.

Why adoption data carries a selection bias

Adoption also carries a selection problem. Developers who adopt AI tools first are often already the most active contributors. A longitudinal study of GitHub Copilot at a public sector IT organization found adopters were pushing commits more often than their colleagues before the tool arrived. The adoption metric looks like it predicts success, but it partly reflects who chose to adopt.

How to prove AI ROI from token spend

A defensible AI ROI story rests on three pieces: a regression of delivery outcomes against token spend, a trend over time for the same team, and guardrail metrics that confirm quality holds steady.

Regressing delivery outcomes against token spend

The primary methodology is a linear regression of a delivery metric against token spend. minware's Lean AI Framework runs three of these regressions, one each for roadmap value delivery, on-time delivery rate, and overhead cost. Each regression fits a single metric pair, with one data point per team per time period.

When no explicit value field is configured, roadmap value delivery defaults to story points completed on non-bug tickets with a parent epic or project ticket, with one point assigned per ticket if no estimate is set.

The regression slope is the change in the outcome metric per unit change in spend. For example, a slope of 0.01 would mean each additional dollar of token spend correlates with 0.01 additional story points completed, or one extra point per $100. The R-squared value tells you what share of the variation in the outcome the spend actually explains.

Name the confounders whenever you draw a conclusion from the slope. Engineers reach for AI on work where it is likely to help (task-level selection), and the developers who adopt first tend to be the most active already (person-level selection). Covariates like codebase age and code quality matter too.

Tracking same-team trends over time

The supporting check to the regression is each outcome metric's trend over time for the same team. As AI usage increases, does roadmap value delivery increase? Does on-time delivery rate improve? Does overhead cost fall?

This trend controls for differences between teams. A team with a mature codebase and strong test coverage may have higher delivery outcomes at any level of AI usage than a team working in a legacy monolith. The regression includes both teams, so the slope reflects the average correlation across different contexts. The trend shows whether a specific team's delivery is improving as their AI usage grows.

AI-vs-non-AI cohort comparison breaks down as adoption spreads. In mid-2026, 90% of professional developers used AI coding agents at work at least weekly, so non-AI groups are shrinking, and the ones that remain are prone to selection bias. Engineers who skip AI are often working where it is unlikely to help, such as a legacy repository with poor test coverage. Regression treats token spend as a continuous variable, so non-AI work appears as the zero-spend endpoint without a separate comparison group.

Using quality and efficiency as guardrails

Quality metrics (bug rate, change failure rate) and efficiency metrics (PR lead time, ticket cycle time) are guardrails on the ROI story. If roadmap value delivery is up but bug rate is also up, the gain may not be real. You may be shipping more story points by shipping more bugs, which will surface as rework later.

A strong pattern would be: roadmap value delivery up, ticket cycle time steady or down, bug rate steady or down. That pattern suggests AI is helping the team ship more value without breaking flow or quality. If any of the guardrails is moving in the wrong direction, the delivery gain is suspect.

When delivery outcomes do not move, the same metrics become diagnostics. Ticket cycle time and bug rate are where you look to find out why.

When Cursor's native analytics are enough

Cursor's native analytics are sufficient if your only question is "how much are we spending on Cursor and who is using it?" That is a legitimate operational question, especially early in a rollout.

Cost tracking and license management

Cursor's daily usage data flags whether each user was active, so you can spot idle seats. The Admin API also returns per-request token consumption and cost, so you can track spend by user or model. This data feeds budget forecasting and license optimization. Spend tracked this way reflects Cursor's reported cost, which can differ from what you actually pay on discounted plans.

If your only goal is to answer "are we getting our money's worth from Cursor licenses," the native analytics are enough.

Usage pattern analysis

Cursor's per-user daily aggregates (tabs accepted, composer requests, agent requests) show which features different teams use. This data helps you understand adoption patterns: Are teams using Tab completions or agent mode? Which models are they calling? Are usage patterns consistent across teams or concentrated in a few power users?

Cursor's dashboard filters usage by directory group, so you can compare teams: Team A has higher agent request volume than Team B. That comparison helps identify teams that may need training or support. The analysis stays within Cursor's own data, so it cannot tell you whether usage patterns correlate with ticket or roadmap outcomes.

When to build or buy engineering analytics

The build-vs-buy decision starts once Cursor's native analytics stop answering your questions. At that point you either build the pipeline that joins Cursor data to the rest of your stack or buy a platform that already does.

Joins a custom build has to maintain

Connecting Cursor's API data to delivery outcomes requires joining it to your version control system and your project management system. Deployment data from CI/CD runs, Git tags, or merges to main adds DORA and quality context, but the ROI regression doesn't need it. The join itself requires relationship recovery, identity resolution, and data normalization.

Building this yourself means writing custom extract, transform, load (ETL) pipelines for each source, then maintaining them as APIs change. When a source API renames a field, a pipeline built to look for that field breaks. A late-2025 Fivetran survey of 500 senior data and technology leaders found legacy or do-it-yourself pipelines break 30% to 47% more often than fully managed ones.

The recurring metric-definition cost

The hidden cost people underestimate most is the recurring "how exactly is this calculated" question. Every time a stakeholder asks, someone has to trace through the code and explain the logic. With a vendor, that is a support conversation. With an internal build, it is whoever built the pipeline, indefinitely.

minware's transparent data lineage shows every metric's formula in the UI, so you can inspect the calculation logic yourself. When a metric needs to match how your org works, customer success typically adjusts it in a single call and about 24 hours.

Total cost of ownership

The comparison between building internally and using minware comes down to total cost of ownership (TCO):

Cost category	Internal build	minware
Initial build	High, typically multiple weeks of engineering time to build custom ETL for each source	14-day trial. First-connection backfill can take hours, depending on repository size
API maintenance	Ongoing updates as vendors change APIs	Handled by vendor
Schema changes	Pipeline updates required	Handled by vendor
Metric definition questions	Internal team owns the explanation	Visible formula in UI, or a customer success call
Org-specific metrics	Built by whoever owns the pipeline	Configured by customer success, typically in a single call and about 24 hours
Ongoing support	Internal team owns long-term maintenance	Customer success support

The tradeoff on the buy side is configuration. Many analyses, including the regression of story points completed against token spend, work as soon as data is connected, while org-specific questions need a new or adjusted metric that customer success usually sets up.

What each type of analytics answers

Cursor analytics measures what you are spending on AI coding tools, plus how much code they wrote, while engineering analytics measures whether that spend is buying more roadmap value delivered on time. Treating the two as interchangeable produces AI ROI claims built on adoption and code output, which cannot answer what the spend bought. Connecting Cursor data to version control and project management data, then regressing token spend against delivery outcomes, gives that answer a slope with an R-squared value behind it.

minware's pre-built AI impact reports connect Cursor token spend to quality, value delivery, and cost outcomes using the patented hypercube data model. minware ingests Cursor data through Cursor's Admin API on Cursor Teams plans. For Cursor Enterprise plans, minware's Enterprise plan adds the integration for the Analytics API and AI Code Tracking API. Pricing is publicly listed at $25/contributor/month for Professional with no seat minimum, and the trial is self-serve with no credit card required. You can connect your data sources and explore the dashboards before talking to our team.

Start a 14-day free trial, no credit card required. Connect Cursor plus your version control and project management data to see token spend correlated against delivery outcomes.

FAQs

Can Cursor's built-in analytics prove ROI to my board?

No. Cursor's analytics measure adoption, token spend, and how much committed code Cursor generated. They cannot connect usage to delivery outcomes like roadmap value delivery or on-time delivery rate, which requires joining Cursor data to version control and project management data, as engineering analytics platforms such as minware do.

What's the difference between Cursor analytics and developer productivity metrics?

Cursor analytics tracks AI tool usage (token spend, agent requests, suggestion acceptance) and AI-written code. Developer productivity metrics track delivery outcomes (roadmap value delivery, on-time delivery rate) across the entire SDLC, with bug rate and cycle time as guardrails.

How do I know if higher token spend is actually improving delivery?

Run a linear regression of each delivery outcome against token spend, with one data point per team per time period. minware's Lean AI Framework runs three: roadmap value delivery, on-time delivery rate, and overhead cost. The slope of each is the ROI answer, such as story points completed per dollar. Each team's trend over time is the supporting check, with bug rate and cycle time as guardrails.

Do I need both a Cursor analytics tool and an engineering analytics platform?

You need Cursor's usage data, but you need it inside an engineering analytics platform such as minware that connects it to delivery outcomes. Cursor's native analytics cover cost tracking and license management, but proving AI ROI needs the delivery data they lack.

Why can't I just compare AI users vs non-AI users?

As adoption spreads, non-AI groups shrink, and the ones that remain are prone to selection bias because engineers who skip AI often work where it is unlikely to help. The supporting check that holds up, and the one minware's Lean AI Framework uses, is each outcome's trend over time for the same team.

Key terms glossary

Cursor analytics: Metrics from Cursor's analytics dashboard and APIs, such as active users, token consumption, Tab acceptance, or the share of committed code Cursor generated. They stop short of ticket and roadmap outcomes.

Engineering analytics: Metrics that connect data across version control, project management, CI/CD, and AI coding tools to measure delivery outcomes. Quality and efficiency metrics act as guardrails.

Token spend: The dollar cost of AI tool usage, as reported by vendor APIs or OpenTelemetry integrations. On flat-rate, tiered, or discounted plans, reported spend may differ from the amount actually invoiced.

Roadmap value delivery: The expected value of completed work items. If no explicit value field is configured, it defaults to story points completed on tickets that are not bugs and have a parent epic or project ticket, with one point assigned per ticket if no estimate is set.

On-time delivery rate: The estimated roadmap item duration divided by the actual roadmap item duration, capped at 100% per roadmap item.

Overhead cost: Personnel cost and token spend that go toward work outside roadmap value delivery.

Bug rate: Bugs created divided by pull requests merged into a main branch, by default.

Cycle time: Time from when work starts until it completes. Ticket cycle time runs from when a ticket is first marked in progress until it is done. PR lead time runs from a pull request's first commit to deployment, which defaults to merge into a main branch.

DORA metrics: Five metrics defined by the DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate, failed deployment recovery time, and deployment rework rate. They measure speed and stability. A value delivery metric has to sit alongside them to show impact.

Delivery outcomes: Business results produced by engineering work, measured by value delivery metrics (roadmap value delivery and on-time delivery rate). Quality metrics (bug rate, change failure rate) and efficiency metrics (PR lead time, ticket cycle time) act as guardrails on them.