DevRel metrics: how to measure developer relations ROI

DevRel metrics show whether your work helps developers adopt your product. The ones worth reporting connect an activity, such as a workshop or a tutorial, to an outcome leadership already tracks, such as activated accounts, retained developers, or qualified pipeline.

Take a hypothetical workshop with 500 attendees. That number answers how many people showed up. Leadership wants to know how many of them made a first successful API call afterward, and how many were still using the product a quarter later.

This guide covers how to set up that measurement, which metrics to track at each stage of the developer journey, and how to report the results upward.

What are DevRel metrics?

DevRel metrics measure how developer relations activities contribute to developer adoption and business growth. They cover everything from event attendance and community engagement to product activation, retention, and influenced revenue.

Measuring that impact is difficult because developers rarely follow a straight path to adoption. Kim Maida, former DevRel leader at Cloudinary, describes how a developer might attend a talk, watch a sponsored video, register for a product, subscribe to a newsletter, and eventually write about it. Each interaction may influence adoption, making it difficult to attribute results to a single activity.

This is why DevRel teams need to distinguish activity metrics from outcome metrics. Event attendance, GitHub stars, and video views show reach and engagement. Activation, repeat product usage, and retention help establish whether those activities are contributing to adoption.

Seth Juarez's DevRel Handbook offers a useful framework: People Metrics measure who participated, Action Metrics track what they did next, and Quality Signals assess the value of those interactions. Together, they help teams evaluate DevRel performance beyond attendance and impressions.

How to set up DevRel measurement

Before choosing DevRel metrics, define what each program is expected to achieve and how you'll measure it. Here's a four-step process.

1. Align each program with a business objective: A hackathon designed to collect product feedback needs different metrics from one focused on developer activation.

Phil Leggetter's AAARRRP framework maps DevRel activities to seven business goals: Awareness, Acquisition, Activation, Retention, Revenue, Referral, and Product. Use it to identify which stage each program supports.

2. Define what activation means for your product: Activation is the first meaningful action that shows a developer is getting value. Leggetter uses the first API call as an example.

For a database, it might be the first successful query. For a deployment platform, it could be the first live deployment. Agree on the activation event with your product team before launching the program.

3. Connect your data sources: Use product analytics tools like PostHog to track signups and activation, GitHub Insights for repository activity, Discord or community analytics for participation, and your CRM for pipeline and revenue.

Add UTM parameters to links shared through workshops, tutorials, and campaigns to track referred traffic and conversions where attribution data is available.

Our developer marketing metrics guide explains how to track events such as API key creation and first successful setup.

4. Define attribution rules and reporting responsibilities: Decide what qualifies as a DevRel-sourced conversion versus a DevRel-influenced conversion. Assign an owner to each metric and review results monthly, with a quarterly report for leadership.

Scott McAllister, co-author of Developer Relations Activity Patterns, shared a similar recommendation on our Everything Outside Code podcast: define the goal and success criteria before launching an activity.

For example, if a tutorial aims to generate product trials, track how many readers start a trial through its call to action. This gives the team a measurable outcome to evaluate.

How to measure DevRel across the developer journey

Once you've defined your goals and tracking setup, the next step is to measure how developers progress from discovering your product to using and recommending it.

At Hackmamba, we use our Developer Adoption Architecture to map that journey across five stages: Discover, Evaluate, Integrate, Advocate, and Compound.

This works alongside Phil Leggetter's AAARRRP framework. AAARRRP helps define the business objective, while the Developer Adoption Architecture identifies what to measure at each stage.

The stages map as follows:

• Discover and Evaluate: Awareness and Acquisition
• Integrate: Activation
• Advocate: Referral
• Compound: Retention and Revenue

AAARRRP's Product goal, which involves collecting developer feedback to improve the product, applies throughout the journey.

DevRel metrics by stage

Stage	What you're trying to achieve	Metrics to track
Discover	Reach developers looking for a solution	Developer-channel traffic, attributed signups
Evaluate	Help developers assess whether the product fits their needs	Tutorial engagement, demo completions, evaluation-to-signup conversion rate
Integrate	Help developers complete their first successful implementation	Activation rate, successful integrations, time to first value
Advocate	Encourage developers to contribute and recommend the product	Merged external pull requests, referral signups, unprompted mentions
Compound	Keep developers using the product and expanding adoption	Developer retention, repeat usage, members active for three consecutive months

