Skip navigation
All Places > Products > Blog > Author: Michaela Iery


14 Posts authored by: Michaela Iery Employee

Many Marketo users do not spend a lot of time, if any, in and do not fully understand how it defines certain opportunity fields. This can be important when you’re leveraging Revenue Cycle Analytics to evaluate the impact of your marketing programs on revenue.


Let’s talk about the field Expected Revenue. While it is defined in our product documentation, I’m going to be really honest with you and admit that when I was a Marketo client myself learning RCA, I missed this completely. So I was stumped for some time about why Expected Revenue was so different from Revenue and where this data was coming from. Was it something the salesperson input and if so, why?


Just in case there’s anyone else out there in the same boat I was in once upon a time, I’m going to lay out what might be obvious to many of you:


Expected Revenue is a field that is automatically calculated in SFDC based on two data values:

1) The Opportunity Amount – a dollar amount (or Euro or whatever currency you’re tracking). This part is input by the salesperson and she may adjust it over time as she learns more about the opportunity – unless her organization’s sales processes require that she keep it as is


2) The Opportunity Probability – a percentage value. It is the likelihood that the opportunity will be won. In most cases, your SFDC instance has been set up to automatically calculate probability based on the latest Stage the opportunity is in (for example, an opportunity in the earliest stages of the sales process have a lower probability of being won than one at the later stages). However, some SFDC configurations will also allow the salesperson to override this probability calculation with their own value.


Expected Revenue then is automatically calculated in SFDC as Opportunity Amount * Opportunity Probability.


Example: An opportunity in SFDC has an Opportunity Amount of $150,000 and an Opportunity Probability of 20% (because it is only 1/5 of the way through the sales cycle). The Expected Revenue will be automatically calculated by SFDC as $30,000 (150,000 * .2).


As you’d expect, this Expected Revenue amount will change over time as the probability changes, the amount is revised – or both.


Some related advice: So since I didn’t see this in the documentation once upon a time, how did I figure out what was going on? Two things:

1) I asked our SFDC Admin what the field was and how it was calculated. Make friends with your SFDC admins – they can help you better understand what the data in SFDC is and how it works and help you troubleshoot if data just doesn't seem to make sense.


2) I had user access to my organization’s instance of SFDC so I spent a lot of time in there just getting familiar with, not only opportunity data, but what my sales colleagues were entering (or not entering) as data for accounts, contacts, leads, custom objects etc. Get familiar with SFDC and the sales processes that drive its configuration and use. By doing so, I was able to work with our sales operations group to make changes to SFDC that benefitted both our sales users and the data we were getting in Marketo.

One of the unsung heroes of the Analytics tab is, in my opinion, the Company Web Activity report. If your organization is B2B, this report offers some powerful utility for your sales and sales development teams by letting them know which companies have people visiting your website - companies that, perhaps, are researching for buying purposes.


