We are building multi-stream nurture programs for each of our verticals ("yay!" *Monty Python and the Holy Grail rejoice) and I want to ensure that I'm future-proofing against program member breaches and fuzzy reporting. Does best practice point to building different default programs for each nurture program (duplicate the program and/or asset), or can I build multiple smart campaigns within one default program for the nurture campaigns to call their specific campaigns (Vertical A Nurture Program calls '01 Vertical A - Send Email' and Vertical B Nurture Program calls '02 Vertical B - Send Email')?
I was going to do the following (image) but wanted input from you smarties before I mass-build.
Many thanks,
Ethan
Solved! Go to Solution.
Ah. I think I understand what you're asking.
If you nest the default program within both of the nurture programs, both referring to the same email send smart campaign, you won't be pushing people who get triggered from Nurture A into Nurture B unless something in a flow step of the nested default program explicitly does this.
You can include a filter in the rules of the nested default program email send smart campaign that require the person triggering the send to be a member of either Nurture A or Nurture B, but this won't really do anything - by definition, this is a prerequisite to the campaign being triggered. It's a safety net, but keep in mind that by including this you will need to remember to update the smart campaign before you can add that default program to Nurture C, otherwise it won't work. (This may be fine if you're solo-ing it, but good factor to keep in mind if you've got multiple users).
As I see it you've got three options, in decreasing order of work required:
None of these options will cause people to move around in other nurture programs unless you add something in the flow steps to explicitly ensure this. If you do want to include steps to make this happen but only in the nurture they are a member of, you should either choose #1 or, with #2 or #3, add conditions to flow steps or use request campaign steps (though that has it's own pitfalls...)
Hope that helps.
I would definitely recommend the single program shared by the multiple nurtures.
Is there anything in particular that you're trying to achieve/avoid by the distinct send/success campaigns for each nurture using the asset? Technically there's nothing wrong with doing that, I would just question whether it's worth the extra steps to enable it - every time you want to add the content to another nurture you'd have to build those again (vs one of each shared by all nurture campaigns).
I suspect intent is for more granular reporting, but think there might be more efficient ways to do that?
My main concern is how to set up the smart campaigns. If I set member of engagement program with both programs, will both nurture programs key off of the same smart campaign without adding members of each nurture program to the other program (Members of Program A enter stream in Program B)? I'll test for sure but hadn't read any documentation on this.
Ah. I think I understand what you're asking.
If you nest the default program within both of the nurture programs, both referring to the same email send smart campaign, you won't be pushing people who get triggered from Nurture A into Nurture B unless something in a flow step of the nested default program explicitly does this.
You can include a filter in the rules of the nested default program email send smart campaign that require the person triggering the send to be a member of either Nurture A or Nurture B, but this won't really do anything - by definition, this is a prerequisite to the campaign being triggered. It's a safety net, but keep in mind that by including this you will need to remember to update the smart campaign before you can add that default program to Nurture C, otherwise it won't work. (This may be fine if you're solo-ing it, but good factor to keep in mind if you've got multiple users).
As I see it you've got three options, in decreasing order of work required:
None of these options will cause people to move around in other nurture programs unless you add something in the flow steps to explicitly ensure this. If you do want to include steps to make this happen but only in the nurture they are a member of, you should either choose #1 or, with #2 or #3, add conditions to flow steps or use request campaign steps (though that has it's own pitfalls...)
Hope that helps.