Turning Product Analytics Into Decisions

Before adding tracking, write down the questions you expect to face in the next quarter. Real ones, in the form someone will actually ask:

• "Should we keep investing in the onboarding redesign?"
• "Is the assessment too long?"
• "Which of these two features should we finish first?"
• "Are people who use the library feature more likely to renew?"

For each, write the specific measurement that would change your mind. "If completion is below 60% we shorten it" is a decision rule. "Track engagement" is not.

Now instrument exactly what those rules need. You will find it is a small number of events, and that you can name them precisely because you know what they are for.

Most products need somewhere between fifteen and forty well-chosen events. Beyond that you are usually recording activity rather than meaning.

Conventions that keep a schema usable as it grows:

• Name events after user intent, not UI mechanics. assessment_completed, not button_7_clicked. Interfaces change; intent is stable.
• Object-action naming, consistently. Pick one order and never mix.
• Properties on events, not new events. One session_started with a source property, rather than four separate events.
• Version deliberately. If the meaning of an event changes, create a new name. Silently changing what an event means makes all historical data untrustworthy, which is worse than not having it.
• Document each event where it is defined — what it means, when it fires, who owns it. An undocumented event becomes unusable within about six months.

Aggregate counts hide the thing you need to know. A thousand assessment starts and six hundred completions is one fact; the interesting fact is where the other four hundred stopped.

Instrument the steps of any multi-step flow individually, and always segment by at least entry point and device. The most common pattern we see: a flow performs acceptably in aggregate and collapses on mobile at one specific step — invisible in the total, obvious in the funnel.

For anything with a time dimension, look at cohorts rather than a rolling average. "Users who joined in March" behaves differently from "all users", and a rolling average will happily conceal a product that is getting worse for new users while long-tenured ones prop up the number.

Analytics implementations track success paths thoroughly and failures barely at all, which inverts their usefulness.

Worth capturing explicitly:

• Validation errors by field. The fastest way to find a confusing form is to see which field people fail repeatedly.
• Empty states reached. A user hitting an empty search or an empty list is a user finding nothing, and it rarely shows up as an error.
• Repeat attempts. The same action performed three times in a minute usually means it did not appear to work.
• Abandonment points with time on step. Leaving after two seconds and after two minutes are different problems.

These four often produce more actionable findings in a week than months of engagement dashboards.

Analytics that ignore consent are a liability, and retrofitting compliance is far harder than building it in.

The baseline we implement:

• Analytics load only after consent, with a genuine choice — not a pre-ticked box or a banner that only offers "accept".
• Product analytics separated from marketing analytics in the consent model, since users often accept one and not the other.
• No personal data in event properties. Identifiers, not names or emails. This also makes data retention simpler.
• A defined retention period, enforced automatically rather than by intention.

There is a practical benefit beyond compliance: a consent-gated setup forces you to be honest about how much of your data is missing, which is information you need when interpreting anything.

Analytics decay. Events stop firing after a refactor, dashboards outlive the questions that prompted them, and nobody notices because there is no error when data is simply absent.

Two habits keep it healthy:

1. A monthly check that your core events are still firing at expected volumes. A silent event is the most common analytics failure and the hardest to spot.
2. A quarterly prune. Delete events nobody has queried and dashboards nobody has opened. A small, trusted set beats a large, doubted one.

The test of an analytics setup is not how much it captures. It is whether, when a decision comes up, someone can answer it in an hour without writing new tracking first.