Most app dashboards are full of numbers nobody acts on. Here's the smaller set of mobile metrics that actually predict whether an app is healthy — and the ones that quietly mislead founders into celebrating the wrong wins.
A founder once described their app's analytics dashboard as "the most expensive way I've ever found to feel good about a problem." Downloads were up, daily active users looked healthy on the surface chart, and the team was celebrating. Three weeks later they realized 80% of new users never opened the app a second time — a number none of the headline metrics had surfaced, because nobody had set up the one report that would have shown it. Mobile analytics isn't short on data. It's short on the specific questions that separate a growing app from one that's quietly leaking users while its download counter climbs.
Downloads and DAU Are Vanity Until Paired With Retention
Download counts and daily active users get reported because they're easy to screenshot and easy to feel proud of, not because they're the most useful numbers available. A spike in downloads driven by a paid campaign or a press mention tells you nothing about whether the app delivers value — it tells you an ad worked. Daily active users can climb even as your actual product is failing, if you're acquiring users faster than you're losing them, masking a retention problem behind a growth number.
The metric that actually tells you whether an app works is retention — specifically, what percentage of users who installed the app on day zero are still opening it on day 1, day 7, and day 30. These three numbers, often called the retention curve, are the single most diagnostic thing in mobile analytics. A healthy consumer app typically retains somewhere in the range of 25-40% of users by day 1, dropping to a smaller but stabilizing percentage by day 30 — the exact healthy range varies enormously by category (a habit-forming social or gaming app should retain meaningfully more by day 30 than a one-time-utility app), which is exactly why comparing your app's retention curve against generic industry benchmarks matters less than watching whether your own curve flattens out or keeps declining toward zero. A curve that keeps sliding toward zero past day 30 means the app has a fundamental value problem no amount of acquisition spend will fix. A curve that flattens — even at a modest percentage — means you've found a core group who get real value, and the next problem is acquisition and expansion, not the product itself.
Activation: The Metric Between "Downloaded" and "Retained"
Between install and long-term retention sits activation — whether a new user actually reaches the moment where the app's value becomes clear to them. This is the most underused metric category in mobile analytics because it requires a team to actually define, in specific product terms, what "getting value" means. For a marketplace app, it might be completing a first purchase or saving a first listing. For a fitness app, logging a first workout. For a messaging app, sending a first message and getting a reply.
Once that activation event is defined, the useful metric isn't just "did they do it" but "how long did it take, and how many steps stood between install and that moment." Every additional screen, permission request, or form field between download and activation is a place users fall off, and most teams don't discover where the drop-off actually concentrates until they build a funnel specifically to look for it. It's common to find that a single screen — an overly long onboarding form, a permissions request asked too early, an account-creation wall placed before any value has been shown — accounts for the majority of lost activation, and fixing that one screen moves the retention curve more than any feature addition would.
Session Data: Frequency and Length Tell Different Stories
Session count and session length get lumped together as "engagement" but they answer different questions. Session frequency (how many times a day or week someone opens the app) reflects how embedded the app is in a user's routine — this matters enormously for habit-based apps (social, news, fitness tracking) and matters much less for apps that are supposed to be used briefly and infrequently by design (a banking app, a car-booking app). Session length reflects depth of engagement within a visit, which is a genuinely good sign for content and entertainment apps and can be a warning sign for utility apps, where a long session might mean a user is stuck trying to complete a simple task rather than deeply engaged.
The mistake we see most often is applying a single "more engagement is always better" lens across every app category. A grocery delivery app where average session length is dropping while conversion rate holds steady is probably a good outcome — users are getting in, ordering, and getting out efficiently. The same drop in session length for a content app is a real warning sign.
Funnel and Conversion Metrics Where Money Actually Changes Hands
For any app with a monetization event — purchase, subscription, in-app upgrade — the funnel from "opened the app" to "completed the purchase" deserves its own dedicated tracking, broken into every discrete step: viewed the item, added to cart, started checkout, entered payment details, confirmed. Aggregate conversion rate (visits to purchases) is useful as a single top-line number, but it hides exactly where in that chain users abandon, and the fix for a drop-off at "entered payment details" (usually a friction or trust problem) is completely different from a fix for a drop-off at "viewed the item" (usually a pricing, positioning, or targeting problem).
For subscription apps specifically, tracking trial-to-paid conversion separately from overall retention is essential, since a healthy free trial start rate combined with a weak trial-to-paid conversion rate points squarely at a pricing or perceived-value problem rather than an acquisition problem — a distinction that changes what a team should actually spend the next quarter fixing.
Crash-Free Sessions and Technical Health Metrics
It's easy for growth-focused teams to under-invest in tracking crash-free session rate and app not responding (ANR) rates because they feel like "engineering's problem" rather than a growth metric. In practice, technical stability is one of the most direct levers on retention available, because a user who experiences a crash in their first session is dramatically more likely to uninstall than one who doesn't, and that effect compounds — a single bad crash-prone release can quietly undo months of retention improvements elsewhere in the product. Both major platforms and most analytics SDKs report crash-free rate automatically; the discipline that matters is treating a dip in that number with the same urgency as a dip in revenue, not as a background engineering ticket.
Attribution: Knowing Which Acquisition Channel Actually Works
Install counts by channel are the easy version of attribution. The harder, more valuable version connects each install back to which channel it came from and then follows that same cohort all the way through activation, retention, and revenue — because channels that produce cheap installs frequently produce the worst long-term users, and channels that look expensive on a cost-per-install basis often produce the users who actually stick around and pay. Without that connected view, a team can easily double down on the acquisition channel that's filling the top of the funnel with users who were never going to retain, while starving the channel that's quietly delivering the best long-term customers.
Cohort Analysis: Why Averages Hide the Real Story
A single aggregate retention number — "our 30-day retention is 18%" — is far less useful than the same metric broken out by cohort: users who installed this month versus last month, users acquired through one channel versus another, users who activated within the first session versus those who took three days to do so. Cohort analysis is simply the discipline of never looking at a metric as one blended average when it can instead be split by the group that installed together, because blended averages routinely hide both good news and bad news at the same time. A product change shipped six weeks ago might be quietly improving retention for every new cohort since, while a blended all-time-average number still looks flat because it's diluted by years of older, differently-behaving users.
The most useful version of this is a retention cohort table — rows for install week or month, columns for days or weeks since install, cells showing the percentage still active — because it makes trend changes visible in a way a single line chart doesn't. If day-30 retention for the cohort that installed after a specific feature launch is visibly higher than every cohort before it, that's a much stronger, faster signal that the feature worked than waiting for a slow-moving blended metric to shift. Most analytics platforms build this view in natively; the discipline is in actually checking it regularly rather than defaulting to the single blended top-line number because it's the first thing the dashboard shows.
Attribution Is Getting Harder, Not Easier
Tracking which acquisition channel actually drove an install and its downstream behavior has become measurably more difficult over the past several years, largely due to privacy changes on both major platforms. Apple's App Tracking Transparency framework requires explicit user opt-in before an app can access the device identifier historically used for cross-app attribution, and a large share of users decline when asked directly, which means traditional device-level attribution now works for a shrinking fraction of installs. Apple's replacement mechanism, SKAdNetwork (and its successor framework), provides aggregated, privacy-preserving attribution instead of user-level tracking — useful for measuring which campaigns drove installs in aggregate, but deliberately withholding the individual-level detail that used to make connecting a specific user's full journey from ad click to lifetime value straightforward.
The practical implication for a team building out analytics isn't to give up on attribution, but to plan for probabilistic and aggregated attribution as the norm rather than the exception, and to invest correspondingly more in first-party signals a team fully controls — what happens after install, measured through the app's own analytics — since that data isn't subject to the same platform-level restrictions as cross-app ad attribution. It also means being skeptical of any acquisition channel's self-reported performance numbers, since a channel grading its own attribution has a structural incentive to claim credit generously.
Building a Dashboard You'll Actually Use
The practical failure mode with mobile analytics isn't a lack of tools — every major analytics platform (Firebase Analytics, Mixpanel, Amplitude, and others) can track all of the above out of the box. The failure mode is instrumenting dozens of events during development without deciding in advance which handful of numbers the team will actually look at weekly and act on. A dashboard with thirty charts gets opened once and ignored. A dashboard with five numbers — day-1 and day-30 retention, activation rate, crash-free sessions, and conversion rate for whatever the core monetization event is — gets checked every week, because it's small enough to actually hold in your head and specific enough to point directly at what needs fixing next.
When we build analytics into a client's app, that's the sequencing we push for: define the activation event and the core funnel before writing a single line of tracking code, instrument only what answers a real question the team will keep asking, and treat the retention curve as the primary health signal the rest of the roadmap gets built around — not the download counter that looks good in a screenshot but tells you nothing about whether the app is actually working.
