As you may know, the push notification reception on iOS and Android is subject to a system Optin. The notifications' reception must be allowed for the application on the device.
The System Process
- On Android, the optin for notifications is granted by default when the application is downloaded. Once the user opens the application, we will track his notification token, and he will be reachable. Note that some devices model (Huawei's for instance) have a system application that can block the push notifications by default, or lock its display depending on the battery level.
- On iOS, there are two distinct processes, linked to the OS version.
For OS versions lower than iOS 12, the optin for notification must be asked within the application navigation. The official permission pop-in can only be displayed once in a lifetime for a device, so we recommend explaining to the user why you will use notifications before showing it. Note that if the user has not seen the official permission yet, he will have no way to enable the notifications (even in the device settings).
Note that on iOS, once a device has seen the official optin popup, you can use the following system deeplink
to send him in his notifications settings and be one click away from turning on/off the notifications :
For OS versions higher than iOS 12, there is the notion of "provisional authorization". This system enables to start sending notifications without explicit permission from the user.
Provisional authorization comes with quiet notifications. You can ask for permission to send to the notification center - and potentially get rejected - or automatically send them quietly on a trial basis.
You could find more information regarding the management of provisional authorization in our technical documentation.
Our SDKs automatically track the notification token of the devices. The token is mandatory to send push notifications. We also check the system optin status of the devices at each new session of the app. This information is automatically updated in the 'System push opt-in' field in our database. Note that this is the last known status of the device, if the user turns on/off the notifications but doesn't open the app again, we would not know that the device opt-in status changed.
Our database has 2 additional fields by default that could help you manage additional opt-in permission :
- 'Enabled push': By default equals to Y. If you propose a notification permission management inside your app, you could you update this field for the users who deactivate the notifications, you'll then be able to exclude these from your segments without turning their system push off. Since you don't manually update this field, its values will remain 'Y' for everyone.
- 'Enabled in-app': Same than the previous one, this default field can enable you to manage an additional application optin level (suggested for inapp campaigns). If not manually updated by your app, its value will remain 'Y' for everyone.
In general, we will deliver your notifications campaigns to all the devices (optin or optout) having a token value and 'bounce' < 3. This means that especially on iOS we potentially reach a lot of opt-out devices. This method allows us to have the wider possible reach for your campaigns, of course in order to enable you to have realistic statistics, the 'target' KPI of our statistics will only include the devices having a 'System push opt-in' value equals to 'Y'.
In the 'Sending summary' and on the Homepage KPI 'Push notifications sent' the volumes shown will be the number of notifications we really delivered, opt-out included. This might therefore explain why these figures are higher than the 'Target' KPI of your push notifications statistics.
The system opt-out devices that are targeted with push notifications will not generate bounces, only the notification display will be blocked by the device.
Custom Optin management
Some applications offer to turn the push notifications on/off from the app itself by directly deactivating the system notifications. The methods are used to unregister the notification token to the Push OS Service. If a token gets deactivated this way, the OS will not make the difference between the opt-out and an uninstallation. Therefore, the next time the device gets targeted with a notification we will receive a bounce while the application is still probably installed on his device. Also, on Android our SDK is not able to detect that the device is optout if this method is used, the device would be still flagged as 'System push opt-in' equals to 'Y' in our database.
This might generate misunderstanding when checking at our statistics as these opt-out would keep generating bounces since the bounce counter is reset every time the user opens the application.
Our recommendations for application optin management would be to use the 'Enabled push' field (you can also create your own custom fields, to keep the device technically optin to push notifications. You can also create your own custom fields if you want to manage this. If you use this method, don't forget to exclude these applications opt-out from your segments.