Campaign Scheduling
This topic provides a high-level overview of the scheduling options available for the different types of Campaigns.
When a Campaign is launched, it goes through two separate and distinct phases: building messages and sending messages.
In the "message building" phase, the platform identifies the intended recipients of the Campaign, identifies all the possible content variations based on the Dynamic Content options used in the Campaign, and determines the Personalization values based on any Personalization fields used in the content. The steps in this first phase are often collectively referred to as the "queue" process.
In the "message sending" phase, the system merges together the data and the content in order to assemble the final messages. These messages are then transmitted to the recipients.
Within a Campaign, each of these phases can be controlled by its own dedicated schedule that defines when to start the schedule for that phase, and (for triggered Campaigns) how often to execute the process.
Queue Schedules are used to control the message building phase for Event-triggered Campaigns and Regular One-off Campaigns. Send Schedules are used to control the message sending phase for these Campaign types.
Date-triggered Campaigns utilize a different concept referred to as the "Recurrence Schedule," which controls when, and how often, the Campaign executes both the message building phase and the message sending phase.
Note: Depending on the channel being utilized, not all of the scheduling options described here are supported.
Regular One-off Campaigns
Unlike triggered Campaigns, which potentially execute multiple times (i.e., when they're triggered), a Regular One-off Campaign builds and deploys messages only once.
The schedule for a Regular One-off Campaign comprises three components:
Queue Schedule Start: This component controls when you want the message building phase to begin. You can either select "Immediately," meaning the Queue Schedule will go live immediately after the Campaign is launched, or you can set a start date / time in the future. You can also derive a start date / time by working backwards from a defined Send Schedule start date / time. For example, "start the build process six hours before the Send Schedule starts."
Send Schedule Start: This component controls when you want the message sending phase to begin. You can either select "Immediately," meaning the Send Schedule will go live immediately after the Campaign is launched (messages will deploy after the message building phase is complete), or you can set a start date / time in the future. You can also set an end date / time when you want to stop sending messages.
Sending Window: This component allows you to define a limited time range, or "window," during which time the platform will send messages. If the Campaign doesn't complete the sending process during the Sending Window, the remaining recipients will stay held in the queue until the next window. Or, you can select to send messages all day long, without the use of a Sending Window.
Note: Campaigns that use the Engagement Data Platform (EDP) as the data source, rather than a Messaging table, have slightly different options for Regular One-off Campaigns. EDP-driven Campaigns utilize a different flow than Campaigns that use a Messaging table as the data source. Because of this different flow, the concept of an "advance queue" is not supported in EDP-driven Campaigns. Therefore, you can't define separate schedules for the message building phase and for the message sending phase, as you can for Campaigns built off a Messaging table. Instead, you must define a single Send Schedule, which encompasses both phases.
Default Schedule
The default schedule settings for a Regular One-off Campaign are to start the Queue Schedule "immediately," and to prompt the user to enter a Send Schedule start date / time (with no Sending Window).
The following diagram depicts the default schedule scenario for a Regular One-off Campaign, with an immediate message building phase, and a user-defined message Send Schedule start date and time. In this example, the Send Schedule was configured to start on Tuesday at 8:00 AM, and the Campaign was launched on Monday. Messages were created immediately, but held in the queue until the Send Schedule start date / time, at which point the messages were sent.
Start Both Schedules Immediately
Optionally, you can set both the Queue Schedule and the Send Schedule to start "immediately." In this scenario, the system will begin the message building phase as soon as the Campaign is launched. The system will then send these messages immediately after the message building phase is complete.
The following diagram depicts a Regular One-off Campaign, with both schedules set to start "immediately" (with no Sending Window).
Delayed Queue Schedule Start
Optionally, you can delay the Queue Schedule to some point in the future, after the Campaign is launched. For example, you may need to wait until additional data is loaded to the platform, or to allow time for additional changes to the message content. In this scenario, you'll need to define a custom Queue Schedule start date / time. When the Campaign is launched and approved, the messages will not be created until this scheduled date and time.
The following diagram depicts the use of a custom Queue Schedule start date / time. In this example, the Queue Schedule was configured to start on Wednesday at 2:00 PM, and the Send Schedule was set to "Start after Queueing" (i.e., after the message building phase is completed). The Campaign was launched on Monday. The platform didn't start the message building phase until Wednesday.
Derived Queue Schedule Start
When setting a custom Qeueu Schedule start, you can define a specific date / time as described above, or you can optionally derive this start date / time based by calculating backwards from a specified Send Schedule start date / time. When deriving the Queue Schedule start, be sure to give the message building phase enough time to complete, so that your Campaign deploys at the desired time. If you need help determining what this duration should be, please speak with your Client Services Representative.
The following diagram depicts the use of a derived Queue Schedule start. In this scenario, the Campaign was launched on Thursday, and the Send Schedule was set to start on Friday at 6:00 PM. In order to make sure messages deployed at exactly that date and time, the Queue Schedule was configured to start "six hours before the Send Schedule start date / time."
Sending Window
By default, the platform will send messages "all day long," until all of the messages have been sent, and the Campaign ends. Optionally, you can define a daily Sending Window, which sets a begin time and end time. The platform will send messages only during this Sending Window. If the Campaign doesn't complete the sending process during the Sending Window, the remaining recipients will stay held in the queue until the next window.
The following diagram depicts the use of a Sending Window. In this scenario, the Queue Schedule and the Send Schedule were both set to "Immediately." However, the client wanted to send messages only between 12:00 PM and 5:00 PM. The Campaign was then launched at 7:00 AM. The message building phase began immediately, but the messages were held in the queue until the next Sending Window at 12:00 PM. At 5:00 PM when the Sending Window ended, the platform hadn't finished sending all the messages yet, so the remaining messages were held in the queue until the next Sending Window the following day.
Date-triggered Campaigns
As described above, a Campaign goes through goes through two separate and distinct phases when it's launched: building messages, and sending messages. For a Date-triggered Campaign, the Audience of recipients is calculated based on the "Recurrence Schedule." The Recurrence Schedule is unique to Date-triggered Campaigns, and it defines when, and how often, the Campaign will execute the Filter to determine the Audience, then build and deploy messages.
The schedule for a Date-triggered Campaign contains the following components:
Recurrence Schedule Start: This component controls when you want the Recurrence Schedule to be active, or to go "live." You can either select "Immediately," meaning the Recurrence Schedule will go live immediately after the Campaign is launched, or you can set a start date / time in the future. You can also optionally set an end date / time for the Recurrence Schedule, or let the schedule run indefinitely (until the Campaign is stopped or cancelled).
Send Schedule Start: This component controls when you want the Send Schedule to be active, or to go "live." You can either select "Start after Queueing," meaning the Send Schedule will go live immediately after the Campaign is launched, or you can set a start date / time in the future. Please note that the Send Schedule Start controls ONLY the first deployment of the Campaign. All subsequent deployments after the first one will be controlled by the Recurrence Schedule Frequency. You can also optionally set an end date / time for the Send Schedule, or let the schedule run indefinitely (until the Campaign is stopped or cancelled).
Recurrence Schedule Frequency: Once the Recurrence and Send Schedules are "live," this component controls when, and how often, the Campaign will execute the Audience Filter, build new messages, and send them.
Building Window: This component allows you to define a limited time range, or "window," during which time the platform will build messages. If the Campaign doesn't complete the building process during the Building Window, the remaining messages will get built during the next window.
Sending Window: This component allows you to define a limited time range, or "window," during which time the platform will send messages. If the Campaign doesn't complete the sending process during the Sending Window, the remaining recipients will stay held in the queue until the next window. Or, you can select to send messages all day long, without the use of a Sending Window.
Note: Campaigns that use the Engagement Data Platform (EDP) as the data source, rather than a Messaging table, have slightly different options for Date-triggered Campaigns. EDP-driven Campaigns utilize a different flow than Campaigns that use a Messaging table as the data source. Because of this different flow, the concept of an "advance queue" is not supported in EDP-driven Campaigns. Therefore, you can't define separate schedules for the message building phase and for the message sending phase, as you can for Campaigns built off a Messaging table. Instead, you must define a single Recurrence Schedule and frequency, which encompasses both phases.
Default Schedule
The default schedule settings for a Date-triggered Campaign are to start both the Recurrence Schedule and the Send Schedule immediately upon launching the Campaign, and to use a Recurrence Schedule Frequency of "once daily, every day, at 9:00 AM" (with no Sending Window).
The following diagram depicts the default schedule scenario for a Date-triggered Campaign that was launched on Monday at 2:00 PM. Both schedules went live immediately, but the platform did not build and send messages at that moment, because the execution of the Campaign is controlled by the Recurrence Frequency (daily, at 9:00 AM). The following day at 9:00 AM, the Campaign built and sent messages for the first time. Then going forward, the Campaign built and sent messages every subsequent day at 9:00 AM.
Delay Both Schedule Starts
Optionally, you can delay both the Recurrence Schedule and the Send Schedule by setting custom start dates / times for both. In this scenario, the system won't do anything when the Campaign is launched, until the schedules' start dates / times are reached, and the schedules go "live." Please note that the Send Schedule start date / time must either be the same as, or after, the Recurrence Schedule start date / time.
The following diagram depicts a Date-triggered Campaign with delayed Recurrence and Send Schedules, that was launched on April 1 at 9:00 AM. In this example, both schedules were delayed to start on April 2 at 10:00 AM, with a Recurrence Frequency of "daily, at noon." After the Campaign launched, nothing happened on April 1 at noon, because the Recurrence and Send Schedules were not yet live.
The following day, April 2, the Recurrence and Send Schedules went live at 10:00 AM. However, the platform did not build and send messages at that moment, because the execution of the Campaign is controlled by the Recurrence Frequency (daily, at noon).
Later on April 2, at noon, the Campaign built and sent messages for the first time. Then going forward, the Campaign built and sent messages every subsequent day at noon.
Delayed Send Schedule
Optionally, you can delay only the Send Schedule start date / time, and leave the Recurrence Schedule to "start immediately." This scenario is a bit more complex than some of the other Date-triggered Campaign configurations, because the initial deployment of the Campaign can potentially execute at a different time than every subsequent deployment.
In this scenario, the system will still execute the message building phase according to the Recurrence Schedule Frequency, but the created messages will be held in the processing queue until the Send Schedule goes live. Depending on how far out you set the Send Schedule, it's possible that the message building phase may even run multiple times, and all those messages will get held in the queue.
At the moment the Send Schedule goes live, the system checks to see if there are message in the queue. If so, the system will send those messages at that moment. Then, following that initial Campaign deployment, all subsequent deployments will follow the Recurrence Schedule Frequency.
The following diagram depicts a Date-triggered Campaign with a delayed Send Schedule. In this example, the Recurrence Schedule was set to start "immediately," with a Recurrence Schedule Frequency of "once daily, every day, at 2:00 PM." The Send Schedule was configured to start on April 5 at 10:00 AM.
In this example, the Campaign was launched at noon on April 4. The first execution of the message creation process occurred a few hours later at 2:00 PM, according to the Recurrence Schedule Frequency. However, these messages weren't actually sent yet, because the Send Schedule wasn't live. These messages were held in the queue.
The following day at 10:00 AM, the Send Schedule went live. At that moment, the system sent all messages currently in the queue. In this case, that included all the messages that were built the previous day.
After that initial deployment, the Recurrence Schedule Frequency controlled all subsequent processing -- the message building phase began every day at 2:00 PM, and those messages were deployed immediately afterward. In this scenario, you can see how you can define a send time that is unique only to the first deployment.
Sending Window
By default, the platform will send messages "all day long," until all of the messages currently in the queue have been sent. Optionally, you can define a daily Sending Window, which sets a begin time and end time. The platform will send messages only during this Sending Window. If the Campaign doesn't complete the sending process during the Sending Window, the remaining recipients will stay held in the queue until the next window.
The following diagram depicts the use of a Sending Window. In this scenario, the Recurrence Schedule and the Send Schedule were both set to "Immediately." However, the client wanted to send messages only between 12:00 PM and 5:00 PM. The Campaign was then launched, with the default Recurrence Frequency (once daily, every day, at 9:00 AM). The message building phase began at 9:00 AM, but the messages were held in the queue until the next Sending Window at 12:00 PM. At 5:00 PM when the Sending Window ended, any messages still in the queue were held over until the next Sending Window the following day.
Event-triggered Campaigns
As described above, a Campaign goes through goes through two separate and distinct phases when it's launched: building messages, and sending messages. For an Event-triggered Campaign, the Audience of recipients is calculated based on who performs the triggering event. For example, if your Event-triggered Campaign uses "Web Form Submission" as the trigger, then the Audience consists of the indivdual(s) who submitted the desired Web Form. The schedule then controls when, and how often, the system will actually build and send messages to the recipients in the Audience.
The schedule for an Event-triggered Campaign contains the following components:
Queue Schedule Start: This component controls when you want the Queue Schedule to be active, or to go "live." You can either select "Immediately," meaning the Queue Schedule will go live immediately after the Campaign is launched, or you can set a start date / time in the future. You can also optionally set an end date / time for the Queue Schedule, or let the schedule run indefinitely (until the Campaign is stopped or cancelled).
Send Schedule Start: This component controls when you want the Send Schedule to be active, or to go "live." You can either select "Start after Queueing," meaning the Send Schedule will go live immediately after the Campaign is launched, or you can set a start date / time in the future. You can also optionally set an end date / time for the Send Schedule, or let the schedule run indefinitely (until the Campaign is stopped or cancelled).
Queue Frequency: Once the Queue Schedule is "live," this component controls when, and how often, the Campaign builds messages based on new trigger occurrences. This frequency can be set to run "immediately" (meaning, immediately after the triggering event happens), or to run once a day at a specified time, to run at a specified frequency throughout the day (with the optional use of a Building Window).
Building Window: This component allows you to define a limited time range, or "window," during which time the platform will build messages. If the Campaign doesn't complete the building process during the Building Window, the remaining messages will get built during the next window.
Sending Window: This component allows you to define a limited time range, or "window," during which time the platform will send messages. If the Campaign doesn't complete the sending process during the Sending Window, the remaining recipients will stay queued until the next window. Or, you can select to send messages all day long, without the use of a Sending Window.
Default Schedule
The default schedule settings for an Event-triggered Campaign are to start both the Queue Schedule and the Send Schedule immediately upon launching the Campaign, to use a Queue Frequency of "immediately when the event occurs" (without the use of a Building Window), and to use a Send Frequency of "every day, all day long" (without the use of a Sending Window).
The following diagram depicts the default schedule scenario for an Event-triggered Campaign.
Custom Queue Frequency
Optionally, you can define a custom Queue Frequency to execute the message building phase only at a specified frequency. The following diagram depicts an Event-triggered Campaign that uses a immediate start for both the Queue and Send Schedules. However, the Queue Frequency is set to "Weekly, Fridays, at 8:00 AM," with a Send Frequency of "every day, all day long" (without the use of a Sending Window). The system will "batch up" all of the event occurrences all week long, then create and send all of the messages starting at Friday at 8:00 PM.
Delay Both Schedule Starts
Optionally, you can delay the Queue Schedule and the Send Schedule by setting custom start dates / times for both. In this scenario, the system won't do anything if a triggering event occurs, until the start dates / times are reached, and the schedules go "live." Please note that the Send Schedule start date / time must either be the same as, or after, the custom Queue Schedule start date / time.
The following diagram depicts an Event-triggered Campaign with delayed Queue and Send Schedules. In this example, both schedules were set to start on Thursday at noon. The Queue Frequency was set to ""immediately when the event occurs," with a Send Frequency of "every day, all day long" (without the use of a Sending Window). The Campaign was then launched on Monday. No messages were created or deployed until the Queue and Send Schedules went "live" on Thursday. All subsequent executions were controlled by the Queue Frequency and Send Frequency.
Sending Window
By default, the platform will send messages all day long, immediately after they're built. Optionally, you can define a daily Sending Window, which sets a begin time and end time. The platform will send messages only during this Sending Window. If a trigger event occurs outside of the Sending Window, the platform will hold the message in the queue until the next Sending Window.
The following diagram depicts the use of a Sending Window. In this scenario, the Queue Frequency was configured to build messages every day, as soon as the triggering event occurred. However, the client wanted to send messages only between 5:00 PM and 10:00 PM. The Campaign was then launched. As events occurred during the day, the platform built those messages, but the messages were held in the queue until the Sending Window started at 5:00 PM
