When a push campaign is published, Iterable will attempt to send a push to all devices registered for the contacts receiving the push. That total number of pushes attempted to all devices registered but not currently disabled will show up as the Total Pushes Sent.
Unique Pushes Sent represents the total number of contacts that were sent the push. If a contact has more than one enabled device, both devices will be sent the push, but the Unique Pushes Sent will only count at a user level.
If a push notification is sent to a device with a disabled token/regId, Apple or Google will register the event as a bounce and provide feedback to Iterable. A token/regId can become disabled due to a variety of reasons such as when a user uninstalls the app, the app or token is no longer valid, the user reinstalled their OS or upgraded to a new OS (less frequent case).
When a push notification is sent to a device that has disabled push notifications, this will not count as a bounce.
The bounce reporting on the campaign metrics page will also include app uninstalls that occurred after the campaign was sent. Iterable measures this by sending a "ghost push" after the actual campaign.
On the user profile view, you will be able to see bounce and uninstall events as two different events.
The total pushes delivered is the total pushes sent minus the total pushes bounced. Therefore, the push delivery rate is (total pushes sent - total pushes bounced)/(total pushes sent).
Each company may have a different approach for how they track push opens. Here are the three possible open scenarios and how to track them:
App is closed. User opens the app by opening the push notification.
If you’ve used the Iterable iOS SDK, then the open will automatically be recorded if the user opens the app via an Iterable push notification.
App is running in the background. User opens the push notification to bring app to foreground.
You can verify that the app was brought to the foreground with an Iterable push notification by checking the payload, and then calling Iterable's
/events/trackPushOpenAPI to tie the open to the push campaign.
App is open in the foreground. Your app can decide to either not show the push notification or show it as a local notification. You count the open as the user viewing the local notification.
If the app is already running in the foreground, and you wish to show the push as a local notification, you can record the open by calling Iterable's
To learn more about the possible scenarios that can arise when the system delivers a remote notification to an Apple device, read Apple's Handling Notifications and Notification-Related Actions document.
Iterable will track uninstalls with no additional work by you.
Uninstalls only happen when we get a bounce, so if a recipient has merely disabled notifications from their device settings, push messages will be received successfully by the device, but will not be displayed to the recipient.
To track uninstalls, Iterable sends a silent push notification, or "ghost" push, some time (currently, 12 hours) after a campaign has been sent. Based on this silent push notification, if Iterable receives feedback that the device token is no longer valid, it assigns an uninstall to the device attributed to the prior campaign.
Similarly, if a "real" push campaign uncovers an invalid device token, it will also check for a prior campaign, within the last 12 hours, to attribute that previous campaign as the cause for the uninstall. If there was no recent campaign, Iterable still tracks the uninstall, but does not attribute it to any campaign.
Apple has changed the way device tokens expire, so they may take up to 8 days to detect if they are invalid. This does mean that uninstall tracking may not be accurately attributable to campaigns sent within that period of time.
Since a push does not require an opt-out directly in the message like an
email would, we allow each company to define the events that would constitute
a push unsubscribe and send the event directly through Iterable's
When the unsubscribe event is sent, the body of the call should include the
campaignId, and either the
messageTypeId (depending on how unsubscribes are managed in your Iterable
account). If you are setting up your Iterable account, read
Message channels and types best practices.