Skip navigation
All Places > Products > Blog > Author: Jodi Florence


7 Posts authored by: Jodi Florence Employee

Marketo's segmentation feature is a fantastic way to easily carve out your database into specific audience segments to deliver dynamic content. Rather than having multiple email versions to edit, approve and send through smart campaigns, dynamic content allows you to create one email with different versions for specific sections of content in it.


The drawback of using dynamic content comes into play with reporting. While a segmentation can be applied to the smart list or used as a grouping in the set up of the email performance report, this only provides a filter of the data based on the segment someone is currently assigned in the segmentation – not where the person lived when the email was delivered using the segmentation.


For example, let’s say you sent an email in March with dynamic content based on a segmentation for Job Title – Manager v Executive.  At the end of March someone gets a promotion (yay!). The same report you pulled in March will show discrepancies if you pull it in April.  Take a look:


Standard Email Performance:

Standard Email Performance.png

Email Performance grouped by Segmentation:



In March

March Segmentation Report  .png

In April

April Segmentation Report.png


The April report implies that the Executive version of the email was delivered when in fact it was the Manager version.


In most cases segmentations are created based off data that rarely changes, so this reporting discrepancy is not a big issue. But if you build segmentation rules on data that can change often – like the example above – the metrics might not be telling the right story depending on when you are analyzing the data.


Best practice to avoid this is to run any reports using a segmentation immediately and always refer to the results at the end of the quarter or year for any summary reporting. If this is not an option and there is an important requirement to know exactly which “version” of an email someone receives then you should (unfortunately) create multiple email assets. While it might seem inefficient, Marketo still provides ways to streamline the build process with tokens (folder and/or program level) and cloning capabilities so that you can quickly get emails out the door.

Many new customers are confused as to how Marketo’s munchkin code works when it is applied on different, separate domains. They often expect to be able to automatically track behavior on multiple domains just by using the munchkin code and cooking someone once.


Unfortunately, (and fortunately) it doesn’t work this way. If you could set a cookie for any domain, well, you could inject your munchkin javascript to any site and set a cookie for any domain. Think of the privacy laws and security havoc this would wreak.


Marketo’s munchkin uses what is called first party cookies. Put simply for non-technical folks, this means that each record in your database must be cookied in each domain first before we can track their behavior.  The good news is once a record is cookied in more than one domain all their web activity is combined into the activity log of their record in Marketo.


As a reminder, these are the primary out of the box ways a marketer can set cookies on a domain with very little, if any, technical resources involved:


  • Marketo Forms – embed Marketo form(s) on the domain so that once someone fills out a form they are cookied
  • Click links in an Marketo email - send an email to your database with links that when clicked will have the record land on a page on the domain where the munchkin code has been applied. When the person clicks the link, they are cookied


If you have a technical resource available to you, there are other ways you can set cookies using our APIs and no Marketo forms or emails. While the two methods above require very little technical resources, you do need a lot of creativity in creating your call to actions – which is exactly what marketers do best.

If you are using  tokens in emails you have probably noticed that if you do not define a default value when inserting the token, Marketo populates language of "edit me" automatically as a default. This is to still give you the option in the email editor to define a default value for whenever the data field of the token is empty without having to re-insert the token.


So what happens if you leave 'edit me' as the default value, will people see this when they get the email and there is no data in the token field? 


Nope.  The system sees it as a null value. Even if you use Send Sample it will not appear, unless you have accidentally deleted one of the brackets around the token. Remember to be extra careful when you are editing {{tokens}} to not remove the brackets, otherwise the whole thing will appear in your email and that would be {lead.token:default=super embarrassing}}.

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.

Many of our clients migrate to Marketo from other marketing automation platforms and want to understand the differences between our email performance and their previous provider.


I have been working with one such client who sends a large bi-weekly newsletter. While the send, delivered and opens rates are on par, the clicked rates had some discrepancies.


