Mobile app analytics: downloads don't matter, retention does
A team runs a paid campaign, and the store console shows a spike of new installs for the week — the whole channel gets a round of applause. A month later revenue hasn't moved, and nobody can say why.
The usual reason is simple: the same chart that shows installs says nothing about who is still in the app next week. An app isn't measured by how many times someone tapped "Install" — it's measured by how many times they open it again, and that's where the real answer to "did the campaign work" actually lives.
What the install count doesn't tell you
When the install number in the console climbs, the team relaxes — but that number records a single moment: the tap on "Install". It says nothing about whether the person opens the app again tomorrow. Google Play Console formally separates this out: it defines 7-day retention as "the number of devices on which your app was opened again on the seventh day after it was first opened" (Google Play Console help) — a distinct, separately measured event, not something you can read off the install count.
The practical fix for a weekly report: the line "N installs this week" isn't enough on its own — it needs a second line next to it, "how many of last week's installers opened the app today." The first number tells you the budget got spent. The second tells you what it actually turned into.
Day 1 retention: the first-impression test
Someone installs the app, taps through a couple of screens, and deletes it before the day is over. There's no session, no opened notification, nothing at all from them the next day.
This is rarely a product-quality problem — it's usually the weight of the first five minutes. Sign-up is mandatory, permission prompts fire one after another, and the person hasn't yet seen what the app is actually for. They close the door before finding out what's behind it.
Track Day 1 retention as a percentage — how many installers opened the app again the next day — and use event tracking to see exactly where in onboarding people drop off. A concrete move for this week: push sign-up one screen later, show the core feature first, and create the account afterward.
How the cohort is read
The number is never calculated for a single day — it's calculated for a cohort: everyone who installed on the same day forms a group, and you measure what share of that group comes back on day 1, day 7, day 30. That is exactly how Google Play's own definition of 7-day retention works — the count of devices that reopened the app on the seventh day after first opening it.
Day 7 retention: is a habit forming
Day 1 looks fine, but a week later most of those users are gone — the app got tried once and then forgotten.
This usually points to a missing bridge between the moment the product delivers value and the user's everyday routine. The value is real, but nothing reminds them of it: no notification, no reason to come back, or the feature is genuinely one they only need once a year, not once a week.
Find the specific "aha" event — a first order, a first search, a first saved item — and compare Day 7 retention between users who hit that event early and those who didn't. If the gap is large, the job is getting people to that event sooner, not shipping another feature.
Day 30 retention: the long-term value
A month out, the chart is down to a thin sliver — almost everyone else has either deleted the app or simply stopped opening it.
Every install bought through ads carries a cost (CPI). That cost is paid once; it only pays for itself for as long as the user sticks around. If Day 30 retention is close to zero, the ad budget is buying one-time installs rather than customers — and that fact hides behind the "installs" line in the report.
Put CPI per channel side by side with Day 30 retention. If installs from a "cheap" channel leave almost nobody by day 30, the channel isn't cheap — the cost has just been filed under a different name.
How to actually build and track this
Most teams don't have any of these numbers, because the store console only shows installs, and no event-level tracking exists inside the app itself.
Measuring retention needs more than an "opened" event — it needs specific in-app actions logged: sign-in, use of the core feature, a session. That's data the store console never gives you.
Wiring in an analytics SDK
iOS and Android need separate integrations — two different codebases — but the reporting dashboard can be unified into one view.
Deciding which events to track
Every screen and every key action gets its own event, so the answer to "where are we losing people" is a number, not a guess.
Building the dashboard and actually reviewing it weekly
Raw data helps nobody on its own — Day 1, Day 7 and Day 30 retention need to live on one dashboard the team actually opens every week.
A hundred thousand installs and zero retention by day 30 isn't a customer base — it's a receipt for a month of ad spend.
On paper this sounds straightforward, but getting it right — finding the actual "aha" event, wiring the SDK correctly on both iOS and Android, building cohorts onto one dashboard without the numbers quietly drifting apart — is its own piece of work. Our mobile app analytics service sets this up from the ground up, so every screen of your app becomes something you can actually measure.
