Mobile Retention Metrics: Reading D1, D7, and D30 Correctly

If a mobile app's retention curve keeps sloping downward even while daily active users climb, that growth isn't durable — the moment new-user inflow stops, the numbers fall back. Mobile retention metrics, especially D1, D7, and D30, are the standard way to measure that durability; but why the D7 number in your App Store Connect dashboard doesn't match the D7 number in your own backend is more technical than most teams assume: cohort definition, counting window, and the "device or account" question. Here I compare Apple's and Google Play's official definitions to show how to read D1/D7/D30 correctly and tie them to a product decision.

💡 Pro Tip: Before you report your D7 retention as a single percentage, write which cohort window you used (install day or install week) right in the title — three months later you won't be able to make a healthy comparison even against your own past data.

Table of Contents

• What Are D1, D7, and D30 Retention?
• Three Different Definitions of Retention and Which to Choose
• The Cohort Window and Timezone Trap
• Reinstalls, Multiple Devices, and Accountless User Counting
• Why Your Store Dashboard and Your Own Analytics Don't Match
• Building Your Own Cohort Table: SQL and Event Schema
• Event naming conventions
• Reading the Retention Curve: Where Does the Drop-Off Break
• What to Watch When Comparing the Curve Over Time
• Which Product Decision Should You Tie Retention To
• Measurement Setup Checklist
• FAQ
• How are D1, D7, and D30 retention calculated?
• Why does my store dashboard show different numbers than my own analytics?
• Which product decision should I tie retention to?
• Do Apple and Google Play define retention the same way?
• Does a user who reinstalls affect my D1 retention?
• Update (September 2026)
• Conclusion
• Sources

What Are D1, D7, and D30 Retention?

D1, D7, and D30 retention measure the rate at which a cohort of users who installed an app on the same day return to the app 1, 7, and 30 days after install, respectively. Apple's official definition puts it this way: "retention tells you the percentage of active devices that installed the app on the selected day and opened the app a certain number of days later." Apple's definition for D1 is even more concrete: "Day 1 retention shows the percentage of active devices that opened your app 1 day after installation."

The general formula:

1D_n retention (%) = (number of devices that opened the app n days after the install date / total number of devices that installed on that same day) × 100

A critical detail: users who install but never open the app enter neither the numerator nor denominator of this calculation. Apple states this explicitly: "Users who install your app but never open it do not qualify, and are not counted in the numerator or the denominator of the calculation." That single sentence explains why "install count" and "retention count" run on different denominators.

Three Different Definitions of Retention and Which to Choose

"Retention" isn't a single standard — there are at least two official definitions, plus a third one specific to your own product.

