Inspired by a (German) video my friend Marcel published a couple of days ago, I’d like to talk about push notifications this week. While Marcel focussed on how apps sometimes carelessly misuse the precious push notification permission, I’d like to focus on one step prior to that: asking the user for the permission to send push notifications at all.
Thereby, I want to focus on 4 important aspects of getting this opt in, I often times see just being done incredibly wrong or are just huge opportunities most app creators miss out on.
You know what sucks? Getting presented with a pop up asking me for a system-wide permission before I even had the chance to get a glimpse of an app’s content. Seriously, this not only reflects bad user experience decisions but also engineering ones. Just because the app has the technical capability of sending pushes, you shouldn’t use the default timing for asking for permission right after the app has been downloaded for the first time.
Instead, bring up the permission after a moment during which the user wants to get actual value from your app and which can then be enhanced by a push notification. For example when a video on YouTube is favorited and you get asked wether you want to get reminded when new videos from that channel get published or not.
Use custom opt-ins for more chances
While you can often times use a ton of marketing mechanics in order to make a bad user experience kind of ‘unhappen’, you can’t do so with push notification permissions. Especially when you’re using the standard iOS dialogue for getting the opt-in, a ‘no’ in that very moment can’t be reversed. You won’t get a second chance to ask again – Even if you considered my tip on timing from above.
This is why I highly recommend building your own ‘pre permission’ dialogue. This doesn’t have to be fancy, but by putting (really low) effort into your own pop up, you don’t miss that one shot to get the opt in should you ask the user in the wrong moment. Instead, it’s up to your (ideally backend-steered) logic when to ask again and again. And only if you pre qualified a users intent for receiving pushes from your custom dialogue, you let her access the official iOS one. You’ll be amazed how much higher your opt in conversion rates will be.
Speaking of conversion rates, another disadvantage of the standard iOS dialogues is the lack of analytics within that dialogue. The only rough estimations you can derive from a standard permission implementation is if the ratio of sent out push notifications (a number which should be present in your backend) increases in parallel to the number of new acquired users. A pretty muddy estimation game.
Having a custom ‘pre permission’ dialogue (I kind of start to like this term) in place also let’s you track the interaction with it in more detail – e.g. within certain user groups. You still don’t get the final numbers from the iOS system dialogue, but you’ll learn much more about when and how to ask for it.
Even though I personally consider timing the much more important aspect of getting a push notification opt in, the actual design of you asking for it plays a huge role as well.
And by design I not only mean the actual Visual Design but also the copy. Customizing the push notification permission gives you the opportunity to deploy multiple variants of how to actually ask for it at the same time. AB/Multi-variant testing is an incredible opportunity by itself – But deploying it for figuring out how to unlock one of the strongest engagement mechanics of your mobile app is HUGE! Regarding the actual pixels I personally think you should just carry-through your product’s identity (like Candy Crush is clearly doing blow).
Nothing too fancy, but I think a clear differentiation from the then followed default dialogue is a plus.
So, how is your app currently asking for push notification permissions? I hope you can derive some concrete improvements for your own work. Let me know what you’ve found out!