Push notification best practices come down to one rule: send a notification because the user needs it, not because the business wants to say something. The single biggest cause of opt-outs and uninstalls is notifications sent on the company's schedule — a promo blast, a re-engagement nudge, a feature announcement — with no bearing on whether that particular user wants to hear it at that moment. Apps that get push right spend a notification only when the message is timely, relevant, and personal. This guide covers why most apps get this wrong, the practices that actually work, and how to measure whether a strategy is helping or hurting.
Why do most apps get push notifications wrong?
Most push notification programs are built around what the business wants to communicate — a sale, a new feature, a reminder to come back — rather than what the user, individually, needs to hear right now. That mismatch is invisible to the team sending the message but very visible to the person receiving it: an irrelevant interruption reads as noise, and enough noise trains the user to mute notifications or delete the app outright. The fix isn't fewer notifications for their own sake — it's a filter applied before every send: would this specific user, at this specific moment, actually want to know this?
When should a notification actually be sent?
Timing that works is triggered by relevance, not by a calendar. A notification that fires because a price dropped on an item the user viewed, a delivery just left the warehouse, or a booking is starting in an hour lands as useful information. A notification that fires because it's Tuesday and the marketing calendar says "send one" lands as an interruption. In practice this means building notifications around events in the user's own activity — actions taken, actions abandoned, milestones reached — rather than a fixed weekly or daily schedule the whole user base receives regardless of what they're doing.
How does personalization change notification performance?
Sending the same message to every user at the same time is efficient to build and inefficient to receive — most of the audience gets a notification that has nothing to do with them. Personalizing based on actual behavior (what someone browsed, bought, ignored, or completed) instead of a shared segment produces messages people recognize as being about them, which is what makes a notification worth opening rather than swiping away. This doesn't require sophisticated modeling to start: even simple rules — a cart untouched for a day, a feature used once and never again, a subscription about to lapse — outperform one message blasted to everyone.
What's a sensible frequency cap?
A frequency cap limits how many notifications any one user can receive in a given window, regardless of how many campaigns or triggers are technically eligible to fire. Without one, individually reasonable notifications stack up into a barrage the moment several teams or triggers overlap. There's no universal number that fits every app, but the underlying principle holds everywhere: cap by user experience, not by campaign volume, and let category matter — a security alert or a booking confirmation shouldn't share a budget with a marketing nudge. When in doubt, fewer, more relevant notifications consistently outperform more frequent, generic ones.
How should the opt-in request itself be written?
The system permission popup iOS or Android shows is generic by design — it says nothing about why this particular app wants to send notifications. Asking cold, the moment the app opens, forces a decision with no context, and most users default to "don't allow." A better pattern is a pre-permission screen, in the app's own words, stating the specific value the user gets — order updates, price drops on saved items, a reply to their message — before the system dialog appears. Users who understand what they're opting into at the point of asking do so at meaningfully higher rates.
How do you measure if a notification strategy is working?
Three numbers tell most of the story: opt-in rate (the share of users who grant permission when asked), opt-out rate over time (the share who later disable notifications or uninstall), and click-through rate (the share who act on a notification they received). Opt-in rate reflects how well the value was communicated before asking. Click-through rate reflects whether individual notifications are actually useful. Opt-out rate is the most important of the three because it is a lagging but direct signal — if opt-outs climb noticeably after a specific campaign or a change in frequency, that is the strategy telling you, unambiguously, to walk it back.
Frequently asked questions
What is the single biggest cause of push notification opt-outs?
Notifications sent on the business's schedule instead of because the specific user needs them at that moment. Irrelevant or poorly timed messages are the leading cause of both notification opt-outs and app uninstalls.
How many push notifications per week is too many?
There is no universal number — it depends on the app category and what each notification is worth to the user. The signal to watch is not a fixed count but the trend in opt-out rate: if it climbs after increasing frequency, that frequency is too high for that audience.
Should an app ask for notification permission immediately at first launch?
No. Asking cold, before the user understands the app's value, tends to produce a lower opt-in rate. A pre-permission screen that explains what the user will get from notifications, shown before the system prompt, generally produces meaningfully higher opt-in rates.
What metric best signals that a push notification strategy needs to change?
A rising opt-out rate after a specific campaign or frequency change. It is a direct, hard-to-misread signal that the current approach is costing more user trust than it is generating engagement.