In this article, we'll examine a scenario in which, due to an error, there was a doubling or multiplication of customers in the flow, resulting in duplicate email, SMS sendouts, or other campaigns. We'll use an email campaign as an example and review the options available to resolve this issue or mitigate its impact.
Such an issue is usually caused by duplicate triggers or by setting triggers too close together, so they fire right after each other.
Example of scenario flow and visualization of the issue
First option
Imagine you have a scenario with multiple email nodes in sequence, and you don't want to stop the scenario; instead, you want to fix the issue and continue the started flow of customers without sending out emails twice in the next email nodes.
Step 1
First, you will need to set up a dynamic wait node to spread out customers and reduce the likelihood of firing campaign events with close timestamps.
This is an important step, because without it, the second step won't work properly.
You need to use the following Jinja code:
{{ range(0,180) | random }} This Jinja is used to assign a random number of minutes to the profiles, indicating how long they will wait. This approach ensures that each profile is assigned a unique wait time. As a result, the sequence in which customers progress through the flow will be randomized, preventing campaign events from firing simultaneously.
You need to place this wait node before the email nodes that will be sent later.
Step 2
The second step is to go inside the email nodes that are awaiting sending.
In the email node settings, you need to set the frequency policy.
Frequency policies control the number of campaigns customers get within specific time periods. This prevents message overload by setting intelligent limits based on customer engagement levels.
With these two steps, you can continue the campaign without stopping it or starting a new flow.
Screenshot of the frequency policy settings inside the email node.
Second option
Step 1
You will create a new flow that continues the sendout only with email nodes that have not been sent yet, but you will not stop the original flow.
The best approach can vary depending on the specific use case or type of scenario flow.
For example, you can have a one-time trigger scenario or an on-event trigger scenario for a daily run.
Step 2
If you don't want to stop the original flow and the double sendout isn't affecting all customers in the flow, you should filter out customers with duplicate enqueued events.
This can be achieved by building an aggregate and checking whether the number of campaign events for a specific action_id equals 1. If not, the customer will be excluded from this original flow.
Screenshot of the aggregate example.
Screenshot of the whole condition example.
Step 3
The new flow will have a one-time trigger as 'now' or 'on date'. This flow will send out the remaining email nodes to customers who were duplicated in the original flow. You will need to re-use the condition with aggregate again; however, now we will check if the number of enqueued email is greater than 1.
This will ensure that the flow starts only for the customers who received duplicated emails.
Remember that this new flow needs to contain only the remaining email nodes that have not been sent yet.
Screenshot of the condition.
Option 3
The third option is to create a new flow, where you will continue sending only with email nodes that have not been sent yet. However, you will stop the scenario and restart it with two flows running simultaneously.
When you stop the scenario, customers will be removed from the original flow. That's why there's no need to set up a condition with aggregate as we did in option 2.
In this case, you can repair the original flow, and in the new flow, you can finish sending out to the customers who were already in the original flow.
The best approach can vary depending on the specific use case or type of scenario flow.
For example, you can have a one-time trigger scenario or an on-event trigger scenario for a daily run.
Option 4
The fourth option would be to stop the scenario and start a new single flow that sends emails based on the conditions' output.
In this flow, you would use conditions to check whether the customer has received the exact campaign, and, based on the outcome, set the nex0t sendout. You can always set up a date filter to check campaign events within a specific date range.
Screenshot of the condition.
Summary
The best method depends on whether the scenario can be stopped, whether all customers were affected, and which campaign nodes have already been sent. Dynamic wait-time and frequency policies are best suited to maintaining the existing flow, while aggregate-based conditions help separate duplicate customers from unaffected customers in replacement or continuation flows.
You have multiple options to resolve issues with duplicate send-outs in your campaign. The best way of fixing this always depends on the specific use case and your goal. Therefore, you can always devise your own approach to dealing with this. Feel free to use our solutions explained above or create your own custom one based on your needs.