Delayed Campaign Triggers

📘 What Are Delayed Triggers?

Delayed Triggers give you control over when leads are delivered. Instead of firing actions immediately when a lead is received, delayed triggers let you schedule delivery hours, days, or even weeks later, based on customizable timing rules.

This is useful for:

• Delaying lead delivery to match buyer schedules and business hours
• Spreading delivery throughout the day to mimic natural lead flow like real traffic
• Delaying lead delivery to meet contractual or timing requirements

With powerful settings like Minimum Delay, Next Business Day windows, blocked dates, and custom delivery strategies, you can build flexible intelligent schedules that match how your buyers actually want to receive leads without requiring custom code.

⚙️ Core Concepts: Understanding Each Setting

🧭 Delay Type

Controls when the countdown starts and how the delivery date is calculated. Each delay type affects timing in a different way:

Minimum Delay

• Enforces a strict wait time before a lead becomes eligible for delivery. The delay starts from the exact time the lead is received.
• A lead received at 2:00 PM with a 1-day delay will not be eligible for delivery before 2:00 PM the next day. Once the delay period ends, the lead is sent in the next valid delivery interval. If the delay ends outside the interval, the lead will wait until the next allowed window.
• Used when: You want to guarantee that every lead waits a specific amount of time before delivery - regardless of time of day or delivery windows

Next Business Day

• A lead received at any time today (even within the delivery window) will not be sent today. Instead, it is held for the next valid delivery day, based on your configured interval (e.g. Tue/Thu only) and any blocked dates (e.g. holidays).
• This is not the same as “next available interval from now” - it strictly looks for the next valid calendar day with an open window.
• Used when: You want to align delivery with the next business day window, not necessarily a fixed delay.

Next Available Interval

• It doesn’t wait a full day or fixed time. It just finds the next valid interval and schedules delivery there.

• If a lead is received before the start of today’s interval, it will be delivered in today’s interval.

  If a lead is received after today’s interval has started (and cannot be scheduled in time), it will be pushed to the next available future interval.

• This logic ensures delivery happens as soon as possible, but always within a valid interval - no fixed delay is enforced.
• Example: if a lead is received at 4:30 PM and your next interval starts at 6 PM, it will be sent in that 6 PM slot.
• Used when: You want delivery to happen soon, but only inside controlled windows.

⌛ Delay Period

How long to delay the lead before it can be delivered.

• Not configurable for "Next Available Interval" type
• Can be defined in days. Minimum is 1 day and maximum is 90.
• This is the core “wait time” before the system even tries to deliver

🎯 Delivery Strategy

Controls how leads are distributed during the delivery interval. This impacts pacing.

Organic

• Most natural pacing.
• Only available with Minimum Delay.
• Example: If a lead is received at 11:23:45 AM with a 1-day delay, it will become eligible for delivery around 11:23:45 AM the next day.

ASAP

• Best for: Cases where leads accumulate overnight and need to be delivered early the next day.
• Warning: This can create a burst of delivery at once, which may overwhelm the buyer’s system.
• Use only with buyers that have proven, reliable systems capable of handling large volumes quickly
• Pro tip: Define a long enough delivery interval to give the system enough time to process all leads - especially if a buyer’s system is slow or under load. This is particularly important after weekends or holidays, when queue volume may be higher.

Spread

• Leads are distributed at randomized times throughout the entire delivery interval.
• The system aims for an even overall distribution, but does not deliver at fixed intervals.
• Example: If you have a 1-hour interval and 240 leads, the system will send about 4 leads per minute on average, but not exactly one every 15 seconds.
• Some minutes might send more, some less - the pacing is intentionally irregular to mimic human traffic.
• Helps avoid overloading systems or looking like automation

🕒 Delivery Interval

Defines when delivery is allowed, also known as the "windows" or "time slots" during which leads can actually be sent.

• You can configure intervals per day of the week
• If a lead is scheduled to send outside the interval, it will wait for the next valid matching window

🚫 Blocked Dates

Days when no delivery is allowed — leads will be delayed until after these dates.

• Great for holidays, weekends
• Leads will automatically shift to the next valid interval

⚠️ Important Notes & Limitations

📌 Trigger Conditions Must Align With Your Interval

Your trigger decides which leads enter the queue. Your interval defines when leads are allowed to be delivered.

It’s critical to configure your trigger conditions (such as lead status, supplier, buyer, or time of day) so that the trigger executes only for the leads you intend to delay and deliver.

A mismatch between trigger conditions and delivery interval can cause unexpected behavior - such as delivering all leads, including ones that should have gone out in real-time, or retrying too many failed leads at once.

Example Use Case: Retrying Failed Leads the Next Day

You want to automatically retry leads that failed delivery (Lead Status = Error ) during business hours the next day.

Recommended Configuration:

• Trigger condition: Lead Status = Error - Not sold
• Delay Type: Next Business Day or Minimum Delay (e.g. 1 day)
• Delivery Strategy: Spread
• Interval: 10:00 AM - 4:00 PM

This ensures failed leads are retried gradually during a predictable business window the following day - not all at once

Example Use Case: Delaying Off-Hours Leads

To capture leads received outside working hours and delay them until the next day’s business window:

• Trigger condition: Lead Time is between 5 PM and 9 AM
• Delivery Interval: 9:00 AM - 5:00 PM
• Delay Type: Next Business Day
• Strategy: Spread

Optional: Add a time-based campaign-level filter (e.g. only allow deliveries from 9 AM to 5 PM) to add an extra layer of protection — especially useful if other triggers exist.

Without a strict time-based filter, you'll need to ensure the trigger conditions explicitly exclude in-hours leads, or you may unintentionally delay and resend leads that were already delivered

📌 System-Wide Domain Throttling

To protect both our platform and your buyers, we enforce global domain throttling limits at the system level. These limits control the rate at which leads can be delivered to the same domain.

You cannot configure this yourself — it's applied automatically in the background to prevent overloads.

Why It Matters:

• Prevents burst traffic from overwhelming buyer servers
• Reduces risk of delivery rejections, timeouts, blacklisting or rate limiting
• Helps maintain system stability during high-volume delivery intervals (e.g. Monday morning ASAP bursts)

How It Works:

• The system enforces a maximum number of concurrent open connections per domain. Depending on the service, known buyers might have higher limits
• This applies across all campaigns, all triggers, and all delivery strategies
• Affects mostly ASAP strategy, but at peak times (ie Mon 9AM) Spread strategy might also be affected. This is not a problem - it just means delivery may take a few extra minutes.

This protects your buyers and ensures safe, reliable delivery - even during burst scenarios like Monday morning queues.

📌 Creating a New Action Does Not Affect Queued Leads

When you add a new action (e.g. an HTTP post or email) to an existing delayed trigger, it will only apply to leads added to the queue after the action was created. This could change in a future release.

📌 Delayed Triggers Cannot Be Converted to Real-Time

Once a trigger is created with a delay, it is permanently considered a delayed trigger. You cannot convert it into a real-time trigger later.

If you need real-time behavior, create a separate real-time trigger.

📌 Updating an Action

When you edit an existing action (like changing an HTTP body or email content), the system must reprocess the payloads for all leads currently in the queue.

While the system regenerates HTTP or email payloads accordingly, you can't edit other actions, but you can change the trigger settings.

📌 Updating Delay Configuration

Changing a trigger’s delay settings (like Delay Type or Delay Duration) can have major effects on the existing queue. This operation is heavy and can require some time to complete. When you update a delay configuration, the system:

• Locks the trigger from further changes
• Recalculates delivery times for all queued leads
• May expire leads from the queue that no longer fit the new logic

Examples

• If you change the delay from 30 days → 7 days, all leads that have been in the queue for more than 7 days will be expired immediately, because they no longer qualify under the new delay rule.
• If you change the Delay Type to Next Available Interval, some leads in the queue may be expired, depending on your configuration and the time of day the change is saved. Leads that no longer qualify under the new interval logic will be expired automatically..

📌 Lead Expiration Rules

Leads in the queue do not live forever. Each lead is assigned a specific delivery window based on your delay type and strategy. If that window passes and the system can’t deliver the lead, it expires silently and will not be retried. A lead may expire in any of the following situations:

1. Queue remains paused past the scheduled window
   1. If the queue is paused and not resumed in time, leads will expire at the end of their scheduled delivery window
2. System delay or bottleneck
   1. Global domain throttling can slow things down if there’s too much volume. Under normal conditions, this isn’t an issue
   2. Under exceptional circumstances, if the system is overloaded, some leads might not be tried before the allocated interval ends
   3. This is uncommon, but possible with tight intervals or massive lead volume
3. Buyer endpoint failures
   1. If the buyer is extremely slow to respond, the lead queue might be affected

In general, ASAP or Spread Strategy leads will expire at the end of the last delivery interval of that day, while Organic expires 4 hours after the original scheduled time.

This is why it’s crucial to:

• Pause/resume queue carefully
• Avoid tight intervals with fragile buyer setups
• Use strategies like Spread for better pacing

📌 Pausing Triggers and Pausing the Queue

Pause Trigger - temporarily stops the trigger from queuing new leads.

• No new leads will be evaluated or added to the queue
• Existing leads in the queue remain untouched, and continue to be sent
• On resume, only new leads will be queued

This is useful when you want to temporarily disable the entire logic for a campaign or workflow, without affecting what's already scheduled.

Pause Queue - pauses delivery, but only at the queue level. New leads are still added to the queue, but nothing is delivered.

• Both new and existing leads remain in the queue and will wait.
• If the queue stays paused past the lead’s scheduled interval, the lead will expire silently.
• On resume, the system will try to catch up and deliver leads that did not expire
  • This can create a burst if too many leads are scheduled in a short time window

💡 Best Practices for Delayed Triggers

1. Match your trigger conditions to your delivery interval to avoid queuing and resending leads that were already delivered in real time.
2. Use Spread and Organic for balanced pacing and only use ASAP if the buyer has a reliable system that can handle bursts.
3. Avoid narrow delivery intervals - short windows increase the risk of expiration or delivery failures.
4. Pause the queue only if you must - leads can expire silently, and resuming can cause a sudden burst.
5. Use caution when shortening the delay - leads older than the new threshold will expire from the queue.
6. Only update configuration when needed - updates can take time to apply, and may result in mixed behavior for leads that are already in queue.
7. Understand expiration behavior - leads expire at the end of their interval (or 4 hours after scheduled time for Organic).