PWA Retention Metrics: D1/D7, Install Funnel, Display Mode (2026)

PWA retention metrics that separate browser from installed users

PWA retention metrics measure whether people come back to your Progressive Web App—and whether the installable experience actually beats the mobile browser. If you only track overall sessions, installed-user gains disappear inside the average.

Split every retention and engagement report by display mode (browser vs standalone / app-mode) and by launch source (home-screen icon, notification, share target, normal URL).

Core retention definitions

Use cohort windows the product team already understands:

• D1 / D7 / D30 retention — share of a start cohort that returns on day 1, 7, or 30.
• Churn — roughly the complement of retention for the same window.
• Stickiness (DAU / MAU) — how often monthly users show up daily.
• Sessions per user / session length / pages per session — depth and habit, not vanity pageviews.

Activation events (finish onboarding, first add-to-cart, first purchase, core feature used) are leading indicators: cohorts that activate early usually retain better.

For ecommerce PWA context, start from PWA for Ecommerce and PWA Offline Support.

Install funnel metrics (Chromium-first)

On Chromium you can observe install prompts; on Safari/Firefox lean on app-mode launches instead:

1. Promotable / prompt shown
2. Prompt accepted vs dismissed
3. appinstalled (or equivalent)
4. First standalone launch

Report acceptance rate and install rate with the same cohort clock you use for retention. Raw install count without funnel context is a vanity number.

Related: PWA vs TWA when you compare packaging choices that change install UX.

Engagement and re-engagement signals unique to PWAs

Instrument events that classic web analytics miss:

• Standalone launches tagged with launch source
• Offline sessions (service worker controlled) and whether key actions still complete
• Push delivery / click / close from the service worker, with notification IDs on open URLs
• Deep-link opens into the PWA shell — see Deep Linking for PWA

Push that raises opens but also raises uninstalls or notification disables is not “good retention.” Track opt-out and quiet hours alongside click-through.

Checkout friction after return visits belongs in the same review as retention—see PWA Payment Integration.

How to read the numbers without fooling yourself

1. Always segment installed vs browser — installed users often show higher visit frequency and value; blending hides ROI of install prompts.
2. Prefer returning-user cohorts over cumulative lifetime totals when judging product changes.
3. Buffer offline analytics (IndexedDB + replay) so retention does not look worse simply because users were offline.
4. Deduplicate event IDs on the server so reconnect storms do not invent fake sessions.
5. Pair retention with revenue — a stickier cohort that never pays is not the goal for commerce PWAs.

Public case studies (for example large retailers shipping installable web apps) often show large lifts in visit frequency for installers vs non-installers; treat those as direction, then measure your own display-mode split.

A minimal weekly PWA retention dashboard

• D1 / D7 retention by display mode
• Standalone share of sessions
• Install prompt acceptance (where available)
• Push click rate and disable rate
• Activation rate within first session / first day
• Revenue or orders per returning user (browser vs standalone)

If D1 falls after a release, inspect first-load performance, permission prompts, and onboarding—not only media spend.

Common mistakes

• Reporting one blended retention rate for the whole site.
• Celebrating installs while standalone launch rate stays flat.
• Measuring push CTR without delivery failures and opt-outs.
• Losing offline events and blaming “bad retention.”
• Optimizing session length when the product should optimize task completion time.

FAQ: PWA retention metrics

Which single metric should we optimize first? D1 retention by display mode plus an activation event. Without those, later windows are noisy.

Do we need an app-store style MMP? Not always. First-party analytics with display_mode and durable user IDs covers most PWA retention questions; add MMP if you also run native apps and need cross-surface identity.

How is PWA retention different from native? Uninstall is harder to observe; Safari install signals differ; offline and push live in the service worker. Definitions must document those gaps.