Apple measures retention on a per-device basis, tied to the "opening the app" action. Google Play answers a different question: did the user keep the app on their device (opening it isn't required). The Play Console help page defines it this way: "Installers who kept your app on at least one of their devices for the number of days shown." So for the same user base, two dashboards can produce two different percentages simply because they're answering two different questions — that's not a bug, it's a definitional difference.

The third option is your product's own definition of a "meaningful session" — for example, an e-commerce app might count adding an item to cart, not just opening the app, or a content app might count reading one article, as the "real return." There's no official source for this; it's a product decision tied to your event schema, and it can deliberately diverge from what the store dashboards show.

The Cohort Window and Timezone Trap

In Apple's cohort table, rows all mean the same thing: "Rows represent cohorts of users who installed your app on the same day." So each row shows the return behavior over time of the group of users who installed on that day. Intuitive so far — but the trap is that the denominator can grow retroactively.

Apple explains this with a clear example: "if someone installs your app on January 1st, but doesn't open it until January 10th, then the denominator for all January 1 retention rates will increase by one on January 10…" In other words, the January 1 cohort's D1 retention might look final on January 3, but if someone belatedly opens the app for the first time on January 10, that cohort's denominator grows and the historical percentage shifts retroactively. Practical takeaway: don't report the last 7-10 days of retention as "final" — that window may not be closed yet.

Reinstalls, Multiple Devices, and Accountless User Counting

Apple's "Installations" metric counts reinstalls on the same device, downloads to multiple devices sharing the same Apple Account, and Family Sharing installations separately, without deduplication: "Redownloads on the same device, downloads to multiple devices sharing the same Apple Account, and Family Sharing installations are included." So even a user who switches phones and reinstalls can inflate your install count — and the retention denominator along with it.

On Google Play, the logic runs in reverse: "Your 'Installers' data only includes unique users who installed your app for the first time" — Play Console's "Installers" data counts only genuine first-time installs, with reinstalls reported separately. The same event (a reinstall) is folded into the metric differently by each platform; ignore that difference when comparing D1/D7/D30 across platforms and you'll end up chasing the wrong question, like "why does retention look lower on Android."

Why Your Store Dashboard and Your Own Analytics Don't Match

The root cause of this isn't a single thing — it's four overlapping filters:

• Opt-in data: Apple Analytics only collects data from users who agree to share it — "Analytics in App Store Connect provides usage data collected from users who have agreed to share their data." Your own backend likely sees your entire user base, while the Apple dashboard only sees the opt-in subset.
• Privacy threshold: Apple may not show data for small cohorts — "To protect user privacy, Analytics only shows data after a certain number of data points are available." If a new country has only a handful of installs, the chart may come up empty or incomplete.
• Minimum OS version: Most of Apple's metrics require a minimum OS version: "Based on devices running a minimum of iOS 8, macOS 11, tvOS 9, or visionOS 1." Your users on very old devices may not show up in the dashboard at all.
• watchOS exclusion: "Analytics doesn't include data from watchOS" — if you have a watchOS companion app, those users never enter the App Store Connect retention figure.

If you've built your analytics stack on Firebase (a general-purpose product that helps you "understand how people use your web, Apple, or Android app," with unlimited reporting for up to 500 distinct events), that adds a fifth filter layer: Firebase runs on your own event definitions, while the store dashboard runs on the four rules above.

Building Your Own Cohort Table: SQL and Event Schema

To calculate your own retention numbers without depending on store dashboards, here's the minimal event schema you need:

1{
2  "event_name": "session_start",
3  "user_id": "anon-install-id",
4  "install_date": "2025-03-01",
5  "event_date": "2025-03-08",
6  "platform": "ios"
7}

Once this schema is written to an event table, a general-purpose query that calculates Dn retention per install cohort can be built like this (adaptable to any data warehouse dialect):

1-- Calculate Dn retention per install cohort
2WITH installs AS (
3  SELECT user_id, MIN(event_date) AS install_date
4  FROM app_events
5  WHERE event_name = 'first_open'
6  GROUP BY user_id
7),
8opens AS (
9  SELECT e.user_id,
10         DATE_DIFF(e.event_date, i.install_date, DAY) AS day_n
11  FROM app_events e
12  JOIN installs i USING (user_id)
13  WHERE e.event_name = 'session_start'
14)
15SELECT i.install_date,
16       COUNT(DISTINCT CASE WHEN o.day_n = 1 THEN o.user_id END) * 1.0
17         / COUNT(DISTINCT i.user_id) AS d1_retention,
18       COUNT(DISTINCT CASE WHEN o.day_n = 7 THEN o.user_id END) * 1.0
19         / COUNT(DISTINCT i.user_id) AS d7_retention
20FROM installs i
21LEFT JOIN opens o USING (user_id)
22GROUP BY i.install_date;

The table below is not data from a real app — it's a hypothetical example cohort meant only to show how to read the output of the query above:

In this example, for the March 1 cohort, D1 retention works out to 38%, D7 retention to 21%, and D30 retention to 9% (the number of users who opened divided by the install count). Seeing these three numbers side by side in your own data is the first step to understanding where the curve breaks.

Event naming conventions

The most common mistake when setting up your own cohort infrastructure is overloading the "app_open" event: logging it both when the app comes to the foreground and when a specific screen opens makes your D1/D7/D30 query produce a retention figure higher than reality. Keep two separate events: session_start (every foreground return, including from background) and first_open (only the first launch after install). Use session_start for retention — first_open only sets the cohort's start date; mixing the two groups your cohort table by the wrong install date.

Reading the Retention Curve: Where Does the Drop-Off Break

When reading a retention curve, I usually look at two points: how steep the initial drop is, and where the curve starts to flatten. A sharp drop from D1 to D7 generally points to friction somewhere in onboarding — the user opened the app once but left without understanding the value proposition. The curve flattening toward a horizontal line between D7 and D30 generally shows the size of your "durable user base"; the users who remain past this point have turned the app into a habit, and the drop-off rate slows down.

Don't interpret the last few days of the curve without accounting for the cohort window trap (the retroactive denominator growth described in the previous section) — that data may not be "closed" yet.

What to Watch When Comparing the Curve Over Time

Even with the same cohort window, comparing month-over-month or version-over-version requires holding two things constant: the data source (dashboard or backend) and the platform mix (a shifted iOS/Android ratio shifts blended retention too, since the two platforms' reinstall/dedup rules differ). If D1 retention suddenly jumps after a version update, before asking "did onboarding improve," check whether something changed on the measurement side (a new event, an SDK version, a cohort-definition shift) — a measurement change produces false positives far more often than a real product change does.

Which Product Decision Should You Tie Retention To

The point of tracking the three numbers separately is tying each to a different product decision. Low D1 usually means an onboarding problem — check how fast you show value on first launch. Low D7 means it's time to revisit your habit loop and notification/email strategy. D30 usually ties to monetization timing: if you run a subscription model, trial end typically falls in this window, so evaluate pricing and trial-length decisions alongside D30 data.

Measurement Setup Checklist

To condense the rules from this article into a single checklist:

• Fix the cohort window: write whether you're using days or weeks right in your report title.
• State the data source: store dashboard or your own backend — the two use different denominators.
• Clarify your reinstall/multi-device rule: Apple doesn't deduplicate, Google Play separates out first installs — account for this when comparing across platforms.
• Remember the opt-in and privacy threshold: the store dashboard may show incomplete data for small cohorts.
• Check the minimum OS version filter: your users on older devices may not show up in the dashboard.
• Don't treat the last few days of data as "final": the cohort window can grow retroactively.
• Tie each number to a product decision: D1 → onboarding, D7 → habit loop, D30 → monetization timing.
• Separate your event names: don't merge session_start and first_open into one event, or your cohort denominator will be grouped by the wrong install date.
• Isolate the effect of platform mix: when the iOS/Android ratio shifts, expect your blended retention figure to shift too — don't mistake this for a product change.

If you want to review this list before your next report, you'll find a checkable version of the same checklist in the "Reader Reward" section at the end of this article.

FAQ

How are D1, D7, and D30 retention calculated?

D1, D7, and D30 retention are the percentage of a cohort of users who installed on the same day that return to the app 1, 7, and 30 days after install, respectively. Per Apple's definition, it is the percentage of active devices that installed the app on the selected day and opened the app a certain number of days later; users who never open the app are not counted.

Why does my store dashboard show different numbers than my own analytics?

Four filters stack together: Apple Analytics only sees opt-in users, small cohorts may show incomplete data due to the privacy threshold, most metrics require a minimum OS version, and watchOS data isn't included. Your own backend likely sees your whole user base without any of these filters.

Which product decision should I tie retention to?

Tying D1 to onboarding, D7 to habit loop and notification strategy, and D30 to monetization and subscription timing is a practical approach. Since each number answers a different question, tying each to its own action plan beats a single "overall retention" goal.

Do Apple and Google Play define retention the same way?

No. Apple uses a device-based definition tied to actually "opening" the app. Google Play Console instead looks at whether the user "kept" the app on their device — opening it isn't required. For the same user base, these two definitions can produce different percentages.

Does a user who reinstalls affect my D1 retention?

It depends on the platform. Apple's Installations metric counts reinstalls on the same device and multi-device installs without deduplication, which can inflate your denominator. In Google Play Console, "Installers" data counts only genuine first-time installs, and reinstalls are reported separately.

Update (September 2026)

This article was first published on March 12, 2025. In the roughly 18.5 months since, the core definition of D1/D7/D30 retention hasn't changed, but the measurement infrastructure and benchmark data have changed significantly.

1) Apple overhauled App Store Connect Analytics on March 25, 2026. More than 100 new metrics were added; the most critical change is that cohort analysis now ships natively: tracking user behavior over time by download date, download source, and offer start date no longer requires a third-party tool. Source: MacRumors, March 25, 2026.

2) Apple's official retention definition is still based on "active device," not "account." This is at the root of the "why does my store dashboard differ from my own analytics" question: Apple counts devices, while most third-party analytics count users/pseudo-IDs.

