Mobile app analytics: what to track and what to ignore

The short answer: start with four to six events that follow the path to your money, plus crash reporting. Not five hundred. Firebase gives you free, unlimited reporting on up to 500 distinct events, and that generosity is exactly how most apps end up with a dashboard nobody reads and no answer to the only question that matters, which is what to build next.

One thing worth saying up front, because it shapes every guide you will read on this topic: almost every article ranking for mobile app analytics is written by a company that sells an analytics product. We build apps at Digital U, from $5,000 for a custom project. We have no dashboard to sell you, so this is the setup we actually put in place, in the order we put it in place, and the parts that go wrong. If you would rather we set it up on your app, that is a 30-minute call away.

What mobile app analytics is, and why it is not web analytics

Mobile app analytics is the practice of recording what people do inside your iOS or Android app, as discrete events sent from an SDK inside the app to a service that turns them into funnels, retention curves and reports.

The difference from web analytics is not cosmetic. On the web you own the page and can change it today. In an app, the user is on a version they installed weeks ago, they may never update, and a chunk of them never consented to being tracked at all. That means your app numbers are a sample with known gaps, and treating them as a headcount is the first mistake people make.

The two tools that answer different questions

You need two things, and they are not the same thing. One tool tells you what people do. Another tells you what broke.

The pairing we use is PostHog for product analytics and Sentry for error monitoring, because the useful decision lives between them. Sentry tells you a screen is throwing errors. PostHog tells you how many people ever reach that screen. Neither one, alone, tells you whether to fix it today.

That is the actual job of analytics in a small product team: not producing dashboards, but ranking work. A crash on a screen 2% of users touch and a crash on your checkout are the same red line in an error tool, and completely different decisions for your business.

What to track, in order

Track the path to the thing that pays you, then stop. A workable starting set for most apps:

What to track	The question it answers
App opened, with app version	Who is here, and on which build
Activation, the first moment of real value	Do new people ever get to the point?
The core action, repeated	Is the app becoming a habit or a novelty?
The money event (purchase, subscription, booking, lead)	Does any of this turn into revenue?
Drop-off points in that path	Where exactly do people give up?
Crash-free sessions, by app version	Is the current build stable enough to push?

Six lines. Every one of them is a decision you will actually make. Add more later, when you have a specific question that the current set cannot answer, and name the event after the question.

The reason to keep it small is not tidiness. An event plan with 200 entries always rots: names drift, nobody remembers which of checkout_done and purchase_complete is the real one, and six months later nobody trusts the numbers enough to act on them. An untrusted dashboard is worse than no dashboard, because it still costs you the time to argue about it.

Have an app live and no idea which of these you are tracking? Let us look together in a free 30-minute call or drop us two lines. You will get the short list of what is missing, even if we never work together.

What to ignore

Some numbers look like progress and inform nothing:

• Total downloads. It measures your marketing, not your product. An app can add installs every week while losing every single person who installs it.
• Session length, without context. Longer is better in a social app and worse in a utility. On its own the number has no direction.
• Daily active users as a single figure. Without knowing whether those are the same people returning or new people cycling through, DAU hides churn instead of revealing it.
• Screen views. They tell you people looked. They do not tell you anyone got anywhere.
• Average rating, watched daily. It moves too slowly to act on and too emotionally to be discussed calmly.

None of these is useless forever. They are just useless as your first six events, which is exactly where they usually end up.

The traps nobody selling a dashboard mentions

Your test data will pollute your production numbers. If development and production builds share one analytics key, your reports quietly fill with your own taps, QA runs and simulator sessions. The charts still look plausible, which is what makes this expensive: decisions get made on contaminated data and nobody knows to question them. Separate keys per environment, from day one, and treat the analytics key exactly like any other environment config.

Consent means your numbers are incomplete by design. Apple’s App Tracking Transparency framework requires apps to ask permission before tracking users across apps and websites owned by other companies, and apps cannot use the advertising identifier without it. Add GDPR consent on top. Some share of your users will decline, and there is no setting that gets them back. Plan to read your analytics as a consistent sample over time, not as a census.

The 500-event cap is a budget, not a target. Firebase offers free, unlimited reporting on up to 500 distinct events. Teams read that as an invitation. It is a ceiling, and hitting it means you can no longer add the one event you actually need.

Numbers attached to no app version are hard to act on. When a metric moves, the first question is always whether something shipped. If your events do not carry the app version, you cannot answer it, and this matters more in mobile than anywhere else, because several versions of your app are always live at once. We wrote about controlling which versions are out there in what remains after AI writes the code.

Free is usually enough to start

You do not need to buy anything to answer the first questions:

• Firebase Analytics is free, with unlimited reporting on up to 500 distinct events.
• App Store Connect reports impressions, product page views, downloads, sessions, retention and crash rate for free, plus peer group benchmarks against similar apps.
• Google Play Console reports acquisitions, uninstalls, active users, crashes and ANRs, and retention at 2, 3, 7, 14 and 28 days.
• Both are the only sources for what happens before the install, where your own SDK cannot see.
• PostHog and Sentry both have free tiers that comfortably cover an app in its first phase.

Paid tiers become worth it when you are running experiments continuously or need session replay to understand a flow you cannot reason about. Not before. Buying a larger dashboard to solve “we do not know what to build” reliably produces a larger dashboard.

How this turns into decisions

The setup above is worth nothing if nobody looks at it. What makes it work is boring: one recurring slot, monthly is enough at the start, where somebody opens four things.

Retention by weekly cohort, so you can see whether the people who arrived after the last release stay longer than the ones before it. The drop-off in your money path, to pick the next thing to fix. Crash-free sessions by version, to decide whether the current build is safe to push wider. And the one experiment you were running, to close it out with a decision instead of letting it run forever.

That is the whole loop. Ship, measure against the version, decide, ship again. The tooling is the easy part, and it is the part every other article on this page of Google will happily sell you.

Frequently asked questions

What is mobile app analytics? Mobile app analytics is the practice of collecting and measuring what users do inside an iOS or Android app. An SDK inside the app records actions as events, sends them to a cloud service, and that service turns them into dashboards, user flows, funnels and retention reports.

What is the best mobile app analytics tool? There is no single best one, because behaviour and errors are different problems. For a product team starting out, a common pairing is a product analytics tool (PostHog, Mixpanel, Amplitude or Firebase) plus an error monitoring tool (Sentry). Firebase Analytics is free with unlimited reporting on up to 500 distinct events, which makes it the usual starting point.

Can I use Google Analytics for mobile apps? Yes. Google Analytics for Firebase is the app version of Google Analytics, it covers iOS, Android, web, C++ and Unity, and it costs nothing. It reports on up to 500 distinct events per app, with unlimited volume within those events.

What is app analytics in App Store Connect? It is Apple’s own free reporting on your app’s store and usage performance. Apple documents impressions, product page views, downloads, conversion rate, active devices, sessions, retention rate and crash rate, plus peer group benchmarks against similar apps. It is separate from any SDK you install, and it is the only place you can see what happened before someone installed the app.

Is there free mobile app analytics? Yes. Firebase Analytics is free with unlimited reporting on up to 500 distinct events, App Store Connect and Google Play Console report installs and crashes at no cost, and PostHog and Sentry both offer free tiers that cover an app’s early phase.

What should you track in a mobile app? Start with four to six events that follow the path to revenue: app opened with app version, activation (the first moment of real value), the core repeated action, the money event, the drop-off points along that path, and crash-free sessions by version. Add more only when you have a question the current set cannot answer.

Why do my analytics numbers not match the App Store numbers? Because they measure different things and different populations. App Store Connect counts store-side events like impressions and downloads, and Apple notes its data only includes users who agreed to share diagnostics. Your own SDK, meanwhile, only sees people who opened the app and consented to tracking, and Apple’s App Tracking Transparency framework requires permission before tracking across other companies’ apps and websites. Neither number is a headcount.

How is mobile app analytics different from web analytics? On the web, everyone sees the current version on the next page load. In an app, users sit on versions they installed weeks ago, update when they choose, and may decline tracking entirely. That makes app version a mandatory dimension on every event, and it makes your totals a consistent sample rather than a headcount.

Building an app, or trying to work out why the one you have is not growing? Drop us two lines or book a 30-minute call: we go through your money path and the events that should sit on it, no obligation. Costs and timelines are in how much a mobile app costs in 2026.