In this post we will introduce the upcoming changes in requesting location permission and cover best practices that brands are applying to maximize transparency, sense of control, and opt-in rates.
Since the early days of mobile, the idea of delivering contextually relevant consumer experiences was a key focus of both Google and Apple. Both operating system platforms made data from smartphone sensors easily accessible to app developers, who in turn leveraged it to create compelling experiences that have become part of our day-to-day lives.
Brands are able to deliver the in-app experiences we have grown to love, such as ordering food, requesting a ride, or finding the top running trails nearby by using this smartphone sensory data in an intelligent way.
The gatekeeper of smartphone sensory data is the consumer-facing location permission prompt. This post will focus on the best practices for requesting access to location in your mobile application in light of the upcoming changes in Android Q and iOS 13.
Real-world data and location services have mainly been used to help brands better serve their customers, but monetization practices that use this data have become more prevalent.
The increase in abuse has led both Google and Apple to slightly modify the location permission request experience. These changes will:
These changes will be released this fall as part of iOS 13 and Android Q.
These changes have not yet been implemented, and we have yet to see real numbers. It is clear, however, that these changes will mainly affect brands that request location permission without effectively communicating and providing consumer value.
It’s safe to assume that mobile applications that are used on a daily basis, such as ride sharing, food delivery, health and fitness apps and others that clearly communicate and deliver their value to consumers, are likely to be impacted only marginally.
Android Q primarily adopts the location permission flow of iOS 12 by introducing two changes:
Currently, all Android operating systems have one permission request for location data. Android Q adds a separate request for allowing apps access to location data in the background.
ACCESS_BACKGROUND_LOCATION allows an app to always access location and other sensors. If you’re requesting this permission, you must also request either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION – just like today.
If your app was already granted consent for location in Android 9 or lower, it will automatically be included with the OS upgrade without prompting the user to provide consent once again.
|Target SDK version||Coarse or finepermission granted?||Background permissiondefined in manifest?||Updated default permission state|
|Android Q||Yes||Yes||Foreground and background access|
|Android Q||Yes||No||Foreground access only|
|Android Q||No||(Ignored by system)||No access|
|Android 9 or lower||Yes||Automatically added by the system at upgrade time||Foreground and background access|
|Android 9 or lower||No||(Ignored by system)||No access|
If a user grants access to background location, a notification will be pushed to the user after a few days, reminding them that the app may always access their location.
Most app publishers are already familiar with these reminders because of iOS 12. In iOS, publishers used contextual primer screens to communicate the added value consumers would experience if they granted location permission. These user flows required constant optimization in order to maximize conversion, so in order to save time and effort, Neura recommends replicating your optimized iOS experience and implementing it into your Android app once the OS updates to Android Q.
iOS 13 will introduce three changes that are designed to empower end users with more transparency and control.
Up until iOS 12, Apple had two types of permissions: background Always and foreground When-In-Use. A third permission is being added in iOS 13, which allows end users to Allow Once. “Allow once” will grant an app the ability to utilize the When-In-Use permission for that one session. The permission will be revoked at the end of the session, and the end user will be prompted again on the next session.
While this change has yet to take effect, Neura believes that this change will impact user behavior in the following ways:
Users who do not wish to commit to always granting the app location access will now have the flexibility to enable it one time. This gives them the opportunity to experience the added value of granting location access to the app.
No one likes to answer “Allow Once” over and over again. Users who do so and appreciate the value of enabling location will eventually opt for When-In-Use or Always.
One of the most effective methods for requesting the Always location permission, already proven successful in iOS 11 and iOS 12, is a two-step background permission request. The idea behind this flow is to allow users to experience the value of contextual features in the app before prompting for “Allow Always” access to location.
Apple embraces this best practice. With iOS 13, the prompt for the “Always” permission will only appear if the user has already given location consent for When-In-Use.
When app publishers request the Always permission, the user will first be prompted with the When-In-Use and the Allow Once options. The operating system will then grant the app with a provisional Always permission and automatically prompt the user for a non-provisional “Always” location access later on.
In iOS 13, Apple will enhance the location access reminders you’ve become familiar with from iOS 12 to include a map that provides users with transparency into the locations that are shared with the app that’s requesting the permission.
Just as in previous versions of the operating system, the usage description section of this prompt is customizable and allows brands to communicate the value they offer users.
When requesting permissions properly, even the most privacy-oriented Neura customers see location opt-in rates of 60% – 90%.
In light of these changes, it’s imperative that brands work to tweak and optimize their location permission flow, primer screens, and on-boarding experiences to align with the new operating system behaviors. If you wish to learn more or would like help preparing for these upcoming OS updates, we’re here to help.