Hey Ben:
Phew. This question. I'm going to be presenting on a piece of this at the Summit in April, but here's quickly how we've solved this problem.
(I also have a hunch that this will be addressed with some new features this Friday with the December release, but I'm not certain yet.)
As you know, how the engagement programs work is they see if a lead has been sent an email—if yes, move on to the next. With campaigns, the engagement program looks to see if the lead is a member of the program. If yes, move on to the next.
We have the same problem, where we promote assets and blog posts in our lead nurturing. The answer is to have actual programs in the queue instead of emails. We then have logic that adds prospects into these programs in the "Exclusion" program status, specific to our Nurturing Email channel.
Here's a screenshot of one of our engagement programs in effect:
We added the program status "Exclusion" to the email blast channel:
Here's the nurture email blast program setup:
The Exclusions are the logic to make sure the right leads are included in the program. In this case, it's pointing someone to read the blog. We had to do this retrospectively when we set it up, hence the batch campaigns. Here's the smart campaign of the Exclusion Batch:
Here's the Exclusion (Triggered) campaign setup:
The Exclusion logic is something that you can set up. It actually led us to redo some of our architecture, making sure that leads are added to a list ("DL - [Asset Type]: [Asset Name]") upon download, no matter what the channel. It's our universal list of "lead has downloaded this," which we use as the exclusion driver for our engagement programs. For our assets, we have a trigger set up for "Added to list" which is the download list—when a lead is added to the list, we add them to the appropriate nurture email blast campaign with the Exclusion program status. The batch campaigns were for retrospectively excluding prospects. We just clone one of these programs every time we create a new email.
(Also, note that the actual email resides in the Design Studio, not in the program. This is just an organizational choice that I made based on our workflow, and you can just as easily include the email within the nurture email blast program itself.)
This setup has its pros and cons. Some pros are that you can actually do this kind of complex nurture email logic, and you can get a bit more visibility to the traditional metrics for email blasts. A con is definitely that this screws up the measurement of the engagement programs natively—right now, our engagement programs show that we have a 0% unsubscribe rate! Real proud of that one... but it's not true. I believe the whole "engagement" proprietary score is thrown off by this kind of setup, but I believe it's worthwhile.
Cheers!
Edward UnthankMarketing Operations Specialist
Yesler