Out of the box, the default Company Web Activity report will look at the last 7 days of activity with Known people (leads). This one is automatically great for sales people - particularly if you continue to sell to customers (you aren't offering a one-and-done product or service). You can see, of all the people you know in your database, how

many from your accounts are visiting your website - how many people, how many page views, and when the first and last activity was.


But I also like to offer sales teams an Anonymous Company Web Activity - Past 7 Days report. This specifically tells them which companies with people we DON'T know - i.e., not cookied leads in the database -  are on our website, with the same data above. The only thing you change in this report is going from Known leads to Anonymous leads in the setup tab. Depending on your industry, you may or may not want to filter out ISPs for those anonymous leads. Regardless, when you're looking to Anonymous leads, they are more likely to be, though certainly not exclusively, from accounts you AREN'T at. This report is often a particular favorite of sales teams.


I also like to further customize this one to offer an Anonymous Company Web Activity - Past 7 Days - Target Customers report. In this one, the same setup, but in the smart list, I add an "inferred company" as a filter. Here's where you can add the names of companies/accounts your sales team is particularly interested in securing for your business - it could be your "unicorn" accounts (those magical ones you desperately want to lock down!) or accounts where you know a competitor currently has their business - that's a particularly fun one, as if they're your competitor's customer, but looking around on your website? That's behavior I would want to know about as a sales person!


Screen Shot 2017-03-14 at 1.43.34 PM.png

I've also further customized each of these reports for some of my clients, leveraging the "inferred state region" or "inferred country" for sales teams organized by region. You just clone and customize for each region.


Remember, each of these reports can have subscriptions. Weekly is a pretty typical frequency, but depending on the volume of your web traffic, the length of your sales cycle and even the processes and preferences of your sales people, you might do daily instead.


How many of you are using the Company Web Activity report functionality - and in what other ways are you using it?

I recently encountered an issue where a webhook I was working with kept failing. The lead fields I was passing over in the webhook via tokens I knew were correct, yet the webhook continued to fail.


Here is part of the webhook payload:

&first_name={{lead.First Name}}&last_name={{lead.Last Name}}&country={{lead.Country}}&email={{lead.Email Address}}&parent_email={{lead.Parent’s Email}}


Did you spot the issue? It’s very, very subtle.


Okay, let me put it like this – do you see a difference between these two values?


lead.Parents Email

lead.Parent's Email


Yep, it’s that seemingly innocuous “curly” apostrophe in the first value. What Microsoft likes to call a “smart” apostrophe versus a straight one. Guess what? It’s a unique character compared with a straight quote, and one that many data systems can’t read/process. When the webhook was built, it had been built in a Word document and then copy/pasted into the webhook payload template in Marketo. And since it came from Word, Word automatically turned the apostrophe curly.


If you’re building webhooks, be sure to copy/paste from Notepad or a similar plain text program. Better yet? When it comes to data, apostrophes and punctuation is generally best avoided if you can.

When I first started using Marketo as a client, the ability to easily create forms that could capture prospect and customer data and get it directly to my sales team via our CRM was heady stuff. We were suddenly going from a situation where users bounced around our website gathering all of our information while we gathered none from them, to one where we could gate EVERYTHING and ask EVERYTHING.


So, naturally, we did.


You can guess how that went! At Marketo, we recommend that you be strategic about your content and when you gate it. Top of Funnel (TOFU) content that builds general awareness of your brand and demonstrates your thought leadership/expertise in an area should be open to all potential prospects. In the Middle of the Funnel (MOFU), more useful content that may be proprietary to you (think RFPs, buying guides, calculators, industry reports) should be gated. And finally, at the Bottom of Funnel (BOFU), we recommend opening the content up again - this content (product comparisons, etc.) is generally most valuable to prospects who are already engaged with you and your sales team and is affirming their decisions.


But when it's the appropriate time and place to gate content, clients often struggle with how much prospect data to request on the form. I always boil it down to this: What's In It for Me? And I don't just mean me the prospect, but also me the marketer.


What's the value for the prospect? This one is fairly obvious, but hard for marketers because we can be pretty biased about the awesomeness of that tool/guide/calculator/report we're offering. Put yourself in the prospect's shoes instead and be brutally honest:


  • Can the prospect get this information elsewhere?

  • Are my competitors or anyone else offering something like it (and if so, are they gating it)?

  • Does this content answer a question my prospect needs to help solve their problem?


The more exclusive and useful the content is, the greater its value to the prospect and the more likely they are to a) fill out the form in the first place and b) fill in more fields to get it. Even subconsciously, prospects are looking at the form between them and your content and evaluating "do I think this will be worth the time to fill out and/or the release of my personal information to get?" So if the value is lower, per the above, consider either not gating it until you can make that content more valuable OR make sure your form is short and sweet.


But also think "What's In It for Me?" as a marketer - what's the utility and value of the data you're requesting on the form? If it's a contact request form, it makes sense to ask for a phone number. But for a buying guide or a report? You don't need that data to deliver the content the prospect is asking for, so why are you asking for it? If this is the first form your currently anonymous prospect is visiting, will they find a "phone number required" field off-putting for a guide? Probably. Do you need to know what their job title / role is in order to provide them the right version of the guide/tool etc.? Definitely ask, but consider explaining to them that's why you're asking. Transparency goes a long way with prospects when asking for data.


