Confirmed Delivery

Tracking received rates on notifications.

With Confirmed Delivery, every device that receives a notification sent through OneSignal will acknowledge successful receipt back to OneSignal. This stat will appear in a Message Report for a notification as “Confirmed.”

Most message platforms will automatically send a delivery confirmation to OneSignal, but some, like iOS, require additional setup.

How do Confirmed Deliveries work?

Push providers, like OneSignal, must go through Apple and Google in order to deliver notifications. After OneSignal has sent a message to a push provider, they forward the message to the end-user’s device. When OneSignal receives a “Confirmed Delivery” it means that the end-user’s device has sent us confirmation that your message was successfully delivered.

OneSignal calculates click-through-rate (CTR) based on OneSignal deliveries, but if you wanted additional granularity for your CTR to exclude devices that will never receive your notification, you can export your delivery data, and calculate CTR based on Confirmed Delivery. To learn more, read on Inactive Devices.

Why isn't this offered by most push providers?

To confirm device-level delivery of a notification, push providers must process an extra inbound request for each push. This leads to a large burst in traffic to their servers. Because OneSignal sends out pushes at a sustained speed of one million pushes per second, it can handle over one million incoming confirmed deliveries at the same rate.

Requirements

📘

Confirmed Delivery is a paid feature.

Confirmed Delivery is available to customers on paid plans. To learn more, read about our pricing.

Tracking Confirmed Deliveries requires devices to have the minimum version of the OneSignal SDK that supports this feature and set up the OneSignal SDK according to our setup guides. Using our API only to add devices or omitting steps from our setup will cause Confirmed Deliveries to be unaccounted for that platform.

When an Android App receives a push, it automatically sends a confirmation to OneSignal, letting it know the app itself has received the push.

On iOS Apps, you must have the iOS Notification Service Extension setup for the confirmed delivery to be counted. Also, ensure you are using a version of our SDK that supports this feature. See below Supported SDKs Table to make sure you have the minimum version or higher.

Supported SDKs

Make sure you have the minimum SDK version or higher installed. We recommend using the latest version of the OneSignal SDK.

Confirmed Delivery Troubleshooting

Confirmed Deliveries cannot be triggered if a device is turned off. If a device is offline when the push is sent, it has a 3-day default time to come back online to get the push. You can increase or decrease this time with the Time To Live parameter.

Also, a Confirmed Delivery may be missed if the device has an unstable network connection at the time of receiving the push. The push may get received and clicked, generating a click response, but the network may not have been strong enough to send the received event.

Other possible reasons for inaccurate Confirmed Deliveries:

Missing or Incorrect iOS Notification Service Extension Implementation

The iOS Notification Service Extension and iOS SDK App Groups setup must be included in your iOS mobile app for Confirmed Deliveries to be counted. If you send a test message to your iOS mobile app and the Confirmed Delivery is not counted, please update the OneSignal SDK and check the Mobile Setup Guide.

Android Devices Force Quitting the App

Some Android device manufacturers put apps into a "force quit state" when you swipe the app away, which causes the device to not get notifications for your app when it is not running. Unfortunately, this is a manufacturer issue that affects all push providers.

We have a list of common devices and fixes for this in our Notification Not Shown Guide. We also wrote a blog post about this and many 3rd party sites discuss this as well, like: https://dontkillmyapp.com/

To try educating your users about this, you could set up In-App Messages to target users on Android and make sure they have battery optimizations for your app turned off or they are setting to keep your app running when swiped away.

Inactive Devices

Users do not normally unsubscribe from all their apps or websites when they get new devices or retire their old ones. In fact, you may have some devices at home that are subscribed to apps you have not visited in years!

Using Segments, you can check all device records that have not opened your app or website in over x amount (1 year, 6 months, event 1 hour) of time using the "Last Session" filter.

If you have devices that have not returned back to the app or site, you can delete these devices. However, make sure you do not accidentally delete active users.

Mutable Content (iOS)

All push notifications sent to iOS devices automatically include the mutable-content parameter set to 1. This allows for the notification to be processed by the Service Extension which is required in order to make Confirmed Deliveries work correctly.

Safari Limitations

Confirmed deliveries cannot be performed due to Safari.

How do I track which devices confirmed delivery?

Currently Confirmed Deliveries only tracks how many devices confirmed. It does not track which devices confirmed yet.

In order to track which specific devices confirmed receiving the push, (for example you want to send an email, In-App Message or SMS if they did not confirm) you would need to target devices individually either with the include_player_ids or include_external_user_ids targeting parameters on our Create notification REST API.

You will want to save the device ids targeted and notification "id" provided in the API Response. Further if the device is unsubscribed, you will get the unsubscribed device id in the invalid_player_ids or invalid_external_user_ids response.

After x amount of time has passed that you want to wait for checking if confirmed, you can use the View notification API endpoint with the notification "id" saved from the response.

If received is 0, then they device has not received the push yet. Depending on how long you want to wait, you can set the ttl parameter to discard the push if x time as passed. See Notification Behavior & Payload Information for more details.

Confirmed Delivery Limitations

Displayed but NOT Confirmed

PlatformDetails
Android & iOS & Web- Networking issue where device couldn’t finish a network call to onesignal.com
- App or NSE crash after displaying
iOS- Network took over 30 seconds (iOS kills the NSE after this timeout) to response.

Confirmed but NOT Displayed

PlatformDetails
Android & iOS- Notification does display BUT user doesn’t notice it due to low visibility; such as no sound, vibration, or grouped within to many other notifications.

- Too many apps open on the device taking up too much memory - Possible but not likely. iOS NSE uses very little RAM. Android, possible on some low RAM devices under rare cases.
iOS- App is foreground AND one of the following:
- OneSignal’s InFocus displaying is set to NONE
- Another SDK or library suppressed the notification
Android- User turns off notifications at the device level and does not open app yet
- User turns off notification category / channel for the notification that we tried to display
- OneSignal NES is not displaying our notification we may be miss reporting it

Delivered status but NOT Displayed AND NOT Confirmed

Not really a “Confirmed Delivered” issue but covering here for completeness.

PlataformDetails
iOS- Device is offline and two or more notifications are sent
- Apple’s APNs server only stores-and-forwards 1 (the most recent) notification per app.
Android- Device is offline and two or more notifications are sent with the same collapse_id
- By design collapse_id replaces the stores-and-forward push on FCM’s server