SOLVED

Best practice for using if was sent email constraints in Smart Campaign flows

Go to solution
Highlighted
Level 1

Best practice for using if was sent email constraints in Smart Campaign flows

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:

  1. Send Email "September Newsletter"
  2. Wait 1 minute
  3. "If was sent email September Newsletter" then "change program status to Email > Was Sent Email"
  4. Wait 1 minute
  5. "If was sent email September Newsletter" then "add to the Static List Was Sent September Newsletter Email"

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?

  1. Send Email "September Newsletter"
  2. "Change Program Status to Email > Was Sent Email"
  3. "Add to List Was Sent September Newsletter email"

 

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

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Level 10 - Community Moderator

Re: Best practice for using if was sent email constraints in Smart Campaign flows


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.

View solution in original post

4 REPLIES 4
Highlighted
Level 10 - Community Moderator

Re: Best practice for using if was sent email constraints in Smart Campaign flows


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.

View solution in original post

Highlighted
Level 1

Re: Best practice for using if was sent email constraints in Smart Campaign flows

Hi @SanfordWhiteman

 

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

Highlighted
Level 3

Re: Best practice for using if was sent email constraints in Smart Campaign flows

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.

Highlighted
Level 1

Re: Best practice for using if was sent email constraints in Smart Campaign flows

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