Now, eventually, as you take your prospect along your customer journey and get them to engage with more and more of your un-gated and then gated content, you will need more and more information from them in order to fully qualify them for your sales team. That's what progressive profiling is for! From form to form, you'll ask them more and more qualifying information and it will a) be easy for them because it's only a couple of questions at a time and b) make sense to them because what your'e asking should also be tracking to their customer journey (region of the world, buying timeframe, buying role, etc.) It won't feel invasive, intrusive or unnecessary to the value of the content you're offering.

I had a Marketo client ask me recently if there was a "best practice" on whether or not to use Marketo for internal (employee) communications.  Here's what I told her: There's no best practice on whether or not you should have employees in your database other than for seed list testing but I do believe there is a best practice for how to manage them if and when they get in there.


There are Marketo users who strongly believe that the only people in your database should be customers and prospective customers. I know some who will go so far as to ONLY include prospects, not existing customers, viewing it very much as a MARKETING database only (customers remain in the CRM only). I also know Marketo users who proactively use our platform for internal communications as well as communicating with prospects and customers.  Depending on your organization, your markets, your data requirements and your business needs, ALL of these can be the right choices in my view.


But what I do encourage Marketo users to do is to plan for employees in the Marketo database and build accordingly:

  1. First, create a custom field in Marketo - something like "Is Employee"

  2. Then create a basic data management smart campaign that marks everyone with your company's email domain as "Is Employee" (for example: If email address contains "" change data value "Is Employee" to TRUE. You can schedule it as a recurring batch (with an "only go through the campaign once" constraint) to catch any new employees who might come in through form fillouts, imports, etc. over time


By taking these two steps, you now can easily filter out - or in - your employees as part of your smart lists and smart campaigns as you desire. Some clients will even use this criterion to do periodic, batch automations to delete employees from the Marketo database. It depends on your data concerns and your business use.


For nearly all clients, I will recommend that "Is Employee" is smart list criteria you use to remove employees from lead scoring and lead lifecycle programs and from various analytics reports. Except in a few cases, most organizations would not view employees as people they want to track for revenue modeling data and certainly don't want employees handed off to sales for followup as prospects. You can also use the "Is Employee" criteria to separate out their email performance and web page performance.


How about the rest of you? How do you feel about employees in the database and do you have different ways of dealing with them?

I recently worked with a B2C client on a campaign where they were targeting leads when they reached a specific mid-stage of the sales cycle with some SMS and email messaging. In their smart list,  they were triggering on Opportunity is Updated  with additional constraints around opportunity stage and the brand.


In reviewing their leads, they found that some leads at the appropriate opportunity stage didn't qualify for the campaign after it was turned on. As it happens, these leads had been converted to opportunities and immediately placed in the qualifying stage versus earlier stages.  Therefore, their opportunities were not UPDATED; they were in fact, Added to Opportunity. By bringing in an additional trigger (Added to Opportunity) with the appropriate constraints on stage and brand,  the two triggers - which, remember, work as "OR" statements - captured all leads once reaching the right opportunity stage.


I wanted to do a quick blog post on this for two reasons:


This is not an uncommon issue: Users sometimes forget that Opportunity is Updated excludes leads whose opportunities are first created (Added). You similarly see this with Data Value Changes - when a lead is created and their field values are populated, this first writing of data to fields doesn't count in Marketo as a "change." So I thought it useful to call this out as a reminder.


Perhaps more importantly, this situation highlighted how important it is to understand your sales teams' processes.  When salespeople create opportunities, do they "skip" stages (i.e., bring someone in "midway" through) and if so, why? Is this something that makes sense for your sales process and therefore should be accommodated in your Marketo build, or is this an opportunity to help sales improve their processes?


