Mobile analytics that answer questions instead of producing dashboards

01Instrument intent, not interface

An event named button_tapped_checkout_v2 is tied to a component that will be renamed, moved or removed. When it is, your historical data becomes uninterpretable and every comparison across that boundary is wrong.

An event named checkout_started describes what the user was trying to do. It survives redesigns, and it can be fired from three different entry points without fragmenting your funnel.

The test: if you redesign this screen, does the event still make sense? If not, you are recording the interface rather than the behaviour.

02A schema that stays usable

Define events before implementing them, and treat the definition as an interface with a version rather than a string someone typed in a component.

• Name events as past-tense actions with a consistent object-action shape. Enforce it in review; naming drift is what makes analytics unqueryable.
• Put variation in properties, not in event names. One checkout_started with a method property beats four separate events.
• Include the identifiers you will need to join to backend data - without them you can count events but cannot connect them to revenue or outcomes.
• Version the schema and record the app version on every event; you will need it to explain a discontinuity.
• Document what each event means in words, because in a year nobody will remember whether it fired on intent or on success.

03The metrics that mislead on mobile

Daily active users rewards notification spam and says nothing about value delivered. It is the easiest metric to move in the most damaging way.

Session length is ambiguous by construction - longer can mean engaged or confused, and mobile sessions end when the user is interrupted rather than when they finish.

Install counts measure marketing, not product. Retention past day seven, and completion rate of the core task, are the two that consistently correlate with a product working.

Crash-free rate is worth watching but hides the failures that matter more: silent errors, requests that never return, and screens that render empty. An app can be crash-free and broken.

04Keeping it honest

Analytics degrades quietly. Events stop firing after a refactor, a rename splits a funnel, and an SDK update changes sampling - none of which raise an alert.

Monitor event volume itself. A step that drops to zero is nearly always instrumentation rather than user behaviour, and catching it in a week rather than a quarter is the difference between a gap and a lost quarter of data.