These metrics answer different questions. A workshop might generate 500 visits, but those visits tell you little about adoption until you track how many developers sign up and complete their first integration.

Matthew Revell's DevRel Flywheel report describes a similar progression. At the implementation stage, it connects increased product usage and revenue with identifying and resolving onboarding problems.

Prioritize metrics based on company stage

You don't need to give every stage equal attention. When Phil Leggetter led DevRel at Pusher during its seven-person, seed-stage phase, he prioritized awareness, acquisition, and product feedback.

The same principle applies when setting your measurement priorities:

• Early-stage companies: Focus on qualified developer reach, signups, activation, and onboarding feedback. These show whether you're reaching the right developers and helping them get started.

• Companies with an established developer base: Add retention, repeat usage, referrals, and expansion. These show whether adoption continues after the first successful integration.

The goal is to track how developers move between stages and identify where they're dropping off.

The most important DevRel metrics and how to track them

The table below covers the metrics we recommend most often for devtool, API, AI, and infrastructure companies. Each one includes instructions for calculating it, so two people on your team get the same number.

Metric	What it measures and why it matters	How to track it
Developer activation rate	Percentage of new signups who reach their first meaningful product milestone. Shows whether developer interest turns into actual usage.	Activated accounts ÷ new signups in the same cohort × 100, using product analytics.
Time to first value	Time developers take to reach activation. Shorter times indicate a smoother onboarding experience.	Median time between signup and the activation event.
Tutorial-to-activation conversion	Percentage of tutorial readers who activate. Identifies content that drives product usage.	Activated accounts with a tracked tutorial touchpoint ÷ unique tutorial readers × 100.
Workshop-to-activation conversion	Percentage of workshop attendees who activate afterward. Shows whether events lead to product adoption.	Attendees who activate within 30 days ÷ total attendees × 100.
Developer retention	Percentage of activated developers who remain active over time. Distinguishes sustained usage from one-time trials.	Developers active in month N ÷ developers in the original activated cohort × 100.
Active community contributors	Developers who answer questions, submit pull requests, or publish content. Indicates how actively members support the community.	Count unique contributors each month across Discord, GitHub, and forums.
Community support resolution	Percentage of community questions resolved. Helps assess community support effectiveness and potential reduction in support workload.	Resolved questions ÷ total questions × 100. Also track median time to first useful answer.
DevRel-sourced and influenced pipeline	Sales opportunities generated or influenced by DevRel activities. Connects DevRel contributions to potential revenue.	Track CRM opportunities with DevRel as the first touch (sourced) or a recorded touchpoint before close (influenced).
Developer advocacy	Unprompted recommendations from developers. Indicates whether users are voluntarily promoting the product.	Count unpaid, unsolicited product mentions, talks, posts, and referrals each month.

For individual content assets and events, the DevRel Handbook's Engagement Ratio helps measure actions relative to audience reach.

For example, if 500 developers watch a video and 50 click through to a code sample, the engagement ratio is 0.1. If 100 workshop attendees generate 120 tracked actions, the ratio is 1.2. This helps compare engagement across activities, though it doesn't necessarily indicate product adoption.

You can also measure DevRel's impact through business outcomes. For example, Hackmamba's published results include a 10% reduction in developer support requests for Flutterwave within six months and 50% faster integration for Celo following a three-week documentation overhaul. These metrics connect developer education and documentation improvements to support efficiency and onboarding.

Treat vanity metrics as context

Event registrations, GitHub stars, and community size are useful context, but they should never stand alone in a report. Each one shows how many people noticed you, but none shows whether those people adopted the product.

Pair every activity number with the outcome it was meant to drive. Report registrations next to workshop-to-activation conversion, and community size next to active contributors.

As Bob Watson, Senior Technical Writer at Google, put it in our session on documentation metrics: "Metrics can tell you whether something has happened, but they can never tell you why."

What is the difference between DevRel metrics and KPIs?

A metric is any number you track. A key performance indicator (KPI) is one of the few metrics tied to a business objective, with a target and an owner. Your team might track 30 metrics and report four KPIs.

Split your KPIs into leading and lagging indicators. Leading indicators move first and predict results, such as tutorial-to-activation conversion or time to first value. Lagging indicators confirm results after the fact, such as 90-day retention or influenced revenue. Leadership needs both: the leading ones to see momentum and the lagging ones to see impact.

Pick three to five KPIs, each traceable to an objective from your setup step. Kim Maida recommends setting KPI goals as month-over-month percentage growth, which pushes the team toward work that keeps producing results over time.

