Hi and welcome to this week's episode on Pulsate Academy. My name is Finóla and i’m from the Customer Success Team here at Pulsate. Last week, we looked at how you can ensure that your app users opt in to permissions in order to enhance their experience with your app. Today, we’re going to take a look at another method that has shown an opt in rate of 99% for some apps, and it’s called Permission Priming. So let’s get into it.
@PulsateHQ [WATCH] Priming Users: It's Not as Difficult as You Think
VIDEO NOTES | CUSTOMER LIFECYCLE MARKETING SERIES
As we know, getting access from your users the first time is critical. For some apps, without getting it can completely change the experience of your app for the user, or even worse, render your app useless. For example, if your app relies on the camera for its core functionality and the user hasn’t granted permission, they may never come back to your app again as they don’t have access to all the benefits of it and they don’t understand why. That’s why spelling out why you need access to a particular function is key, and when you ask is just as important.
So let’s take a closer look at what Permission Priming is.
Apple only allow you to trigger their default system permission once per feature. Permission priming is when an app “primes” their user with a permission that looks like one of Apple’s system permissions before the actual system permission is displayed. However, it’s what happens after a user taps one of the two buttons that’s important, so let’s take a look at this in more detail.
- The user downloads the app and either in the onboarding sequence, or when they are using the app are presented with a permission outlining the benefits of allowing access to this feature.
- If the user taps “OK” on the explainer screen, then we know that they are likely to accept the native prompt to opt-in for what is being asked, so now is the optimum time to display the Apple System permission screen.
- If the user taps “Not Now” then delay displaying the native Apple push notification prompt until later on.
- Allow the user to continue using the app until they get to a section that requires them to give access to that area.
- When the user comes to that section, display the benefits screen again. At this point they are more engaged with the app and more likely to opt-in to accept the request.
- If the user hits “Not Now” again, delay the native Apple prompt until they come to a screen again that needs them to grant access. At this point, another pre Apple prompt screen may be designed so that it doesn’t become repetitive.
- If the user taps “OK” then we know that they are likely to accept the native Apple prompt on the next screen so it is the ideal time to display it.
When writing the copy for the pre native permissions prompt, be sure to make your benefits simple, clear and non complex for the user. It’s a good idea to A/B split test the copy here to see if one explainer screen wins out over the other.
Putting thought and consideration into how you ask for access permission is very important. If you are not using the Permission Priming method and the user taps “Don’t Allow”, it is not an easy process for them to reverse that decision as it takes 5 steps through the settings pages for them to turn them on, and there is no way of directing there.