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.

In a campaign journey, subsequent trigger delays are based on previous messages and not when the event/user entered the segment or campaign.

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
Dayparting	x	x	x	x

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.

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).

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.