Push Notifications Users Keep On: 7 Rules for Apps

Imagine a grocery delivery app in its third month. Order updates work well, so the marketing team starts using the same channel: a weekend discount, a new brand in stock, a reminder that the basket is not empty, a recipe of the day. Each message makes sense on its own. Together they arrive four or five times a day, some of them at 23:00. A few weeks later, a large share of users have switched notifications off in the phone's settings, and now they no longer receive the message they actually wanted: "Your courier is at the door."

That is the real cost of a bad notification. It is not one ignored message. It is the loss of the whole channel, usually for good, because very few people go back into system settings to turn it on again.

Most advice about push notifications is about the permission prompt: ask at the moment the benefit is obvious, not on first launch. That matters, but it is only the entrance. The rules below are about what happens after the user says yes.

1. Give every notification a job before you write it

Before a notification type is built, sort it into one of three groups:

• The user asked for it. Order status, a booking reminder, a reply to their message, a payment that failed. These are the reason people allow notifications at all.
• The user would want it, if it is relevant. A price drop on an item they saved, a back-in-stock alert, a streak that is about to end in a learning app they use daily.
• You want them to see it. General campaigns, new features, "we miss you" messages.

The first group should be reliable and fast. The second group should be narrow and tied to something the user did. The third group should be small, and it should never be allowed to crowd out the first. If a team cannot say which group a new message belongs to, it is usually the third.

2. Offer categories inside the app

On iOS, the system switch is all or nothing for your app. On Android, notification channels let people turn off one type at a time, but only if you created the channels sensibly; many apps put everything into a single default channel.

Either way, give users a short settings screen inside the app: order updates, reminders, offers. When someone is annoyed by campaigns, you want them to find "Offers: off" before they find the system switch. Three to five categories is enough. Twenty toggles is a settings page nobody reads.

The same screen is a good place to show what each category sends, in one line, with an example. People are more willing to keep a category on when they know what it contains.

3. Send in the user's local time, and respect the night

A message scheduled for "10:00" on the server goes out at 10:00 in one time zone and at 03:00 in another. Store the user's time zone, or at least infer it from the device, and schedule non-urgent messages for their morning or early evening.

Then define quiet hours, for example 22:00 to 08:00, during which only the first group from rule 1 is allowed through. A courier update at 22:30 is welcome. A discount at 22:30 is a reason to turn everything off.

4. Set one weekly ceiling for the whole company

Notifications usually come from several places: the product team, marketing, a customer success tool, an automated re-engagement flow. Each one stays within its own limit, and the user still receives too many.

Agree on one ceiling per user per week for everything outside the first group, and enforce it in one place, the service that actually sends the messages. When the ceiling is reached, lower-priority messages wait or are dropped. This feels restrictive to the teams at first. It is also the only way the limit survives the next campaign.

5. Write for the lock screen

Most notifications are read on the lock screen, in one glance, and many are never opened. Write so that the message works there:

• Put the useful part first. "Order #2381 is out for delivery" beats "Good news! We have an update about your order."
• Avoid teasers that only make sense after a tap. If the content is hidden, the user learns that your notifications waste their time.
• Do not put sensitive details in the text. A lock screen is visible to anyone near the phone; a health or banking app should say "You have a new message" and show the details after sign-in.
• Open the exact screen the message is about. A notification about an order that opens the home page is a small broken promise.

6. Do not send what the user has already seen

If a user reads a message in the app, the notification about it should not arrive five minutes later. If they use the app on two devices, reading it on one should clear it on the other. If an item came back in stock and sold out again within an hour, cancel the alert that has not gone out yet.

This is mostly back-end work: the sending service needs to know the current state, not only the event that triggered the message. It is the kind of detail that users never praise but notice immediately when it is missing.

7. Measure disables, not only opens

Open rate is the number most dashboards show, and it rewards the wrong behaviour: more messages and more curious wording produce more opens in the short run. Track these as well:

• The share of active users who have notifications enabled, week by week.
• Which category was turned off in your in-app settings, and how soon after which message.
• Uninstalls within a day of a campaign send.

If a new message type raises opens but also raises disables, it is costing you the channel. Remove it, even if the campaign report looks good.

A short checklist for the next notification

Before a new notification type goes live, the person who requests it should be able to answer:

1. Which of the three groups does it belong to?
2. Which in-app category will turn it off?
3. Does it respect local time and quiet hours?
4. Does it count towards the weekly ceiling?
5. Is the first line useful on a locked screen?
6. Will it be cancelled if the user has already seen the content?
7. Which number will tell us if it is hurting more than helping?

In short

Users keep notifications on when the messages they asked for arrive on time and the rest stay rare, relevant and easy to switch off. Give each message a job, offer categories inside the app, send in local time, set one company-wide weekly ceiling, write for the lock screen, avoid repeats and watch how many people turn notifications off. The permission prompt gets you in; these habits decide whether you stay.

When we build mobile apps, we plan notification categories, quiet hours and the sending rules together with the first screens, because they are much harder to add once several teams are already sending messages.