Before You Pull the Trigger on Triggers

Level 5

Triggers for smart campaigns are fantastic – they allow what I affectionately call slow cooker marketing automation (aka “set it and forget it”). Turn it on and then when the behavior occurs, it takes care of it.

But as your marketing database grows and the number of programs and smart campaigns you build in Marketo grows, it’s important to understand how triggers work and the impact they can have on the performance of your Marketo instance. One Marketo customer with a large database (millions of records) and nearly 900 active smart campaigns at any given moment experienced this recently when their trigger campaign queue became very busy.

It’s important to understand that active trigger campaigns are always on and always listening for their cue. And their cue is, at first, very broad.

Consider the “Data Value Changes” trigger in a smart campaign. In the smart list, you have the trigger “Data Value Changes” and then the attribute (data value) it is to listen to for changes (such as First Name). The very first thing this trigger is listening for is the change in a data value – any data value - before it then evaluates whether its particular attribute (First Name) was affected. This means that ANY time a data value changes for any reason in Marketo, this trigger campaign is first activated by the fact that a data value – any data value – has changed, and then will run through to determine if it was the First Name attribute that was changed. Considering a typical Marketo instance integrated with a CRM can have a few hundred field values, that’s a LOT of trigger firing.

Same thing happens with “Email is Delivered,” often a popular attribute to assign program membership status for a particular program. Marketo is listening for this any time ANY email is delivered – first it triggers on the fact than any individual email was delivered, then runs if the email specified was the email in question. When you are sending emails to tens of thousands of leads in a day, those trigger fires can add up.

With that in mind, choose when you truly need a campaign trigger versus running things as batch. Time-sensitive information such as clicking certain links to trigger a sales alert, or certain data values changing to remove someone from eligibility for a program, may be critical to keep as triggers. But often times, a batch campaign would do (such as changing program status), set to run in the middle of the night daily or even once a week on a weekend.

Due to the size of your Marketo databases, most of you will never experience any kind of trigger queue impact. But it should be in your best practice arsenal to always consider whether a trigger is truly necessary for executing immediate action versus scheduling recurring batch campaigns to achieve the same result.

Tip: Want to make it easy to evaluate what trigger campaigns you have and how/what they are executing, to look for chances to optimize performance? If you have admin rights, click on a workspace and then select “Campaign Inspector.” You can export all of the campaigns in that workspace into an Excel document and then filter to look just at Active Triggered campaigns. Then look in the Flow Step and filter to those types of actions (Change Program Status, for example) that might be better suited to batch campaigns.

Thanks to Ken Niwa and Jonathan Wu​ for their insights into this issue.​

Level 5

Thanks for the info! Question, though: if you set, say, the "Email is Delivered" trigger and choose a specific email, doesn't it only ACTUALLY trigger if the email listed is delivered? If not, it doesn't send people to the flow step and therefore doesn't change anything for the lead that doesn't qualify, nor does the lead show up in "Results".

I also think it's worth noting that campaigns triggered by things like "data value changes" or "lead score changes" can be affected if you are merging leads. When you merge leads, data values change and it could trigger unwanted actions for your leads (especially if you have a "send email" flow step - that would cause your leads to receive content that isn't necessarily relevant to them at that time!)

According to my friends in technical - and this is me putting a non-technical jargon on it because I am SO not on the tech side to be able to explain it like they would - basically the trigger is open and listening...and therefore "partially" activating just based on any email delivering. It won't fully "pull the trigger," so to speak, if the specific email isn't the one being delivered, but just having the trigger cocked and loaded (wow, can I get any more puns in here?) to listen for email delivery (or data value change, or opportunity updating) creates a load for the trigger queue. The system must first respond to the email deliver trigger, then further evaluate whether its specific email was the one being triggered. So it won't fully fire, but it does start a process.

Level 3 - Champion Alumni

Hopefully, one day Marketo will introduce the possibility of setting the date and time when trigger smart campaigns are to be inactivated. There's been several requests for this but so far no luck.

Level 5

I totally agree!

Level 5

Great article Michaela Iery​. At a previous role I walked into a Marketo instance with a database of 800k leads, and several hundred 'Data Value Changes' trigger campaigns. That instance experienced significant campaign queue backlogs until we rebuilt the system.

Do you have any insight into how Project Orion will change these concerns? I attended the Project Orion session at Summit, and it seemed like lots of performance concerns around trigger campaigns will disappear once your instance is on Orion.

Thanks, David! It's amazing what a difference the trigger campaigns can make to a large database. In terms of Orion, I can't speak to the specifics as well as our more technical consultants, but you are correct that you would see a difference with it. Having said that, it should always be best practice to try to keep triggers to truly real-time-response-required actions and use batch for everything else, even when on Orion. After all, why waste all that yummy performance gain on things that could be accomplished just as well otherwise?

Level 5

Agreed!  Always best to save those triggers for when you really need them.

As for those Orion performance gains - I'm really looking forward to putting Munchkin code everywhere in our product and setting up some amazing upsell triggers.

Level 7 - Champion

Thanks for the article! I had no idea that triggers would evaluate based on any field changing then narrowing down based on the exact field, slowing an instance down. I had wondered in the past why I was told to make scheduled batches but consultants instead of triggers, but no one explained this to me. Makes sense now!

I am trying ot understand the logic used with triggers - If you are setting up a Smart Campaign with  multiple triggers, are they by default ALL or ANY?

Trigger campaigns are always ANY -> as soon as one of the trigger conditions is met, actions will run