Push Campaign Metrics

Send

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.

#Bounce

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.

#Delivery

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).

#Open

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:

1. 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.

2. 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/trackPushOpen API to tie the open to the push campaign.

3. 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 /events/trackPushOpen API

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.

#Uninstall

12 hours after a normal push message is sent to a user, we will also send a "ghost" push to the same user. If the "ghost" push fails, it means the user uninstalled the app after the initial push message was sent.

This event counts as a push uninstall event and is attributed to the original campaign.

Uninstalls only happen when we get a bounce. If push notifications are disabled on the device, the push message/ghost will still be successfully delivered, just dropped by the device.

#Unsubscribe

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 /users/updateSubscriptions API.

When the unsubscribe event is sent, the body of the call should include the email of the contact, the campaignId, and either the channelId or 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.