Trigger Automations

Batch Automation Builder is an interface where you can create multi-step and multi-channel Trigger Automations. Thanks to different branching and targeting options you can create advanced scenarios in order to deliver personalised customer experiences.

Entering and exiting the scenario

The Automation Builder enables you to create event-based scenarios. Begin by specifying your trigger event, the one that initiates the user's journey.

Note this behavior: Before a first attempt to send a message to the user, new similar events received will make the user restart the automation. After a first attempt to send a message within the automation, new similar events received while the user is waiting in the Automation will not restart the automation, and as such the user will continue their progress in the flow. If you want the user to enter a new instance of the Automation each time they fires the trigger event, check "Parallel Automations" section below.

To further refine user entry, you can:

• Use event filters. This feature allows you to filter the entry event based on event attributes.
  • Ex: in a retail scenario, upon an 'add to cart' event, you can ensure that only customers with a product of a specific value and/or belonging to a particular product category will enter the sequence.
• Define your targeting. Use the query builder to specify which users you want to target by selecting targeting conditions amongst all events, attributes, segments and audiences at your disposal.
  • Targeting is checked at the entry of the Automation and after each delay step.
• Specify a Capping at the Automation level. The capping is the maximum number of times a user can enter the automation. We count an entrance when at least one message has been sent to the user.
  • Ex: If the capping is 1 and the user first enters the Automation but ends up being excluded from it by an exit event before being addressed by a message, it will not count in the capping and the user will be able to re-enter the Automation.
• Specify a Grace Period at the Automation level. The grace period is the minimum time between a user exiting the Automation and re-entering it. The grace period is counted from the moment a user reaches a final state in an automation (user finishes the automation, is excluded from it by an exit event etc.). Just like Capping, if an Automation has never attempted to send a message to a user, we do not apply the grace period.
  • Ex: If a user reaches a final state of an automation that never tried to send them a message, he can re-enter this same automation immediately.
• Specify the type of communication, Marketing or Transactional, you want to send with the scenario. If you select “Marketing”, in step of the Automation which is an Email or SMS message, only the users subscribed to the given channel’s marketing communications will be targeted. If you select Transactional, users will be targeted whether or not they have subscribed to the given channel. Please note that marketing vs transactional does not apply to push communications.
  • The marketing/transactional block is only evaluated when an SMS or Email message is sent, so there is no blocking to enter Trigger Automation (users who are opt-out to SMS and Email communications will be able to enter the Automation but will not be able to receive SMS or Email messages).
• Enable Parallel Automations. When this option is activated, the user can trigger and advance through the same Automation several times in parallel. The Automation is triggered each time the user fires the trigger event with a new event parameter. The event parameter can be an attribute attached to the event or the event label but can only be a String.
  • Ex: Trigger a series of messages each time a user adds a product to his cart, based on the product category.
    • When Parallel Automations option is enabled, any external event later used in the scenario will be automatically checked to see if they carry the same discriminating attribute as the one specified on the entry event so it is not necessary to do it manually.

For example: you create a scenario on an add_purchase event and enable parallel automations with an id associated with each add_purchase event as the discriminant attribute. If you add cancellation events to your scenario, Batch will automatically check that the cancellation events triggered by the user carry the same id as the one that the event that prompted entry into the Automation.

• Specify a start date. Any event triggered before the start date will not trigger the Automation.
• Specify an end date. When the end date is reached, the automation essentially goes to sleep, stopping any further progress and preventing any more messages from being sent.

Regarding exiting from an Automation, users can exit for 3 reasons:

• The user triggered an exit event. The user was in a walt until step and they triggered an exit event within the allotted time. When a user triggers an exit event, they are excluded from the Automation, and thus will not continue their journey.
• The user arrived at the end of the Automation. The user just finished their journey and arrives at the final step of the Automation.
• The user no longer complies with the targeting conditions. Each time the user moves from a delay step to another step, we re-check whether they still comply with the targeting conditions. If this is no longer the case, the user is excluded from the Automation.

Behaviour when relaunching an Automation or postponing the end date:

• If you stop an Automation and restart it, it's treated as if the Automation had just been created. Everyone has to go through the entry event. If a user was already part-through the scenario before the Automation was stopped, they are removed from their state and they must once again wait for the entry event.
• Once the end date has been reached, any events that could have moved the user forward in the Automation are ignored. If you update the Automation end date to a later date:
  • If there are less than 90 days between the initial end date and the date on which the new end date was set, then we listen to the events again and the users who were in the Automation retain their previous state (their place in the scenario).
  • If there are more than 90 days between the initial end date and the date on which the new end date was set, then the events are listened to again, but all users are evicted from the automation and must once more go through the entry event.