3) On October 17, 2025, Google largely shelved its planned Privacy Sandbox infrastructure on Android. The Attribution Reporting API, Protected Audience, Protected App Signals, and the Topics API were retired. Source: Privacy Sandbox official blog.

4) Apple's AdAttributionKit now adds re-engagement (redownload) measurement. SKAdNetwork hasn't been deprecated; the two frameworks operate together in 2026. Source: Admiral Media, 2026.

5) With iOS 26 (September 2025), "Advanced Fingerprinting Protection" became the default in Safari across all browsing modes. This doesn't directly change the D1/D7/D30 definition, but it does add noise to web-to-app attribution chains. Source: Apple Newsroom, June 2025.

6) The App Tracking Transparency (ATT) opt-in rate rose to roughly 38% in its fifth year and continues to climb gradually each year. Source: SignalSeal, 2026.

In short, what changed: the depth of Apple's cohort analysis, AdAttributionKit's re-engagement measurement, the retirement of four Privacy Sandbox APIs on Android, and the rise in the ATT opt-in rate. What didn't change: the fundamental definition of D1/D7/D30, Apple's device-based counting, and reinstalls being reported as a separate metric.

Related posts published later:

• StoreKit 2 subscription guide
• Subscription offer codes in App Store Connect
• Google Play Billing v7 guide
• The real $1 million strategy on the iOS App Store

