How to Keep App Users Coming Back: Onboarding, Retention and Push Notifications

Users keep coming back to an app when they reach its core value quickly and are reminded of it at the right moments. In practice, that means defining one activation event and steering every new user towards it in the first session. Ask for notification permission only once its benefit is obvious, and read retention by cohort (D1, D7, D30) so you can tell whether each change helped.

This guide is for founders in the UK, US and Canada whose app is live, who are getting installs, and who are watching too many of those users disappear.

What is activation, and how do you find your "aha" moment?

Activation is the first moment a new user gets the value your app promises: a first booking confirmed, a first invoice sent, a first workout logged. The "aha" moment is when the user realises the app is worth keeping.

Find it in your own data, not in a brainstorm:

1. List three to five candidate actions a user can take in the first days.
2. Compare users who were still active after 30 days with users who left. Which early action did the retained group take far more often?
3. Talk to five retained users and five who left. Ask what they were trying to do in their first session.
4. Choose one action and give it a deadline, for example "booked a first appointment within 24 hours of install". Track it as a single event.

A correlation is not proof. Once you have a candidate, change onboarding to push more users towards it and see whether retention improves for the cohorts that follow.

What should onboarding look like?

Good onboarding is the shortest route from install to activation. Everything else can wait.

• Let people see value before an account. If the app can show something useful before sign-up, such as browsing services or a sample report, do that first.
• Ask only for what the first task needs. UK GDPR requires personal data to be "limited to what is necessary" for the purpose anyway (ICO, accessed Oct 2026).
• Replace tours with a first task. Feature carousels are easy to skip; completing a pre-filled first action teaches more.
• Use empty states. An empty screen should say what will appear there and offer the button that fills it.
• Request permissions one at a time, in context. Ask for the camera when someone taps "scan", location when they search nearby, notifications when they do something they will want updates on.

When should you ask for notification permission?

Ask after the user has done something that makes notifications clearly useful, not on first launch. Both platforms say so.

iOS. Apple advises making the request "in a context that helps people understand why your app needs authorization". Its example is a task app asking after the person schedules a first task, which it says is better than "automatically requesting authorization on first launch". The system prompt appears only once: "subsequent authorization requests don't prompt the person" (Apple Developer, accessed Oct 2026). After a refusal, the user has to change it in Settings.

iOS also offers provisional authorisation. Notifications arrive quietly in Notification Center's history, with no sound, banner or lock screen alert, and include buttons to keep or turn off future notifications (Apple Developer). It lets users judge your notifications before deciding.

Android 13 and later. Notifications are a runtime permission (POST_NOTIFICATIONS). For new installs, "notifications are off by default" until the user grants it. Google advises letting users "familiarize themselves with your app" first, and gives examples of good moments: tapping an alert bell, following an account, or submitting a food delivery order. Waiting until the third or fourth launch is another option it suggests (Android Developers, accessed Oct 2026). Apps that target Android 12L or lower usually get the prompt on startup, and one "Don't allow" stops further prompts until a reinstall or an update that targets Android 13. Targeting Android 13 puts the timing in your hands.

A simple pattern for both: show your own short screen explaining what the notifications will contain, with "Turn on" and "Not now". Show the system prompt only after "Turn on". Android's design guidance also says not to show the permission dialog "if the user has dismissed the UI" (Android Developers, accessed Oct 2026).

How do you read D1, D7 and D30 retention?

D1, D7 and D30 retention is the share of a cohort that returns one, seven and 30 days after their first open. A cohort is a group of users who started in the same period, usually the same week.

Read it as a table, one row per weekly cohort:

• Read across a row to see how quickly a cohort drops away. If most of the loss comes in the first days, onboarding is where to look.
• Read down a column to compare cohorts at the same age. If D7 for this month's cohorts is higher than last month's, something you changed is working.
• Look at the shape. A curve that flattens means a group of users has found lasting value. A curve that keeps sliding towards zero means nobody has yet.
• Split by source. Compare paid users with organic users, and iOS with Android, before drawing conclusions from a blended number.

Google Analytics 4 has a cohort exploration for this. You set the inclusion criteria (for example, first touch), the return criteria, and daily, weekly or monthly granularity. "Standard" counts users who returned in that specific period; "rolling" counts users who returned in that period and every earlier one (Analytics Help, accessed Oct 2026). Use "standard" for the classic D1/D7/D30 view.

