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 or dynamic value calculated from an event attribute. In addition, advanced features like engage time optimization and dayparting can introduce 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, 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 are met. If the hold criteria are 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 of 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 particular time before or after an event occurs.
• Conditional hold: This holds the user at the trigger until specific 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 the message is sent no later than 'X' hours after the user is eligible.
• Dayparting: Select the days of the week and the hours when the message will be delivered.

The types of delays you can use depend on the kind of campaign.

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

Fixed time delays

A fixed time delay 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 only sends a message using the specified template if the conditions are met.

Attribute-based delays

An attribute-based delay makes the trigger wait for a specific time before or after an event.

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 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 specific criteria are met within a certain period of time. Fixed and attributed-based delays end when the time criteria are met. Holds end when the hold criteria are met. If the hold criteria are not met during the time specified, the user will exit the journey.

Use case

• Just like delays, conditional holds can impact the left-to-right prioritization of triggers if not used uniformly across all triggers at the same level.
• Example: There are two sibling triggers on the same level - trigger 1 (left) with a conditional hold for 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 assessed for trigger 2. 
• 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 of the week and times during the day to deliver your message. To learn about these advanced delay settings, refer to the optimization section.