Last updated: 20/07/2026
The short answer
The KPIs that matter after launch are the few that answer three questions — are people using the app, is it technically healthy, and is it doing its business job — and you do not need to be technical to reason about them. Watch engagement and retention (active users, sessions, retention rate) to see whether people come back; watch technical health (crash rate and ANR rate) to see whether the app is stable; and watch your one or two business-outcome metrics (typically conversion rate) to see whether it earns its keep. Everything else is a supporting detail, not a headline.
Two things make this easier than it sounds. First, the numbers already live in tools you are paying for — Apple's App Store Connect, Google's Play Console and Firebase — so measuring rarely costs anything extra. Second, on technical health you are not guessing what "good" means: Google Play publishes hard thresholds, and an app that crosses them is, in Google's own words, made "less discoverable". This guide sorts the metrics, shows where to read each one, and gives those published limits so you can hold both your app and your vendor to an objective bar.
The three jobs a KPI can do
Every useful post-launch metric earns its place by doing one of three jobs, and sorting them this way stops a dashboard from overwhelming you. A metric either tells you whether people use the app, whether the app works, or whether the app pays off. If a number does not clearly do one of those three, it is probably noise.
- Usage (engagement & retention) — do people come back? Active users, sessions per user and retention rate live here. A beautiful app nobody reopens has failed regardless of its ratings.
- Health (stability) — does the app work reliably? Crash rate and ANR (Application Not Responding) rate live here, and this is the only group with objective, published limits.
- Outcome (business) — is it doing the job you built it for? Conversion rate — a purchase, a booking, a sign-up completed — lives here, defined by whatever "success" means for your specific app.
Pick one or two metrics from each group and you have a scorecard of roughly five numbers. That is far more useful than a wall of forty, because five numbers get read every week and forty get read never.
Which KPIs matter — and where each one lives
The table below lists the core post-launch KPIs, the plain-English question each answers, and the tool that already surfaces it — so you can find each number without buying anything new. The "where you read it" column names capabilities confirmed on each tool's own site today.
| KPI | Job | Plain-English question | Where you read it |
|---|---|---|---|
| Active devices / users | Usage | How many people actually open the app? | App Store Connect (Active Devices); Play Console; Firebase / Google Analytics. |
| Sessions | Usage | How often do they come back to use it? | App Store Connect (Sessions metric); Firebase / Google Analytics. |
| Retention rate | Usage | What share of new users are still using it after a week or a month? | App Store Connect ("the percentage of devices on which…"); Firebase / Google Analytics. |
| Crash rate | Health | How often does the app fall over? | Play Console (Android vitals); App Store Connect ("crashes per session"); Firebase Crashlytics. |
| ANR rate | Health | How often does the app freeze and stop responding? (Android) | Play Console (Android vitals). |
| Conversion rate | Outcome | How often do visits turn into the action you care about? | App Store Connect (Conversion rate, for downloads); Firebase / Google Analytics (in-app funnels). |
Notice the same three or four tools appear again and again: for most apps a store-console view plus one product-analytics tool (Firebase/Google Analytics) covers every row. You do not need a specialist "growth stack" to run a healthy scorecard — you need the discipline to look at these six numbers on a schedule and ask what changed.
Technical health: the one set of objective thresholds
Technical health is the only group of KPIs where "good" is not a matter of opinion, because Google Play publishes hard limits and enforces them through discoverability. Play designates the user-perceived crash rate and the user-perceived ANR rate as "core vitals" — the ones counted when a user is actively engaged with the app, "causing the most disruption" — and it defines a bad-behavior threshold for each. Cross the overall threshold and, in Google's words, your app "is likely to be less discoverable on all devices".
| Core vital | What it measures | Overall bad-behavior threshold | Per-device threshold | Consequence of exceeding |
|---|---|---|---|---|
| User-perceived crash rate | Percentage of daily active users who experience a crash while using the app | ≥ 1.09% of daily active users (across all device models) | ≥ 8% for a single device model | App "is likely to be less discoverable on all devices". |
| User-perceived ANR rate | Percentage of daily active users who experience an "Application Not Responding" freeze | ≥ 0.47% of daily active users (across all device models) | ≥ 8% for a single device model | App "is likely to be less discoverable on all devices". |
These two numbers are the most useful objective bar you have after launch: they are set by the platform, not by a vendor's opinion, and staying under them protects the discoverability that drives your organic installs. On iOS, App Store Connect reports crash rate as "the average number of crashes per session" and Firebase Crashlytics reports crashes in real time — but Google's published percentages give you a concrete target to hold everyone to, including the studio that built the app.
Avoiding vanity metrics
The fastest way to waste a dashboard is to celebrate numbers that only ever go up. Total downloads is the classic example: it never falls, so it always looks like progress, but it says nothing about whether anyone kept the app. A large one-off spike in installs alongside a flat retention curve usually means a marketing push found the wrong audience — a fact the download counter alone will hide from you.
The discipline is to pair every "reach" number with a "kept" number: downloads with retention, sessions with crash rate, sign-ups with the action those sign-ups were supposed to lead to. We deliberately did not put an industry "good retention is X%" figure in this article, because a credible universal benchmark for your specific app, market and category does not exist — and quoting one would be inventing a fact. The reliable comparison is your own trend over time: is this month better than last, and did the change you shipped move the number you expected it to move?
What measuring costs (usually nothing extra)
Measuring your app rarely adds a line to the budget, because the core tools are bundled with accounts you already hold or are free to use. The table below sets out the everyday measurement stack and what each part costs, using each provider's own published figures.
| Tool | What it gives you after launch | Cost |
|---|---|---|
| Apple App Store Connect (App Analytics) | Active devices, sessions, retention, conversion and crash rate for iOS. | Included with the Apple Developer Program — 99 USD per membership year. |
| Google Play Console (Android vitals) | Crash and ANR core vitals, installs, uninstalls and ratings for Android. | Included with the Google Play registration — US$25 one-time fee. |
| Firebase Crashlytics | Real-time, automated crash reporting across iOS and Android. | No-cost (Spark plan) — no payment method required to start. |
| Namtech Maintenance & Support | Someone to read the numbers, triage crashes and ANRs, and ship fixes. | From 15% of build cost per year. |
So the cost of measuring is almost never the tools — it is the attention. The store consoles and Crashlytics will collect the data for the price of your existing developer accounts; what turns that data into a healthier app is a person who looks at it on a schedule and acts. That is the line item worth budgeting for, and it is exactly what a maintenance plan buys.
Questions to ask about measurement
- "Which five metrics will we review, and how often?" A good answer names specific KPIs across usage, health and outcome — not "we'll keep an eye on analytics".
- "Are our crash and ANR rates under Google Play's thresholds?" The numbers are public (1.09% and 0.47%); your vendor should be able to tell you where you stand against them.
- "Is crash reporting wired in before launch?" Crashlytics is no-cost; there is no excuse for finding out about crashes from a one-star review instead of a dashboard.
- "What action follows each metric?" A metric with no owner and no action is decoration. Ask who reads it and what they do when it moves.
- "How do we tell a real problem from noise?" The honest answer is trend and threshold — your own month-on-month line, plus the platform's published limits — not a single scary-looking day.
How Namtech turns numbers into fixes
At Namtech, measurement is part of support, not an afterthought you set up alone. Crash reporting is wired in before launch, and after go-live your app is covered by Maintenance & Support, from 15% of build cost per year, which includes monitoring, OS-version updates, security patches and priority support — the work of watching the vitals and shipping fixes when a number crosses a line. The same project manager who ran your build stays with you, so the person reading the dashboard already knows the app.
This closes the loop that our six-step build process opens: Discover, Design, Build, Test, Launch and Support. Launch is where measurement starts earning its keep, and support is where the numbers become decisions. If you are planning a build, ask us how we will measure it from day one — or start from the tiers on our pricing page and book a scoping call.
After launch, a healthy app is not the one with the most downloads — it is the one whose small scorecard of the right metrics is read every week and acted on, and whose crash and ANR rates stay under the limits the platform itself publishes.