Push Notification Mistakes That Kill User Engagement

12 min read

Push notifications can be one of the most powerful tools for keeping users engaged with your app... but they can also be one of the fastest ways to get people to uninstall it. After ten years of building apps for clients in healthcare, fintech, and ecommerce, I've seen businesses make the same mistakes over and over again, and the data doesn't lie when it comes to how quickly users will abandon an app that annoys them with poorly thought-out notifications.

Getting push notifications right is about understanding that you're entering someone's personal space, and they can shut you out permanently with a single tap.

The thing is, most businesses approach notifications thinking about what they want to tell users rather than what users actually want to hear. I've worked with companies spending 80 grand on app development only to see their retention rates drop through the floor because they got notifications wrong (and it's genuinely painful to watch). The average app loses 77% of daily active users within three days of installation, and notification misuse is one of the biggest contributors to that stat.

Sending Too Many Push Notifications

Look, I've seen apps send six notifications in a single day and then wonder why their uninstall rate spiked. There's this temptation to stay top-of-mind by constantly pinging users, but what you're actually doing is training them to view your app as a nuisance. We worked with an ecommerce client who was sending a notification for every single order status update (order confirmed, order processing, order packed, order shipped, out for delivery), and their engagement metrics were terrible because users were just turning notifications off entirely.

The frequency that works varies by app type, but as a general rule, most consumer apps should limit themselves to one or two notifications per week unless the user has specifically requested more. We tested this with a fitness app we built, and found that going from five notifications per week to two actually increased click-through rates by 34% because users were more receptive when we did reach out.

  • Keep promotional notifications to maximum one per week
  • Transactional notifications (like delivery updates) should only be sent when there's meaningful new information
  • Time-sensitive alerts (like a booking reminder) get more leeway but should still be limited to what's genuinely useful
  • If you're sending more than three notifications weekly, you're probably overdoing it

Forgetting to Personalise Your Messages

Sending the same generic message to everyone is sort of like shouting into a crowd and expecting each person to feel personally addressed. When we built a healthcare app that helped patients manage chronic conditions, we initially sent the same medication reminders to everyone at 9am... which was useless for people who took their medication at bedtime. We ended up rebuilding the notification system to accommodate individual schedules, and adherence rates went up by 41%.

