I’ve been working at 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 , and I’ve seen some . 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. Carnival.io great strategies less great strategies 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 , not . people devices So here they are, my best practices for push notifications. These can be thought of as four pillars*: : Make them timely When : Make them relevant Who : Make them precise What Implement them correctly Tech: 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 want? you 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 , 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. limit is relative to the value People Sleep While I imagine most people have their phones on 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? do-not-disturb 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. If you’re part of that overnight noise, you have a lower chance of standing out. 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 . Chats, deals based on history, or news alerts based on preferences. Don’t send me junk and don’t something that apply to me, for whatever reasons. for me certainly can’t 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. 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. Preempt it. 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 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 . forever lol 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 , I’d love to hear them! @samjarman 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 from this talk by Pete LePage. somewhat Google IO
