Developer experience metrics for SaaS and API companies

Search for developer experience metrics and you will get DORA, cycle time, deploy frequency, and a satisfaction survey to send your engineers. Every result on the first page measures the same population: the developers on your payroll.

If you sell an API, those are not the developers who decide whether you make money.

The ones who do are outside your company. They signed up an hour ago, they are reading your documentation right now, and if they cannot make a successful call in the first session most of them will not come back. Very few companies have a single number pointed at them.

Five metrics measure that experience. Each one comes from a system you already run, and each one translates into a business line rather than a documentation score.

The two things called developer experience

Developer experience metrics measure two different populations. Internal metrics tell you whether your own engineers ship efficiently. External metrics tell you whether a developer who has never met your team can integrate your product, and most API-first companies instrument only the first.

Both are real. DORA gives you deployment frequency, lead time for changes, change failure rate, and time to restore service. SPACE widens that to satisfaction, performance, activity, communication, and efficiency. They came out of serious research, there is a large and well funded tooling category built to collect them, and the reason every devex metrics guide leads with them is that they work.

They just answer a question about your organization.

The distinction matters because the two columns fail independently. Your engineers can be shipping daily, on a platform team that has automated everything, while the developer who signed up this morning sits on an auth page that was accurate in March.

Nothing in the internal set is watching that. Deployment frequency does not drop when a code sample stops compiling. Change failure rate does not move when your quickstart skips a required parameter. Those are the failures that cost revenue, and they are invisible to every dashboard in the first column.

That asymmetry is why a company can pass an engineering review and still lose integrations it never knew it was competing for.

Why page views stopped being a documentation metric

Documentation traffic no longer maps to documentation use. AI summaries answer questions without sending anyone to your site, and most requests hitting your docs are now made by software rather than by people. The number still goes up and to the right. It just stopped describing developers.

Here is the shift, measured on one platform across a single year.

The March figure comes from Cloudflare user-agent headers across roughly 790 million requests over 30 days, with Claude Code and Cursor driving most of it. By the midyear report it had reached two thirds.

Read those three rows as one sentence: a metric that was roughly honest in January describes something else by July.

Almost nobody re-baselined in between. Documentation reporting still runs on page views, sessions, and time on page, and those numbers now blend two audiences with opposite meanings. A human spending four minutes on your auth guide is a developer working. An agent pulling the same page in 200 milliseconds is a developer who never read it at all, and might be integrating successfully or generating code against something out of date.

The second problem is the traffic that never arrives. Google's AI Overviews and chat assistants answer directly from your content, so the developer gets their answer and your analytics record nothing. A question answered well and a question never asked look identical in a traffic report.

So the denominator is broken in both directions. Requests arrive that are not people, and people get answers without arriving.

None of this makes documentation less measurable. It makes traffic the wrong thing to measure, which is a different problem with a better solution: stop counting visits and start counting outcomes.

The five external developer experience metrics that matter

Five metrics tell you whether developers outside your company can integrate your product: time to first successful API call, integration completion time, support ticket deflection, documentation accuracy rate, and search-log intent gap. Every one of them comes from a system you already run. None of them requires a new platform.

Time to first successful API call

The clock starts when an account is created and stops at the first authenticated request that returns a 2xx. It is the highest-signal single number here because it compresses everything upstream of it: whether the quickstart is findable, whether auth is explicable, whether the first code sample actually runs.

You already have the data. API logs carry one timestamp and the account record carries the other, so the join is a query rather than a project. Most companies have simply never run it.

Yuno reached 15 to 20 minutes after restructuring their documentation, and won a Best Payment API award the same year.

The limit is worth stating plainly: this only sees developers who eventually succeeded. Anyone who gave up before their first 2xx never produces a row, so a healthy median can sit on top of a leaking funnel. Pair it with the count of accounts that never made a successful call at all. That number is more uncomfortable and it moves faster.

Integration completion time

Signup to production traffic. Where the first metric asks whether someone can start, this one asks whether they finish, and it is usually a number your budget owner already tracks under a different name.

The data lives in the CRM or in onboarding milestones rather than in docs analytics. That is exactly why documentation teams rarely quote it, and why it lands harder when they do.

PagBank went from 20 days to 7. Tonder went from two months to 10 days and doubled product adoption [Internal Link: how to reduce API integration time].

This one is heavily confounded, so read it carefully. An enterprise with three engineers assigned finishes faster than a startup with one, whatever your documentation says. Use it as a trend against your own baseline, never as an absolute against somebody else's.

Support ticket deflection

Support ticket deflection is the share of integration questions your documentation answers before a human has to. It converts into money more directly than anything else on this list, because every deflected ticket is engineering time not spent re-explaining something already published.

Getting the number requires your support team to tag cause on integration tickets. The tooling for that is trivial. Persuading people to tag consistently for a full quarter is the actual work.

PagBank cut support tickets by 50%, with CSAT moving from 29% to 89%. Tonder and Nayax each landed around an 80% reduction in support costs.

The trap here catches almost everyone. Deflection also improves when developers stop asking, which is what abandonment looks like from inside a support dashboard. Always read it next to integration completion. If deflection climbs while completion falls, you have not deflected anything. You have lost people quietly.