Published retention benchmarks vary widely by category, country, platform and acquisition source, so this guide doesn't quote any. Your own earlier cohorts are the benchmark that matters.

What makes a good push notification?

A good push notification is something the user would be annoyed to miss: an order update, a reply, a reminder they asked for. Both platforms have explicit rules on the rest.

Apple's Human Interface Guidelines (Apple, accessed Oct 2026):

• "Don't use notifications to send marketing or promotional content unless people explicitly agree to receive such information." You need an interface that describes what you will send and gives a clear way to opt in or out, plus an in-app settings screen to change that choice.
• Use the right interruption level. Passive is for things to view "at their leisure", Time Sensitive for "an account security issue or a package delivery". Time Sensitive should be about an event "that's happening now or will happen within an hour".
• Avoid sending several notifications about the same thing, and keep "sensitive, personal, or confidential information" out of notifications, because others may see the screen (Apple, accessed Oct 2026).

App Store Review Guideline 4.5.4 says push notifications "must not be required for the app to function" and "should not be used to send sensitive personal or confidential information". They should not be used for promotions or direct marketing "unless customers have explicitly opted in to receive them via consent language displayed in your app's UI", with an in-app way to opt out (App Store Review Guidelines, accessed Oct 2026).

Android's guidelines require every notification to belong to a channel, and only the user can change a channel's behaviour once you create it. Google advises creating "a channel for each type of notification", so people can mute promotions without losing order updates (Android Developers, accessed Oct 2026). Its design guidance lists what not to send, including "cross-promotion or advertisement of another product", notifications to users who have never opened the app, requests to rate the app, holiday or birthday messages, and nudges that "provide no direct value (for example, 'Haven't seen you in a while!')" (Android Developers, accessed Oct 2026).

Practical rules: send transactional messages first, cap marketing messages per week, respect time zones and quiet hours, and open the exact screen each notification mentions.

Where do email and in-app messages fit?

In-app messages reach people who are already active, email reaches people who have stopped opening the app, and push sits between the two. Coordinate them, so one event doesn't trigger the same message three times.

Marketing messages carry legal duties that differ by country:

• UK. PECR covers "electronic mail", and the ICO lists "in-app messages" alongside email and texts (ICO, accessed Oct 2026). Marketing to individuals needs consent, or the "soft opt-in" for your own similar products and services, where you collected the details during a sale or negotiation and offered an opt-out then and in every message (ICO, accessed Oct 2026).
• Canada. CASL requires consent, identification of the sender and a working unsubscribe for commercial electronic messages. Unsubscribe requests must be honoured within 10 business days (Government of Canada, accessed Oct 2026). PIPEDA separately governs how private-sector organisations collect and use personal information in commercial activity (Office of the Privacy Commissioner of Canada, accessed Oct 2026).
• US. CAN-SPAM requires commercial email to identify itself as an advert, include a valid postal address and a clear opt-out, and honour opt-outs within 10 business days (FTC, accessed Oct 2026). State privacy laws also apply. California's CCPA, for example, gives residents rights to know, delete and correct personal information and to opt out of its sale or sharing (California Attorney General, accessed Oct 2026).

Transactional messages, such as receipts and password resets, are treated differently from marketing. Under CAN-SPAM, an email whose content is only transactional or relationship content is "exempt from most provisions", but the FTC says the law views these categories "narrowly" (FTC). Keep them free of promotions.

This is general information, not legal advice. Check your consent flows with a qualified adviser in each market you serve.

How do you win back users who have lapsed?

Give them a concrete reason to return, not a generic nudge. Android's guidance rules out "Haven't seen you in a while!" notifications, and a lapsed user may have switched notifications off or uninstalled the app.

What works better:

• A real change. A new feature they asked for, a fixed bug they reported, or new content in a category they used. Email, sent with consent, may be the only channel that still reaches them.
• Unfinished value. A saved basket, a draft, or a booking slot that has opened up.
• Subscription win-back offers. On the App Store, win-back offers target lapsed subscribers. You choose eligibility by minimum paid duration and time since the subscription ended, and from iOS 18 eligible customers can see the offer in your app (App Store Connect Help, accessed Oct 2026). Google Play lets you create offers with "developer determined" eligibility, and it gives win-back offers for lapsed subscribers as an example (Play Console Help, accessed Oct 2026).
• Ask why they left. A one-question email to users who lapsed recently often explains more than a dashboard.