So when you see something like this occur in Marketo, focus not just on correcting your smart lists but also using it as an opportunity to examine your related sales and marketing processes and make sure they are working as planned.

In case you missed it, Marketo just introduced with the Summer 16 Release our new integration with Vibes, a terrific new way to leverage SMS within Marketo. Isn't it great? But many of you have been using, and may continue to use, the services of Twilio, one of our other wonderful Launchpoint partners.


I've previously posted about using Twilio for SMS and wanted to share a few quick thoughts on some additional lessons learned:


I recently received a request to include fairly long URLs with querystring parameters within some SMS messages my client was sending out. Obviously, SMS messages with a long URL could cause an issue - though Twilio does offer messages over 160 characters with its Messages Resource UI. However, Twilio also offers automatically URL shortening, which is probably advised as a very long link with querystrings is not particularly attractive in an SMS message. We did test this functionality and it does work as expected, with query string parameters being preserved with URL shortening.


One thing that is important to understand, though, is that with regard to being able to measure/report on link clicks, this is not something that is out-of-the-box supported with Marketo's analytics tools. There is no "clicks link in SMS" filter to use for smart lists. If you've used a unique querystring for the message, you can create a web page performance report to show known or anonymous leads that visited the page with that querystring. (And of course, if you have Google Analytics or similar, you would see the traffic there as well.)


Keep in mind, people may be cookied on their computer but not necessarily on their phone - it depends on if they've previously engaged with your emails on their phone, going to a munchkined page on that device. So using a "Visited Web Page" smart list to look for that querystring will only show you known leads who visited that page with their cookied mobile device - and that may be a lower number.  (I know for myself, I will typically read emails on my phone but if there's a link to a website, I may wait to do so when I'm back on my laptop, as many pages are, sadly, still not as mobile-optimized as they could be.)

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.

Wait steps can be powerful in the flow of a smart campaign - allowing you to create really customized timing in your interactions with your customers, either by wait steps of duration, date or date token.


But it's important to realize that when you have longer wait steps, this could have an impact on which leads are truly moving through your smart campaign. The ones you qualified to enter the smart campaign may not qualify any more, because their data has changed during the wait time.


Smart campaigns qualify leads at the time they are triggered or are run (batch). The smart campaign doesn't automatically re-qualify leads after a wait step.

SMS wait flow step.pngA recent example I worked on: You are running a campaign to send a series of SMS messages to a targeted segment of your audience. One of the requirements of that targeted list is that they are opted in to SMS messages. They will then receive weekly SMS messages about a particular topic you've targeted them for. You build the smart campaign flow to send an SMS message, wait 7 days, then send the next SMS message, then wait 7 days and so on.


Here is the potential problem: within the 7 days of any of those wait steps, your lead could have opted out of SMS messages. In this campaign, however, she qualified at the time she was put into the initial flow - the smart campaign does not re-qualify people to make sure she still meets the criteria of being opted in.


(Now, of course, we were working with a reputable SMS messaging service that would prevent a message from going to our lead who has opted out even if we tried to send it. Nonetheless, you can certainly imagine other scenarios where smart campaign  qualification criteria being maintained throughout a long flow would be important and certainly I would want to prevent SMS messages from even trying to be sent to someone opted out, regardless of whether the service would stop it.)


But as with nearly all things Marketo, you've got options!


SMS wait with remove fromf low.png

Build in a "Remove from Flow" step. If your smart list criteria is fairly straightforward - particularly if only one or two changes would change the lead's qualification - you can simply ask Marketo to check and make sure the lead still meets a particular criterion, and if not, remove them from the campaign flow. The default choice = do nothing. Then everyone else who is still opted in passes through but those who have since opted out are taken out. You could even add in an additional Remove from Flow step to also filter out any other criteria change that might be critical (such as their targeted product interest changing).


