DevRel measurement connects the team’s work to outcomes the business recognises. A useful measurement system moves from business outcomes through community behaviour to the activities a team can change, with the evidence for each connection stated explicitly.
Three layers of metrics
One model groups DevRel metrics into three layers. A programme can track all three while stating the evidence for any claimed causal connection between them.
Layer 1: Program metrics (business outcomes)
What the company actually cares about. Examples:
- New active developers acquired.
- Time to first hello world (system-wide median).
- Activation rate (% of new signups who reach an activation milestone).
- 30-day / 90-day retention.
- Revenue influenced.
- Developer-qualified leads (DQLs).
- Product feedback items shipped.
These are what you report to executives. They should map cleanly to AAARRRP goals.
Layer 2: Community metrics (ecosystem health)
What’s happening in the developer community around the product. Examples:
- Active community members (DAU / WAU / MAU).
- Contributor return rate at 90 days.
- NPS / sentiment.
- First-response time in community.
- Member orbit-level distribution (Explorers, Participants, Contributors, Advocates).
- Geographic and demographic distribution of the community.
These are leading indicators for Layer 1 outcomes. A weakening community in Q1 predicts weakening retention in Q2.
Layer 3: Activity metrics (what the team does)
What the DevRel team itself produces. Examples:
- Blog posts published.
- Conference talks delivered.
- Videos shipped.
- Newsletter subscribers and open rate.
- GitHub stars, social followers.
- Workshop attendance.
These are easy to measure and easy to game. They matter only insofar as they drive Layer 2 and Layer 1 outcomes, so an executive report should connect them to those outcomes rather than present them alone.
The narrative connection
Mature DevRel reporting connects all three layers explicitly. A reportable insight looks like:
Tutorial content (Layer 3: 12 new tutorials published, 78% completion rate) drove measurable docs engagement (Layer 2: 23% increase in tutorial-page DAU), which contributed to improved activation (Layer 1: 18% reduction in median TTFHW, 7-point activation-rate lift).
A team that reports this evidence consistently is better prepared for budget reviews.
The “we don’t measure” problem
State of Developer Relations surveys consistently show a non-trivial share of DevRel teams report they “don’t measure” rigorously. The share has dropped over time, from ~14% in 2022 to ~9% in 2023 (per SlashData), but remains higher than executives find acceptable.
If you are not measuring:
- Pick three metrics this quarter. One Layer 1, one Layer 2, one Layer 3.
- Instrument them. Even if crudely.
- Report weekly. To yourself; monthly to your manager; quarterly to executives.
- Iterate. As you learn what matters, refine.
Starting with three keeps the initial instrumentation bounded. Add metrics as the team learns which relationships it can support with evidence.
What not to measure (or, at least, what not to report up)
Some commonly-tracked metrics are noisy enough that reporting them up creates more confusion than insight:
- GitHub stars in isolation. See Vanity metrics.
- Social follower counts. Same.
- Conference attendance numbers (raw, without engagement context).
- Newsletter subscriber counts without engagement data.
- Total blog page views without per-post analysis.
- “Reach” without conversion data.
These can be useful internally as diagnostic signals. For executive reporting, connect them to an outcome and state the evidence for that relationship.
Connecting to AAARRRP
A useful exercise: take your current set of metrics and map each one to AAARRRP goals.
| Metric | Awareness | Acquisition | Activation | Retention | Referral | Revenue | Product |
|---|---|---|---|---|---|---|---|
| New signups | ● | ||||||
| TTFHW (median) | ● | ||||||
| 90-day retention | ● | ||||||
| Member-generated content | ● | ● | |||||
| DQLs | ● | ● | |||||
| Product feedback shipped | ● | ||||||
| Conference attendance | ● |
If metrics cover only Awareness and Acquisition, the measured work is primarily marketing. If they cover only Activation and Retention, the measured work is primarily developer success. A programme that claims broader DevRel scope should measure the additional goals it serves.
Frequency and audience
Different metrics serve different audiences and cadences:
| Audience | Frequency | Focus |
|---|---|---|
| Daily team standup | Daily | Layer 3 activity check |
| Weekly team review | Weekly | Layer 2 community signals |
| Monthly leadership | Monthly | Layer 1 outcomes + commentary |
| Quarterly board / exec | Quarterly | Layer 1 outcomes vs. goals, big strategic stories |
Specific metric families
The remaining files in this directory drill into each family:
- Activation metrics: TTFHW, activation rate, DQLs, the signup-to-shipped funnel.
- Community metrics: Active members, contributor return, NPS, sentiment, orbit metrics.
- Business impact metrics: Revenue attribution, influenced pipeline, ROI.
- Vanity metrics: Stars, followers, and other deceiving numbers.
Primary sources
- SlashData, State of Developer Relations reports (2022, 2023, 2024).
- Mary Thengvall, The Business Value of Developer Relations (Apress, 2018).
- Phil Leggetter, AAARRRP framework writings.
- DX (getdx.com), State of Developer Experience reports.
- Kamran Ayub, “DevRel metrics” reference (kamranayub.com).