Latest site update: "Whether a conference covers your travel, on every open CFP"

All stacks

The DevRel measurement stack

How do you measure developer relations without inventing numbers?

The honest version of DevRel measurement is narrower than the dashboards suggest: a handful of things you can actually observe, each with a stated limit. Seven steps from web analytics to package-level adoption to what AI assistants say about you when you are not looking.

By Fabian HugUpdated

7 decisions · 10 tools

01 · Decision

Start from a decision, not a dashboard

Every tool below produces numbers. Only some of those numbers change what you would do next, and the rest become a monthly slide nobody acts on. Before installing anything, write down the decision the number is supposed to inform - which content to make more of, which integration to build, whether to keep sponsoring an event. If no decision hangs on it, skip the step; a metric with no decision behind it is a reporting obligation you are volunteering for.

02 · Decision

Measure your own pages first

The surfaces you control are the only ones where you see the whole funnel, so start here even though it is the least exciting part. Both of these run without a consent banner in most configurations, which matters on developer content: the banner itself costs you more readers than the analytics gains you.

03 · Decision

Follow adoption past the download

Pageviews stop exactly where the interesting part starts. Package and container telemetry is the one signal that connects a piece of content to somebody actually running your software, and it is the closest thing DevRel has to a conversion event. Expect it to be directional: registries cache, CI pulls inflate everything, and neither of those is a person.

04 · Decision

Read the repository honestly

Stars are a vanity metric that executives already believe in, so the useful move is to bring the better numbers alongside them rather than fight about it: first-time contributors, issue response time, whether activity is broadening or concentrating in one maintainer. That last one predicts trouble earlier than any engagement chart.

05 · Decision

Count people, not events

Every tool above counts actions. This one counts humans across them, which is what lets you say a specific person read the docs, filed an issue, and turned up at a meetup rather than reporting three unrelated increments. It is also the step with the heaviest setup cost, so it belongs after you have something worth joining up.

06 · Decision

Catch what you did not publish

Mentions elsewhere are evidence you did not manufacture, which makes them unusually credible in a discipline that mostly reports on its own outputs. Cheap to set up, and the alerts double as an early warning when something breaks in public.

07 · Decision

Check what AI assistants say about you

A growing share of developers ask an assistant before they visit your site, and what it says is downstream of documentation you may not have written for that purpose. This is the newest and least settled measurement surface here, so treat the numbers as a rough read on whether you appear at all rather than as a rank you can optimise.

How to read this

These are shortlists, not rankings. Every tool named here has its own directory entry with the facts it publishes and the date they were checked, and the order within a step is the order it was written in, not a verdict about which is better. We do not run these tools in production and we take no money for inclusion. Where a step has two options that genuinely suit different situations, it says which is which instead of picking one.

Upcoming events on these topics