Enabling users to take full advantage of all the features you have built into your app may require them to approve the app’s access to device features. During the onboarding process, test when you ask for these permissions.
You probably ask for a multitude of permissions, but do your users know why you are asking for each one? And are there some that they are more likely to respond to?
Asking for several permissions on during initial app load requires unnecessary taps and may make users weary of how the app will use their personal data. Introducing friction in onboarding may discourage users from completing the ultimate goal of onboarding: registration.
When to prompt the user
One of the biggest factors that determines whether users accept your requests is when they occur. If your new user experience begins with a slew of requests, you may be missing a critical opportunity to engage users and help them opt-in to your full-featured app.
Metrics to track: Acceptance rates, engagement rates
Idea #1: Test aligning permission requests with the obvious benefits of your app.
Once users are engaged, they could be more likely to accept your requests.
Facebook Messenger asks for contact permissions when users would first want to sync their contacts.
Compare this with Snapchat, which does not start asking for permissions until much later in its tour, and includes this priming message, clearly explaining why it needs your permissions and what it will not do with them.
Idea #2: Test "pushing" requests vs. "pulling" for them.
Test prompting users to accept permissions only when they try to use a specific feature. This way, your permission requests will be more contextual and intuitive.
Cluster decided to have the user trigger requests for features. When the user taps a feature like the camera, that triggers the request for photo permissions.
Idea #3: Test asking for all permissions at once vs. asking for different permissions progressively.
Skype Qik explains why it needs all of the user's permissions at once.
Priming before the request
You can only trigger Apple's default permission request once per feature, so some apps “prime” their users to accept requests before the actual Apple permission request screen appears. This is a prime opportunity to test how to best prepare your user to accept permissions.
Metrics to track:
- Acceptance rates
- Engagement rates
Idea #1: If you're not priming your users at all, test including "primer" messages before the Apple request screen appears.
See how the inclusion of a primer screen affects user behavior.
Inbox by Gmail asks for permissions before beginning its onboarding tour, with no additional context. Could it increase acceptance and engagement by providing a primer?
Compare this to Cluster's flow, which includes a context-building screen, a primer, and then finally the permission request.
Idea #2: If you already have primers, test the copy and style to see what works best.
Try copy that makes your user feel at ease versus copy that drives at the value that the user will get from accepting the request on the next screen.
Instagram uses a primer almost identical to the Apple default, providing maximum context for why it needs all permissions.
Rooms uses a pop-up style similar to the Apple default for its primer, with minimal context for why the user should accept. It also provides the option in its primer to save the permissions prompt for later.
Cluster used to use a permissions dialog similar to Apple's, but ended up building their own version that includes an image and some copy explaining the value of accepting the permission.
Idea #3: Test the rationale you give for your permission requests.
Users may respond to different reasons that you need them to give your app permission.
Foursquare uses FOMO (fear of missing out) as a way to ask users to accept notifications.
Grouper asks for Contacts permissions by using invites as a way to move up in its waitlist.
You may also try handling objections preemptively. For example, when asking for push notification permissions, you could say, "We promise not to bother you." Will that instill confidence or will that put the idea in their minds that your app is bothersome? For example, how does Snapchat's primer make you feel when it mentions spam?
Idea #4: Test priming during the request.
You can do this by providing a background image that contextualizes the permission request.
Foursquare primes users as the Apple default pop-up is on-screen, by providing a background image that explains why the app needs that particular feature.
Prompt for re-notification
If users do not accept your permissions the first time, test how you prompt them to notify you when they need to accept permissions again.
Metrics to track:
- Acceptance rate
- Engagement rate
- Acceptance rate for users who have initially declined
Idea #1: Test including re-notifications in your settings.
Some apps make it so difficult to re-activate notifications that once users click "Don't Allow," they are never be able to activate those features easily. For instance, this is a sample user workflow to reactivate permissions:
Idea #2: Test the copy of your re-notification prompt.
What might be persuasive to users who did not accept your permissions, and how can you help them understand why and how they should reconsider?
Idea #3: Test re-notification prompts that focus on why accepting permissions is beneficial versus how to access the permission requests in the future.
Do you think your users are not re-signing up for permissions because they do not see the value or because they do not know how to do it? Test this hypothesis through re-notification request copy.
<%= heading %>