The Must-Follow Best Practices for Your Push Notifications

I’ve been working at Carnival.io a while now, and I’ve worked with many fortune 500 companies and startups to help them get set up with push notifications, and advising on their stragies for content. I’ve seen some great strategies, and I’ve seen some less great strategies. So in this post, I want to discuss what those great strategies, these best practices, are, and how you, a developer or marketer, can use them in your app.

Push is important. Push is probably as important or even more important than the rest of your app’s UX. Why?

Source unknown. I asked. Take with a grain of salt.

The good thing about notifications is they remind your users that your app is installed. A bad thing about notifications is they remind your users that your app is installed.

Get that touchpoint wrong, and you’ve lost that user, perhaps for life. Usage, feedback and revenue are all gone. Bad push practices can really harm your bottom line.

Secondly, it’s important to remember this simple truth:

Push Notifications go to people, not devices.

So here they are, my best practices for push notifications. These can be thought of as four pillars*:

• When: Make them timely
• Who: Make them relevant
• What: Make them precise
• Tech: Implement them correctly

When: Make them Timely

So my first tip is make push notifications timely. And what I mean by this is to try predict the right time to contact your user. Can you be more flexible than just when you want?

Respect Local Timezone

Respect their timezone. It might be easy to say “Oh it’s 6 PM here in New Zealand, lets send out a push to all commuters”, only to have your audience asleep in other parts of the world. If you have a sale or time-sensitive event, try send in the local timezone for the user. This will stagger the pushes over a window and might even reduce load on your server, if that’s required. A decent push service should give you this option.

Use Backoff Times

Sometimes you might want to send multiple pushes per day, or different services that interact with your app with to inform the user. Consider having a hard limit on this. The limit is relative to the value, but something like a 5–10 max per day would suit most applications. Chat apps for example, won’t have a limit, but 25 marketing messages in a day is probably (read: definitely) going to annoy your users. Consider developing internal priority for some notifications types over the other, perhaps favouring transactional pushes over generic.

People Sleep

While I imagine most people have their phones on do-not-disturb overnight, or at least on silent. But consider this: do you read all your notifications in the morning? Or do you clear them all immediately maybe after reading the important ones?

If you’re part of that overnight noise, you have a lower chance of standing out. Perhaps restrict the amount of pushes you send over night and send a summary style push in the morning, a few hours after waking up.

Who: Make them Relevant

The most important thing is to keep pushes relevant to the user.

Don’t send content for anyone

Ultimately the most valuable pushes are the pushes for me. Chats, deals based on history, or news alerts based on preferences. Don’t send me junk and certainly don’t something that can’t apply to me, for whatever reasons.

Personalize based on Journey

Many services offer personalization based on journey. This could be anything to do with the context of the app. What level of the game you’re on, which items you have in your cart, which news stories you’ve read. How long you’ve had the app installed, or how long it’s been since you’ve last used it. There’s a bunch of marketing and engagement automation possible based off just some basic data points — have a think what could be awesome inside your app!

Use Transactional Push

Alternatively, but not mutually exclusively with audience segmentation, is transactional push. These are the 1:1 pushes that go to a single users only. Perhaps their package is shipping, or they have a chat, or they’ve got a new like. These sorts of notifications are perfectly personalized by definition, but still must adhere to the other best practices, such as timeliness.

Personalize with Names

Use the persons name in a push, if you have it (and your users would remember where they gave it to you — don’t be creepy). For example: “Sam, we have new Doctor Who toys. Tap here”. Oh, and don’t ever say “click” if you’re on mobile. We don’t click there. /peeve

What: Make them Precise

The rule is simple here and there’s only one.

10 Words

Generally speaking, you have about 10 words to make your impact, so use precise language. Be obvious what you want. Make the call to action clear. “You have a new chat from Ben”. “A new deal for you. Tap here for more” “Sam sent you a friend request”. 10 words. Use them wisely.

The Tech: Implement Them Correctly

Notifications are quite tricky to implement, beyond the confusing mess of provisioning and certificates, but taking the time to do them right further helps with reducing the scary 71% stat above.

Ask for Permission Carefully

That alert box that pops up for notification permission may be one of the most important dialogs for your apps. Preempt it. Onboard your user well. Explain “Hey, here’s why we want to send you pushes and here’s what you get out of it. Are you in?” If you explain the value before you present that alert, you’ll get a much higher opt in rate. I’ve seen rates go from 20–30% opt jump to 70–90% with these techniques. This also applies to all other dialogs such as location or bluetooth as well. Explain the value, then ask the user to give up some privacy.

Use a 3rd Party Service

Don’t try do this yourself. 3rd party services are all relatively cheap for the value they provide. They worry about scaling, reliability and have good feature sets. Just use another service.

Preload Content

If your push drives a user to some in app content, you should really be pre-loading that with the available API first. This will delay the push by 20 seconds or so, but when they open the app, the UI should be ready to go. No one wants to be taken to a loading screen.

Duplicate Notifications Inside Your App

It’s almost too easy to clear notifications. You should always try and duplicate the notification content inside the app. This could be an activity log, a chat history or a notifications log. Make it so users can always re-read the alert text of a notification. I really like Tweetbot’s implementation of this.

Expose Settings

If your app has different scenarios in which to send push, let the user turn off hearing about certain situations. Additionally, You can also use the Notifications API on iOS or Android to see which alerts your user has enabled. For example; if they have turned off push, you can detect that and present the benefits again, and if they say yes, you can deep link them to the Settings app. This, over time, will slowly increase your opt in rate again.

Rich Push

In additions to notifications with Actions or Text Input, iOS 10 and Android forever lol brings Rich Push, which allows you to show a selection of Images, GIFs and Videos in your push previews. In iOS 10 you can even do arbitrary views too, and you can learn more about that here.

Clear the Badge

Finally, my last best practice is to clear the unread count on the badge icon. Either natively on iOS or however it’s implemented on Android (It’s complicated), be sure to remove the badge count when the app is finished launching. Me, and I’m sure several others, have an obsessive compulsion to have all the badges cleared on our phones, so please don’t make us tap around to find out how to clear it.

So that’s my best practices for Push Notifications. Remember:

• Push Notifications go to people, not devices
• Who. What. When. Get the Tech Right.
• Get them right or your bottom line will suffer

And that’s my thoughts so far. If you have any best practices, please comment or tweet me — I’m @samjarman, I’d love to hear them!

If you liked this article, go ahead and press the green heart below (💚), it’ll give me the warm fuzzies.

Oh, and this originally appeared on my blog.

* Borrowed somewhat from this Google IO talk by Pete LePage.