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.

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.

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.

Eligible Trigger Ordering

In a simple setup where eligible triggers have no delay, dayparting or other advanced features, the triggers get evaluated for a user from left to right (higher priority to lower priority).

Trigger ordering is more complicated when triggers have delays because a lower priority trigger can have a calculated send time that comes before a higher priority one. As a result, the ordering is not always left to right. When there are delays involved, the following happens at each step:

• The campaign calculates the send time for eligible triggers. It groups the triggers into those that can be sent now and those that can be sent later.
• For the triggers that can be sent now, it evaluates those left to right for the user.
• If none of the triggers eligible for messaging now match, the campaign calculates the minimum amount of time before the next set of eligible triggers can be sent. It waits this amount of time and starts this process again. It also remembers which triggers it has already evaluated and does not evaluate them again.

Example 1:

Consider the following example with two email triggers.

• The user qualifies for Trigger A and an email is sent to the user.
• Trigger B has a delay of 2 hours. The user is evaluated for Trigger B only after the delay of 2 hours is completed. If after 2 hours the user qualifies for Trigger B, an email is sent to the user.

Example 2:

Consider the following example where Trigger A and Trigger B are siblings and Trigger C and Trigger D are siblings.

• Trigger A and Trigger B do not have any delays and hence the triggers get evaluated for a user from left to right. 
• Trigger C has a delay of 4 hours and Trigger D has a delay of 2 hours. Hence the minimum amount of time before the next set of eligible triggers can be sent is 2 hours.
• After 2 hours, although Trigger C is on the left and we would evaluate Trigger C before Trigger D, given that Trigger D has a shorter delay, the user is evaluated for Trigger D before Trigger C. If the user qualifies for Trigger D, Trigger C is skipped.