Product analytics earns its place when a number changes what gets built. Most implementations track everything and change nothing, because they were installed before anyone decided which questions the roadmap actually needs answered.
This guide covers the small set of metrics that reliably inform product decisions, how to instrument for them, and how to avoid the traps that make analytics confidently misleading.
Key takeaways
- Activation predicts everything downstream: The share of new users reaching first value is the most useful single number.
- Retention curves beat retention rates: Whether the curve flattens tells you if you have a product.
- Feature usage needs a denominator: Raw counts reward the features with the most traffic.
- Instrument for questions, not for coverage.
Track these six, and little else
| Metric | Definition | What it decides |
|---|---|---|
| Activation rate | Share of new users reaching first value | Whether onboarding works |
| Time to first value | How long that takes | Where the friction is |
| Retention curve | Share still active at day 1, 7, 30, 90 | Whether the product is worth keeping |
| Feature adoption | Users who used it ÷ users who could | Whether a feature earned its build |
| Task completion | Share who finish a started journey | Where the product fails |
| Business outcome | Revenue, orders, cases resolved | Whether any of it mattered |
Six is enough. Analytics implementations that track two hundred events produce a warehouse and no decisions, because nobody knows which numbers to look at when a question arises.
Define first value before anything else
Activation depends entirely on what counts as first value, and that definition is a product judgement rather than a technical one.
It is the moment a user gets what they came for: the first order placed, the first document uploaded, the first team member invited, the first report generated. Not registration, which is a step toward value rather than value itself.
Once defined, activation rate and time to first value become the two most actionable numbers you have. Almost every product with a retention problem has an activation problem underneath it.
Read the retention curve, not the number
A single retention percentage hides the shape, and the shape is the information.
A curve that declines and then flattens means a group of users found lasting value. You have a product, and the work is widening that group. A curve that declines to zero means nobody stays, and no amount of acquisition will fix it.
Cohort by signup period. If the day-30 retention of recent cohorts is better than older ones, your changes are working; if the aggregate number is flat, improvement in recent cohorts can be entirely hidden by the size of the older ones.
Give feature usage a denominator
Raw usage counts tell you which features get traffic, which mostly reflects where they sit in the interface.
The useful measure is adoption among users who could plausibly use the feature: of the people with more than one team member, how many used sharing. That distinguishes a feature nobody wants from one nobody can find, completely different problems with completely different fixes.
Also look at repeat usage. A feature used once by many and twice by nobody solved a curiosity rather than a need.
Instrument deliberately
Name events consistently before shipping the first one, a short convention agreed in advance prevents the most common reason an analytics implementation has to be redone.
Capture for each event: what happened, when, who (a stable identifier across sessions and devices), and the context needed to segment later. Without a stable identifier, one person appears as four visits and every per-user metric is wrong.
Verify events fire correctly from a production build before relying on them. Instrumentation that works in development and silently fails in production is a common and painful discovery, usually made when someone asks a question three months later.
Segment or be misled
Aggregate product metrics routinely hide the thing you needed to know. The same activation rate can be new customers succeeding and enterprise customers failing, or desktop working and mobile broken.
Segment by device, plan or customer type, acquisition channel, and cohort. Look for the segment with the worst number and enough volume to matter. That is the project, and it is invisible in the average.
Pair the number with a reason
Analytics tells you where users stop. It does not tell you why, and inferring the reason from the shape of the funnel is where most analytics-led decisions go wrong.
Pair every finding with something qualitative: session recordings of that step, support tickets mentioning it, or three short interviews. Ten minutes watching someone fail explains more than a month of funnel data.
Keep it lawful and proportionate
Under GDPR and Turkish data protection law you need a lawful basis, a stated purpose and proportionate scope. In the EU, analytics cookies generally require consent, which means a share of users will not be measured, design for that rather than assuming full coverage.
Collect what answers a defined question, aggregate where possible, avoid unnecessary personal identifiers, and set a retention period you actually enforce. Server-side capture of essential operational measures is both more reliable and easier to justify than client-side tracking of everything.
Close the loop on every change
The point of the instrumentation is the decision. Before shipping a change, write down which metric should move and by how much; afterwards, check.
Teams that skip this ship continuously and learn nothing, because every release changes several things and nobody attributes any of it. One change, one prediction, one measurement is slower per release and far faster at accumulating knowledge.
Related guides
- Alongside Product Analytics: Metrics That Should Shape Your Roadmap, continue with How to Build a Business Case for Custom Software.
- Alongside Product Analytics: Metrics That Should Shape Your Roadmap, continue with How to Choose a Digital Transformation Partner.
If the work prompted by Product Analytics: Metrics That Should Shape Your Roadmap leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Software Project.
Ali Boran Gazel