Hi community,
I was hoping to find out what the best practices are for using filter choices and wait steps in the flow of smart campaigns. For example, when I am sending an email to customers, changing their program status and then adding them to a static list to ring fence those I have sent to, I have been setting up my smart campaigns as follows:
If I am sending to every customer who is run through that flow, is it best practice to use the wait steps and the choices "If was sent email" or should I have it setup as below where there are no wait steps or choices included?
I have been told that unless there is an action that needs time to occur before another flow step can be completed (i.e, the email CTA is to fill out a form and you need to wait 2 days to give them time to fill it out) then adding in wait steps and choices can causing a racing condition.
All help is appreciated
Thanks
Solved! Go to Solution.
changing their program status and then adding them to a static list to
Not clear on why you're using a static List in addition to a Program Status change. Both are permanent, and the Program Status gives you richer information.
Send Email "September Newsletter"
"Change Program Status to Email > Was Sent Email"
You can change the Status. Not necessarily any to look back in the Activity Log, which is unnecessarily resource-intensive.
Now, there is one case this will not cover, and that's when the Send Email step is ignored, for example if the person has Marketing Suspended = true. But the flipside is that having the Send Email logged doesn't mean the person got the email, anyway; it could have any number of reasons to bounce instead of being delivered.
If you did find a concrete need to log only people for whom an email was actually attempted, I would strongly recommend using a batch, not a trigger.
... then adding in wait steps and choices can causing a racing condition.
It's not that adding Wait steps cause a race condition. It's that Wait stops cannot solve an inherent race condition.
There's no amount of of time that is guaranteed to be enough time in all cases, under all loads, for completely unrelated processes to complete. Concepts like "Wait 1m for a webhook to finish" are effectively random and not guaranteed to work. As you say — Waits should be used for deliberate marketing pauses only, not for guesses.
changing their program status and then adding them to a static list to
Not clear on why you're using a static List in addition to a Program Status change. Both are permanent, and the Program Status gives you richer information.
Send Email "September Newsletter"
"Change Program Status to Email > Was Sent Email"
You can change the Status. Not necessarily any to look back in the Activity Log, which is unnecessarily resource-intensive.
Now, there is one case this will not cover, and that's when the Send Email step is ignored, for example if the person has Marketing Suspended = true. But the flipside is that having the Send Email logged doesn't mean the person got the email, anyway; it could have any number of reasons to bounce instead of being delivered.
If you did find a concrete need to log only people for whom an email was actually attempted, I would strongly recommend using a batch, not a trigger.
... then adding in wait steps and choices can causing a racing condition.
It's not that adding Wait steps cause a race condition. It's that Wait stops cannot solve an inherent race condition.
There's no amount of of time that is guaranteed to be enough time in all cases, under all loads, for completely unrelated processes to complete. Concepts like "Wait 1m for a webhook to finish" are effectively random and not guaranteed to work. As you say — Waits should be used for deliberate marketing pauses only, not for guesses.
Thank you very much for this explanation, that is really helpful.
So do you think it is better to do the ‘if was delivered email then update status’ in a separate batch campaign rather than in the flow of a campaign or in a trigger based (listener) campaign?
Cheers
Caleb
I tend to use the Program Status as Sanford suggests. In addition, there is something to be said to use the Email is Delivered trigger rather than the Send Email trigger to ensure people who did not receive the email are not included in your member count. You may have a valid use case for using Sent, but it is worth considering which activity works best to achieve your goal both for reporting and for follow-up purposes.
Hi Katja,
Thank you for your reply. That is a very good point regarding the use of "if email was delivered". We plan to implement this into future campaigns as this is a much better way of more precisely identifying who was sent/delivered the email. Thanks again.
Cheers
Caleb