Personalisation isn't just about inserting someone's first name into a template (though that's better than nothing). It's about using what you know about user behaviour, preferences, and context to send messages that feel relevant. I've seen apps collect loads of data about users and then completely ignore it when crafting notifications, which is a massive missed opportunity.

Start with basic segmentation based on user behaviour. Split your audience into at least three groups: new users (first week), regular users (active in past 30 days), and lapsed users (inactive for 30+ days). Each group needs different messaging and different frequencies. You can always refine from there, but this basic split will immediately improve your relevance.

User Segment Notification Focus Frequency
New Users (0-7 days) Onboarding, feature discovery 2-3 per week
Regular Users (7-90 days) Value-add content, updates 1-2 per week
Lapsed Users (90+ days) Re-engagement, what's new 1 per month

Poor Timing Choices That Annoy Users

Sending a notification at 2am is an obvious mistake, but I've seen plenty of less obvious timing failures that still wreck engagement. We worked with a food delivery app that was sending lunchtime promotions at 11am, which sounds logical until you realise that most people are in meetings or commuting at that time and can't act on the offer. When we shifted those notifications to 10:30am, redemption rates jumped because users had time to plan their lunch order.

Time zones are another area where apps fall down constantly. I remember reviewing analytics for a fintech app we'd built that was sending market opening notifications based on the company's headquarters timezone rather than the user's actual location... which meant people in Australia were getting woken up at 3am with stock market updates they couldn't do anything about. When considering fintech development best practices, proper timezone handling is absolutely critical. Fixing that one issue reduced opt-out rates by 22%.

The best performing notification times vary massively by industry and user base. For a meditation app we developed, evening notifications (7-9pm) performed brilliantly because that's when people were winding down. For a productivity app, early morning (6-8am) worked better. You can't just copy what other apps do and hope it works for your audience.

  1. Test different times for each notification type rather than using one universal send time
  2. Always use the user's local timezone for scheduling
  3. Avoid early mornings (before 8am) and late evenings (after 9pm) unless your app specifically serves those times
  4. Consider what the user is likely doing when they receive the notification and whether they can act on it

Writing Boring or Confusing Content

Most notification copy is terrible (I've written plenty of terrible notification copy myself over the years, to be honest). There's usually either too much information crammed into a small space or so little information that the user has no idea why they should care. We built an ecommerce app where the client wanted to send notifications saying "New products available" which tells you basically nothing about whether those products are relevant to you or worth opening the app to see.

You have about two seconds and roughly 40 characters on the lock screen to communicate value before the user swipes away.

The apps that do this well focus on one clear piece of information or one clear action. When we redesigned notifications for a property rental app, we changed from "New properties match your search" to "3-bed flat in Camden, £1,800/month, just listed" and saw open rates go from 12% to 31%. The specificity matters because it lets users decide whether opening the app is worth their time right now.

Another mistake I see constantly is using internal jargon or unclear language. A banking app we worked on was sending notifications about "account reconciliation complete" when what they meant was "your balance has been updated". Users aren't sitting around thinking in your terminology, so your notifications shouldn't either. Write like you're texting a mate who needs to know something useful, not like you're filing a technical report.

Ignoring User Preferences and Settings

If someone turns off notifications for your app, that's usually a permanent decision... which makes it absolutely bonkers how many apps make it difficult or impossible to customise notification settings. I've worked with clients who want to keep their notification settings simple (meaning they offer no granular control) because they worry about confusing users, but what actually confuses users is getting notifications they don't want with no way to turn off just those specific types.

We built a news app that initially had one notification toggle (all on or all off), and about 40% of users just turned everything off. When we rebuilt it to let users choose which news categories they wanted notifications about and how often, the percentage of users with all notifications disabled dropped to 18%. People are willing to receive notifications if they have control over what they receive.

The preference centre should be easy to find (not buried four menus deep) and easy to understand. We use plain language like "sales and offers" rather than "promotional communications" and give users frequency options where it makes sense. For a fitness app, users could choose whether they wanted daily workout reminders, three times per week, or none at all... and surprisingly, about 60% chose daily because they wanted the accountability.

What to Include in Your Settings

At minimum, let users control promotional versus transactional notifications separately. If you're sending multiple types of content, break those out too. Frequency controls work well for certain app types (daily digest versus real-time alerts). And always include a "pause notifications" option that temporarily mutes everything for a week or month, which prevents people from turning things off permanently when they just need a break.

Not Testing Your Push Notifications

You'd think testing would be obvious, but I've lost count of how many times clients want to blast a notification to their entire user base without running any kind of test first. We built an education app where the client wrote a notification encouraging students to "complete your outstanding assignments" which they thought sounded motivating... but when we A/B tested it against "you're almost done with Module 3", the second version got 2.5 times more clicks because it felt like progress rather than nagging.

Testing isn't just about copy either (though that matters loads). We've found that emoji in notifications can increase open rates by 15-20% for some audiences and decrease them for others. Image-rich notifications perform better for visual content like recipes or fashion but worse for financial information. Understanding effective app marketing testing methods is crucial for getting notification strategy right. You won't know what works for your specific users unless you test.

Start with simple A/B tests on your highest-volume notification types. Change one variable at a time (copy, timing, or format) and run each test to at least 1,000 users per variant before making decisions. Track not just open rates but also downstream actions like whether users who opened the notification completed the intended action. That's the metric that actually matters.

The technical side of testing needs proper implementation too. Make sure you're tracking delivery rates (did the notification actually reach the device), open rates (did the user tap it), and conversion rates (did they do what you wanted). Using proper debugging and monitoring tools can help identify when notifications are silently failing for certain device types or OS versions, and without proper tracking, the client had no idea they were losing 30% of their audience.

  • Test on both iOS and Android as they render notifications differently
  • Check how your notification appears on both lock screen and notification centre
  • Test with different lengths of copy to see what gets truncated
  • Try sending at different times to find optimal engagement windows
  • Compare emoji versus no emoji for your specific audience

Using Push Notifications for the Wrong Reasons

This is probably the biggest strategic mistake I see (and the hardest one to fix because it's often driven by stakeholders who don't understand mobile user behaviour). Push notifications should serve the user first and your business objectives second, but loads of companies flip that around. I worked with a retail client who wanted to send notifications every time they published a blog post because their marketing team had KPIs around blog traffic... but app users hadn't downloaded a shopping app to read blog posts, and the notifications just annoyed people.

Notifications work best when they provide genuine utility or time-sensitive information. A delivery app telling you your food is arriving in five minutes? Perfect use case. That same app telling you to rate your experience from three days ago? Pretty weak. We did an audit for a fintech app that was sending weekly notifications reminding users to check their budget, and engagement was awful... but when we changed it to send notifications only when users were approaching their budget limits, suddenly people found it helpful rather than naggy.

Re-engagement notifications (trying to bring back inactive users) are particularly tricky. Most apps send something generic like "we miss you, come back" which rarely works because it doesn't give the user a reason to return. The ones that work well offer something specific... an ecommerce app offering a discount code, a game app mentioning new content, a productivity app highlighting a new feature that solves a problem. Understanding what makes apps memorable can help craft more effective re-engagement messages. But honestly, if someone hasn't opened your app in three months, a notification probably won't fix whatever caused them to stop using it in the first place.

When Notifications Make Sense

Use notifications for information the user has explicitly requested (order updates, booking confirmations, messages from other users). Use them for time-sensitive opportunities that require quick action (flash sales, appointment reminders, breaking news if you're a news app). Use them sparingly for feature announcements if the feature genuinely improves the user experience. Don't use them for general marketing, content that isn't time-sensitive, or things that could easily live inside the app interface.

When launching a new app, it's particularly important to establish the right notification strategy from day one rather than trying to fix problems later when users have already formed negative associations with your app's communication patterns.

Conclusion

Getting notifications right requires thinking about them as a privilege rather than a right... because that's exactly what they are. Users grant you permission to interrupt their day, and they can revoke that permission instantly if you abuse it. I've seen apps with hundreds of thousands of pounds invested in development fail because they treated notifications as a broadcast channel rather than a respectful conversation. These design and engagement mistakes can destroy user retention faster than almost any other factor.

The apps we've built that succeed with notifications share some common traits: they send fewer notifications than the client initially wanted, they obsess over relevance and timing, they give users proper control over what they receive, and they constantly test and refine based on actual user behaviour rather than assumptions. It's not complicated, but it does require discipline to resist the temptation to over-communicate.

Start by doing less. Seriously. Cut your notification frequency in half and see what happens to your engagement metrics. Chances are they'll improve because the notifications you do send will be more welcome. Then layer in personalisation, timing optimisation, and better copy. Your users will thank you by actually staying engaged with your app instead of uninstalling it.

If you need help getting your app's notification strategy sorted (or building an app that handles notifications properly from day one), get in touch with us and we can walk you through what's worked for the apps we've built over the past decade.

Frequently Asked Questions

How many push notifications should I send per week without annoying users?

Most consumer apps should limit themselves to one or two notifications per week unless users have specifically requested more. Keep promotional notifications to maximum one per week, and if you're sending more than three notifications weekly, you're probably overdoing it.

What's the best time to send push notifications?

The best performing notification times vary massively by industry and user base - meditation apps see success with evening notifications (7-9pm) while productivity apps work better in early morning (6-8am). Always use the user's local timezone and avoid early mornings (before 8am) and late evenings (after 9pm) unless your app specifically serves those times.

How do I personalize notifications without being creepy?

Start with basic segmentation based on user behaviour - split your audience into new users (first week), regular users (active in past 30 days), and lapsed users (inactive for 30+ days). Use what you know about user preferences and context to send relevant messages, like scheduling medication reminders for individual user schedules rather than sending generic reminders to everyone.

What should I include in my notification settings to give users control?

At minimum, let users control promotional versus transactional notifications separately, and break out different content types if you're sending multiple kinds. Include frequency controls where it makes sense (daily digest versus real-time alerts) and always offer a "pause notifications" option that temporarily mutes everything for a week or month.

How do I write notification copy that actually gets users to open the app?

Focus on one clear piece of information or action in about 40 characters, and be specific rather than generic - "3-bed flat in Camden, £1,800/month, just listed" performs much better than "New properties match your search". Write like you're texting a friend who needs to know something useful, avoiding internal jargon or technical language.

Should I send re-engagement notifications to inactive users?

Re-engagement notifications can work if they offer something specific like a discount code, new content, or a feature that solves a problem, rather than generic "we miss you" messages. However, if someone hasn't opened your app in three months, a notification probably won't fix whatever caused them to stop using it in the first place.

How do I test push notifications properly before sending them to all users?

Start with simple A/B tests on your highest-volume notification types, changing one variable at a time (copy, timing, or format) and testing with at least 1,000 users per variant. Track delivery rates, open rates, and conversion rates (whether users completed the intended action), and test on both iOS and Android as they render notifications differently.

When is it appropriate to use push notifications versus keeping information in the app?

Use notifications for information users have explicitly requested (order updates, booking confirmations), time-sensitive opportunities requiring quick action (appointment reminders, flash sales), or sparingly for genuinely useful feature announcements. Don't use them for general marketing, non-time-sensitive content, or things that could easily live inside the app interface.

Subscribe To Our Blog