Measure a win-back campaign by whether returning users stay for the following weeks, not by how many opened the message.

How should you measure retention?

Instrument a small set of named events before you change anything, and report them weekly. In GA4, app streams collect some events automatically, including first_open (the first launch after install or reinstall) and user_engagement. On Android, app_remove records uninstalls (Analytics Help, accessed Oct 2026). Add your own events for sign-up, activation, the core repeat action and notification opt-in.

GA4 or a product analytics tool can produce the cohort and funnel reports; consistent event names matter more than the tool.

Measurement has its own data protection duties. The ICO says PECR's storage and access rules apply "in web browsers, mobile apps and connected devices" (ICO, accessed Oct 2026). Analytics may fall under the statistical purposes exception if users get clear information and a simple, free way to object, but advertising measurement needs consent (ICO, accessed Oct 2026). Collect only the event data your reports actually use, and keep names, email addresses and health details out of analytics events.

When Digital Architect builds the backend for an app, we run it on AWS (Amazon Web Services), and we choose the rest of the stack per project to fit the scope.

What should you avoid?

• Asking for notification permission on the first screen. On iOS you get one system prompt, so spend it when the value is clear.
• Marketing pushes without explicit opt-in. This breaks App Store guideline 4.5.4 and Apple's HIG.
• Re-engagement notifications with no content. Android's guidelines rule them out by name.
• Personal or sensitive details in notifications. Lock screens are visible to other people.
• Judging changes on blended averages or on someone else's benchmark. Compare your own cohorts, split by platform and source.
• Buying installs to fix a retention problem. It only makes the problem more expensive. Our guide on getting your first app users covers when paid acquisition makes sense.

A 30/60/90-day retention plan

Days 1–30: measure

1. Define one activation event with a deadline, and instrument sign-up, activation, the core repeat action and notification opt-in.
2. Build a weekly cohort table for D1, D7 and D30, split by platform and source.
3. Interview five retained users and five who left.
4. Audit consent: cookie and SDK choices, marketing opt-ins for push, in-app messages and email, and the in-app notification settings screen.

Days 31–60: fix the first session

1. Cut every onboarding step that doesn't lead to activation.
2. Move the notification request to a moment of clear value, with your own explanation screen first. On iOS, consider provisional authorisation.
3. Set up notification channels or categories, so users can mute marketing without losing updates.

Days 61–90: bring people back

1. Add one transactional and one value-based notification, tied to real events.
2. Run one consented email win-back to users who lapsed recently, and a store win-back offer if you sell subscriptions.
3. Compare the new cohorts with your Days 1–30 baseline, and keep only what moved retention.

Frequently asked questions

When should I ask for push notification permission?

After the user takes an action that makes notifications clearly useful, such as placing an order or scheduling a task. Apple and Google both advise against asking on first launch, and iOS shows its system prompt only once.

What is a good D30 retention rate?

There is no reliable universal figure, because retention varies by category, country, platform and acquisition source. Compare each new cohort against your earlier ones, and look for a curve that flattens.

Can I send marketing push notifications on iOS?

Only if users have explicitly opted in through consent language in your app, and you give them an in-app way to opt out. That is the requirement of App Store guideline 4.5.4.

Do UK marketing rules apply to in-app messages?

Yes. The ICO lists in-app messages as electronic mail under PECR, so marketing messages to individuals need consent or a valid soft opt-in.

How do I win back users who have uninstalled?

Through channels outside the app: email sent with consent, store win-back offers for lapsed subscribers, and a clear reason to return, such as a new feature or a fixed problem.

About the author

Arjun Raj is the founder of Digital Architect, a web, app and digital marketing studio founded in 2023 and headquartered in LB Nagar, Hyderabad, with a studio in Bengaluru. The team builds and markets apps for clients across India, the US, Canada and the UK. Arjun holds a B.Tech in Computer Science and Engineering, specialising in cybersecurity, from IIT Guwahati. More about Arjun

Users signing up but not sticking? Tell us what the app does, where users drop off and what you measure today, and we will tell you where we would start. See our app development work or talk to Digital Architect.