Mobile

Mobile analytics: measuring the few things that inform decisions

Most apps collect far more events than anyone uses. A small, well-defined set answers more questions than an exhaustive one.

Key takeaways

  • Define the decisions first, then the minimum events that inform them.
  • Retention, not installs, tells you whether the product works.
  • Consistent naming keeps analytics usable beyond a few months.
  • Collect the minimum and honour platform privacy controls.

Start from decisions, not events

The useful question is not “what can we track” but “what decisions will this inform”. Events that will never change a decision are cost without benefit — in engineering time, in payload size and in privacy exposure.

Write the questions first, then define the minimum event set that answers them.

Retention over installs

Installs are a marketing measure. Retention tells you whether the product works: what proportion of users return the next day, the next week, the next month.

Segment by acquisition source and by first-session behaviour. The finding that a particular channel produces installs that never return is common and immediately actionable.

Instrument the funnel properly

  • Define a small number of named funnels and instrument every step consistently.
  • Use a consistent naming convention or the data becomes unusable within months.
  • Record enough properties to segment, and no personal data you do not need.
  • Version your schema so analysis can account for changes.

Privacy is part of the design

Collect the minimum, be clear in the privacy policy, honour platform tracking permissions properly, and avoid sending identifiers you have no use for.

Beyond compliance, this is a trust matter. Users increasingly notice, and platform-level restrictions have made excessive collection less useful anyway.

Keeping the data trustworthy

Analytics implementations degrade quietly. Events get renamed, screens change, a refactor drops a call, and nobody notices until an analysis produces an implausible number.

Treat instrumentation as code covered by tests where practical, and add automated checks that expected events fire on key journeys. Review the event schema whenever the interface changes materially.

Document what each event means and when it fires. An event named button_tapped with no context is worthless six months later, and most analytics debt takes exactly that form.


Frequently asked questions

Most mainstream products answer the common questions well. Weigh data ownership, privacy posture and cost at your expected volume more heavily than feature lists.

Fewer than most teams implement. A few dozen well-defined events covering the main journeys usually answers more than hundreds of ad hoc ones.

Only where there is a clear purpose and a lawful basis. Aggregate and cohort analysis answers most product questions without individual-level tracking.

Working on this?

A conversation with our team, no charge and no obligation.

Book a conversation