Batch provides a simple interface where you can access all your app/website parameters and use other advanced tools. Click the "Settings" button in the top right corner of the dashboard to:
- General App Settings: Access all the information related to your app/website information (e.g. app name, website URL, default language, API keys, etc).
- Push Settings: Edit all your push-related settings (e.g. iOS push certificate, FCM settings, delivery speed limit, etc).
- Team Access Management: See who can access your app in your team or grant app access to new teammates.
- Custom Data Management: See the list of custom data sent to Batch from the SDK or your servers, using the Custom Data API, and disable specific attributes/events.
- Custom Audiences Management: Create, edit or delete custom audiences.
- In-App Themes Management: Create, edit or delete themes you can use in your In-App campaigns.
- Debug Tools: Access the debug tool to see the data attached to specific IDs, test your integration, review the IDs targeted with the Transactional API or see if an install is in a user journey.
- Privacy Center: Request data removal or data access for a specific ID.
- Labels Management: Create, edit or delete a label you can attach to a push or an In-App campaign.
- Frequency Capping Management: Limit the number of notifications an install can receive in a customisable time frame by creating or editing rules.
Some options may be locked depending on your plan or on your access rights.
That section of the settings contains basic information on your app or website.
Required - Name of your app or website. Batch will prefill that field based on the information gathered from the App Store, the Play Store or the metadata of your website.
If you didn't provide your App Store/Play Store app ID when you created your app, it will be the name you chose. Batch only uses the app/website name in the app list and in in the push preview of the campaign editor. Feel free to modify it you need to organize your app list (e.g. "[DEV] My App", etc).
Batch won't use that name in the push notifications. On iOS and Android, the app name displayed in your push is set in your project.
Required, Web only - The URL of your website. Batch uses that URL to get the name and the icon of your website. Batch also uses your website URL to generate the SDK Auth key.
Required - The default language is the fallback language used in your push and In-App campaigns. All your campaigns must contain a version of your message in the default language of your app.
If a localized version of your message is not available in the language detected for a targeted install, Batch will send the message in the default language in the app.
E.g. Your app default language is "English". You created a push campaign targeting all your userbase, with a localized wording in English (default), French and Spanish. Italian speaking users targeted by your campaign will receive the notification in English.
Make sure you use the same default language across all the platforms (iOS/Android/Web). Otherwise, you may not be able to replicate a campaign from a platform to another.
Important note: We strongly recommend against modifying the default language parameter once you have created your first campaigns. You won't be able to edit or replicate your existing campaigns until you add a localized version of your message for the new default language. If you use the Push/In-App Campaigns APIs, ensure you provide a message in the new default language.
Required, iOS/Android only - Platform or framework used to develop your app. You can choose between iOS/Android (Native), Cordova, React Native, Unity or Adobe Air. Modifying that parameter will adjust the integration steps you can access by clicking the "Integrate" button, in the top right corner:
Your app or website icon. The icon is only used in the app list and in in the push preview. Batch gathers your website icon from your site metadata. On iOS and Android, Batch uses the app store URL you provided to gather the app icon from the store.
If you want to update your app icon, click the "Fetch icon from your application store/website" button and make sure you save the changes by clicking the "Update App" button.
This is not the icon used in your push notification. On iOS, the app icon is set in your project. On Android and for web push notifications, you will need to set it manually when integrating Batch (See more here: Android / Web).
Only users with the "Administrate" right can delete apps/websites. Batch will automatically disable all the running push/In-App campaigns. If you are using Batch APIs, any attempts to target the API key of the deleted app will be rejected.
Batch generates an SDK API key for every app and website added to your company. The SDK API key identifies your website or your app on a specific platform. For example, you will notice your iOS app, your Android app and your website don't have the same SDK API key.
The SDK API key has two purposes:
- Integration: The SDK API key authenticates the requests sent to Batch servers and allows Batch to attach the data to the right app or website.
- APIs: The SDK API key is the unique reference to your website or your app on a specific platform when you call Batch REST APIs.
Websites only have one SDK API key. You can set the "dev" parameter to
iOS and Android apps have two different SDK API Keys:
- Dev API key: Starts with "DEV". Use it for development or testing purposes. This API key won't trigger stats computation. Please take care not to ship an app to the store with that API key.
- Live API key: Should be used in a production environment only and in the final version of your app on the store.
Restricted to users with App or Administrate rights.
If your KPIs decrease abruptly after an app update, then you may have released a version of your app using the Dev API key instead of the Live API key. You can check the API attached to your install in the debug tool.
Users updating from a version including the Live API key will have their push token registered on both the live and development environment. As a consequence, they will receive push notifications twice.
Take the following steps as soon as possible to fix the issue:
- Invalidate the Dev API key: Send an email at firstname.lastname@example.org describing your issue. Our team will invalidate the DEV API Key after receiving validation from a user with the "Administrate" right.
- Release a new update: Make sure the new version includes the correct Live API Key.
If you need to manage sandbox and production environments separately, you can create separate apps on the dashboard and rename them accordingly (e.g. [DEV] MyApp, [PROD] MyApp, etc).
This is a good option to reduce the risk of using the Dev API key in production or sending a test push in production. This will also allow developers to use a Live API key in their development builds, simplifying their tests.
The REST API key authenticates the calls made to Batch APIs targeting your apps/websites API keys.
The REST API key is sensitive information as it allows you to send push notifications, display In-App messages, send data, and more from Batch APIs. Do not expose it to your users and avoid sharing it in your company. Batch only generates one valid REST API key per company.
If you suspect your REST API key is compromised, send an email to email@example.com describing the issue. Our team will invalidate the REST API key and generate a new one after receiving validation from a user with the "administrate" right.
Restricted to users with Administrate rights.
The Inbox secret key is the authentication key required to use the Inbox feature in your app.
Restricted to users with App or Administrate rights.
You will find here all the settings related to push notifications, from uploading your iOS certificate, editing your FCM IDs to editing the push delivery speed.
Restricted to users with App or Administrate rights.
On iOS, Batch servers need to have a valid certificate to communicate with Apple Push Notification Services (APNS). There are two types of files you can use:
- p8 files (recommended): Valid for all the apps added to your Apple developer account. You will need to specify the Application Identifier (App ID) or the Bundle ID of your app on Batch's dashboard.
- p12 certificates: Generated for a unique App ID and are only valid for one year.
If you are using a p8 file, here are the fields you will need to fill in:
- App ID / Bundle ID / Topic: We recommend you use the bundle ID you will find in Xcode. You can also use the app ID available from the Developer Console.
- Team ID: The team ID is also available from the Developer Console.
Make sure you send a test push to your device using the debug tool after editing any of these fields. This will avoid errors the next time you send a push campaign (e.g. revoked p8 file or "device not for topic" issues, due to a wrong bundle id).
If the development version of your app uses a different bundle ID than your production app, you will need to create two separate apps on the dashboard.
On Android, Batch needs a pair of IDs to send push notifications: the Sender ID and the Server API Key of your Firebase project. Both are available in your Firebase Console.
You can provide several pairs of Sender IDs/Sever keys for a single Android app. Batch will automatically use the appropriate Server key when sending notifications to a token.
This is useful if you have to switch to another Firebase project (e.g. lost Firebase credentials, etc) and want to keep sending push notifications to users who didn't update the app yet. You can also use that feature to avoid creating two separate apps if you don't use the same Firebase project in staging and production.
Click the "Change my GCM/FCM Settings" button and confirm. Then click the "Add another configuration" button to add a new pair or Sender ID/Server key.
Batch will use the "default credentials" to push new tokens. If that configuration doesn't work, Batch will try to use the additional server keys available in the list.
Recent Huawei devices now rely on Huawei Mobile Services (HMS) for push notifications, as an alternative to Firebase Cloud Messaging (FCM). A single Android build can implement both FCM and HMS. You will find more details on the HMS integration in the documentation.
Before sending your first push notification using HMS, you will need to add credentials on both Batch dashboard and Huawei AppGallery Connect.
This guide assumes that you've already got an Huawei account and created your AppGallery application
PushKit needs to be enabled on AppGallery for HMS Push to work. See Huawei's guide about enabling APIs and enable "Push Kit".
Batch needs a pair of IDs to send push notifications using HMS: the App ID and App Secret of your Huawei project.
Both are available on the Huawei Developer Console:
- Click "AppGallery Connect"
- Go to "My Projects" and pick the right project
- Go to "Project Settings" → "App Information"
Add these keys to the settings of your Android app on Batch dashboard. Click "Settings" → go to "Push Settings" → Then select "Huawei (HMS)" in the "Push Configurations" part.
Batch will automatically generate credentials for your app. You will need to add them to your project settings on AppGallery Connect:
- Callback address
- HTTPS Certificate
- Callback key
- Callback username
Here is how you can add these credentials to your project:
- Go to the Huawei Developer Console and click "AppGallery Connect".
- Select your project, click "Push Kit" in the left panel, then "Settings".
- Locate "Receipt status" and click "Enable"
- Use the credentials displayed on Batch dashboard to fill in the form and click the "Submit" button.
Each website has a pair of VAPID keys associated with it:
- A private key: Used by Batch servers to sign the authorization headers sent to the push service of each browser, when you want to send a notification to your opt-in users.
If needed, you can change the VAPID keys to match the one you were using with another provider.
The SDK Auth Key is a key generated by Batch for every website added to the dashboard, using the SDK API Key and the URL declared when you added your website. A new SDK Auth Key will be generated if you change the URL of your website in the dashboard settings.
Only used in HTTP / multidomain mode
Name of the subdomain Batch will use for your website.
Average number of sent push notifications per minute.
By default, Batch will send push notifications at the maximum delivery speed defined in your plan (see more here).
You can decrease/increase the delivery speed if needed. This will be applied to all the notifications sent to the users of your app/website.
You can set a global expiration delay or a Time To Live (TTL) in hours for all the notifications sent to your app/website users. The notification won't be displayed if the device doesn't receive it or doesn't come back online within this time.
By default, Batch sets a TTL of 14 days for all the notifications you send. If your user's device comes back online before being off for two weeks, it will display the last notification you sent to your user (iOS) or all the notifications sent over the previous two weeks (Android and web push). On iOS, APNS should only store for one month the notification waiting to be displayed.
Defines the priority of your notifications on iOS (APNS) and Android (FCM/GCM). The default value is high on iOS and Android.
On Android, you can use the high priority if you have a messaging/VoIP app and if you notice delivery issues due to native (Doze) or constructor related (Samsung Smart Manager, etc) energy-saving features.
High priority Android notifications can drain your user's battery faster since they wake up the device and open a network connection. Switch to Normal priority if your notification is not time-sensitive.
Defines how notifications are managed when an offline device goes online. If enabled, the device will only show the most recent notification. If disabled, it will show all the notifications received when the device was offline.
You should disable the collapse key if all your notifications matter (e.g. messages, etc). You can use up to three different collapse keys if you want users to get only one notification of each kind when coming online (e.g. marketing message, alert, etc).
This is the list of test IDs added by your team. You can easily rename, edit or delete them. Use the send a test button, next to the "edit" button, to check if that ID is still valid. You can add new test devices using the Debug tool.
To facilitate collaborative work, a user with "Administrate" rights can grant another user access to a group of selected apps. This is useful if you want to make sure specific users cannot access all the apps on the dashboard or if you have multiple projects with separate teams working on each one.
You can review the list of access and grant access permissions on the application level from the "Team" tab. You can also manage the list of users who can access your company's dashboard from the team manager.
The Custom Data tab shows the list of all the custom data collected once for your app/website from the SDK (attributes, tag collections, events) or from the Custom Data API (user attributes, user tag collections).
New custom data need to be manually enabled before being displayed in the userbase tab and used in a campaign. Before activating a new attribute, tag collection or event, make sure the name and the data type is correct.
You can add a custom name to any attributes or events. This is useful if you want to display simplified names in the interface instead of the technical name of the attributes/events:
You can also change the data type of an attribute (e.g. from string to date) if you already made that change in the code of your app or in your call to the Custom Dara API. Batch will adapt the operators displayed in the campaign editor to the new data type. If you changed the data type by mistake, Batch indicates with a * the data type detected for that attribute (e.g. "Integer*").
Use the "DEV/PROD" toggle to switch between the list of custom data attached to the Dev API Key or the Live API Key.
Important note: Attributes, tags and tag collections attached to the Dev API key cannot be used as targeting conditions in push or In-App campaigns created on the dashboard. This is why they cannot be enabled from the "Custom Data" tag.
Custom audiences allow you to upload static segments exported from your userbase (e.g. top 500 buyers, etc) or created by third-party tools.
You can retarget these custom audiences with a push or an In-App campaign from the dashboard.
You can easily create, edit and delete custom audiences from the "Audiences" tab.
The display name of your audience. Batch will only use it on the dashboard.
The audience name is the ID of your custom audience. You will need it to target that audience if you are using the Push/In-App Campaigns API.
If you are planning to use the same audience on another platform, you will need to upload it for the other apps and make sure you use the same "audience name". This will ensure campaigns targeting a specific audience can be replicated from an app to another (know more on campaign replication).
After uploading your audience, select the type of ID contained in your file:
- Custom User IDs: Select that option if your file contains the type of internal IDs you share with Batch (see more here: iOS/Android/Web).
- Advertising IDs: Choose that option if your file contains advertising IDs like IDFAs (iOS)/ GAID (Android).
- Installation IDs: Select that option if your file contains a list of an anonymous IDs generated by Batch the first time users open your app or your website (see more here: iOS/Android).
Your file must be a csv or txt file (50MB maximum) containing a list of IDs (one per line). Use the preview to make sure the audience only contains the ids you need, in the correct format. Also, make sure the file doesn't contain any extra columns or headers.
For each custom audience, Batch displays information such as:
- Display name: Name of the audience, only used in the dashboard.
- Name: This is the unique ID of your audience.
- Type: Type of ID used in the campaign (e.g. Advertising ID or custom user ID).
- Tokens / IDs: estimated number of tokens matching the IDs in the audience. Depending on the number of IDs included in your audience, the estimate may take several minutes to calculate the number of tokens matching your audience.
- Last update: Date of the last update.
Before creating your first In-App Campaign, you need to create a theme. Themes are templates you can use for your Mobile Landings or In-App Campaigns. You can choose between several formats.
Restricted to users with Privacy or Administrate rights.
Supported from Batch SDK 1.10.
Fullscreen In-App themes can contain text (header, title, body), an image, up to two buttons and a close button. Use the fullscreen format for all your important messages that deserve to interrupt the navigation.
Supported from Batch SDK 1.11.
Banners can be displayed on the top or the bottom of the screen. They can be attached to the borders to the device or not. Banners can contain text (title, body), up to two buttons, a close button and an auto-dismiss timer. Use banners to suggest optional actions and avoid bothering them when they are making important actions.
Supported from Batch SDK 1.14.
The modal format will always be displayed in the center of the screen. You can add an image, disable text fields, buttons and change their color. You can also set a 10 second timer to autodismiss the In-App message.
Supported from Batch SDK 1.14.
Displays a full screen image or a modal with a close button or an auto-close timer. Editing an image theme is straightforward: Choose the format Batch will use to display your image (fullscreen or modal), the background color displayed behind the image and turn on/off the autodismiss option for your theme.
Supported from Batch SDK 1.17.
The WebView format allows you to include a view based on custom HTML. All you need to define to edit a WebView theme is: the background color and opacity (visible during loading time and behind transparent images), and the color and background of the mandatory close button. Use it with your custom HTML design if other Batch formats don’t meet your needs.
Once you have picked a format, you can edit the layout and properties of your theme to adapt that format to your use case. Batch provides a simple interface to customise a new theme:
These are the basic properties of your theme:
- Code: ID of your theme. Use it in the payload of your call to the In-App or Push Campaigns API (in case you use a Mobile Landing) to use a specific theme.
- OS UI color: On iOS, determines whether the text of the statuts bar should be dark or light.
- Placement: Top or Botton. Allows you to choose whether you want to display your banner on top or at the bottom of the screen (banner format only).
- Attached: True or false. Determines whether the In-App message should be attached or not to the left and right borders of the screen (banner/modal formats only).
- CTA mode: Horizontal or Vertical. Determines whether the two buttons of your theme should be arranged horizontally or vertically (fullscreen, banner, modal formats only)
- Fullscreen: True or false. Determines whether the image should be displayed in fullscreen or detached from the screen borders (image format only)
- Background: Hex color code. Background color of the theme.
- Opacity: Percentage. Determines the opacity of the background of the theme. (WebView format only)
The fullscreen, modal and image formats enable you to add an image in your In-App message. You can adjust the way Batch will display your image:
- Cover: Batch will use the entire width of the screen to display the image. In portrait mode, depending on the screen size of the user device, the bottom and the top of the image will be cropped.
- Contain: Batch won't crop the image vertically. You will now have two empty spaces on the left and the right of your image. If you choose the cover mode, we recommend you use the same color for the background of your In-App message and the background of your image.
You can enable or disable blocks of centered text and change their color:
- Header (fullscreen format only)
You can add up to two buttons to your theme. For each button, you can modify the text and background color and the border-radius (in pixels, fullscreen format only).
- A close button, in the top right corner of your theme. (mandatory for the WebView format)
- An auto-dismiss option that will dismiss the In-App message after 10 seconds (banner, modal and image formats only)
- Or a CTA, triggering a dismiss action.
You can change the color and background of the close button. The auto-dismiss feature displays a gauge which shows the time remaining before the In-App message is dismissed.
Once you are done editing your theme, you can save it and send a preview to your device to see how it looks. Click the "preview" button in the top right corner. Before sending a preview to your device, you can use one of the example contents in the dropdown menu.
Themes are created at the company level:
- Attached themes: The upper part of this interface displays the available themes for the currently selected app.
- Available themes: The lower part shows the available themes for all your other apps. If you want to make one available for your currently selected app, just hover your mouse over it and click the "Attach" button.
Make sure the same themes are attached to the iOS and the Android version of your app to avoid campaign replication issues.
Batch provides simple debug tools that allow you to test your integration (⚙ Settings → Debug) and debug your calls to the Transactional API.
Batch provides a simple tool you can use to see the list of installs tied to a specific ID and the data Batch collected for each one of them. You can search installs based on:
- An advertising ID: IDFA (iOS) or GAID (Android). You can find your advertising ID by using The Identifiers on iOS or by going to your device settings → Google → Ads on Android.
- A Custom User ID: Your own user IDs shared with Batch (see more here: iOS/Android/Web).
- An Installation ID: ID generated by Batch for all the installs the first time your users open the app. You can get your installation ID in the log of your app or display it in your app for debug purposes (see more here: iOS/Android).
You can also see the data collected for random installs in your userbase:
For every install, the debug tool displays basic information on the left side:
- Basic information: Device type, last SDK start date, country, language, installation date, push optin status, app/OS/SDK version.
- API Key: API key tied to the install. This can be your live or your dev API key.
- Custom user ID: Custom User ID set for the install. The field will be empty if no custom user ID is set.
- Installation ID: ID generated by Batch for the install when user opened the app for the first time.
- Push Token: Push token attached to the install. The field will be empty if Batch hasn't received any token yet for the install or if the token has been invalidated (e.g. uninstall).
On the right side, you will find the list of all the data collected for a specific install:
- Native data: app version, bundle ID, carrier code, city code, device brand/type, installation date, last location, and more.
- Custom data: You will find here the list of all the attributes, tag collections and events received from the SDK or the Custom Data API. You search a specific value in the list if needed.
The dashboard will display the most recent install first. Simply click again the "Debug" or "Reload" button to refresh the list of installs and update the attributes/events list.
Batch enables you to send a test notification to all the installs attached to the ID you are debugging. Clik the "Send Test Push" button at the top of the installs list:
If you need to send push notifications to your device on a regular basis, then you should add your ID as a test device by clicking the "Save as a test device" button.
You can also see if a specific install is or has been in the user journey of a trigger campaign. Click the ⚡️ lightning icon in the top right corner of the debug tool. This will show the list of trigger campaigns that targeted your install at some point.
For every campaign, you can see when your install entered the user journey and when/why it exited that user journey:
- push_done: Batch sent a push to the install when the timer finished
- cancel_event: Your user triggered the cancellation event before the timer finished.
- stop: The trigger campaign has been stopped before the timer was finished.
- no_pushtoken: Batch tried to send a notification to the install, but it didn't have a token. This may happen if users didn't see the opt-in prompt yet or didn't turn off push notifications on iOS.
- pushtokennot_registered: The token attached to the install was not valid anymore when Batch tried to push it. This usually happens when users reinstall or uninstall the app.
- query_mismatch: The install was not matching anymore the targeting of the campaign when the timer finished.
There are several points you should check if you don't find any installs matching your advertising ID (IDFA/GAID):
- App restriction: Your app may not be able to collect advertising IDs. This happens frequently on iOS, especially if it doesn't displays ads.
- Device settings: Check your device settings to be sure you didn't turn on limited ad tracking in Settings → Privacy → Advertising.
- Batch integration: Make sure that the advertising id collection hasn't been disabled (more information here: iOS/Android).
Batch provides a simple debug tool that lets the list of all the targeted push tokens for any given API call to the Transactional API. Go to ⚙️ Settings → Debug, select "Transactional" and input the token generated by the API on each successful call:
The advanced analytics view gives you detailed information for a specific transactional push:
- Sent: The total amount of sent push notifications.
- Not Founf: Number of Custom User ID or installation ID are not linked to any push token.
- Undeliverable: Number of push tokens that were flagged as invalid by Apple/Google. Your app may have been uninstalled.
- Errors: Number of APNS/GCM/WNS errors (see more here: iOS/Android).
The Privacy center makes it easy to handle data access and data removal requests. Requests must be submitted for every app separately and must provide a valid data subject identifier (e.g. customer-level or device-level ID). You can also use Batch REST API to do the same thing (know more on the GDPR API):
The dashboard also shows the status of all your data access/removal requests:
You can filter these requests by origin (Dashboard or API):
Restricted to users with Privacy or Administrate rights.
As soon as the request is completed, users with the Privacy and Administrate rights will receive an email (e.g. "[BATCH] Your GDPR request [request token] has been processed") with a link to an archive containing all the data Batch has stored for the provided identifier (e.g. list of sent notifications, list of installs attached to the id along with the data collected for each install, etc).
That file can also be downloaded from the Privacy center:
All the data Batch has stored for the provided identifier will be deleted.
Important note: Batch will blacklist the ID for one month after the data removal. If you request a data removal for a specific ID and your user keeps or reinstall the app, Batch will not accept the data coming from that install. Batch will also discard the data sent from the Custom Data API for that specific ID.
Labels have two main purposes:
- Marketing pressure limit: You can set a specific marketing pressure limit on all the campaigns attached to the same label (e.g. no more than 1 push a week for all campaigns using the "onboarding campaigns" label). You will find more information here: frequency capping.
- Filtering: You can filter the list of your campaigns based on the labels attached to your campaigns (e.g. "onboarding campaigns"):
Restricted to users with App or Administrate rights.
You can create as many labels as you want. Every label you create has:
- A code: Unique id of a label. Use it as a reference in your calls to the Transactional, Push or In-App Campaigns API. Avoid editing label codes. By changing a label's code, you might trigger errors on your API calls if you don't update them with the new name. This may also reset the frequency capping limits on running campaigns already using this label.
- A name: Used to identify your label on the dashboard.
Important note: Keep in mind labels are created on the app level. If you are planning to use the same label across different platforms (iOS/Android/Web), make sure you use the same "Code". Otherwise, you will not be able to replicate a campaign with one or several labels to another app without these labels.
You can edit the code and the name of existing labels or delete them if needed. Batch shows the number of campaigns attached to each label so you can understand the impact of deleting or modifying one.
Batch's frequency capping allows you to limit the number of notifications a device can receive in a customisable time frame.
That marketing pressure limit is useful when you accidentally target the same users several times in a short period of time, encouraging them to disable notifications or uninstall your app. This can happen when you are sending many different types of push notifications:
- Alerts in real-time with the Transactional API (e.g. order confirmed, delayed flight, friend request, etc).
- Recurring push notifications to automatically onboard newcomers or retain existing users.
- And one-time campaigns to let your users know about new content, sales, and more.
You can adjust the frequency capping for your app in two different ways.
Frequency capping is available on the Enterprise plan and, as an option, on other paid plans. That feature works on iOS and Android and is restricted to users with App or Administrate rights.
You can either define a simple limit that will be applied to all the notifications you send or fine-tune your global frequency capping:
- All push notifications: The capping rules will affect all your push notifications.
- Campaigns: The capping rules will only affect notifications coming from campaigns created on the dashboard or with the Campaigns API.
- Transactional: The capping rules will only affect real-time notifications sent with the Transactional API.
All these rules can work together. For example, you can set a global capping of 5 push notifications per day and create two additional rules that will ensure users won't receive more than 1 transactional push every 2 hours and 1 push from a marketing campaign per week.
If you are looking for a more granular way of capping the number of push notifications a single device can receive, you can set a label-based frequency capping.
You can create a frequency capping for all the notifications attached to a specific label. This will work for notifications sent from the dashboard or Batch's APIs:
Please note all rules are dynamic. Batch will check the number of notifications that have been sent in the last X hours/days to see if the notification has to be sent or not.
Important note: Batch uses the number of push notifications already sent to an install to determine whether the push should be sent or not. The number of push notifications sent to a specific install is counted in near-real-time. Campaigns sent very closely or at the same time may not be taken into account by the global capping feature.
For all your push campaigns, Batch will display the number of notifications that were not delivered because users already reached the limit defined in your dashboard settings: