Your DevRel programme reports growing impressions, follower counts and packed conference sessions, but finance is asking what it returns. How would you show whether the work is driving adoption, and how would you defend the budget when you cannot attribute cleanly?

Short answer

Split your numbers into reach, engagement and behaviour, and only ever claim the behavioural ones as results. Where attribution is impossible, defend the programme with cohort comparisons, holdouts and counterfactual costs rather than an invented revenue figure.

In a strong developer relations answer, the proving devrel is working without attribution detail should connect the decision to a visible consequence.

Sort the numbers into three tiers before defending any of them

Impressions, follower growth and session attendance are all real numbers, and none of them is a result. They measure how many people the programme reached, which is an input you bought — with a conference slot, a publishing schedule, a headcount — and inputs are how you diagnose a programme, not how you justify one. The distinction to hold in front of a finance partner is between reach, engagement and behaviour. Reach is who saw it. Engagement is who spent effort on it: scrolled a tutorial to the end, cloned the sample repository, asked a question afterwards.

Behaviour is who did something to your product that they were not doing before: created their first key, made a first successful call, moved from sandbox to production, upgraded to a version they had been avoiding.

Only the third tier is defensible as a result, and the honest position is that most DevRel dashboards are heavy on the first tier because it is the tier that requires no instrumentation. A follower count arrives free. Knowing that seventeen developers who read a specific migration guide subsequently completed the migration requires someone to have joined content analytics to product telemetry, and that work is usually the actual gap rather than any shortage of enthusiasm for measurement.

The funnel is where the argument gets specific

The useful move is to name the steps between a developer encountering your content and a developer depending on your API, then say which of those steps you can currently see. Most programmes can see the first and the last and nothing in between, which is precisely why the argument collapses into impressions.

flowchart TD
    A[Developer sees content<br/>or talk] --> B[Reads or watches<br/>to a decision point]
    B --> C[Creates a sandbox key]
    C --> D[First successful<br/>API call]
    D --> E[Second week of<br/>continued calls]
    E --> F[Production traffic<br/>and a paid tier]
    B -.->|invisible without<br/>joined analytics| D

The dotted edge is the whole problem. If nothing links the content session to the key creation, every claim you make about the middle of that funnel is inference, and a competent finance partner will treat it as such. Closing that gap is usually unglamorous: a consistent campaign parameter on every link you publish, a signup field asking how the developer found you that you actually read, or a sandbox key that carries the source it was created from. None of that requires attribution science, and it converts the middle of the funnel from anecdote into a number you can put in a sentence.

Defending it without pretending attribution is solved

Do not claim a revenue figure you derived by assigning a fraction of new business to talks. It is the fastest way to lose the argument, because the assumption doing the work is visible and someone will pull on it. Three defences hold up better.

The first is cohort comparison. Compare developers who touched a specific piece of content with matched developers who did not, on a behavioural metric such as reaching a first successful call within a week. This is correlational and you should say so, but a consistent gap across several cohorts is real evidence, and it is falsifiable, which is what makes it credible.

The second is a deliberate holdout. Delay a new guide for one region or one segment, then compare. This is harder to justify than it sounds, because withholding help from developers has a cost, so it works best for net-new material where the counterfactual is genuinely "nothing existed yet" rather than removing support people already had.

The third, and the one most often left out, is counterfactual cost. If support tickets on authentication fell after a guide shipped, the guide has a measurable value in support hours, and support hours have a rate. If a partner integration that took an engineer three weeks of hand-holding now takes a working sample and two days, the difference is a real saving with a real owner. These numbers are smaller than the ones a revenue claim produces, and they survive being questioned, which makes them worth more in the room.

Where this answer usually goes wrong: conceding the whole framing

The failure mode is not choosing bad metrics. It is accepting the premise that a function which cannot attribute revenue is therefore unmeasurable, and retreating either to impressions or to "you cannot measure community, you just know". Both readings end the same way at budget time. The position that holds is narrower and more honest: attribution of a specific developer's decision to a specific talk is genuinely not solvable, and it does not need to be, because the programme's value shows up as a distribution shift in behavioural metrics that you can instrument, plus a set of costs that measurably did not happen. State which claim you are making, state its evidence class, and never dress an inference as a measurement.

The second-order thing an interviewer listens for is whether you would let a metric change what you do. A candidate who says the tutorial series is working because traffic is up, and would keep publishing it either way, has described a reporting habit rather than a measurement practice.

Reach is what you bought, behaviour is what you achieved, and the credibility of a DevRel programme rests entirely on never confusing the two in front of the person holding the budget.

© 2026 Preptima. Originally published at preptima.com.