Staying abreast of OS updates, particularly around key messaging channels such as push, is key to building an effective mobile growth and engagement strategy.
Alice Muir is a Growth Consultant who specializes in optimizing retention and engagement rates across the user lifecycle. Alice also develops Phiture’s sandbox iOS app, in Swift, which involves testing new iOS features and SDK integrations.
In this article, we will cover:
- What are provisional push notifications?
- How to implement this new iOS feature into your app
- Some thoughts on why you should consider provisional push as part of your app’s growth strategy
Introduction
Provisional push notifications are notifications that appear silently in the user’s notification center without making a noise or appearing on the user’s home screen. Technically, publishers can start sending them as soon as a user has downloaded and run your app for the first time. Provisional push notifications can be sent indefinitely unless the user explicitly turns them off.
Prior to the release of iOS 12, publishers had one chance to obtain permission to send push notifications through the native APN prompt. If a user selected ‘not now’ then publishers lost the ability to target them unless the user opened their device settings and switched on notifications for that particular app. Let’s face it – an unlikely scenario. Provisional push enables publishers to send notifications to a user’s device without explicitly obtaining prior permission. These notifications give users a preview of the type of content sent via push notifications before deciding whether they want to receive them in the foreground. For those that work in mobile growth, optimizing reach across email and push is crucial to being able to impact retention rates across the user lifecycle.
Although this sounds like a game-changer, there is one fundamental catch; publishers have to make the decision to either keep the traditional APN prompt and only obtain permission to send prominent push notifications or scrap the APN prompt completely in order to provisionally authorized users.
The reason for this is that the provisional push functionality is a part of the same function in Swift as the APN prompt itself. So, in less technical terms, this same line of code has to be initialized before the user can either be provisionally or prominently authorized to receive push notifications.
How to Implement Provisional Push in Your App
Assuming your app already has an APN prompt, implementing provisional authorization should be incredibly simple. All that is required, is that you add the .provisional property of type UNAuthorizationOptions to the options argument in the call to requestAuthorization(options:completionHandler:).
For some publishers, this will be in the App Delegate class; for others, this will be in whichever class includes the APN prompt (e.g. “welcomeScreenViewController”).
Before:
UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { (granted, error) in
if granted
{
print("Notifications permission granted.")
}
else
{
print("Notifications permission denied because: \(error?.localizedDescription).")
}
}
return true
}
After:
UNUserNotificationCenter.current().requestAuthorization(options: [.provisional, .alert, .badge, .sound]) { (granted, error) in
if granted
{
print("Notifications permission granted.")
}
else
{
print("Notifications permission denied because: \(error?.localizedDescription).")
}
}
return true
}
After the provisional property has been added, all notifications will go to the Notification Center on the device, and will no longer appear on the device’s background or lock screen, as before.
Revising Your Opt-In Strategy with Provisional Push
A well-thought-out onboarding funnel should prompt users to opt-in to push notifications as close to the beginning of the onboarding as possible, so that we can re-engage users that fail to complete the signup process through push notifications, hence increasing activation rates.
As Apple only allows publishers to show users the APN prompt once, growth marketers often use a push ‘pre-permission’. This can be deployed either natively or remotely via an in-app modal which deeplinks to the APN prompt if the user clicks ‘enable notifications’. If the user clicks ‘not now’, then the APN prompt is not shown, saving that one-shot chance for later in the user lifecycle.
With provisional push notifications, the traditional APN prompt is replaced altogether. Your app will send provisional push notifications as the default until a user clicks ‘keep’ and ‘deliver prominently’ in the notification itself.
Removing the APN prompt all together can seem daunting to marketers, particularly since there’s currently limited documentation and research yet on the effect that provisional push has on overall retention rates. It would therefore be advised to experiment with provisional push using a phase rollout (e.g. a small percentage of new users, as opposed to the entire user base).
Since provisional notifications are designed to give users a sample of the types of notifications that an app will send, publishers should use this as an opportunity to put their best foot forward and consider sending only the most relevant notifications. For a social app, this could include, e.g., social notifications about a user’s followers interacting with their content (Note: for more information on the relevance of push notifications, please refer to the RRF Framework). In other words, we need users to feel motivated to check the Notification Center for updates.
Experimenting With Provisional Push
At Phiture, we spoke with a number of companies that had been experimenting with provisional push to understand their position on this new feature. The general consensus across all the companies we spoke to, was that experimentation was crucial in order to collect data on this new feature to stay ahead of the game. Apple have been making changes to their OS recently, which indicate that they want to provide more transparency to the user around issues such as screen time and user distractions, as well as alerting users when they haven’t used an app or interacted with notifications for a while.
Of the companies that we spoke to who had started running experiments with provisional push, early results showed the same opt-in rate for people who got provisional push vs people who got the APN prompt. In other words, getting rid of the traditional APN prompt and having new users provisionally authorized did no harm to their opt-in rates or addressable audience. Further, the companies we interviewed did not see any difference in retention rates of users who were provisionally authorized or an increase in those users opting-in to prominent pushes. Early results indicated that D1, D3 & D7 retention also looked similar.
One thing that is obvious, is the importance of understanding the metrics behind Provisional Push. If Apple does choose to do this long-term, yet growth teams don’t have any data on this new feature, it will be very problematic. There is a chance that Apple, who are moving towards creating a less intrusive and distracting mobile experience for the user will consider removing prominent push and only offering provisional.
Conclusion
With the introduction of iOS 12, Apple has launched an entirely new approach to push notifications by enabling publishers to send notifications without obtaining prior permission. Marketers should be looking to experiment with this new feature as much as possible, considering Apple has dropped several hints that this new approach to push notifications may become the only option available to publishers in the near future. While silent notifications may not be the preferred choice for most publishers, provisional push does, however, present the opportunity to send notifications to 100% of an app’s user base from the moment they download the app. This may be a game-changer from a retention standpoint.
