Instrument decisions, not everything
The standard failure is tracking hundreds of events, building an elaborate dashboard and then never opening it. It happens because the tracking was designed around what is technically capturable rather than around a decision anyone needs to make.
Before adding any metric, write the sentence: “if this number is X we will do A, if it is Y we will do B.” If you cannot complete that sentence, do not track it.
The six that earn their place
- Core workflow completion rate. Of users who start the main thing, how many finish? The most diagnostic number in most products.
- Time to first value. From signup to the first genuinely useful outcome.
- Weekly active accounts, defined by a meaningful action rather than a login.
- Adoption of the three features that matter, not all forty.
- User-visible error rate. Failures the customer actually experienced, which is a different number from your server error rate.
- Cancellation reasons, structured, read monthly.
Define your events before you write them
Agree the taxonomy first: naming convention, required properties, what counts as active. Retrofitting consistency onto a year of ad hoc events is miserable and often impossible, because the historical data cannot be corrected.
- One naming pattern, applied without exception
- Every event carries account, user and timestamp
- Events describe what happened, not what the code did
- A written definition of “active” that everyone uses
Funnels lie unless you segment them
An aggregate funnel hides the story. New versus returning, plan tier, acquisition channel, company size — the aggregate is an average of populations behaving very differently, and the average describes nobody.
The most common discovery when segmenting is that one channel brings users who never complete onboarding, which is a marketing problem being misdiagnosed as a product one.
Qualitative beats quantitative for the why
Analytics tell you what happened and cannot tell you why. Ten recorded sessions of real users attempting your core workflow will explain a drop-off that a month of dashboard analysis will not.
Budget time for this explicitly, because it never happens by accident. Two sessions a fortnight is enough to keep a team honest about what their product is actually like to use.
Review on a schedule, or it will not happen
A monthly half-hour with the six numbers, one question each, and a decision written down. That is a functioning analytics practice. A beautiful real-time dashboard nobody opens is not, however impressive it looked in the demo.
If a number has not changed a decision in six months, either the threshold is wrong or the metric does not matter. Both are worth acting on.