Push notifications: what works and what gets immediately ignored

Push notifications are one of the highest-leverage and most abused tools in a mobile app. Done well, they bring lapsed users back at almost no cost. Done poorly, they're the single most common reason users disable notifications entirely or uninstall the app outright, permanently closing off a channel that could have been valuable.

Requesting notification permission immediately on first app open, before a user has any reason to trust the app, produces the lowest opt-in rates we've measured, often under 40 percent. Delaying the request until after a user completes a meaningful action, their first booking, their first saved item, routinely pushes opt-in rates well above 60 percent, because the value of notifications is now contextually obvious to the user.

Generic re-engagement pushes, "come back and check out the app", get ignored and eventually muted. Notifications tied to something specific and time-relevant to that user, a price drop on a saved item, a booking confirmation, a message from someone they follow, get meaningfully higher engagement because they're solving an actual problem for the recipient rather than just asking for attention.

We set explicit caps, no more than one or two notifications per day per user regardless of how many triggers fire, because engagement teams left unchecked tend to add triggers over time until the app is sending five or six pushes a day and users start disabling notifications entirely rather than muting individual types they don't want.

The apps with the best long-term notification performance segment users before sending rather than blasting everyone the same message. A user who hasn't opened the app in three weeks needs a different message than one who used it yesterday, and treating them identically wastes the channel's effectiveness on both groups, converting neither as well as a tailored approach would.

For users who've disabled notifications, we design a soft, contextual prompt inside the app itself, tied to a moment where notifications would obviously help, rather than repeatedly nagging through the OS-level permission dialog, which tends to backfire and reinforce the original decision to opt out.

For a booking app, moving the notification permission request from app launch to right after a user's first successful booking took opt-in from roughly 35 percent to just over 70 percent, without changing anything else about the app or the messaging in the prompt itself.

Image-rich push notifications outperform plain text for visually driven categories, retail, food, travel, but add negligible value for purely transactional messages like a booking confirmation, where clarity and speed of reading matter more than visual appeal. We match the format to the message type rather than defaulting to rich media everywhere.

For an international app, sending a single scheduled push to the entire user base at once means it lands at genuinely different times of day for different users. We schedule sends relative to each user's local time zone wherever the platform supports it, since a 3am notification reliably drives disengagement regardless of how good the content is.

Open rate alone can be misleading, since a notification can be opened and immediately dismissed without producing any real value. We track the actual downstream action, a completed booking, a viewed item, a re-engagement that leads to a session of meaningful length, as the metric that actually matters for judging a notification strategy's success.

For apps with a team or organizational usage pattern, a notification relevant to one team member can be irrelevant noise to twenty others on the same account. We build role-based and preference-based notification targeting specifically for these apps, rather than sending every notification to every user tied to an account regardless of relevance.

Rather than a single blanket on-off toggle, we design granular notification preferences by category, so a user who wants booking confirmations but not promotional messages can express that distinction clearly, rather than being forced into an all-or-nothing choice that pushes many users toward disabling notifications entirely.

B2B app users generally tolerate a different notification cadence and tone than consumer app users, often preferring fewer, more substantive notifications tied clearly to work-relevant events rather than the more frequent, lighter-touch engagement notifications that work well in many consumer contexts. We calibrate frequency and tone to match this different tolerance rather than applying consumer app notification norms to a B2B product by default.

We also test notification copy with the same rigor we'd apply to ad copy, running genuine variations rather than assuming intuition alone will produce the best-performing message. A notification's entire persuasive job has to happen in a single short line visible on a lock screen, which makes word choice disproportionately important relative to its length, and small wording changes we've tested have moved open rates by a meaningful margin even when the underlying offer or information being communicated stayed completely identical between versions.

Not every update needs to interrupt a user with a sound and a banner. For lower-priority updates, a badge count or a silent, in-app notification center entry often serves the purpose without contributing to the daily notification budget that's better reserved for genuinely time-sensitive messages. Treating every event as equally worth a full push notification is one of the fastest ways to burn through a user's patience for the channel entirely.

We roll new notification types out to a small percentage of users first, watching opt-out rates and engagement closely before expanding to the full user base. A poorly tuned new notification type can quietly damage trust in the channel for every future message if it's blasted to everyone at once, so a cautious, staged rollout protects the long-term value of the channel rather than just the immediate campaign it was built for.

The two platforms handle permission prompts, delivery reliability, and rich media differently enough that a single unified notification strategy applied identically to both often underperforms what a platform-aware approach would achieve. We tune timing and format separately per platform where the underlying behavior genuinely differs, rather than assuming a strategy tuned on one platform automatically transfers cleanly to the other.

Genuine broadcast moments, a service outage notice, a critical security update, are one of the few legitimate exceptions to our usual frequency caps and segmentation rules. We keep a separate, clearly documented process for these rare situations specifically so a real emergency communication doesn't get delayed by the normal review and segmentation workflow built for routine engagement messaging.