In-App Automations
In-App messages are messages displayed inside your app. You can trigger them when users open your app or perform a specific action (e.g. tapping a button, browsing a page, etc). They can be managed from the “Automations” tab of your dashboard.
Synchronization workflow
When the app is launched, the SDK automatically retrieves from Batch's servers the list of automations available at that moment.
This implies that every events and attribute that have been collected during the current session won't be taken into account for the targeting of an In-App automation until the next session.
For instance, if you set the targeting to a count of events, then the user's own count has to match the targeting criteria at the app launch rather than during the session in order to display the In-App automation.
Please note the following:
If the user has a limited network connection, the synchronization may be delayed. After a certain time, the SDK will stop the synchronization and will not display any more message to avoid impacting the user experience.
During the user’s very first session it is not possible to display an in-app message within the session.
Creating an In-App Automation
The first thing you need to do to save your In-App automation is to name it. You can also attach 1 to 5 labels to it, which allows you to define a label capping in the settings. Note that any changes to your labels and label capping can take up to 20 minutes to be effective. See the documentation on labels for more information.
Choosing the right trigger
You have several settings available to define when your in-app message will be displayed to your users.
First, you can choose 1 to 10 events to trigger its display. As soon as one of your users triggers any of these events, it will initiate the in-app's display (provided they meet other targeting criteria and conditions).
Custom trigger events must be events triggered by your users on their iOS or Android applications, which are sent via our SDK following the tagging plan established with our teams. It's not possible to trigger an in-app message based on an event triggered by API.
You can also trigger your In-app with the native event
New sessionso the message will appear on the next launch of your user’s app or when the user returns to the foreground after being in the background for at least 5 minutes.When a user matching the set targeting opens the app and therefore starts a new session, Batch’s SDK will retrieve all the information related to the automation. It will then trigger the automation as soon as the synchronization is finished.
You can then filter these events based on their string or label attributes (one filter at a time).
For example, if you want to specify multiple pages where the in-app message can be displayed, and the page name is an event attribute, you simply need to call the trigger event multiple times with a different filter each time.
You can also specify a delay between the event trigger and the in-app display. This delay can be up to 60 seconds and allows you to make your in-app messages less intrusive for your users.
If the application is in the background when the timer ends, the message will not be displayed. It will be shown the next time the event is re-triggered.
Finally, you can also refine your display by setting a capping and grace period:
The capping allows you to limit the maximum number of times an In-App automation will be displayed to a user. This is useful to avoid overwhelming your users with the same message.
If you have already had deliveries for your in-app message and you apply capping later, previous deliveries will be taken into account. For example, if I have an in-app message that has been running for two weeks and I add a capping of 1, any profiles that have already displayed the in-app message at least once since it was published will not see it again.
The grace period allows you to set a delay between each display of the same In-App message. This feature is quite handy to avoid your user to see the same message multiple times in a single session.
Just like with Capping, previous sends are taken into account when you apply a Grace Period after the fact. For example, if an in-app message was shown to a profile 30 minutes ago and I apply a Grace Period of 1 hour, that profile will not be able to trigger the in-app message again for another 30 minutes.
Defining your targeting
Check this documentation to know more about targeting.
For in-app automations, targeting is checked after each trigger event occurs to ensure profiles still comply with the criteria before displaying the message.
Under your Targeting you can check your In-app estimated reach, that is to say the number of profiles with installs with SDK version 3.1 and higher that match your targeting. The estimate gives a breakdown by device type (iOS and Android, excluding web).
Defining your timing
This section lets you program your In-App automation. You can schedule the start and the end date of your automation based on Universal time or Profile’s local time.
You have more control over your timing thanks to the Quiet Times block: this feature allows you to specify a time slot or days during which your Profiles won’t be displayed messages.
By enabling Quiet hours, you define a time slot during which profiles will not be displayed messages.
By enabling Weekly Quiet Days, you define one or several days during which profiles will not be displayed messages.
You can enable Quiet hours on its own but Quiet days can only be enabled when Quiet hours is also activated (to make sure we will not send messages at midnight + 1 minute on the following day).
Note that: The Quiet times (Quiet hours/Quiet days) are based on device's local time.
Even if a user bypasses Quiet Hours by changing the date on their device, our backend will still prevent the message from being displayed. This is because the time is also verified server-side.
Composing your message
Check this documentation to know more about our In-App Composer and Settings.
Note that In-App messages support multi-language and A/B testing, mirroring the capabilities available for Mobile Landings.
Managing an In-App Automation
Modifying an In-App Automation
Batch doesn't send live updates to your app when you save changes for an In-App automation. These changes will be detected the next time your users open the app or returns to the foreground after being in the background for a few minutes.
During that session, the SDK will sync again with Batch servers. The SDK may still display an outdated version of your campaign or an In-App automation recently disabled. All the changes received from Batch servers will be applied in the next session. This is why we recommend you include an end date in your automations or double-check the wording of your automation before activating it:
Stopping an In-App Automation
In-App automations cannot be disabled immediately. When you stop an In-App automation on Batch dashboard, Batch stops serving it to new profiles and sets its status to "disabled", but users may still be able to display it if they already synced it before.
This happens because the SDK must sync with Batch servers at least once to be aware of the new status of preloaded In-App Automations. The SDK syncs with Batch servers when users open the app.
As a result, users who synced the Automation before you stopped it on Batch dashboard will display it one last time. All the changes received from Batch servers will be applied in the next session. This is why we recommend you include an end date in your automation or double-check the wording of your automation before activating it.
Last updated