Push Notifications: Best Practices and Common Mistakes

Push notifications are one of the most powerful tools in a mobile app -- and one of the most commonly misused. Used correctly, they increase engagement, bring users back to the app, and build habits. Used poorly, they lead to disabled notifications, app uninstalls, and negative store reviews. The difference between these two scenarios often comes down to implementation details and strategy.

Why most apps get push notifications wrong

The typical scenario looks like this: a user downloads the app, on first launch the app immediately asks for notification permission, the user taps "Don't Allow" (because they don't yet know why they'd want them), and the app permanently loses the ability to communicate through this channel.

The second common scenario: the user grants permission, the app starts bombarding them with generic messages ("We have a new offer for you!", "You haven't visited us in a while!"), and the user either disables notifications or deletes the app.

Both situations share the same problem -- the app approaches push notifications from its own perspective ("we need to increase engagement") instead of from the user's perspective ("what is valuable to me").

Permission timing -- don't ask right away

On iOS, the push notification permission is an irreversible decision. If the user declines once, they must manually go to Settings and enable it. Most users will never do that. This is why the timing of the request is critical.

Never ask on the first screen. The user has just opened your app for the first time. They don't know its value, they have no reason to trust you, and the default response to any system dialog is "no." Statistics show that the opt-in rate when asking on the first screen is 40-50%. With a delayed request after demonstrating value, it rises to 70-80%.

Wait for the right moment. The ideal time to ask is after the user has experienced the app's value. If you have an e-commerce app, ask after the first order -- "Would you like to receive updates about your order status?" If you have a fitness app, ask after the first workout -- "Would you like reminders for your next workout?" Context changes the answer from "no" to "yes."

Use a pre-permission screen. Before showing the iOS system dialog, display your own screen that explains what notifications you'll send and what value they'll provide. This screen has an "Allow" and "Not now" button. If the user taps "Not now," you don't show the system dialog and can ask again later. If they tap "Allow," you show the system dialog and the user is much more likely to approve.

On Android, the situation is different. Starting with Android 13 (API level 33), push notifications require explicit permission, similar to iOS. On older Android versions, notifications are enabled automatically and users can only retroactively disable them. Even so, annoying notifications lead to disabling or uninstalling.

Segmentation -- not everyone wants the same thing

Sending the same notification to all users is like sending a mass email without any personalization. It technically works, but the results are below average.

Segment by behavior. An active user who opens the app daily doesn't need re-engagement notifications. Conversely, a user who hasn't been in the app for a week might appreciate a relevant reminder. A new user who registered but didn't complete onboarding needs a different type of communication than a long-term customer.

Segment by preferences. Allow users to choose which types of notifications they want to receive. In the app settings, offer categories: orders and delivery, discounts and promotions, new content, social activity, system information. A user who turns off "discounts and promotions" but keeps "orders" enabled is significantly happier than a user who receives everything.

Segment by time zone and activity. A notification at 3 AM won't delight anyone, even if it's relevant. Analyze when your users open the app and send notifications during those windows. For most B2C apps, this is 9 AM-noon and 6-9 PM. For B2B apps, typically business hours.

Personalization and relevance

A generic notification like "Check out what's new in our app" has an open rate of around 2-3%. A personalized notification like "Your favorite product is back in stock for $29.99" has an open rate of 15-20%. The difference is relevance.

Use the user's name. "Peter, your order has been shipped" is significantly more effective than "Your order has been shipped." But be mindful of context -- a name in a transactional notification is natural, in a marketing one it can feel forced.

Reference specific user actions. "The product in your cart is now 20% off" is relevant to a user who actually added it to their cart. "New article from an author you follow" is relevant to a user who actually follows that author.

Dynamic content. Instead of static text, include current data -- price, delivery time, number of new messages, score. Numbers in notifications attract attention and increase open rates.

Frequency caps -- less is more

One of the most important rules of push notifications is not overdoing the frequency. Studies consistently show that most users tolerate 3-5 notifications per week from a single app. Above this threshold, opt-outs increase steeply.

Set a global frequency cap. The maximum number of notifications a user can receive per day, week, and month. Recommended minimum: no more than 1 notification per day for marketing purposes. Transactional notifications (order status, incoming messages) don't count -- users expect and want those.

Respect opt-out signals. If a user ignores the last 5 notifications (doesn't open them), reduce the frequency. If they ignore 10, stop sending marketing notifications entirely. Continuing to bombard a disengaged user is a reliable path to uninstalling.

Prioritize quality. One relevant, personalized notification per week delivers better results than a daily generic message. Before sending, always ask: "Will the user perceive this as value or as annoyance?"

Rich notifications -- more than text

Modern push notifications offer far more than plain text.

Images and media. Both iOS and Android support images in notifications. An e-commerce notification with a product photo has significantly higher engagement than text-only. A news app notification with a cover image attracts more attention than the headline alone. The maximum image size is typically 1 MB, with an optimal resolution of around 1024x512 px.

Action buttons. Add buttons directly to the notification -- "Buy," "Reply," "Remind me later," "Mark as read." Users can interact without opening the app, which lowers the barrier and increases conversion rate. On iOS, you can add up to 4 action buttons, on Android 3.

Expandable content. Long text, a large image, or a list of items in an expandable notification. The user sees a shortened preview and swipes down to reveal the full content.

Deep linking -- where the notification leads

Tapping a notification should always lead to a relevant place in the app, not the home screen. If you're notifying about a new message, open the conversation. If about a product discount, open the product detail. If about order status, open the tracking screen.

Implement deep links correctly. Every notification must carry a payload with destination information. When opened, the app must process this payload and navigate to the correct screen. Test deep links in both states -- when the app is in the background (warm start) and when it's closed (cold start). The behavior can differ.

Handle edge cases. What happens when a user taps a notification about an order that has since been cancelled? What if they tap an offer that has expired? The app must handle these situations gracefully -- displaying a clear message, not a blank screen or error.

Silent push -- syncing without interrupting

Not all push notifications need to interrupt the user. Silent push (or background push) notifications don't appear to the user but wake the app in the background for data synchronization.

Typical uses include: content updates (new articles, updated feed), data synchronization (server-side changes), content pre-fetching (downloading data before the user needs it), and cache invalidation.

On iOS, silent push is limited -- the system may throttle or ignore it if sent too frequently. Apple recommends a maximum of 2-3 silent pushes per hour. On Android, they are less restricted, but reasonable limits still apply.

A/B testing notifications

Small changes in text, timing, or notification format can have a significant impact on results. A/B testing should be a standard part of your push strategy.

What to test. Text formulation (question vs. statement, short vs. long), send time (morning vs. evening, weekday vs. weekend), presence of emojis, presence of images, different action buttons, personalized vs. generic text.

How to test. Split users into two groups (50/50 or 90/10 for a more conservative approach). Send each group a different variant. Measure open rate, click-through rate, and conversion (not just notification opens, but completion of the target action in the app). Statistically evaluate results -- you need a sufficient sample size, typically at least 1,000 users per variant.

Tools like OneSignal, Firebase Cloud Messaging with Remote Config, or Braze offer notification A/B testing as a built-in feature.

Opt-out rate -- the quality barometer

Track the percentage of users who disable notifications. It is the most honest feedback on your push strategy.

Benchmark. The average opt-out rate on iOS is around 50-60% (many users never grant permission). On Android, it is significantly lower because notifications were historically enabled automatically. If your iOS opt-out rate is growing and your Android rate is approaching 30%, you are doing something wrong.

Analyze correlations. When do users disable notifications? After how many notifications? After what type of notification? If you discover that a large wave of opt-outs follows Monday's marketing push, you have a clear signal about what to change.

Differences between iOS and Android

Push notification implementation differs between platforms more than you might expect.

Deliverability. On Android, notifications are delivered virtually always (as long as the device has a network connection). On iOS, Apple uses a prioritization system -- low-priority notifications may be delayed or bundled. Time-sensitive notifications (marked as such) have higher delivery priority.

Lock screen display. iOS since version 16 uses a new notification design at the bottom of the lock screen, grouped by app. Android displays notifications from the top, individually. This affects how much text the user sees without interaction.

Notification channels (Android). Starting with Android 8.0, you must organize notifications into channels. Users can individually disable or customize channels (for example, muting marketing but keeping transactional ones). Well-designed channels are an advantage; poorly designed ones (a single channel for everything) are a wasted opportunity.

Focus modes and Do Not Disturb. Both systems allow users to filter notifications. On iOS, Focus modes can block notifications from specific apps. Your time-sensitive notifications can break through these filters, but abusing this priority leads to users explicitly excluding your app from Focus mode.

Conclusion

Push notifications are a direct line to the user's attention -- and that is precisely why you must handle them carefully. Every notification is an implicit agreement: the user gave you access to their phone in exchange for relevant, valuable information. If you break this agreement with generic spam, you lose it.

Start with a clear strategy: what types of notifications you will send, to whom, and how often. Implement segmentation, personalization, and frequency caps from day one. Measure not just open rates but also opt-out rates and the long-term impact on retention. And above all, before sending any notification, ask yourself whether you would want to receive it. If not, don't send it. A disciplined approach to push notifications is an investment in a long-term relationship with the user that unambiguously pays off in engagement metrics.