The KPIs that matter most for any mobile app are DAU/MAU (stickiness), day 1/7/28 retention, crash rate, ARPU and CAC, because together they show whether people come back, whether the app is stable enough to keep them, and whether growth pays for itself. The one action to take today: wire up first-open, key conversion events and crash reporting through App Store Connect, Play Console and Firebase before building anything else.
TL;DR:
- Wire up crash reporting, first-open events, and key conversion metrics in Firebase, App Store Connect, and Play Console before building any app features.
- Focus on a small set of KPIs aligned with business goals, such as day 7 retention for retention or ARPPU for revenue, and assign clear ownership to each.
- Monitor technical performance KPIs like user-perceived crash and ANR rates, which impact app discoverability and user satisfaction.
- Prioritize fixing stability issues, especially crash spikes, as they directly affect growth, retention, and app store visibility.
- Regularly perform KPI audits, eliminate unowned metrics, and ensure data sources are reconciled for a clearer, actionable dashboard.
Table of Contents
- Quick reference: core mobile app KPIs with definitions and owners
- Acquisition and activation KPIs: what to track and how to measure
- Engagement and activation metrics that predict retention
- Retention, churn and cohort analysis
- Monetisation and revenue KPIs: measuring value and payback
- Technical performance and quality KPIs: stability, speed and battery
- How to choose the right KPIs and keep dashboards actionable
- Practical examples and checklist from Pocket App
- Author perspective: why discipline and focus win
- Pocket App services: discover, design, develop and deploy
- FAQ
- Sources
Quick reference: core mobile app KPIs with definitions and owners
Before diving into categories, it helps to see the full set in one place. This list covers the KPIs most product, marketing and engineering teams need on a single dashboard, with the formula and who should own each number.
- Downloads/installs, the raw count of app installs from a store or campaign; owned by marketing, pulled from App Store Connect or Play Console.
- Store listing conversion rate, product page views divided by downloads; owned by marketing, used to judge screenshots, copy and icon performance.
- Cost per install (CPI), total campaign spend divided by installs; owned by marketing, tracked per channel to compare paid acquisition efficiency.
- Customer acquisition cost (CAC), total acquisition spend divided by new paying or active customers; owned jointly by marketing and finance.
- Time to first value (TTFV), the time between first open and the first meaningful action; owned by product, measured through a defined "aha" event in Firebase or GA4.
- DAU/MAU (stickiness ratio), daily active users divided by monthly active users; owned by product, the clearest single engagement signal available.
- Sessions per user, total sessions divided by active users over a period; owned by product, useful for spotting habitual versus occasional use.
- Average session length, total time in-app divided by number of sessions; owned by product, best read alongside sessions per user rather than alone.
- Feature adoption rate, users who engage a given feature divided by active users; owned by product, tied to specific onboarding or release goals.
- Day 1/7/28 retention, the percentage of a cohort still active on each of those days after install; owned by product, the earliest predictor of churn.
- Rolling retention, the percentage of users active on or after a given day, smoothing out single-day noise; owned by product.
- Churn rate, the percentage of users or subscribers lost over a period; owned by product and finance together.
- ARPU (average revenue per user), total revenue divided by total active users; owned by finance and product.
- ARPPU (average revenue per paying user), total revenue divided by paying users only; owned by finance, sharper than ARPU for freemium apps.
- LTV/CLTV (lifetime value), the total revenue expected from a user over their relationship with the app; owned by finance, central to the LTV:CAC comparison.
- Conversion to paid, free users who upgrade divided by total free users; owned by product and marketing for subscription or freemium models.
- Subscription churn, cancelled subscriptions divided by active subscriptions in a period; owned by product, critical for recurring revenue apps.
- User-perceived crash rate, the percentage of daily users who experience at least one crash; owned by engineering, sourced from Play Console's Android vitals.
- User-perceived ANR rate, the percentage of daily users who experience an app-not-responding event on Android; owned by engineering.
- App load time, the time from tap to usable screen; owned by engineering, a direct influence on early abandonment.
Treat this as a menu, not a mandate. Few teams need all twenty on one dashboard at once, and the next sections explain how to narrow it down by category and by objective.
Acquisition and activation KPIs: what to track and how to measure
Acquisition metrics answer one question: are the right people finding the app, and at what cost? Installs alone say little. A spike in downloads from a badly targeted campaign can look like success while quietly inflating CAC and dragging down retention.
Store listing conversion rate, product page views divided by downloads, tells you whether your icon, screenshots and description are doing their job before you spend a pound on paid acquisition. Both App Store Connect and Play Console report this natively, broken down by territory and device.
Cost per install (CPI) is campaign spend divided by installs, a channel-level efficiency number. Customer acquisition cost (CAC) goes further: total acquisition spend divided by the number of users who reach a meaningful outcome, whether that is a completed registration, a first purchase or an activated subscription. The two numbers often diverge sharply, and CAC is the one that should set your budget decisions.
Attribution is where most teams lose accuracy. A few practical rules:
- Use UTM parameters consistently across every paid and organic campaign link so Firebase and your mobile measurement partner agree on source.
- Reconcile store console numbers against Firebase event counts; both App Store Connect and Play Console sample opted-in users, so small percentage differences against internal data are expected and not a bug.
- Treat install-to-registration as its own funnel stage, separate from registration-to-activation, so you can see exactly where people drop off.
- Segment CPI and CAC by channel and creative, never as a single blended average, because blended figures hide your worst-performing spend.
Pro Tip: Set CAC targets per channel before launch, not after the first campaign report, so a bad number has an obvious benchmark to compare against.
Engagement and activation metrics that predict retention
Engagement is the strongest early signal of product-market fit, well ahead of revenue. A user who has not found value within the first session rarely comes back to find it later.
Time to first value (TTFV) measures the gap between first open and the moment a user completes a defined "aha" action, whether that is sending a message, completing a profile or finishing a first transaction. Shortening TTFV is usually the single highest-leverage onboarding change a team can make.
DAU/MAU, the stickiness ratio, divides daily active users by monthly active users. A ratio above roughly 0.2 generally signals a habit-forming app; anything close to the monthly total logging in daily is social or utility-grade engagement. Sessions per user and average session length add texture: high session counts with short duration suggest a quick-utility pattern, while fewer, longer sessions suggest deeper content consumption.
Feature adoption rate ties engagement directly to product decisions. If a new feature is used by only a sliver of active users within two weeks of release, that is a signal to investigate discoverability or genuine demand, not just a vanity statistic to report upward.
To find which behaviours actually predict retention, segment cohorts by their earliest actions:
- Compare users who completed onboarding within five minutes against those who took longer, and track their 7 day retention separately.
- Isolate users who tried a specific feature in week one and measure whether their 28 day retention beats the overall average.
- Break engagement down by acquisition channel, since paid and organic users frequently show very different stickiness.
- Watch for a "magic number", a specific action count in the first session that correlates strongly with long-term use.
Our guidance on instrumenting engagement events goes deeper into setting up these cohort comparisons in Firebase.
Retention, churn and cohort analysis
Retention is where most of the honest signal lives, because it is nearly impossible to fake and directly predictive of long-term revenue. Day 1 retention measures the percentage of a cohort still active the day after install; day 7 and day 28 extend the same logic further out. Rolling retention, the percentage active on or after a given day, smooths out the noise of any single bad day.
Churn rate, the inverse of retention, is calculated as users lost over a period divided by users at the start of that period. For subscription apps, subscription churn should be tracked separately from general inactivity churn, since a lapsed free user and a cancelled paying subscriber carry very different financial weight.
To diagnose a retention problem, build a cohort table with install week down one side and days since install across the top, then read it like a staircase:
- Check day 1 retention first. A low number here usually points to onboarding friction, not a long-term product problem.
- Compare day 7 against day 1. A steep drop between these two points often means the app delivered a first value moment but failed to build a habit.
- Watch day 28 and beyond. Retention that flattens into a long tail, rather than continuing to decline, signals a stable core user base worth building on.
- Segment by acquisition source. Organic users frequently retain better than paid users, and blending them hides which channels are worth the spend.
GA4's retention overview report shows this day-by-day curve across the first 42 days by default, which is usually enough to spot where a cohort is leaking. For a sense of what counts as a reasonable target, Statista's retention data is a useful industry reference point rather than a hard benchmark, since retention varies enormously by app category.
Pro Tip: When day 1 retention is healthy but day 7 collapses, look at what happens between a user's first and second session rather than redesigning the onboarding screen itself.
Our retention benchmarks piece walks through target-setting by app category in more detail.
Monetisation and revenue KPIs: measuring value and payback
Monetisation KPIs tell you whether growth is sustainable, not just loud. ARPU (average revenue per user) divides total revenue by total active users across a period, giving a blended view across paying and non-paying users. ARPPU (average revenue per paying user) narrows that to paying users only, which is the sharper number for freemium and subscription apps where most users never spend a penny.
LTV (lifetime value), sometimes written CLTV, estimates the total revenue a user generates over their relationship with the app. A pragmatic early-stage proxy is the cohort average revenue per user over a 90 day window, used conservatively until enough long-term data exists to model true lifetime value. MRR (monthly recurring revenue) and subscription churn complete the picture for recurring revenue models.
A simple worked example makes the relationship concrete. Say an app spends £50,000 acquiring 5,000 paying users in a quarter, giving a CAC of £10 per user. If those users generate £4 ARPPU per month and the average paying relationship lasts 9 months, LTV comes to £36 per user. An LTV:CAC ratio of 3.6:1 is healthy by most standards, and payback period, the time needed to recover that £10 CAC at £4 per month, works out to roughly 2.5 months.
Which KPIs to prioritise depends heavily on the revenue model:
- Ad-supported apps should prioritise DAU and session frequency, since ad revenue tracks impressions rather than spend per user.
- In-app purchase apps should watch conversion to paid and ARPPU, since a small share of users typically drives most revenue.
- Subscription apps should treat subscription churn and MRR as north-star metrics, since retention of paying users matters more than raw install volume.
A healthy LTV:CAC ratio of 3:1 or higher is a commonly cited rule of thumb for sustainable unit economics, though the right threshold varies by category and funding stage.
Our monetisation guide breaks down LTV modelling by revenue model in more detail.
Technical performance and quality KPIs: stability, speed and battery
Technical KPIs are easy to treat as an engineering-only concern, but crash rate and load time influence discoverability directly, not just user mood. Android vitals defines "bad behaviour thresholds", including user-perceived crash rate and user-perceived ANR rate, and exceeding them can reduce an app's visibility in the Play Store itself.
User-perceived crash rate is the percentage of daily active users who experience at least one crash. User-perceived ANR rate measures the same for app-not-responding events on Android. Both matter more than raw crash counts, because they weight by how many real users are affected rather than how many crash reports pile up in a log.
Where to find these numbers:
- Play Console's Android vitals reports crash rate, ANR rate and excessive battery or wakelock usage against Google's own thresholds.
- App Store Connect's analytics dashboard surfaces crash-adjacent quality signals alongside acquisition and engagement data in one view.
- Crash diagnostics on Android rely on stack traces and deobfuscated symbol files, as Android's developer documentation explains for reproducing and fixing crashes.
- Internal crash trackers (Firebase Crashlytics or equivalent) should be the fast-moving source of truth between store console refreshes.
To decide what to fix first, a simple triage rule works well: multiply reach (the percentage of daily users affected), frequency (how often it recurs per user) and impact (session loss or revenue loss).
| Metric | What it measures | Where to find it |
|---|---|---|
| User-perceived crash rate | Share of daily users hitting at least one crash | Play Console Android vitals |
| User-perceived ANR rate | Share of daily users hitting an app-not-responding event | Play Console Android vitals |
| App load time | Time from tap to usable screen | Internal analytics, Firebase |
| Quality signals | Store-level stability and performance indicators | App Store Connect analytics |
Our piece on why app performance matters sets out the discoverability link in more detail, and our optimisation guide covers remediation steps once a problem is confirmed.
How to choose the right KPIs and keep dashboards actionable
The biggest mistake teams make is tracking everything and acting on nothing. A focused KPI set, tied directly to business objectives, beats a sprawling dashboard every time.
- Start from the objective, not the metric. Decide what the business needs this quarter, whether that is growth, retention or revenue, before picking any number.
- Pick one leading KPI per objective. For a retention objective, that is typically day 7 retention; for a revenue objective, it is usually ARPPU or MRR.
- Add two or three supporting metrics. These explain movement in the leading KPI rather than competing with it for attention.
- Assign a named owner to every KPI. Retention sits with product, CAC sits with marketing and finance, crash rate sits with engineering.
- Set a review cadence per KPI. Acquisition metrics often need weekly review; retention and LTV are better read monthly, since daily noise obscures the trend.
Before a KPI earns a place on the dashboard, run it through a short checklist: is it measurable with existing tools, does it suggest a clear action when it moves, does someone genuinely own it, does it align with a stated business objective, and is it free from sampling bias that would make small changes meaningless?
Pro Tip: If two KPIs always move together, keep the one that is easier to act on and drop the other from the dashboard rather than reporting both.
A partner resource on mapping metrics to business objectives covers a similar framework from a broader digital marketing angle, which is a useful cross-check for teams running app and web campaigns side by side.
Practical examples and checklist from Pocket App
When we onboard analytics for a new build, we run through the same short checklist every time, regardless of sector:
- Define core events first (first open, registration, key conversion, crash) before touching dashboard design.
- Tag every event with app version, platform and environment (production versus staging) to avoid polluting production metrics with test data.
- Set user attributes that matter for segmentation, such as acquisition channel and subscription tier, at the point of first capture.
- Confirm crash and ANR reporting is live before the first release candidate ships, not after launch.
A short anonymised example from a recent project: a retail client's day 7 retention dropped sharply after a routine release. The cohort table showed day 1 retention holding steady, which pointed away from onboarding and towards something introduced in that release. Cross-referencing Android vitals showed a spike in user-perceived ANR rate on one device family, traced to a blocking network call on the home screen. Fixing the call and shipping a hotfix returned day 7 retention to its prior level within two cohort cycles.
Pro Tip: When a retention metric drops sharply right after a release, check Android vitals and crash consoles before touching onboarding copy or design.
Our guide to instrumenting engagement events covers the tagging conventions behind this checklist in more depth.
Author perspective: why discipline and focus win
Most teams do not have a measurement problem. They have a metric inflation problem: twenty numbers on a dashboard with nobody accountable for any of them. Run a 30 day KPI audit, cut anything without an owner, and watch how much clearer the picture gets.
I would also push technical regressions higher up the priority list than most teams do. A crash spike is not just a bug ticket; it is a growth and discoverability problem, because Android vitals ties store visibility directly to stability thresholds.
— Paul
Pocket App services: discover, design, develop and deploy
Getting these KPIs instrumented properly, and fixed when they slip, takes more than good intentions on a sprint board. Our Discover and Develop services cover analytics implementation alongside the build itself, so event tracking is designed in from the first sprint rather than bolted on afterwards. Our Deploy stage includes ongoing monitoring, and when crash rates or retention dip after a release, our Mobile App Clinics offer a fast, focused way to diagnose the cause and agree remediation steps.
If your dashboard is full of numbers nobody owns, book a Mobile App Clinic and we will help you cut it down to the KPIs that actually move the business.
FAQ
What is mobile app analytics?
Mobile app analytics is the practice of collecting and interpreting data on how people use an app, covering acquisition, engagement, retention and revenue. Tools such as Firebase, GA4, App Store Connect and Play Console each cover a different slice of this picture, from store-level performance to individual in-app events.
Can you give me an example of a SMART KPI?
A SMART KPI for retention might be: "increase day 7 retention from 25% to 30% within one quarter by shortening onboarding." It is specific, measurable through cohort data in GA4 or Firebase, achievable within a defined timeframe, relevant to a stated business objective, and owned by the product team.
How much is an app with 100,000 users worth?
There is no single answer, because an app's value depends on ARPU, retention, churn and revenue model rather than user count alone. A simpler way to think about it is through LTV: multiply average revenue per user by expected lifetime, then weigh that against acquisition cost to judge whether the user base is actually profitable.
What are the 7 stages of app development?
Definitions vary across agencies, but a common version runs discovery, strategy, UX/UI design, development, testing, deployment and post-launch support. Our own process groups these into Discover, Design, Develop and Deploy stages, with ongoing monitoring and maintenance continuing after launch.
Sources
Good reporting starts with matching each KPI to the right source rather than pulling everything into one spreadsheet and hoping it reconciles. Store-level metrics, downloads, listing conversion and quality signals, live in App Store Connect and Play Console. Event-level metrics, sessions, feature adoption, funnel steps, belong in Firebase or GA4. Stability metrics belong in a dedicated crash console, cross-referenced against Play Console's Android vitals.
A minimal dashboard that teams can actually use daily needs very little:
- Monitor your app's technical quality with Android vitals - Play Console
- Analytics dashboard - App Store Connect
- Crashes | Android Developers
- Statista — iOS and Android app user retention rate
Sampling is the quiet source of most dashboard disputes. Reconcile the two sources once, understand the gap, and then trust the trend rather than chasing exact parity every week. A partner guide on measuring website success with KPIs and dashboard hygiene covers similar sanity-check habits for web analytics that translate directly to app dashboards.