Here is an example KPI set for a hypothetical devtool company focused on developer adoption:

KPI	Type	Target example
Developer activation rate	Leading	Increase from 22% to 30% this quarter
Median time to first value	Leading	Reduce from 40 minutes to 20 minutes
90-day developer retention	Lagging	Hold above 35% for each monthly cohort
DevRel-influenced pipeline	Lagging	Grow 15% quarter over quarter

The targets in this table are illustrative. Set yours from your own baseline.

How to prove DevRel value and ROI to leadership

Leadership reporting works when each audience sees the numbers it already uses. A CEO wants to know whether DevRel moves company growth, and a CFO wants cost against return. Engineering leaders care about product feedback that improves the roadmap, and marketing leaders want to see how DevRel feeds the funnel they own.

Report pipeline in two ways. DevRel-sourced pipeline counts opportunities where DevRel was the first touch, such as a developer who found you through a workshop and later brought in their company. DevRel-influenced pipeline counts opportunities where DevRel touched the account at any point before close.

Sourced is the stricter claim, and influenced is the broader one, so label which one you report.

For relationships that lead to deals, partnerships, or programs, Mary Thengvall's DevRel Qualified Leads give you a countable unit. Maida's version requires a name, a company, a stated intent, and a follow-up action before a conversation counts.

When reliable financial attribution exists, calculate ROI the standard way: value generated minus program cost, divided by program cost. Maida's Keystone DevRel Metrics framework handles the harder part, assigning value. You pick a metric the company already prices, such as a registration, and value DevRel outcomes as fractions or multiples of it.

At Cloudinary, Maida's team valued one DevRel Qualified Lead at 25 registrations. Treat that as one company's calibration, and run her plausibility checks against company revenue and the DevRel budget before you present any total.

A hypothetical example. A devtool company spends $40,000 on a quarter of workshops and tutorials. Those programs reach 2,000 developers, 300 of whom activate.

Of the activated developers, 12 work at companies that later open sales opportunities, and four close for a combined $120,000 in first-year revenue. On a sourced basis, the program returned $120,000 on $40,000, an ROI of 200%. Every number in this example is invented to show the math.

Phil Leggetter, now Head of Developer Experience at Hookdeck, described what this looks like at scale on Everything Outside Code. At Vonage, he said, his DevRel team cost about $3.5 million a year and was directly accountable for about $6 million in self-serve revenue.

He called that accountability for revenue unusual for a DevRel team, and said those were the figures he had to state to get buy-in and support from executives.

A one-page leadership report template

Copy this structure for your quarterly report, and keep it to one page.

DevRel report: [Quarter, Year]

KPIs                         This quarter   Last quarter   Change
Developer activation rate    __%            __%            __ pts
Median time to first value   __ min         __ min         __%
90-day developer retention   __%            __%            __ pts
DevRel-sourced pipeline      $__            $__            __%
DevRel-influenced pipeline   $__            $__            __%

Key outcomes
- [Outcome tied to a business objective, with its number]
- [Product change shipped from developer feedback]

What we learned
- [One finding that changed our plan]

Next quarter
- [Two or three priorities, each tied to a KPI above]

How to build a DevRel measurement framework in 90 days

You can build a working DevRel measurement framework in one quarter, from defining KPIs to presenting your first leadership report.

Timeline	Action	Expected output
Weeks 1–2	Define business objectives, activation events, and KPIs.	Three to five KPIs and a clear activation definition agreed with leadership.
Weeks 3–6	Implement event tracking and connect data sources.	Activation events tracked in product analytics and UTM parameters applied to DevRel links.
Weeks 7–10	Establish baselines and identify measurement gaps.	Baseline figures for each KPI and a list of tracking gaps.
Weeks 11–13	Review performance and prepare the leadership report.	A one-page report showing results against baselines, key findings, and next steps.

Establish your baselines before preparing the report. Without them, you won't know whether developer activation, retention, or other outcomes have improved.

Final thoughts

A useful DevRel measurement framework should answer three questions: Are we reaching the right developers? Are they using the product? Are they continuing to use it?

Start with three to five metrics tied to business goals, track them consistently, and use the results to decide which programs to improve, scale, or stop.

At Hackmamba, we work with DevTools, API, and infrastructure companies to build DevRel programs that drive developer adoption. If you need help defining KPIs, tracking activation, or measuring business impact, explore our DevRel services.