Batch and your analytics tools measure user visits to your app in different ways.
You may observe discrepancies between Batch direct opens, Daily Active Users, starts, installations, and the number of sessions tracked by your third-party analytics tools (AT Internet, Firebase Analytics, Google Analytics, Mixpanel, etc.).
If you notice more direct opens from a Batch campaign than sessions in your analytics tool, this could be due to several reasons.
On Batch's side, each click on a push is counted as a direct open (without grouping push opens within a specific time window). This measurement is precise, as it is directly provided by our SDK. Calculation methods can vary across different tools. Keep in mind that:
Your analytics tool may count sessions only after a certain delay or a set number of interactions on your app/website.
Your analytics tool may group multiple visits within a specific time frame into a single session (e.g., 'Google Analytics groups hits received within 30 minutes into the same session' – see )."
Direct opens are measured by Batch when the user opens the notification, while your analytics tool measures a session when the app has effectively been opened.
After the notification has been clicked, your analytics tool may not count a new session, depending on the configuration. For example:
The user has not provided consent for session tracking in the app (e.g., via your Consent Management Platform).
The notification contains a deep link that opens in the device's web browser instead of the app.
The number of visits in your analytics tool may be higher than Batch's active users, installations, or starts. You should bear in mind that:
A "Start" as shown on Batch's dashboard corresponds to a start of the Batch SDK. If Batch SDK has been disabled by some users (e.g. by not giving their consent, see our ), a visit may be counted in your analytics tool but not in Batch.
You may also have defined specific rules to allow Batch to start in your app/website (e.g., IP filtering, after a specific action, a minimum delay, etc.).
For the web, Batch analytics do not include unsupported platforms (e.g., Internet Explorer), but your analytics tool is likely to include them.
To track your campaigns effectively, you should implement an event dispatcher (Guides: /). This enables the automatic dispatching of push opens and in-app displays from Batch's SDK to your analytics tool.
Read these guides for more details:
You don’t know where to track the uninstall stat of your application? I’ll tell you where you can find this indicator.
At Batch, we do recommend using tools such as Google play developer for Android or iTunes Connect for iOS that can give you relevant information about uninstalls.
If Batch does not know the information on the uninstallation of your application, Google knows it.
All you have to do is connect to your Google Play Console and find on the statistics tab the number of uninstalls. You can also check on the dashboard the number of installs and uninstalls for the last week, month, or year.
iTunes Connect does not give you the exact number of uninstallation. But it can give you another information, which is "retention". Retention measures the usage of your app over time.
Here is everything you should check if you have no opens on your push campaigns.
If your campaigns have no opens, something may be misbehaving in your integration.
The problem can come from different places depending on the platform:
On iOS, the issue may be caused by a conflict with another SDK that automatically integrates with your application delegate (such as but not limited to Firebase).
You can fix this by manually integrating Batch. If you implement your own UNUserNotificationCenterDelegate, you need to make sure that Batch is integrated into it (learn more about this advanced setting).
On Android, it can mean that Batch is not integrated into all activities.
If you are using a Custom Receiver (or ) and displaying your own notifications, you might not have copied the data Batch needs in the intent.
If you use a Custom Receiver, we recommend checking if the interceptor meets your needs instead. It greatly reduces the likeliness of this kind of errors.
Also, Opens might not be detected if the splash screen ends too soon. We recommend using the feature to exclude the splash screen from Batch's lifecycle handling.
Once you have made the fixes, you can test your integration by taking the following steps:
Run the Xcode or Android Project on a device in debug mode.
Send a notification while outside of the app (in background mode, do not kill the app).
Open the notification.
Check your Xcode logs or your logcat. You should see the following logs: "App was opened from a Batch push".
To interpret opt-outs and app uninstalls correctly, you need to understand how they're calculated.
You can track your opt-out users in the Analytics → Reach tab:
Batch can only have information about what's going on in the app. When a user installs and opens the app, we receive a push token from Apple/Google that allows us to communicate with them:
If the user opt-outs from notifications in the device settings, no information is provided to Batch servers. The actual opt-in status will be updated only when the user opens the app again. Likewise, we do not know in real time when an opt-out user activates push notifications again.
Therefore the Batch database is potentially always "out of synchronization" with reality regarding the opt-in status.
Batch always targets all opt-in and opt-out tokens: it allows us to update the state of the tokens, clean the database and recover the users who would have reactivated the notifications. The notification will never be displayed to an actual opt-out user, it will be blocked by the device.
There are two pages where you can track your app uninstalls:
In this example, we report that 509 users, who were targeted by the push, did not receive it because they uninstalled the application. Uninstalls concern both opt-in and opt-out users, as long as they were targeted by the campaign.
Unlike opt-outs, we receive by return loop the uninstalls that took place between the sending of the last campaign and the campaign of the day. This loop occurs only once a campaign has been sent. That's why you will see uninstalls only on days when a push has effectively been sent.
Learn more about your campaign's uninstall/opt-out/deleted tokens.
It is normal to see unsubscriptions (opt-out = uninstall = deleted tokens) at the level of campaign analytics or globally on the days you send campaigns.
Here are the three spots to track deleted tokens :
Indeed, on web push, we receive by return loop the unsubscriptions that took place between the sending of the last campaign and the campaign of the day. This loop occurs only once a campaign is sent. That's why you'll see deleted tokens only days when a push is made (as in the picture above).
So, instead of reading "the January 20th campaign generated 29 opt-outs", you should interpret it as "between January 10th and January 20th, approximately 29 opted-in users unsubscribed from web push". This highlights the importance of sending campaigns regularly to keep your user base clean.
About the ascent of deleted tokens:
on Firefox: the deleted tokens are sent to us each time an old opt-in connects to the website again, that's why we observe opt-outs even on days when no campaign is sent.
on Chrome: the deleted tokens are sent to us each time a new campaign is sent.
