Push Notifications Users Don't Turn Off
By CodexierPublished 7 min read
Push notifications are the only channel where your app can reach a user who is not looking at it. That makes them valuable, and it makes every one of them a small withdrawal from an account of trust the user opened when they granted permission. Overdraw it and the notifications are muted, then the app is deleted. This guide sets out the rules we apply in the apps we build and maintain: timing the permission request, separating transactional from marketing pushes, relevance, frequency and measurement.
Asking for permission at the right time
On iOS you get one chance: once a user declines the system permission prompt, you cannot ask again, and sending them to Settings rarely works. Android since version 13 behaves similarly. So the prompt must appear when the value is obvious. A booking app should ask right after the first booking is made, with a short in-app screen first: "Want a reminder the day before?" Then, on yes, show the system prompt. A news or content app should ask after the user has chosen topics. Asking during onboarding, before the user has done anything, gets the worst acceptance and burns the only chance you had.
Transactional vs marketing pushes
A transactional push is triggered by something the user did or is waiting for: a delivery update, a booking reminder, a message from a contact, a payment confirmation. Users want these and rarely turn them off. A marketing push is triggered by your calendar: a sale, a new feature, a re-engagement nudge. Users tolerate these in small doses. The mistake is mixing them in one channel, so that the only way to stop the sale announcements is to lose the booking reminders. Both platforms support notification categories; use them, and make the categories visible in your own settings screen so nobody has to dig into the operating system.
| Type | Examples | Default | User control |
|---|---|---|---|
| Transactional | Booking tomorrow at 10, parcel delivered, new reply | On after permission | Per type, in app settings |
| Service | Appointment moved, price change on a saved item, security alert | On | Rarely needed; keep it possible |
| Marketing | Seasonal offer, new feature, we miss you | Off until the user opts in, or on with an easy opt-out | One switch, prominent |
| Community or social | Someone liked your post, event reminder | On, capped daily | Per type, with a digest option |
In Sweden, marketing pushes to consumers sit under the same marketing rules as email: a clear opt-out and no messages a reasonable person would not expect.
Relevance and personalisation
Relevance is not about inserting the first name. It is about the notification being true for this user right now. A push about a sale on running shoes to someone who has only ever bought yoga mats is noise. A reminder about an unfinished booking is useful for a day, then irritating. Build the rules from data the app already holds: what the user did, what they saved, where they are in a flow, and when they are usually active. Then apply three constraints: send in the user's local daytime, never send twice about the same thing, and give every push a deep link to the exact screen it refers to. A notification that opens the home screen makes the user do the work you promised to save them.
- Segment by behaviour, not by demographics: recent activity, saved items, incomplete flows.
- Respect quiet hours per timezone; a push at 03:00 is an uninstall.
- Write the message so it is complete on the lock screen: what happened, what to do, in one sentence.
- Deep-link to the relevant screen and handle the case where the content no longer exists.
Frequency limits
Every app needs a written frequency policy, enforced in code, not in a marketing calendar. The policy sets a maximum number of marketing pushes per user per week, a minimum gap between any two pushes, and a rule for what happens when several triggers fire at once. Batching into a single daily digest beats five separate alerts. Transactional pushes sit outside the cap but still respect the minimum gap, so a burst of order updates arrives as one notification that updates rather than five that stack.
Weekly cap
One or two marketing pushes per week is where most apps should start. Increase only if opt-outs stay flat.
Collapse and replace
Use collapse keys so a new update replaces the old one on the lock screen instead of piling up.
Silence after ignoring
If a user has not opened the last several marketing pushes, stop sending marketing and keep only transactional.
Kill switch
Have a way to stop a campaign mid-send. Mistakes happen, and the second wrong push costs more than the first.
Measuring opt-outs
Open rate is the number every dashboard shows and the least useful one. What you want to see for every push campaign is the change in notification opt-outs and app uninstalls in the days after it, compared with a quiet period. Both platforms expose permission status; log it on each app launch so you can see when it changed and which campaign preceded it. Track the same for each notification category. A campaign that gets many opens and a spike in opt-outs was a bad campaign. Over a quarter, this data tells you which categories earn their place and which should be retired.
When you do not need push at all: if the app is used a few times a year, such as a tool for filing a claim or renewing something, an email or SMS at the right moment does the job with no permission prompt and no trust account to overdraw. And if you have nothing transactional to send, marketing-only pushes are almost never worth the opt-out cost. Notification infrastructure, category management and the measurement above are part of the ongoing work covered by our app maintenance and scaling service; what that yearly work involves is set out in what app maintenance costs. Whether your app needs it is a 15-minute conversation.
- App maintenance and scalingNotification infrastructure, OS updates, monitoring and store compliance handled monthly.
- What does app maintenance cost?The yearly work an app needs whether or not you send a single push.
- Book a free 15-minute callShow us your current notification setup; we tell you what to change first.
Frequently asked questions
How many push notifications per week is too many?
For marketing, more than one or two per week is where opt-outs climb for most consumer apps. Transactional pushes are limited by events, not by a cap, but should collapse into one updating notification rather than stacking. Measure opt-outs per campaign and let the data set the number for your users.
Do we need consent for push notifications under GDPR?
The operating system permission is the technical consent to deliver notifications. Using personal data to decide what to send still needs a legal basis, and marketing pushes to consumers should follow the same rules as marketing email: clear information, an easy opt-out and no unexpected messages. Keep a record of what the user agreed to and when.
Can we re-ask for permission if the user said no?
Not through the system prompt on iOS; the answer is final until the user changes it in Settings. On Android the prompt can appear a limited number of times. The practical approach is an in-app pre-prompt that only shows the system dialog when the user has already said yes, so a no never reaches the operating system.
What should a good push notification contain?
One clear event, one action, and a deep link to the screen where the action happens. Short enough to read on a lock screen, specific enough that the user knows why they got it, and sent at a time when acting on it is possible.
Opt-outs climbing after every campaign?
Fifteen minutes with an engineer: we look at your notification categories, permission flow and frequency rules, and tell you which changes would stop the bleed.
Book a free 15-minute call