Why 90 days? Because as soon as there is no more change of state in the scenario, the user’s state in the scenario is kept for 90 days. After 90 days, it automatically exists.

Adding steps to the scenario

To build your scenario, the Automation builder offers 3 main step types:

• Message steps: you can create SMS, Email and Push messages and place them wherever you want in the scenario. On each message step you have the same composition interface as for Campaigns and Recurrings, complete with the same capabilities.
  • On the push channel you will be able to target either iOS and/or Android and/or Web devices.
• Branching steps: you can split your audience into different branches thanks to 2 main branching options. You can even nest multiple decision branches as desired.
  • Yes/No Splits: your audience is split into 2 groups depending on whether they match or not the targeting condition(s) you specified in the split.
  • Random Splits: your audience can be split into up to 4 algorithm-based random groups. Please note that if a specific user enters the Automation several times, they will not go into the same branch each time.
    • This feature is useful to run AB tests on the entire scenario, on a specific branch or message.
  • Delay steps: The “Delay” step in the Automation Builder contains 3 different options.
    • The “Wait for” option makes it possible to set waiting times from 1 minute to 30 days between the various steps of the scenario. The starting point is the triggering of the input event.
      • You can chain several “Wait for” steps if you want the user to wait more than 30 days between 2 messages steps.
    • The “Wait until” option which makes it possible to define the time and, optionally, the weekday at which users will proceed to the next step.
      • Ex: If a user enters an automation at 11 a.m. with the first message step set to wait until 10 a.m., they will receive the message at 10 a.m. the following day.
    • The “Wait until date attribute” option which makes it possible to wait until a specific time before or after the date of a date attribute associated with the trigger event.
      • Ex: If your event is add_to_cart and you have associated it with the date when the sales end, you can wait 1 day before the sales end to send your next message.
    • For each of these delay options, exit events can be set. If one of these events is triggered by a user during the wait time, they will exit the automation.

To be noted that the maximum number of message steps you can have in the same Automation is 20.

Handling the marketing pressure of the Automation

To make sure each user entering the Automation receives an appropriate amount of messaging and receives messages at the right time you can:

• Leverage automation level capping already described above.
• Leverage label capping: This capping applies to all types of orchestrations (Campaigns, Recurrings and Trigger Automations). You can add up to 5 labels to your scenario. In the Automation Builder, after a message has been skipped (not sent) due to a capping rule, the user will not exit the automation flow, and instead continue to the next step.
• Specify a quiet time: At the entry point of your scenario, the Quiet Time feature allows you to specify a time slot or days during which your audience won’t be messaged.
  • By enabling Daily Quiet hours, you define a time slot during which users will not receive messages.
  • By enabling Weekly Quiet Days, you define one or several days during which profiles will not receive 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).
  • When you activate Quiet hours / Quiet days, you need to define what is the required behaviour for the messages that should have been sent during the Quiet time:
    • Send at the next available time (ex: an SMS message should have been sent on Sunday, which is a Quiet day. It will instead be sent in the first hour of the open message slot on Monday and, only after that, the user will continue their journey).
    • Skip the message step and continue (ex: an SMS message should have been sent on Sunday, which is a Quiet day, it will not be sent and the user continues their journey directly).
  • When Quiet Times (Quiet hours/Quiet days) are enabled, they are applied by default to all automation messages. However, it is possible to deactivate Quiet time from the Advanced Settings of each Automation message. Note that: The Quiet times (Quiet hours/Quiet days) are based on the user's local time. If no local time can be found, the Quiet times will be based on the UTC Timezone.

Analysing Automation with Analytics

In the Automation, you have 2 views:

• The “Builder” view: the one on which you land by default, allowing you to create, update and review your scenario.
• The “Analytics” view: the one on which you can check how your Automation is performing, from an engagement and delivery perspective.

i: You can access the Analytics view of your Trigger Automations directly from the Automations listing on the three dots kebab menu.

The Analytics view has up to 4 sections, depending on how many different channels and steps are used within the Automation:

• The “Step by step” section: a table that sets out the key engagement data for each of the messages in your scenario, no matter the channel.
  • This section is displayed when there is more than one step in the Automation.
• The “Email” section: gathers all the data of your email channel in the Automation, in other words the data of all your email messages. This section is similar to the Analytics available on Email Campaigns and Recurring Emails.
  • This section is displayed when there is at least one email message step in the Automation.
• The “Push” section: same as for email.
• The “SMS” section: same as for email.

Note that what is explaind on this page is focused on how Trigger Automations works for email, SMS and Push v2 channels. For Push v1, the experience is slighly different, with a form based interface, allowing you to create single push message sendings based on events received, by Platform (iOS, Android, Web).