Lorixen.
EN
Menu

App analytics after launch: the few numbers that matter

Short answer: After launch, watch five things: how many new users reach the app's first useful moment (activation), how many come back (retention), how stable the app is (crash-free users), where people drop out of your main flow (one or two funnels), and whether the store listing turns visitors into installs. Track the in-app numbers with an analytics SDK such as Firebase and a crash reporter, and read stability and store numbers in App Store Connect and Google Play Console. Ignore download totals on their own; they say little about whether the app is working.

Most small-business apps launch with analytics either missing or collecting everything and answering nothing. A short list of numbers, each tied to a question, beats a dashboard nobody opens.

1. Activation: do new users get to the point?

Question it answers: Of the people who open the app, how many complete the first meaningful action, such as a booking, an order, adding a card or finishing setup?

How to track it:

  • Firebase (Google Analytics for Firebase) logs some events automatically. Its reference lists first_open, logged the first time someone launches the app after installing or reinstalling, not at download.
  • Log your own event for the activation moment, for example booking_completed or first_order. Firebase's docs say you can log up to 500 different event types per app, with no limit on total volume. You'll need far fewer.
  • Activation rate = users with your activation event ÷ users with first_open, over the same period.

What to do with it: if many people open the app but few activate, look at sign-up, permissions prompts and the first screen before spending more on installs.

2. Retention: do people come back?

Question it answers: Is the app useful enough to be opened again?

How to track it:

  • App Store Connect Analytics shows retention as the percentage of active devices that installed on a given day and opened the app a set number of days later (Day 1, Day 5 and so on). Apple notes that installs that are never opened aren't counted, and that usage data is based on users who opted in to share analytics with developers.
  • Firebase and Google Analytics also show cohort retention for your users across both platforms.
  • On Android, Google Play's Android vitals page now shows "core value" metrics: DAU/MAU (daily active ÷ users active in 28 days) and user loss rate (users who uninstalled from all devices compared with users who have it installed on at least one active device). Google states thresholds of 8% for DAU/MAU and 5% for user loss rate, beyond which a warning may appear on your listing and the app may not be eligible for some Google Play surfaces (as of November 2026).

What to do with it: judge retention against how often people need you. A dentist's app opened twice a year isn't failing; a coffee loyalty app opened once a month might be. Pick the window that matches your real usage (weekly, monthly) and watch the trend after each release.

3. Stability: crash-free users

Question it answers: How many people get through their sessions without the app crashing?

How to track it:

  • Firebase Crashlytics automatically calculates crash-free users and crash-free sessions as percentages, shown at the top of its dashboard.
  • Google Play Console's Android vitals tracks user-perceived crash rate and ANR rate ("app not responding"). Google defines bad-behavior thresholds, for example at least 1.09% of daily users experiencing a user-perceived crash, or 0.47% experiencing a user-perceived ANR, across all devices. Above those, the app is likely to be less discoverable on Google Play.
  • App Store Connect also reports crashes among its usage metrics.

What to do with it: check stability within a day or two of every release, sorted by app version and device. A crash affecting one popular phone model can drag the whole number down.

4. One or two key funnels

Question it answers: Where do people give up on the thing that makes you money?

How to track it:

  • Define the steps of your main flow as events, for example view_service → select_time → enter_details → booking_completed, or view_item → add_to_cart → begin_checkout → purchase.
  • Build a funnel report in your analytics tool from those events.
  • Add properties that explain drop-offs: payment method, service type, logged-in or guest.

What to do with it: fix the biggest drop first. Typical culprits are forced account creation, an unexpected fee, a slow payment step or a confusing time picker.

5. Store listing conversion

Question it answers: Do people who see your app in the store install it?

How to track it:

  • App Store Connect Analytics includes App Store metrics such as impressions, product page views and conversion rate.
  • Google Play Console's store listing reports measure the moment someone shows intent to install, and its Listing conversion analysis page (Grow users → Store performance → Conversion analysis) shows visitors, clicks and click-through rate.

What to do with it: if conversion is low, test the first screenshots and the short description before anything else.

Numbers to treat with caution

  • Total downloads. Useful for trends, not for judging the app.
  • Session length. Long sessions can mean engagement or confusion. A booking app should be quick.
  • Raw daily active users without context. Compare to how often people genuinely need your service.

A simple monthly routine

  1. Activation rate this month vs last month
  2. Retention for your chosen window, by month of install
  3. Crash-free users for the latest release
  4. The biggest drop-off step in your main funnel
  5. Store listing conversion
  6. One change to make next, and how you'll know it worked

FAQ

Do I need Firebase if I have App Store Connect and Play Console?

The store dashboards show installs, stability and some usage, but not what people do inside your app. For activation and funnels you need in-app events from an analytics SDK.

Why don't my analytics numbers match the store's?

They measure different things. Firebase's own reference notes that first_open fires on first launch, not download, and Apple's usage data only covers users who opted in to sharing. Expect gaps and compare trends, not exact totals.

How soon after launch should I judge retention?

Give it a few weeks of real users and at least a couple of install cohorts. Early numbers from friends and staff are misleading.

Should I track everything just in case?

No. Track the events behind these five questions, name them consistently, and add more only when a real question needs them. Check the rules on consent and data where you operate before collecting more.

If your app is live and you'd like these five numbers set up and readable in one place, tell us which platforms you're on.

Sources

WhatsAppLet’s talk