Modified on: Fri, 21 Dec, 2018 at 5:12 PM
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 device model (Huawei's for instance) have a system application that can block the push notifications by default, or lock it's display depending on the battery level.
- On iOS, the optin for notification must be asked within the application navigation. The official permission popin can only be displayed once in a lifetime for a device, so we recommend to explain 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 system deeplink :
to send him in his notifications settings and be one click away of turning on/off the notifications.
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 turn on/off the notifications but don't open the app again, we would not know that the device optin status changed.
Our databases have 2 additional fields by default that could help you manage additional optin permission.
- 'Enabled push' : By default equals to Y. If you propose a notifications 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. Which means that, especially on iOS we potentially reach a lot of optout devices. This method allow us to have the wider possible reach for your campaigns, off 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, optout included. This might therefore explain why these figures are higher than the 'Target' KPI of your push notifications statistics.
The system optout 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. It usually calls methods 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 optout and an uninstallation. Therefore, the next time the device get 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 mis-understanding when checking at our statistics as these optout would keep generate bounces since the bounce counter is reset every time the user opens the application.
Our recommendations for an 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 application optout from your segments
Did you find it helpful?
Not what you were looking for? Try a search!