Every success metric defined in a mini-PRD needs a real tracking event behind it, or it can never actually be checked.
1Ship the Metric With the Feature, Not After It
Instrumentation added after launch misses the early usage window, often the most informative period for catching problems fast. Treating the tracking event as part of the feature's definition of done, in the same commit, closes this gap.
2Track What Maps to the Metric, Not Everything
A small number of well-chosen events (did they reach the screen, did they take the action, did it succeed) tied directly to the defined success metric produces usable signal. Tracking every click on the page produces noise that's just as hard to act on as no data at all.
3Step-by-Step Breakdown
Defining a success metric ('export click-through rate') only becomes checkable if a real event fires every time the relevant action happens. Without the event, the metric is just a sentence — instrumentation is what turns it into a number you can actually look up later.
Add the tracking event in the same commit as the feature itself, not as a follow-up task. Shipping a feature without its instrumentation means the first week of real usage — often the most informative — goes unmeasured, and 'add tracking later' tends to slip.
Why should instrumentation be added in the same commit as the feature it's measuring, rather than as a follow-up task?
- →It doesn't matter when it's added, as long as it eventually happens
- →Shipping without it means real usage during the most informative early period goes unmeasured, and 'add it later' tasks tend to slip indefinitely
- →Analytics platforms require same-commit instrumentation to function
- →It makes the pull request diff smaller
Instrumenting everything indiscriminately creates noise that's as unusable as instrumenting nothing. Track events that map directly to your success metric and a few surrounding signals (did they reach this screen, did they complete the action) — not every possible click on the page.
Why is tracking every possible click and interaction on a page not actually better than tracking a focused set of meaningful events?
- →Tracking everything is always better with no downside
- →Excessive, unfocused tracking creates noise that makes it harder to find the signal that actually maps to your success metric
- →Analytics platforms charge per event with no exceptions
- →It's technically impossible to track more than a few events
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Segment Tracking Events by Input Method Where Possible
If your analytics can capture whether an action was completed via keyboard, mouse, or assistive technology, do so — it lets you check later whether a feature that looks healthy in aggregate is actually working for every user, not just the majority input method.
track('export_clicked', { inputMethod: 'keyboard' | 'mouse' | 'touch' })SEO Implications
- 1
Target 'how to instrument a feature for product analytics' aimed at engineers, not analysts
Readers here want the practical habit of shipping tracking with the feature, not a broad overview of analytics platforms aimed at a dedicated data team.
Best Practices
Name the Event Before Writing the Feature Code
When filling out the mini-PRD's success metric field, also name the specific event that will produce it (e.g. `export_button_clicked`) — deciding the event name upfront makes it a concrete, unskippable part of the build instead of a vague future intention.
Frequent Bugs
Shipping a feature with a plan to 'add analytics later,' which then never happens because there's no natural forcing moment to remember it.
Add the tracking call in the same pull request as the feature, and treat a missing event as a legitimate reason to request changes in code review, the same as a missing error state.
Real-World Examples
The Untracked Launch
A team shipped a new onboarding step without instrumentation, planning to add tracking 'next sprint.' Three sprints later, a stakeholder asked how it was performing — there was no data for the first month, the period that would have mattered most for catching an early problem.
// Missing at launch: track('onboarding_step_completed')
// Result: no usable data for the most informative first month