Documentation accuracy rate

The share of your published code samples and documented behaviors that are still true against the API you shipped this week. Hardly anyone runs this, and when it is bad it invalidates every other number on the page.

It belongs in CI. A code sample is a small program that has to compile and return what the page around it claims, which means it can run on a schedule like any other test. Teams treat samples as prose because they live in documentation, and prose does not have a build step.

Across the portals we have audited, more than 40% of code examples failed against the current API version. The changelog was usually fine, which is the part worth sitting with: the artifact built to announce change was accurate, and the pages it pointed at were not [Internal Link: release notes that hold up].

Samples automate cleanly. Prose does not. A renamed field described correctly in one guide and wrongly in another, a workflow that no longer matches the product, a concept page describing last year's model: all of that still needs a person. Comparing an OpenAPI spec against SDKs, release notes, and published pages with AI assistance is starting to narrow the gap, but the honest position today is that accuracy is part automated and part audited [Internal Link: how to audit your API documentation].

Search-log intent gap

What developers type into your documentation search and fail to find. Not the queries that work. The ones that return nothing useful, and the ones where the content exists under words your customers never use.

Your platform already collects this and almost nobody reads it. A developer searching "login problems" will not find a page titled "identity federation," and that failure is invisible from both directions: your content inventory says the topic is covered, and your traffic report shows a session.

It is also the cheapest product feedback available anywhere. A search that recurs weekly with no good answer is a customer telling you what to document or build next, in their own vocabulary.

The limit is that it needs volume to mean anything. On a small portal you get a handful of queries a week, which makes it a signal to read rather than a KPI to report. Treat it as the thing that explains the other four.

What good actually looks like

The companies with the strongest external metrics did not get there by buying a better documentation platform. They got there by restructuring content, then keeping someone accountable for it afterward. This is why identical tooling produces opposite outcomes at different companies, and it is the part most measurement advice leaves out.

Nayax is the clearest version. Ten or more products, each with its own documentation site, each with its own search box and its own name for the same concept. Consolidating them into a single portal produced 80,000+ monthly visits, one search index, one glossary Related: structuring documentation for multiple products.

Most of that content was already accurate. What was broken was that a developer integrating two Nayax products had to learn two navigation models before writing a line of code.

The counterexample matters more. CarePortals saves 20+ developer hours a week on ReadMe, a platform with real information-architecture limits on complex multi-product APIs. Those limits are close to the reason other companies leave it. CarePortals is fine because their API is not complex and three products fit the structure comfortably.

Same category of tooling. Opposite constraints. Both worked.

That is an inconvenient finding for anyone selling a documentation platform, which is roughly why you rarely read it.

So what actually varied? Across these engagements the variable that tracked with the outcome was whether anyone owned the documentation after launch. Not who wrote it. Who was accountable for it still being true six months later.

That has no field on any dashboard in the first section of this post. It has no line in DORA. It is the best available predictor of whether the five metrics above move, and it is a staffing decision rather than a measurement one.

Which is the awkward conclusion of any measurement exercise. Instrumentation tells you the documentation stopped being true. It does not tell you whose job it was.

How to report this upward

Translate every metric into the business line it moves. A budget owner does not fund a documentation score, and presenting one is how documentation work gets filed under maintenance instead of growth.

The translation is mechanical:

Nothing on the right side mentions documentation. That is deliberate. The person approving budget is solving for conversion, cost, and risk, and the fastest way to lose the room is to make them do that translation themselves.

Then report two of them, not five.

Pick two, baseline them this quarter, report the delta next quarter. Five numbers with no history is a dashboard nobody opens twice, and a metric without a baseline is an opinion with a number attached to it.

If you want the pair that argues best, take time to first successful call and support ticket deflection. One is revenue speed and the other is operating cost. Between them they cover both halves of the case, and neither requires anyone in the room to care about information architecture.

One last point, and it is the sharpest version of this argument for anyone selling into financial services. During partnership diligence the other side reads your developer portal before the first call. Their engineers form a view of how hard you will be to integrate with, and that view arrives at the table ahead of you.

That review happens whether or not you instrumented anything. The only variable is whether you know what they found.

Key takeaways

• Developer experience metrics describe two different populations. Nearly every guide covers the internal one, and if you sell an API the external one is where the revenue sits.

• Page views stopped describing developers once agent traffic went from 15.2% of documentation requests to 66% inside seven months. Traffic-based reporting is measuring a denominator that changed underneath it.

• Time to first successful API call is the highest-signal single number available, and most companies already hold the data needed to compute it.

• Documentation accuracy is the metric almost nobody runs. Audits routinely find more than 40% of code samples failing against the current API version, and a bad accuracy rate invalidates every other number on the dashboard.

• None of these survive unclear ownership. The same platform produces opposite outcomes depending on whether anyone is accountable for the documentation after launch.

If you want to start somewhere, start with accuracy. It costs nothing to measure: run your own code samples against your current API version and count what fails . That number tends to end the internal debate about whether documentation is a priority.

And if what you conclude is that you would rather not own the instrumentation, the upkeep, or the question of who is accountable in six months, that is the conversation to have [Internal Link: developer portal services].