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. For instance, in SMS triggers, you can also apply Quiet Hours instead of Dayparting. Quiet hours restrict message sending during a configured time window, based on the customer's or account's time zone. If applied, dayparting settings are disabled for the quiet hour window. For setup instructions, refer to the quiet hour settings in your account configuration.

	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 (and Quiet Hours for SMS only)	✓	✓	✓	✓

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

Use Engage Time Optimization (ETO) to send messages when a user is most likely to engage based on past behavior. This improves open and click rates by aligning message timing with individual habits. Click here for more information.

Dayparting

With Dayparting, you can choose specific days of the week and time ranges during which a message can be sent. Use this to avoid sending messages at odd hours and maintain compliance with sending norms. Refer to this help document for further details.

SMS quiet hours

For SMS triggers, you can apply Quiet Hours to control when messages are sent. In the Delay tab of the trigger, you’ll see the option to either apply Quiet Hours or Dayparting. If quiet hours are set on your account, it will be selected by default.

Quiet hours prevent messages from being sent during specific time windows configured at the account level. These settings can be based on the customer’s time zone (if available) or the account time zone. To configure these preferences, see the Quiet Hour settings.

If the message falls within quiet hours, you can choose how to handle it:

• Queue message (default option): Wait and send it after quiet hours end.
• Skip message: Don’t send the message at all.

Note: When this feature is enabled, all existing SMS triggers will have quiet hours disabled by default. All new SMS triggers will have quiet hours applied by default, but you can disable them during trigger setup, as shown in the tip above.