Push notifications: the feature every client wants and most apps misuse
Almost every mobile app client asks for push notifications early in the project, usually framed as a straightforward engagement feature: send users reminders, and they'll come back to the app more often. The reality is messier. Used carelessly, push notifications are one of the fastest ways to get a user to delete an app entirely, not to bring them back.
We've inherited apps with notification systems that fire multiple times a day for reasons that made sense to whoever configured them and mean nothing to the actual user receiving them. Every one of those apps had uninstall rates that correlated directly with notification frequency, and every one required real work to unwind.
Why more notifications almost never means more engagement
There's a natural instinct to treat notifications as a lever: more sent, more opens, more engagement. Real usage data consistently shows the opposite past a fairly low threshold. Notification fatigue sets in quickly, users start ignoring or disabling notifications wholesale once frequency crosses a threshold, and once disabled at the OS level, that channel is effectively gone for good, regardless of what's sent through it afterward.
We track notification opt-out rates as a leading indicator on every client app, specifically because it's an early warning sign of overuse, well before it shows up in the more visible metric of overall app engagement or retention numbers.
The one question that determines whether a notification should exist
We ask, for every proposed notification: does this specifically benefit the user receiving it, right now, in this specific moment, or does it primarily benefit the business sending it. Reminder notifications tied to something a user actually cares about, an appointment approaching, a price drop on something they favorited, pass this test easily. Generic "come back and check out what's new" notifications almost never do.
This question filters out a large share of notification ideas clients propose in early planning meetings, and it's usually an easy filter to apply once stated this plainly. Most clients agree immediately once the distinction is framed this way, even when their original instinct pointed toward more frequent, more generic messaging.
Timing and relevance matter more than volume
A single, well-timed, genuinely relevant notification outperforms five generic ones sent on a fixed schedule, every time we've measured it directly. We push clients toward event-triggered notifications, tied to something specific and meaningful that just happened, rather than time-triggered ones sent on an arbitrary recurring schedule regardless of whether anything relevant has actually occurred.
This requires more engineering thought upfront, building the triggers correctly rather than just scheduling a recurring blast, but it produces dramatically better open rates and, more importantly, dramatically lower opt-out rates over the life of the app.
Letting users control frequency and type, not just an all-or-nothing toggle
A blanket on-off switch for notifications forces a user into an all-or-nothing decision, and a meaningful share of users choose "off" entirely rather than accepting notification types they don't want alongside the ones they might. Granular controls, letting a user opt into specific notification categories individually, preserve engagement on the types users actually value while respecting their disinterest in the rest.
We build this granularity into every app now by default, even when clients initially push back on the added complexity. It consistently produces better long-term opt-in rates than a single blunt toggle, because it lets users keep the value they want without having to tolerate the noise that would otherwise drive them to turn everything off.
A blanket on-off switch for notifications forces a user into an all-or-nothing decision, and a meaningful share of users choose "off" entirely rather than accepting notification types they don't want alongside the ones they might.
What we test before shipping any notification strategy
We run a soft launch with a limited, real user group before rolling out any notification cadence broadly, watching opt-out rates and actual re-engagement closely during that window. This lets us catch an overly aggressive cadence before it damages the broader launch, when the cost of correcting course is still low and the affected user base is still small.
Clients are sometimes impatient with this extra step, wanting the full notification strategy live immediately at launch. We hold the line on this one specifically, because the cost of getting notification cadence wrong at full scale, a wave of opt-outs and uninstalls that's hard to win back, is far higher than the short delay this testing step requires.
How we monitor this after launch, not just at the start
Notification strategy isn't a set-once decision. We review opt-out trends and open rates by notification type on a recurring basis after launch, and we retire or adjust any notification type whose performance degrades meaningfully over time, rather than letting a strategy that made sense at launch quietly become stale and counterproductive months later.
This ongoing review is a small, recurring task, and it's caught drift more than once on apps we manage long-term, where a notification that performed well initially gradually became background noise as the novelty wore off for the exact same user base.
What we tell clients who want to "just try" an aggressive cadence
We ask for a specific, small test window instead of a permanent commitment, with agreed-upon metrics defined before the test starts, not judged after the fact based on whichever number happens to look best. This satisfies a client's genuine curiosity without risking the broader user base, and it usually produces the exact data needed to end the debate cleanly.
In every case we've run this test, the aggressive cadence underperformed the more disciplined approach within a few weeks, on both engagement and retention. Real data from a client's own app has settled this argument far more effectively than our advice alone ever could, no matter how confidently we stated it upfront.
Push notifications are a genuinely powerful tool, and that power cuts both ways. Used with real discipline, tied to specific, relevant moments a user actually cares about, they drive real engagement. Used carelessly, as a generic broadcast channel, they drive exactly the opposite outcome clients were originally hoping for.
We'd rather ship an app with fewer, sharper notifications than one with an aggressive schedule that looks impressive in a planning document and quietly erodes the user base it was meant to grow.
Every client who's pushed back on this restraint early has, without exception, come back around once they saw the opt-out data from their own app confirm exactly what we'd predicted going in.
The apps that keep users longest treat every notification as a small withdrawal from a trust account that has to be replenished by genuine value, not as a free channel to be used as often as the platform technically allows.