Use Batches for Time Insensitive Campaigns. In another recent use case, we had a client for whom it was very important that certain criteria be met about the lead and this criteria could change for individual leads fairly often. They'd built a smart campaign as the initial form fill out (plus several qualifying filters) triggering a flow that involved several actions over a period of a couple of days. Only a few of the initial steps were time sensitive (needing to happen almost instantaneously after the trigger). But all of the steps were critical in terms of only being applied to the leads who really met the criteria. In this case, what made sense was to limit the triggered campaign to those truly time-sensitive actions and then take the remaining steps and turn them into daily scheduled batch campaign(s), so that the significant qualifying criteria could be run before each less-time-sensitive action.


Shout out to Kristen Carmean, who said to me yesterday, "You know, someone really ought to write a blog post about this"!

When I helped a client implement SMS messaging in their Marketo instance using Twilio, we leveraged John Mattos’ great blog post about it quite a lot. And along the way, I also learned some things that I thought might be useful to others. Like many of our great Launchpoint partners, Twilio leverages Marketo’s webhooks to engage with the Marketo instance. So this brings up issue #1:


Webhooks Always Require Triggers

First, and this comes up in the comments on John’s blog post but it bears elevating – when calling a webhook in your smart campaign flow, it must be a triggered smart campaign. All Marketo webhooks require triggers. In the case of this client, we use “data value changes,” as we are looking for a specific value to change in order to ask someone to opt in to SMS messages. I've also seen "Campaign is Requested" from a Marketo flow action. When testing, we leveraged the “Add to List” trigger and spent many hours moving our internal guinea pigs onto and off of a static list to trigger the Twilio webhook call that would send the SMS messages we were testing. And speaking of testing:


Use the Activity Log or Smart Campaign Results for Additional Detail If Something Goes Wrong

Occasionally, during testing, the webhook failed (an important reason to test!) – we could see this in the Activity Log for our test leads or in the smart campaign results. Don’t forget to click on that log item to get more information – it almost always tells you everything you need to know to solve the issue. In this case, we didn’t realize one of our test leads had inadvertently opted out during testing – but Twilio knew and prevented the SMS from getting to him, exactly as we would hope it would! Which brings me to the final insight:


Set Up a UAT (User Acceptance Testing) Plan to Test All Possible Outcomes

As noted above, we had a tester opt out of the SMS messaging before we intended him to and had to spend a little time figuring out why his SMS send failed. Take just a few minutes to set up a plan of who will be testing, who will be responding (or not responding) to the SMS message and how, and document what the expected result will be. For example, if they opt in, do they get the expected confirmation message? If someone opts out and then opts back in, what happens and how long does it take to happen? Was the result expected? What if someone responds with an SMS message that isn't in the "Yes" or "No" category (Yes, you will have leads who respond with some colorful language!) All of these things should be tested to ensure the results are as expected. By the time the client and I got to our third phase of SMS messaging, we could count on testing to be both rigorous AND quick because we had it down to a science!

Following up on Kristen Carmean's awesome blog post with great examples of Velocity scripting, I’ve got another example of a basic email token Velocity script that allows you to serve up dynamic content without segmentation or snippets.


While Marketo's segmentation functionality is terrific, there are times when it isn't what you need when you want to deliver dynamic content based on the customer's data. Especially when the dynamic content you need isn't based on an either/or scenario like salutations (Mr. v. Ms. or U.S. v. Canada).


I’ve had multiple requests for a use case similar to the following:


A lead fills out a form or otherwise has data in their record indicating interest in multiple products/topics/requests. The lead can choose more than one topic, making segmentation and snippets undesirable, as you can be in only one segment at a time within a segmentation and building a segmentation for each topic area is not always feasible in many Marketo instances. The lead then receives an email response with dynamic content based on the topics they requested.


For our example here, we will be a fictional company offering a variety of dog-related topics (Training Tips, Toys and Accessories, Nutrition and Health and Adoptions) that customers can get a monthly email update about by registering via a form. This data about their interest is captured in individual custom fields in Marketo, though it could also be associated with the lead via CRM fields as well.


