iOS and most recent versions of Android require app users to grant permission for key services (such as push notifications) and access personal information such as location, contact information, photos.
How you ask for the permission greatly affects the success of your app.
We are all used to being asked for location and push notification permissions.
However there are a lot more permissions that users need to allow than you may have thought. Take a look.
Consider this example from a banking app. For the app to be fully functional it needs access to six services: Camera, Location, Contacts, Push Notifications, Headphones/Bluetooth, and Touch-ID.
If the user denies access to any, the app’s functionality is significantly impaired.
In short, don’t be this app. On the very first open, United bombards new users with standard system permission requests for Location and Push Services.
Users get no context as to why they would grant permission. Hence most users will deny access severely impacting this travel app.
As iOS only shows these permission requests once, it is now incredibly hard for United to get the user to re-permission at a later date.
Try these various methods. They will greatly improve user opt-in to permissions.
When first configuring your app, be sure to instrument the Swrve SDK to automatically send events such as permission status. This enables you to track, and message off, individual user behavior.
Never ask for permissions without first showing the user the value they will get. So focus on the core value the user gets, and message to that.
A banking client found that this simple message was most effective in getting customers to opt-in to push notifications.
Decide which permissions to ask during the First-Time User Experience. Quite often, push notifications take priority as they are vital to subsequent customer messaging.
Here you see a Swrve message with a configured call-to-action. When the user taps TURN ON NOTIFICATIONS, only then is the system prompt called.
Making them is easy: anybody can create these sophisticated messages. Explain the value, configure the call to action, and make the campaign live.
Another strategy is to ask for permission in the context of a user’s use of your app.
In this example the user has tapped “Transfer” for the first time. As this feature requires Contact Access, Swrve instantly serves an in-app message explaining the value proposition, and what the user needs to do next.
An alternative approach is to replicate the system’s User Interface. The in-app primer messages is displayed first in the form of a modal. It exactly replicates the system UI only it explains the value.
If the user taps ‘Allow’, the system permission call is made. If they tap ‘Don’t Allow’, no permission call is made and you are free to retarget the user at a later time.
If a user has denied permission, you need to implement re-permission campaigns.
Here’s how Uber do it. The user obviously has denied access to location services. Rather than let the user use the app, Uber displays an in-app message explaining what they need to do. The message then deeplinks the user to Uber’s settings on device where the user can turn on location services.
In this example, a user has denied the bank access to contacts. This feature is essential for their Text Transfer feature.
When the user next taps on this feature, an in-app message instantly appears explaining the problem and solution.
Permissions greatly affect the success of your app, and there are more needed than you may have thought. How you ask for these permissions is the single most influential agent in whether your opt in rates are successful or not.
Don't be the app that bombards new users on first time app open with the standard system permissions for location and push. There is no context, no explanation, and it interrupts the FTUE. You only get one chance to serve a system permission; don't waste it by doing this.
Focus on the core values that the user will get from opting in, and make sure that you explain this to them in a preemptory message. If they opt to allow, serve the system permission; if they don't, save it for another time.
If a user has denied permission, all is not lost. Deeplink them to the page in Settings where they can change their permissions preference. It is particularly effective to do this in context, when a user needs to allow a permission to continue with your service.