Increasing opt-ins by deferring iOS permissions requests (Push, Location etc)

Nov 24
Example Onboarding Screens

Increasing opt-ins by deferring iOS permissions requests (Push, Location etc)

[UPDATE: Also check out a more recent post on best practice iOS permission handling].

In a previous post I wrote about the focus that Apple & Google have on increasing the utility of push notifications – specifically to support that your phone/tablet is rapidly becoming the inbox and remote control for your life. But I also covered the range of challenges in getting push notifications to be opened.

Key amongst these is getting the user to opt-in to push notifications and other permissions – Android and iOS have different approaches to Application Permission such as:

  1. Push Notifications
  2. Access to User Location
  3. Background Location
  4. iBeacons
  5. Address Book/Contacts

In Android, users see the permission requirements at Install time (in Google Play) and makes a decision if they accept it. The developer can then make a decision of what to turn on/off.

iOS is different – this post mostly addresses the benefits and challenges of deferring permission requests from your users.

Current Practice & Better Practice

The systemic problem is that in the rush to get a mobile App released a Mobile Engagement Strategy is generally overlooked. This means that you’ve no specific plan to onboard your users, segment them and drive retention – the result is the “churn curve”. Some symptoms of this systemic problem are:

3 Huge Mistakes

  1. Not using the first few seconds of a user experience to guide, delight and explain how to use the App. This onboarding step is not generally done well but your product managers/designers/developers should be focussing on an instant gratification and understanding. Take a look at Canva for a great onboarding and also check out this Quora thread for games.
  2. Forcing a registration is a bad habit left over from the web and I’ve written about it here. Social Apps are probably the exception but I recommend focussing on making the user happy before you demand an Facebook login or an email login.
  3. Prompting for any of the permissions I mentioned above (e.g Push Permission) when the user first runs the App!

4 Steps to Onboarding Epiphany

4 Steps to Onboarding Epiphany

Deferring Permission Requests

We are often asked about what the opt-in rates are for push notifications and the answer is “it depends”. In the broad landscape (as discussed here) push is:

  • increasing in consumer acceptance and understanding
  • more often accepted in younger generations
  • broadly ranges from 60-75% based on App type and user demographic
  • is reduced if the user/consumer expects to be spammed. There is a counter wave of “push fatigue” that means users will not accept push requests. This is mainly because of Apps not segmenting users and targeting push for relevance.

A Better Practice

Onboarding is like being on a first-date and if you want more uplift on permissions then treat the request as a key part of the user lifecycle – in other words an important event in your Engagement Strategy!

Like any other first-date there is some earning of trust:

  1. the user has installed the app, so they are interested in what you (your App) can do for them
  2. but they really want to get to know you (your App) better and see if we have some sympatico
  3. in order to receive, you (your App) needs to give first . . . give a great experience.
  4. After you’ve provided a great experience (lets say its “favouriting” a product/item or completing a transaction or playing some media), tell them what the benefits are in opting in to Push, Location etc.
    • Tell them in context
    • Tell them with your own dialog box that matches the App design
    • Make it beautiful. Optimize for “YES”
  5. In this way, you’ve given the user understanding of why. Go Google the work of Ellen Langer  a Professor of Psychology at Harvard showed the power of the word “because” in influencing people. The TL;DR is that when you use the word “because” you get a higher acceptance regardless of how silly the because reason is!
  6. Once you’ve got permission, go ahead and call the iOS permissions.

For Developers – deferring Permissions

OK, this gets geeky for a moment - the detailed documentation is here but this is a brief summary.

For deferring Push Permission follow this process:

  1. StreetHawk.isDefaultNotificationEnabled = NO;
  2. //do [StreetHawk registerInstallForApp…]
  3. // later after you’ve performed the contextual prompt and permission is given
  4. StreetHawk.isDefaultNotificationEnabled = YES;

For deferring Location Permission follow this process:

  1. StreetHawk.isDefaultLocationServiceEnabled = NO;
  2. //do [StreetHawk registerInstallForApp…]
  3. // later after you’ve performed the contextual prompt and permission is given
  4. StreetHawk.isDefaultLocationServiceEnabled = YES;

Challenges in deferring Permission Requests

Naturally its not that simple, there is always a tradeoff (*sigh*).

If you can’t reach your user’s by push, then you need to be able to track, segment and engage them via another method. In reality, this should be part of your Engagement Strategy anyway – if you have a segment of users (who in StreetHawk we call the “Unreachables“) – you need to engage them either via inApp content or other out-of-band communication such as:

  • email/SMS
  • Social Media
  • Real-world (e.g in-store engagement such as loyalty scans, treasure hunts)
  • Great needed utility!

Personally I think you should try to deliver the permission request in the first 1-3 sessions (remember abandonment churn rates are huge. If you get a “NO”, you can always automatically trigger this again and try different prompts to different segments using StreetHawk segmentation and your inApp content. For example your prompt to a Power User will possibly be different to a Registered user.

  Get our Referral Program Guide