We will send out an email auto response confirming the topics they signed up for and providing a brief update on each topic. Only the topics they signed up for will be in the email copy.


To accomplish this, we leverage very basic Velocity #if and #end functionality. (If the value is “X,” make this text appear and then end the script.) You can do this all within one token and have the script address each value one after the other. In this case, our fields = "1" when a lead has selected that topic.


#if (${lead.mktoAdoptionsandRescues} == "1")

Adoptions and Rescues: Meet our latest furry friend, Charlotte, who is available for adoption. Charlotte is a mature, 7-year-old basset hound who would love nothing more than finding her forever home and would do well…



Dog Topic Selections.png

#if (${lead.mktoToys} == "1")

Toys and Products: All of our dog companions here are just wild about the new backyard tug toy  from ACME Dog. Your dog gets all of the yanking and pulling play time he love, without the strain on your arms…



#if (${lead.mktoTrainingTips} == "1")

Email with Tokens.png

Training Tips: Are you saying "Down" but the rest of your household says "Off"? Consistency is key to your dog understanding what you want. We've got a top 10 list of dog training Dos and Donts …



#if (${lead.mktoNutrition} == “1”)

Nutrition and Health: Dogs can get the flu too – it’s time to start thinking about Fido’s annual vaccination. Talk with your vet about…



I’ve saved this email script token as {{my.Dog Content Updates}} and have placed the token within the body of the email.Note that in my own record, I have only signed up for the Adoptions and Training topics, and those are the only pieces of content that appear, and without obvious space/breaks between the topic script pieces that don’t apply.

Email with Script Result.png


Bonus Tip One: Not strong on html writing? (Neither am I.) Build an email where you write and format the copy as you like it. Embed links, create bolded headlines, etc. Then go into the html of that email and copy the text as formatted. For example, the script piece for Adoptions actually is in my token as

<p><b>Adoptions and Rescues</b><br>

