Trigger Delays

A Delay is the amount of time that must pass before a user can get messaged by a trigger. It can be a fixed value or it can be a dynamic value calculated from an event attribute. In addition, advanced features like engage time optimization and dayparting can introduce their own delays.

You can use delays in triggers of a campaign to send messages to a user after a certain amount of time has passed. For example, if a user purchases something from your store, you can specify a delay of two days after the purchase to send them a message that contains recommendations on what they can buy next.

Consider the following points about trigger delays:

When you use delays in triggers, trigger ordering becomes more complex and the ordering is not always left to right.
When a trigger has a delay included, the user is evaluated for the trigger only after the delay is completed.
In a campaign journey, subsequent trigger delays are based on previous messages and not when the event/user entered the segment or campaign.
For a conditional hold, the user is evaluated immediately based on the filter criteria, but the action is taken only when the hold criteria is met. If the hold criteria is not met during the time specified, the user exits the journey.
To filter users (split a journey) before applying a delay, use the Decision Split trigger followed by a Delay trigger.
Blueshift supports delays up to 1 year. Setting delays longer than a year might not work as required.

Best Practice

It’s always a good practice to use the same delay for all sibling triggers for predictable trigger prioritization (i.e. left to right).
You can also use a decision split to filter the audience. Using a decision split ensures that all branches are evaluated left to right.

Delay Types

You can set delays from the Delay tab for a trigger. The following types of delays are available for you to use in campaigns:

Fixed time: Wait for a specific time duration.
Attribute based: Wait for a specific time before or after an event occurs.
Conditional Hold: This holds the user at the trigger until certain criteria are met within a certain period of time.
Optimization: Send a message when a user is most likely to engage with it based on their past behavior. You can also set it so that the message is sent no later than X hours after the user is eligible.
Dayparting: Select the days of the week and the hours of the day with the message will be delivered.

The types of delays available for you to use depends on the type of campaign.

	One time	Recurring	Segment triggered	Event triggered
Fixed time		x	x	x
Attribute based				x (Not available for API triggered campaigns)
Conditional hold				x (Where the triggering event is part of a transaction.)
Send time optimization	x	x	x	x
Dayparting	x	x	x	x

Fixed time delays

A fixed time delay is one that makes a trigger wait for a fixed duration of time.

When you create or edit a trigger, you can specify how long you want the trigger to wait (in seconds, minutes, hours, days, or weeks) from the last message (or from the beginning of the journey, if it is the first trigger in the journey) in the When section.

After the specified period of time has passed, the campaign checks the Filter criteria specified in the Filter tab. It sends a message using the specified template only if the conditions are met.

Availability: Fixed time delays are available for all types of campaigns except for 'one-time sends'.

Attribute based delays

An attribute based delay is one that makes the trigger wait for a specific time before or after an event occurs.

When you create or edit a trigger, you can specify the timestamp attribute and the time offset in seconds, minutes, hours, days, or weeks, before or after this timestamp. The trigger execution logic will wait for the specified time and then check the criteria specified.

For event timestamp based delays, the time is specified with respect to a timestamp in the triggering event data.
For transaction timestamp based delays, the time is specified with respect to a timestamp in the transaction data.

Availability:

Event and Transaction timestamp based delays are available only for event triggered campaigns.
For Transaction based delays, the triggering event must be linked to a transaction.
The Blueshift platform must have received at least one event for the system to recognize timestamp attributes in the event.

Conditional Hold delays for transactions

A conditional hold based delay is one that makes the trigger wait for a specific time based on the transaction type. This delay is available only where the triggering event is part of a transaction.

This holds the user at the trigger until certain criteria are met within a certain period of time. Fixed and attributed based delays end when the time criteria is met. Holds end when the hold criteria is met. If the hold criteria is not met during the time specified, the user will exit the journey.

Use case

Conditional holds, just like delays, can impact the left-to-right prioritization of triggers if not used uniformly across all triggers at the same level
Example: There are 2 sibling triggers on the same level - trigger 1 (left) with a conditional hold up to 3 hours and trigger 2 (right) without a conditional hold. A user will first be evaluated for trigger 1. If they do not meet the conditional hold criteria, they will be evaluated for trigger 2.
And this evaluation will continue until the user meets the criteria for either trigger or exceeds the conditional hold duration for trigger 1. Hence it is possible that a user gets messaged by trigger 2 even before they meet the conditional hold criteria of trigger 1 as this screenshot illustrates:

Advanced Delay Settings

Engage Time Optimization: You can optimize the delivery of the message to a time when the user is most likely to engage with it.

Dayparting: You can choose the specific days in the week and times during the day to deliver your message. To learn about these advanced delay settings, refer to the optimization section.