Analytics & Metrics

Organise metrics by journey stage so each has a clear purpose:

Choose a North Star that captures developer value, such as "weekly active developers making successful API calls", and 3–5 supporting metrics. Mary Thengvall's The Business Value of Developer Relations and the DevRelCon metrics talks provide practical frameworks.

Vanity metrics look good but don't change decisions: follower counts, total community size, page views without context, repo stars.

Signal metrics reflect real developer behaviour and connect to outcomes: activation rate, active usage, retention, questions answered by members, and docs searches that end in success.

A quick test: "If this number doubled, would we do anything differently, and would the business be better off?" If not, it's vanity.

Vanity metrics aren't useless. Reach can be an early indicator, and leadership sometimes likes them. Just never report them alone. Pair each with a signal: "Our tutorial got 20k views and 1,200 developers created an API key from it."

Track content in a simple, consistent way:

• UTM parameters on every link you share (source, medium, campaign) so sign-ups can be attributed.
• A content inventory: a spreadsheet or database of every piece with URL, date, type, goal and owner.
• Monthly snapshot: views, average engaged time, conversions (sign-ups, key creation, repo clones) and search position for target terms.
• Quarterly review: top 10 and bottom 10, update or retire, and double down on patterns.

Be honest about attribution limits. Developers often read content, leave, and sign up weeks later from a colleague's link. Use self-reported attribution ("How did you hear about us?") alongside analytics. It often surfaces DevRel impact that tools miss.

Community analytics answer: is this place alive, helpful and growing in the right way?

Core measures:

• Activity: messages, posts and events per week (trend, not absolute)
• Activation: new members who participate within 14 days
• Responsiveness: median time to first reply; percentage of questions answered
• Self-sufficiency: percentage of answers from non-staff
• Retention: cohort retention by join month
• Contributor funnel: members → contributors → maintainers or leaders

Most platforms have built-in insights (Discord, Discourse, GitHub). Community platforms and CHAOSS metrics help standardise. Look at cohorts, not totals: a growing total can hide collapsing retention.

Executives give your report about 30 seconds. Design for that.

• Lead with the headline: "DevRel-sourced developers activate at 2× the rate of paid acquisition", then show the chart that proves it.
• One message per chart. Title charts with the insight, not the metric name.
• Choose simple forms: line charts for trends, bar charts for comparisons. Avoid pies and 3D.
• Highlight what matters with colour; grey out everything else.
• Context: targets, previous period and what changed.
• Connect to company goals: use leadership's language (revenue, retention, cost), not DevRel jargon.

Storytelling with Data is the definitive guide, and Cole Nussbaumer Knaflic's talk at Google is a great 60-minute primer.

Two kinds of tools answer different questions:

• Web analytics (Google Analytics 4, Plausible and similar) show how developers find and use your content: traffic sources, pages, engagement and conversions from docs and blog.
• Product analytics (Amplitude, Mixpanel, PostHog and similar) show what developers do in the product: sign-up → key creation → first call → active usage, as funnels and cohorts.

DevRel's power move is connecting the two: which content or events lead to activation in the product? That usually needs consistent UTMs, a shared user identifier after sign-up, and collaboration with your data or growth team.

Learn the basics of events, funnels, cohorts and segments. You don't need to be an analyst, but you need to ask good questions of the data and read the answers correctly.

Data's real job is deciding what to stop, start and scale.

A quarterly iteration loop:

1. Review each program against its goal metric.
2. Classify: scale (clearly working), fix (promising but underperforming), stop (not working, no clear fix).
3. Experiment: run small, time-boxed tests of new ideas with a clear success criterion.
4. Reallocate time and budget toward what works.
5. Document decisions and why, so you learn over time.

Stopping things is the hardest and most valuable part. Every program you stop frees time for one that works. Be as rigorous about your favourite program as your least favourite.

Regular reporting builds trust and protects your team's budget.

• Weekly (team): what shipped, key numbers and blockers. A few bullets.
• Monthly (manager and partners): progress against goals, highlights, "voice of the developer" insights and product feedback status.
• Quarterly (leadership): outcomes versus OKRs, 2–3 stories with data, what you learned, and the plan and asks for next quarter.

A good report structure: headline → metrics vs targets → stories → insights from developers → next steps and asks.

Include stories every time: a developer who shipped with your help, a community member who became a contributor, a product fix driven by your feedback. Numbers get attention; stories get remembered and repeated.