Conclusion

The key to reading D1, D7, and D30 retention correctly isn't a single "correct" definition — it's knowing which source answers which question: Apple asks whether the device was opened, Google Play asks whether the app was kept on the device, and you choose your product's own definition of a "meaningful session." Remembering that the cohort window can grow retroactively, tie each number to a separate product decision (D1 → onboarding, D7 → habit loop, D30 → monetization).

Sources

• Apple — App Retention (App Store Connect Analytics) — the official definition of D1/D7/D30 retention, cohort window behavior, and the "users who never open aren't counted" rule.
• Apple — Metrics Definitions (App Store Connect Analytics) — official definitions of Installations, Active Devices, and minimum OS version requirements.
• Apple — Analytics Dashboard Overview — opt-in data collection, privacy threshold, and watchOS exclusion rules.
• Google Play Console Help — Retention Report — Google Play's "installers who kept your app" definition and the first-install/reinstall distinction.
• Privacy Sandbox — Update on Plans for Privacy Sandbox Technologies — announcement of the retirement of the Attribution Reporting API, Protected Audience, Protected App Signals, and Topics API on Android.
• Firebase — Google Analytics for Firebase Documentation — the general product scope of Firebase Analytics and event reporting limits.
• MacRumors — App Store Connect Receives New Metrics (March 25, 2026) — news confirmation of Apple's 2026 cohort analysis update.
• Apple Newsroom — Apple Elevates the iPhone Experience with iOS 26 (June 2025) — the official announcement that Advanced Fingerprinting Protection expanded to all browsing modes by default in Safari.
• Admiral Media — AdAttributionKit iOS Measurement Playbook — a technical overview of AdAttributionKit's re-engagement measurement capability.
• SignalSeal — ATT Five Years On — the trajectory of the App Tracking Transparency opt-in rate as of 2026.