Here are some things to consider when embarking on your own comparison:


  • Marketo’s Clicked column means people who have clicked one or more links in the email. Be sure the competitor is talking the same language in any type of Click metrics.
  • Check the math – in doing number crunching between reports, we discovered that the other provider uses different dividing metrics in their calculations. Marketo uses (Unique) Clicked/Delivered to report on Clicked %. You can’t rely on a pure side-by-side comparison of the reports, you need to dig in and crunch the numbers yourself.
  • View as Webpage link in an email is not a metric that is counted in the Marketo Clicked column (Note: if a person then clicks a CTA link on that view as webpage, it will be counted in the clicked column*) Marketo doesn’t report on view as webpage links at all – and I’d argue that if we did, this type of “click” should be counted as an open, not a click. Read more about view as webpage here:
  • Delivered size and content varies with each send which is the ultimate driver for your clicked reporting. A true apple to apple comparison on a specific email’s performance can only happen by running an A/B test between platforms. Even then, there are going to be differences based on the technology.


To fully understand the implications of View as Webpage for this target audience, we designed 3 test scenarios to perform within Marketo with the next few newsletter sends. These are:


  1. Create a landing page with the same newsletter content on the page as if it were the view as webpage. Replace the {{system.viewAsWebpageLink}} with text and a normal href to treat this like any other link in the email
  2. Move the {{system.viewAsWebpageLink}} reference lower in the email so that it is not as prominent of a call to action at the top of the Newsletter
  3. Remove the {{system.viewAsWebpageLink}} offer all together to see if that drives more actionable clicks


*Special thanks to Susan Sauter for helping to verify the CTA clicks on view as a webpage.

One of the hardest things about using targeted web personalization campaigns is testing the campaign before launching it. Within Marketo’s automation platform, there are a host of testing techniques available including being able to see how emails and landing pages look in different browsers or email clients, viewing dynamic content as a specific person or as part of a segment within a segmentation, and creating seed lists or using filters to run smart campaigns to perform an end-to-end test of a program.


With web personalization, testing web campaigns is trickier since the IP information of the person doing the testing might not qualify to actually see the campaign.


Here are the various ways to work around IP information limitations in increasing complexity and level of effort:


1.  Preview on site

Preview on Site .png

The preview on site functionality allows you to see a campaign on a specific web page before launching it. In fact, by checking “Via Proxy” you can use this functionality to see how a campaign will look on any website regardless of if the web personalization tag has been installed on that site.  Clicking the share button will generate an email with a link for someone else to preview the campaign. When using the share feature, the campaign link is still based on session times so keep this in mind if you are sharing widget or dialog campaigns.


2. Sandbox segment


Screen Shot 2016-07-25 at 4.09.11 PM.png

Create a specific test segment where the rules of the segment are based on specific URL matches of Sandbox=1 (or similar). Update the Target Segment of your campaign to the Sandbox segment and launch the campaign.  Then, visit the web page where the campaign should appear and add the sandbox URL parameter to the end (e.g.  When using the sandbox segment, if edits are made to the campaign, the changes will not show on subsequent visits without a person clearing their browser cookies or a session time expiring.


3. Configure a QA site as a separate domain


Depending on your contract, you may be able to add your development site as a separate domain within your instance. However, the IP restrictions of segments still apply so you will need to ensure that anyone performing testing still meets the criteria of the segment. Usually test websites are only accessible behind a company firewall so people performing any tests need to be able to access the test website. Given the level of effort and maintenance, this method is usually only used for an initial implementation and occasionally to test new In Zone and/or API campaigns after web personalization is live on a web site.


Want more how to details on using these different test methods? Visit

A client recently asked me if a sales rep used Marketo Sales Insight to send an email which was in an engagement program, would that email be sent again in the nurture or skipped.


In theory, it seems like the nurture program would not send the email since it is the exact same email – it was just enabled for Sales Insight in the email settings.  This, however, is not the case when using out of the box functionality of Marketo.


While the email is the same content and just one email to edit within the UI, the Marketo platform sees this one email as two individual emails on the back end. 


Why?  Because every Sales Insight email is assigned a unique ID to help Marketo’s system distinguish between a “marketing” email and a “sales email” when it is sent. It is this functionality that allows the Sales Email Performance report to be generated and grouped either by Email or Sales Rep.


The engagement program looks for the unique ID of its email, and since the nurture email has not been sent to the person, it will indeed be sent again.


Because seeing is believing, here are the test results that show how the system considers the email two separate emails.




Now, you can set up a more complex engagement program using nested default programs, program statuses and add choice flow steps to trick the system into thinking an email has been sent to someone before and therefore have it skipped inside of an engagement program. But this is a topic for another day. If you would like to learn how now, reach out to and learn how our professional services team can help. 

Filter Blog

By date: By tag: