What happens when you make changes to a campaign
Each campaign type in Customer.io behaves a little bit differently, so changes will have a different effect on the messages they contain. What kind of change you make is also significant— whether it’s a trigger, filter, delay action, or message. We’ll describe all of those in detail below, for each campaign type as appropriate.
Changing triggers and/or filters…
…in event triggered campaigns
If you change the event trigger:
- Users already moving through the campaign workflow based on the original event continue their path.
- New users enter the campaign based on the new event.
If you change the event filter:
- Existing users continue on their original path to receive the subsequent actions in the workflow until they finish the campaign.
- New users enter the campaign based on the new event filter.
If you change the segment filter(s):
- Existing users are re-evaluated once they reach the next message to be sent in the sequence. If they no longer match, they fall out of the campaign and won’t receive any subsequent emails.
- New users match the campaign based on the new segment filter(s).
Also important: the 30 minute retry only applies to the initial match. If a user fails to match the segment filter for later on when we’re continuing the campaign after a delay, they will be kicked out immediately.
…in segment triggered campaigns
If you change the trigger segment(s):
- Users that are waiting in a delay or time window will be re-evaluated before moving to the next action, delay, or time window. For example, if your users are waiting in a delay when you’re changing the trigger segment(s) and the delay is followed by a time window, users are re-evaluated when they enter the time window. At this point, anyone who doesn’t match the new trigger segment(s) falls out of the campaign and won’t receive messages. People who still match the new trigger segment(s) simply continue the campaign.
- New users match based on the new trigger segment(s).
If you change the filter segment(s):
- Existing users are re-evaluated as soon as they reach the next message in the workflow. Anyone who doesn’t match the new filter(s) exits the campaign, while people who match the new filter segment(s) simply continue the campaign.
- New users match based on the new filter segment(s).
…in API triggered broadcasts
These work a little bit differently in that your recipients don’t have to be defined at the outset. When you trigger your broadcast via the API, you can specify recipients in that call. That API call will override anything you’ve set in the ‘Recipients’ section.
Also, API Triggered Broadcasts send messages multiple times, similar to event triggered campaigns. This is true even if a customer enters and leaves your recipient segment(s). You have more fine-grained control here when it comes to overriding recipients.
If you change the recipient segment(s) in the UI:
If you change these in the Recipients tab of your campaign overview, that change will go into effect the next time you trigger the broadcast.
If you use a different recipient segment(s) in your API call:
If you trigger the send via API and specify your recipient segment(s) there, whatever segment ID you use in that API call will take precedence; it doesn’t matter what you’ve set in the Recipients tab in the app. So if, in the app, your broadcast is set to send to people in Segment A, but your API call specifies Segment B, then the broadcast will be sent to Segment B, not both!
Making changes while a broadcast is in the sending queue:
An API triggered broadcast is “in the sending queue” if you’ve triggered it to send, either manually or via the API, and we’re generating deliveries for it— essentially, the broadcast is in the process of being sent to all of its recipients. Any changes you make to messages during that time will take effect immediately! We recommend that you don’t do this, because it might mean that you send different messages to different people.
You can tell whether or not a send is in progress by checking out your Task History in the top navigation bar:
Changing or deleting delays
If you shorten a delay (for example, from 7 days to 5 days):
- All users waiting in that particular delay are re-evaluated. You will see a processing circle while this is happening.
- Users who have already waited for more than the new delay (in our case, more than 5 days) will immediately move to the next action.
- Everyone else continues waiting in the delay for the required period.
If you lengthen a delay (for example from 5 days to 7 days):
- Users all wait based on the new delay (7 days instead of 5). The only visual feedback is the new delay being saved; there is no re-evaluation done.
If you delete a delay:
- People automatically move to the next action in the workflow.
- If the next action is a delay or a time window, they wait the required number of minutes/hours/days or until the time window is open.
- If the next action is an email, they receive it immediately.
Changing or deleting time windows
If you limit or extend a time window:
- Users adapt to the new time window.
- If the time window wasn’t open before the change, but it is now, all the users previously waiting move to the next action in the workflow.
As an example, let’s say it is currently Monday at 09:30. There is a time window currently set to allow sending on Tuesday and Thursday from 09:00 to 12:00, and we alter it to allow sending on Monday from 09:00 to 12:00 also. People currently waiting in the delay will immediately proceed to the next action in the workflow. If, instead, we were to alter it to allow sending on Monday from 10:00 to 12:00, all users waiting in the time window would be scheduled to move to the next action in the workflow at 10:00 (i.e. in 30 minutes), instead of waiting until Tuesday at 09:00.
If you delete a time window:
- All the users waiting for the next available slot in the time window will immediately move to the next action in the workflow.
Changing, deleting or re-ordering emails
Users continue on a linear path through the campaign.
If you add a new email or move an existing one to a different position in the workflow:
- It will be received by all the users who didn’t yet reach that particular email (even those who are waiting in a delay or time window right before the new/moved email).
- If the user already received that particular email because the email was initially earlier in the workflow, they will skip ahead to the next action.
If you delete an email:
- Users waiting in the delay/time window before that email will move to the next action following the deleted email (if one exists).
Changing the email behavior
“Send Automatically” sends out all the emails as soon as they match the delays/time windows you set.
If you change an email to “Don’t Send”:
- Users skip it to move to the next action in the workflow.
If you change an email to “Queue Draft”:
- Emails are created under “Drafts.” You’ll have to send them manually by clicking “Send All” or choosing particular ones and pressing the “Send” button next to each of them.
- Users move to the next action in the workflow even if the drafts aren’t sent.
Changing sending behavior
If you change tracking from “Enable Tracking” to “No tracking”:
- Links will no longer be wrapped in tracking links. Opens or clicks will not be recorded for that particular email.
If you change “Don’t send to unsubscribed” to “Send even if unsubscribed”:
- Unsubscribed users will start receiving your particular email.
- If you have the first email in a campaign set to “Don’t send to unsubscribed”, but the second email has “Send even if unsubscribed”, your unsubscribed users will skip the first email and receive the second one and any others that are meant for unsubscribed users.
- Event-triggered campaigns default to "Send even if unsubscribed”.
- Segment triggered campaigns and API triggered broadcasts default to "Don’t send to unsubscribed”.
Changing the email content
- If you edit the content of an email, all the existing drafts will update to reflect your changes, but the ones that were already sent won’t be affected.
- Users who received the email previously won’t receive an updated version even if the email changed position in the workflow.