Skip navigation
All Places > Marketo Whisperer: Implementation Tips > 2016 > September
2016

Reduce Workload, Maximize Consistency (and Get Your Marketing Automation Geek On While You're Doing It!)

 

I think most of us are leveraging system-level tokens and lead-level tokens to personalize content for their prospects, and many are even using program-level tokens (aka "my.tokens") to further customize and make dynamic the content inside of their programs. But some of you are taking it to the next level, placing tokens into folders into "waterfalls" of local and then inherited tokens that cascade into each program. See an excellent blog post on this approach here.

 

Why take this kind of token folder structure approach? There are a lot of advantages - just to name a few:

  • Reduce the amount of time spent editing or updating programs when shared information changes
  • Help "hold brand" for programs, ensuring that headers, footers, brand messaging and images stay consistent
    • Added bonus: by not having this inside your templates directly as text/imagery, you can make updates without having to re-approve templates (and all of their related assets)
  • Guided landing pages and email 2.0 templates make it deliciously possible to have just a few templates support multiple brands (with different imagery, colors, etc.) but without tokens, it can still require the user to know hex code or image URLs to swap out for their brand. Turn those into tokens inside the template, place the tokens in your brand's top folder, and your user doesn't even need to edit those!

 

Sounds awesome, right? But a little intimidating? It doesn't have to be - it just takes some time and planning.

 

Plan for your tokening

 

Grab a variety of the emails and landing pages you are leveraging today. Compare them and mark up what elements, if any, are shared across the assets - or could be with edits to layout and/or content. What is shared at say, the corporate level v. the brand level or channel level v. specific programs? (I find color coding useful for this.)

        

You'll almost certainly find that your highest-level headers and footers have commonalities across the board. But you'll probably find that content associated with certain brands and/or channel types also tend to leverage identical or nearly identical content - imagery, calls to action, brand messages. This is, in essence, your token plan.

 

  • What do all of your brands/products/services and/or program types have in common? Place these at the top level - things like corporate-level messaging, imagery, corporate-level color schemes.
  • How do you organize your brands/products/services in terms of how they face the customer; or does your face-to-the-customer take a more regional approach
    • Does a brand or region have a specific color scheme, imagery or even content (product A has standard copy always referenced). This may be your second level folding and tokening
    • TIP: Evaluate your tokening and folding from a customer-facing perspective, not necessarily how you are internally organized; tokening will be easier to "cascade" down through folders and programs in terms of how, where and why content is presented to the customer - you'll see more opportunity for commonalities and where the differences are
  • Within a brand/product/service, do you have programs that always tend to utilize the same type of content, flow, etc.
    • You can consider folder-level tokening at this level too but this is also a great opportunity to create shell programs (i.e. program templates) that leverage the above tokens wherever possible to make things even easier
  • Bring in your designers and think about what you can token at the top level across templates - build in tokening for page/email imagery, color, footer boiler plate information - remember, by leveraging tokens built into the template, you can make updates to the token rather than the template.

 

If I can get a program down to two or three local or overridden tokens, with the rest cascading down from the folders above it, then a) I feel a real sense of accomplishment because I'm a total Marketo geek like that but b) I know that I've just drastically reduced the number of touches a Marketo user has to make to a program to get it out the door - that's a huge win.

        

I have seen Marketo programs go from taking 60 minutes to clone and edit to literally 10 minutes (including testing!) with use of tokens and shell programs that leverage folder-level tokening. That's a metric any marketing organization can feel good about!

 

In what other ways are you using tokens and how have tokens helped you optimize your marketing operations?

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.

Many Enterprise clients implementing Marketo struggle to define which fields need to be created in CRM to help sales. And sometimes there is a lot of pressure to get it right from the start as it is often a long and complicated process to have CRM administrators create new fields  – and an even bigger battle to facilitate change management processes with a large and distributed sales team.

 

Here are the top 5 fields my clients find valuable and their use case:

 

  1. Acquisition Date – this is useful if you are holding records back from syncing with CRM until they are auto-qualified. The acquisition date gives more insight into when the name was acquired by marketing and when the nurturing relationship likely began.
  2. Most Recent Campaign – since people can be members in many different programs, having a field to track what the most recent Marketo program someone was a part of helps sales understand what the person has been doing lately and what that last marketing touch is.
  3. Most Recent Product Interest – this is especially important if you have many different solution areas or products. Like Most Recent Campaign, this field allows sales to understand what area of interest someone has either through visits to specific web pages or by downloading product specific content.  While this may not be the only area of interest for the person, it is an extremely relevant touchpoint that will help sales to start a conversation with the person.
  4. Lead Score – while each business varies on the intention of scoring leads and the value that is populated, creating a score field in CRM is valuable – even more so if you are immediately synching records upon creation in Marketo. The key when creating this field is to clearly communicate how sales should interpret and use the data in it.
  5. Lifecycle Status – this field is used to show sales as to what buyers stage someone is in. This is a mirror field of Marketo’s revenue stage field which is a field that cannot be exposed through the API. Values in this field are typically read-only for sales and will map to the stages in your lifecycle such as MQL, SQL, and Recycled.