Meet our latest furry friend, Charlotte, who is available for adoption. Charlotte is a mature, 7-year-old basset hound who would love nothing more than finding her forever home. <a href="" target="_blank">Learn more</a>...</p> (Depending on how your email template is se


Bonus Tip Two: Consider your content carefully. Each topic/brand/request needs to be able to stand alone, as the lead may or may not have requested two that you are tying together. Also consider content length – if each piece is long and the lead signs up for all of them, this could make for a very long, unwieldy email (and depending on your email template, might look a bit clunky). For the same reason, I would be cautious about the total number of topics/brands/requests that can be selected in this type of delivery. It’s a balancing act – the more topics, the shorter the content should be. I might only use 4-5 for a content piece like the above, where you’re delivering almost newsletter “blurb” pieces of content of a few sentences. For an email that is simply listing a customer’s selections without additional content (say, confirming someone’s subscription choices without providing content for them), you might be able to get away with 10-12 choices.


I should add that I'm not in the least fluent in Velocity script - but I suspect many of you may be in the same boat. This is just a simple script token that I think can be applied in many typical, fairly straightforward use cases for Marketo.

Lead List.png

Consider a lead nurturing program for people who love basset hounds. (Anyone who knows me knows I would be the first person on this list.) Your sales team has given you a .csv file of customers that they would like you include in this nurturing program. So you import them into a static list within your engagement program. But they don't show up as members in your engagement program. What gives?


Something that often slips up even the most experienced Marketo user is the idea of what makes someone a member of a program. Many of us use static or smart lists as local assets within a program to identify whom we are going to include within the program. But just populating those local lists with leads doesn't make those leads members of that program. Marketo doesn't assume list inclusion alone makes someone a member of a program, as you might have any number of reasons for creating a list within it and end up not using some or all of the leads within that list in the program. The Marketo program must take action on the leads in the local list in a way that tell it these leads are members of the program.


add to engagement.png

In this case, the easiest way to tell your engagement program that yes, these leads belong to this program as members, is to use a Lead Action to add the members to one of your program's engagement streams. Now Marketo understands that these leads in your list are members of your program – they are in one of its streams.


For other programs, like Default and Email Send, where you are using local lists, you’ll need to tell Marketo the leads are members by changing their program status. It’s that action that tells Marketo the members of the list are members of the program, regardless of whatever other action you may take on them.

import members.png


You can also use the Members tab of your program and import members directly into your program and set their status as members of the program - though in the case of engagement programs, you'll still have to take an additional action step via flow action or smart campaign to eventually put those members into streams.


Why use lists as local assets instead of importing directly into the program via the Members tab? It depends on the scenario. Sometimes using separate lists allows you to differentiate within the program between different sources of the members (sales-provided list versus people who attended a particular marketing event) or you'd like to keep a simple "snapshot in time" of who you originally brought into the program versus those who may come in later.  What other scenarios do you use local lists for?

When using triggers to either update lead data or to act upon that data, it's important to understand that triggers could cause smart campaigns to "compete" with one another. Consider the following scenario – taken from a Marketo client situation but revised for a fictional organization that sells animal products and services. This organization require two separate campaigns - one to set the brand (animal) preferences of prospects and another to specifically sets a new lead's emailability for that brand (animal).


The Case:

Smart Campaign 1 - Set Animal Preference: This triggered campaign qualifies prospects as a dog lover, cat lover, etc. This campaign updates the mkto_Loves Dogs field to "true." The campaign is constantly qualifying new prospects based on specific forms they fill out, opportunity activity, etc.  SM1-SL.png



Smart Campaign 2 - Set Communication Preference by Animal: This triggered campaign qualifies prospects in the database as emailable for dog-focused content. One of the filters in this campaign is that mkto_Loves Dogs = true. If they qualify, the Marketo field mkto_Emailable Dog Lovers is updated to "true." This field must be true for a prospect to receive any promotional communications about dogs and is leveraged by the dog brand marketing team in all of their smart lists to simplify identifying emailable prospects.




Over the next several weeks, most prospects that should have qualified for Smart Campaign 2 didn't. Several thousand dog-loving prospects were not getting their emails about dogs. So what happened?


The Investigation:

If you haven't already guessed from the title of this post, the two triggered campaigns were "racing" one another and, often times, the second smart campaign setting them as emailable for dog communications was the *****. The triggers in each smart campaign could initiate at the same time - and often did, as the same activities that might tell the system the prospect was interested in dogs could also indicate they were emailable. 


In Smart Campaign 2, the prospect has mkto_Dog Lovers = true as one of its filters to determine emailability for dogs. But many times, Smart Campaign 1, which set the Dog Lover value, hadn't finished running at the same time Smart Campaign 2 triggered. The prospect would then fail to qualify for Smart Campaign 2 and would not be marked as mkto_Emailable Dog Lover = true.


The Solution:

Since Smart Campaign 2's ultimate priority was to identify prospects who are Dog Lovers in order to then determine if they can be emailed about dog communications, we modified the campaign. Instead of using the mkto_Loves Dogs as a filter, we made a change to it a trigger, then kept the remaining filters around email validity, unsubscribes, etc. With this in place, Smart Campaign 2 remains a triggered campaign but will never fire prior to the prospect's Loves Dogs value being set via Smart Campaign 1.


As we all know, there are many ways to build things in Marketo and this is just one way to achieve brand communication preferences. The CRM and sales processes of this fictional organization required that the two processes - establishing brand preference and establishing brand emailability -  be separate and be triggered in real time off of some specific events as part of their process. Creating batch campaigns with coordinated schedules would be another option to resolve this issue. So just keep in mind that if you have two campaigns triggering off of similar criteria, and one campaign relies on the values set by the other, they may "compete" with one another. You may have to take a second look at what your triggering criteria really needs to be.


Bonus Tip! Don't forget that triggers never operate together as "and" the way filters can. They are always "or." So in smart campaign 1, being added to a K9 opportunity OR filling out the dog form would trigger the smart campaign.

Filter Blog

By date: By tag: