After launch, measure whether people get value from your app and come back: activation (completing the first key action), retention at day 1, 7 and 30, crash-free sessions, conversion through your main funnel, and revenue or bookings per active user. Downloads alone tell you almost nothing. Set these up before launch, not after the first complaint.
A useful way to frame it: every metric should answer a question you'd act on. "How many people installed?" rarely changes a decision. "How many people who installed made a first booking within a day?" tells you whether onboarding works.
What are the core app metrics, in plain English?
There are six numbers worth watching from week one. Everything else is detail underneath them.
| Metric | What it means | Question it answers | Where to find it |
|---|---|---|---|
| Activation rate | Share of new users who complete the first meaningful action (first booking, first order, first saved item) | Does onboarding deliver value? | Your analytics events |
| Retention (D1, D7, D30) | Share of a day's new users who return 1, 7 and 30 days later | Do people come back? | Analytics retention report |
| Active users (DAU, WAU, MAU) | Unique users active per day, week, month | Is usage growing or shrinking? | Analytics dashboard |
| Crash-free sessions | Share of sessions with no crash | Is the app stable enough to grow? | Crash reporting tool, store consoles |
| Funnel conversion | Drop-off at each step of a key flow | Where do people give up? | Analytics funnels |
| Revenue or value per active user | Bookings, orders or subscription revenue divided by active users | Is usage turning into business results? | Analytics plus your backend or billing |
If you only look at one number in the first month, look at day-7 retention. It's the clearest early sign of whether the app has a reason to exist in someone's week.
There's no universal "good" retention figure. It depends heavily on category: a weekly class-booking app and a once-a-year travel app will never look alike. Compare your app against its own earlier cohorts and against the usage pattern you expect, rather than chasing an industry average quoted without context.
Which events should you track?
Track the handful of actions that map to your business goal, named consistently, with a few useful properties. A tidy plan of 15–30 events beats hundreds of auto-captured taps nobody reads.
A starter event plan for a booking app might be:
app_opened,sign_up_started,sign_up_completedservice_viewed(property: service type)booking_started,booking_completed(properties: price band, staff member, payment method)booking_cancelled(property: reason)notification_opened(property: campaign)review_prompt_shown,review_submitted
Write the plan in a shared spreadsheet before development: event name, when it fires, properties, and the question it answers. Your developers implement it; you review it. An event without a question attached is noise.
Server-side events matter too. A payment that succeeds on your backend is more reliable than a "thank you" screen view in the app, which can be missed if the user closes the app early.
Which analytics tools should you use?
Most business apps need three layers: product analytics, crash reporting and the store consoles. You don't need an expensive stack to start.
| Layer | Common options | What it gives you |
|---|---|---|
| Product analytics | Google Analytics for Firebase, Mixpanel, Amplitude, PostHog | Events, funnels, retention, user properties |
| Crash and performance | Firebase Crashlytics, Sentry | Crash reports, slow screens, affected versions |
| Store data | App Store Connect, Google Play Console | Store views, installs, ratings, uninstalls, Android vitals |
| Attribution (if running paid installs) | Mobile measurement partners, platform SDKs | Which campaign or channel brought each install |
| Business data | Your backend, admin panel, billing provider | Revenue, refunds, real bookings |
Firebase is a common free starting point because it bundles analytics and crash reporting. Product-focused tools like Mixpanel or Amplitude make funnel and cohort analysis easier as you grow. Pick one product analytics tool and stick with it; running three in parallel produces three slightly different answers and arguments about which is right.
How do you read retention without fooling yourself?
Look at cohorts, not totals. A cohort is a group of users who started in the same week. Comparing each week's cohort shows whether changes you made actually helped.
Total active users can rise even while retention falls, simply because you're buying more installs. That looks like growth on a dashboard while the bucket leaks faster underneath. A cohort chart exposes it immediately.
Practical habits:
- Review a weekly cohort chart every Monday.
- Mark releases and campaigns on the timeline so you can connect changes to causes.
- Segment by acquisition source. Users from your customer list often behave very differently from users from paid ads.
- Segment by platform and app version. A retention dip limited to one Android version usually means a bug, not a product problem.
The same discipline applies to web; our article on the analytics that actually matter makes the case for fewer, better numbers.
What should you measure for notifications and monetisation?
Measure notifications by what they cause, and monetisation by revenue per active user rather than raw sales.
For push notifications, track opt-in rate, open rate per campaign, and, most importantly, the opt-out or uninstall rate after a send. A campaign that gets clicks but triggers uninstalls is a net loss. Our guide to push notifications that bring users back explains how to design sends that pass this test.
For revenue, the right metrics depend on the model:
- Subscriptions: trial-to-paid conversion, monthly churn, average revenue per paying user.
- In-app purchases: purchase conversion, repeat purchase rate.
- Ads: revenue per daily active user, and retention compared with ad-free users.
Our comparison of ways to monetise an app covers which model suits which app. If your app is a SaaS product's companion, the same subscription maths applies as on the web; see the SaaS metrics every founder should track.
How do privacy rules affect app analytics?
You must disclose what you collect, get consent where the law requires it, and avoid sending personal data to analytics tools. On iOS, tracking users across other companies' apps and websites requires the App Tracking Transparency prompt, and many users decline it, which limits ad attribution.
Good practice:
- Use an internal user ID, never email addresses or phone numbers, in analytics events.
- Respect consent choices for users in regions with strict privacy laws such as the EU, the UK, India under the DPDP Act and Australia under the Privacy Act.
- Keep your App Store privacy details and Google Play Data safety form consistent with what your analytics SDKs collect.
Our mobile app security checklist covers SDK inventories and disclosures in more detail.
What does a simple post-launch review rhythm look like?
Daily for stability, weekly for behaviour, monthly for business results.
- Daily (first month): crash-free sessions, new crash types, store reviews.
- Weekly: new users by source, activation rate, D1 and D7 retention by cohort, funnel drop-off.
- Monthly: D30 retention, revenue per active user, notification opt-outs, top feature usage, what to build or remove next.
The output of every review should be one decision, such as fixing the step where most users abandon sign-up, rather than a slide of charts. For how analytics fits into the wider build, admin panel and maintenance plan, see our complete guide to mobile app development.
Frequently asked questions
When should analytics be added to an app?
Before launch, as part of the first version. Adding tracking afterwards means you lose the most informative period, your first users, and you'll have no baseline to compare improvements against. Ask for the event plan to be included in the project scope.
Is Firebase enough for a small business app?
For many small apps, yes. Google Analytics for Firebase plus Crashlytics covers events, basic funnels, retention and crash reporting at no licence cost. You may want a dedicated product analytics tool later if you need deeper funnel and cohort analysis.
What's the difference between downloads and active users?
Downloads count installs; active users count people who actually opened and used the app in a period. Many installed apps are never opened again, so active users and retention are far more honest measures of success.
How do I know which marketing channel brings the best users?
Tag every channel: separate store links or campaign parameters for email, website banner, QR codes and paid campaigns. Then compare activation and retention by source, not just install counts. Cheap installs that never activate are expensive in reality.
Can analytics slow down my app?
Poorly implemented SDKs can add startup time and battery use, especially when several overlap. Keep the number of SDKs small, batch events, and check app performance in your crash and performance tool after adding any new library.
Measure what you'll act on
Good app analytics is a short list of questions, a tidy event plan and a weekly habit. If you're building an app and want measurement designed in from the start, see how we approach app development or get a fixed-price quote.