Skip navigation
All Places > Marketo Whisperer: Implementation Tips > Author: cf6e74f923461f259f8545a45b947aa7b1c66503

This is somewhat of an odd example to post, since there's a Gravity forms integration with Marketo. But, since it's SOAP API-based, I'm pushing my clients to move away from those integrations and use some of the newer APIs. I thought this would be helpful to show you because there's surprisingly few actual examples of doing the Forms 2.0 Javascript API post method that Kenny Elkington recommends. You can probably use this to extrapolate to some other form systems.


So, our goal was to do a hidden form submission from a Gravity form to a Marketo form using the Forms 2.0 Javascript API. This allows you to use your existing forms on your website, but still get a copy of that form submission into Marketo, allowing you to not only have the data in the system but also trigger off the Fills Out Form activity. (A primary benefit of not using the SOAP API method.)


The yellow highlighted section in the code below should be replaced with the Embed code for the form you have built in Marketo as directed in Kenny's post. It is not necessary for this form to have any fields on it, as you will be coding the desired fields.


The green highlighted section should be replaced with the Gravity form ID. To identify the form ID, go to the page with the Gravity form on it, and right click to View Page Source.


In the code, search for the section that begins with <form method=’post’...> The area with id=’... is where you will find the ID for your form. The form id for this form is gform_2.


The blue highlighted sections should contain the SOAP API names of the fields you wish to capture information in on the Marketo lead record. The SOAP API names of the fields can be found by exporting field names in Admin > Field Management.


The red highlighted sections should contain the Gravity form field ids that correspond to the fields that capture the information you wish to store in the corresponding Marketo form field. You can locate these by right clicking on the form field label on the Gravity form and going to Inspect Element.

This will take you to the label section of the code. Underneath that, you should see a section beginning with <input id=”...> This is where you will find the ID that corresponds to that field. In the example below, the input_2_3 refers to the field for Email.


<script src="//"></script>

<form id="mktoForm_0000"></form>

<script>MktoForms2.loadForm("//", "000-XXX-000", 0000);</script>

<script type="text/javascript">

$(document).ready(function () {

   $("#gform_2").submit(function(event) {

      var marketoForm = MktoForms2.allForms()[0];


  //These are the values which will be submitted to Marketo

  "Email": $('#input_2_3').val(),

  "FirstName": $('#input_2_1_3').val(),

    "LastName": $('#input_2_1_6').val(),

"Address": $('#input_2_6_1').val(),

"City": $('#input_2_6_3').val(),

"State": $('#input_2_6_4').val(),

"PostalCode": $('#input_2_6_5').val(),

"Phone": $('#input_2_2').val()



     return false;





And that's that. (No doubt here comes Sanford Whiteman to come tell you how to do this better. Always cleaning up after me !)

In a flow step, you can add a choice “Program Status is” or “Program Status is not”. When you look at the dropdown options, you will only see program statuses that apply to the program the smart campaign lives within. For example, if the smart campaign is inside of a Live Event program, you will only see the program statuses available for the Live Event channel.


However, people sometimes wonder if this choice applies only to those who have that status within the program or if it applies to anyone who has that status in any program with that same channel. After testing, I confirmed that this only applies to the program that the smart campaign lives within. If you have one individual with Registered status in Program A and one individual with Registered status in Program B, a smart campaign built within Program A will only apply to the first individual; it would not apply to the second individual.


In Marketo, there are often multiple ways of designing the same program using one or more smart campaigns, particularly when it comes to nurture. Not all ways of doing things are equal from a performance/efficiency standpoint. I recently had the opportunity to do some testing to confirm which of the variations would be the most efficient and which tradeoffs are worth making.


Note that throughout all of these tests, smart list optimization techniques were applied as described in this earlier blog post.


These tests were run with batches of 20,000 leads to compare overall and average processing time. They were done with a specific campaign objective in mind and, as such, may not be applicable in all situations.


The basic premise of this campaign was that an Interest field was being populated by various actions in the Marketo database. Based on this Interest field, we wanted to check against a list of qualification criteria to update another field, indicating which nurture program and which stream the person should be in. We then wanted to move them into the appropriate stream of the appropriate nurture.


Question 1: Are two triggers triggering off the same action better than one trigger with choices in the flow step?

Even this morning I saw someone suggest on the discussion forums that someone consolidate two identical triggers into one single campaign. I think this is a pretty common viewpoint among Marketo users, even myself. But is it always the best choice? In this particular example, I had several filters on the smart list in addition to the triggers. I ran a test of this variation against a variation in which I moved the qualification criteria into the flow step and combined the two campaigns into one campaign, but using choices and referencing smart lists containing the filters.

Variation A (criteria in SL)

  • Average run time of campaign A: .1557 sec per lead
  • Average run time of campaign B: .2115 sec per lead
  • Summed total processing time for 20,000 records: 7,500 sec

Variation B (criteria in flow with choices)

  • Average run time of combined campaign: .3539 sec per lead
  • Summed total processing time for 20,000 records: 7,077 sec

So, as you can see, the difference is relatively minimal. However, since in Variation A, I can be running two campaigns simultaneously, the total time to complete could be slightly lower. As you add additional flow steps with more choices, however, the performance of Variation A pulls away from the performance of Variation B.


Question 2: If I have shared criteria across multiple campaigns and want to move them into a smart list to make it easier to manage, how much efficiency gain do I lose?

Often times when we're constantly repeating the same criteria over and over again, it can be tempting to pull that criteria into a central smart list to make it easier if we have to update it. But as most Marketo users know, Member of Smart List references do add a little more performance overhead. Is it still worth it? How much performance do we lose? I took the criteria from variation A and moved all of the shared components into a central smart list to test this out. (Note by this point I was doing tests on batches, not triggers, so my baseline comparison will be different from Question 1).

Variation A (criteria in smart campaign)

  • Average run time of campaign A: .2928 sec per lead
  • Average run time of campaign B: .1230 sec per lead
  • Summed total processing time for 20,000 records: 2,394 sec

Variation B (criteria in separate smart list)

  • Average run time of campaign A: .1122 sec per lead
  • Average run time of campaign B: .1385 sec per lead
  • Summed total processing time for 20,000 records: 2,471 sec

As you can see, the additional cost for moving the smart list criteria out into a central smart list was relatively small, so this may be worth doing in cases where you have complex criteria being used over and over and you want to maintain central management.


I'll share some more tests in a few days when I have a little more time to write them up.

What's a control group?

A control group is established in order to facilitate tracking the impact of a marketing campaign. It is executed by selecting a random sample from the target audience and excluding them from the marketing tactic. This allows you to filter out the effect of those individuals who might have purchased anyway as well as the effect of other channels that might be difficult to measure, such as TV or radio advertising.


What are the options for control groups in Marketo?

There are several ways of structuring control groups in Marketo. However, only one approach provides complete capabilities for program-level reporting, so if you want to report in Marketo (particularly in Revenue Explorer), having separate programs is your best choice. The chart below compares the four major approaches:



Lead Custom Field

Static List

Program Status

Separate Program

Can be in multiple control groups at a time





Works for both campaign and tactic-level reporting





Visible in RCA





Usable in all RCA program reporting







To see how this would be executed in Marketo, we will use the example of Campaign A, which will have a control group, and which consists of two marketing tactics: Tactic 1 (an email) and Tactic 2 (a direct mail), each of which will also have a control group. For the purposes of this example, we will set the control group at 10%.


Program Structure

For Campaign A, we create two programs – one to contain the eligible audience and one to contain the control group. We do the same each of the tactics. The channel utilized for the campaign audiences is operational, while the channels utilized for the tactics are selected based on the type of tactic (Email and Direct Mail).

Selecting Control Groups

Selecting control groups is done using Marketo’s random sample functionality, which allows you select a percentage of a target audience defined in a smart list and then take some action.


To select the campaign control group, we define our audience in the smart list and then run a Change Program Status flow action to select a random sample of 10% and add that group to the Campaign Control Group program. The balance of the audience is added to the primary program.


To select the tactic control group, we define our audience in the smart list based on membership in the primary campaign program.

In the flow, we then select another 10% of this remaining audience to pull out into a control group specific to this tactic. The balance is placed in the program that will complete the outbound activity.


The end result with 111 people who are initially eligible for the campaign would look roughly like this:




In reporting, the outbound program and the control group program can be viewed side-by-side for comparison purposes. To facilitate this by ensuring the programs show up next to each other in the reporting, I recommend naming them virtually identically, with the addition of CG at the end to indicate which program is for the control group.


Each program should also be tagged as being a member of that specific campaign:


This will allow you to group the control groups and the active programs to compare success rates and pipeline/revenue generated:

Note: There may be one small flaw here with my operational control group programs not showing up in the Program Opportunity Analysis report. I'm still testing various things to figure out exactly what's making them not show up. I'll update this once I figure out the best approach.


If desired, these programs can be synced to Salesforce using the Salesforce campaign sync.

What is a period cost?

Period cost is a Marketo term that refers to the amount spent on a program. This amount is defined by the Marketo user in the Setup tab of a specific program. Information on how to add the period cost can be found on the Marketo Community.


Why do we need period costs?

Period costs are important for reporting in Marketo for a couple of reasons:

  1. The default behavior in Marketo is to only show programs with period costs in Revenue Cycle Analytics (RCA) reporting. If you do not put a period cost in the program Setup tab, you will be missing valuable information from your reports.
    Note that you now have the ability to override this default behavior at the Admin > Channel level as well as at the individual program level if desired. However, there are still other reasons you should include period cost in your programs, as explained below.

  2. The Program Cost Analysis, Program Opportunity Analysis, and Program Revenue Stage Analysis reports in RCA have cost-related options for timeframe – Cost Year, Cost Quarter, and Cost Month.  If you do not associate some kind of cost, even $0, to a specific month, the program will not show up in any reports where
    you use the Program Cost Timeframe dimension. In the Program Opportunity Analysis report, opportunity-related timeframes are available, but in the other
    two, cost timeframe is the only time dimension.
  3. Much of the reporting available in Revenue Cycle Analytics utilizes cost to help analyze the effectiveness of marketing tactics. Metrics like Cost Per New Name, Cost Per Success, and Return on Investment will be meaningless without cost data entered into Marketo.


What costs should be listed as a period cost?

We advise that you capture variable costs in Marketo as period costs. Fixed costs, such as headcount and capital resources, are complex to add in and do not provide a large amount of additional value, since the primary purpose of cost reporting in Marketo is to enable comparisons between programs. By excluding fixed costs from all programs, we can obtain a reasonably accurate comparison without unnecessary work that is better suited to a financial reporting tool.


Variable costs that should be included in Marketo as period costs include agency fees, event sponsorship costs, pay-per-click fees, and any other incremental expenses accrued specifically for the execution of one program.


How should costs be allocated across time?

For variable costs that are accrued at a specific point in time, there are arguments to be made for accumulating the cost in the month it occurred, in the month the marketing activity is launched, or dividing it across all of the months the marketing activity is live. Although it is not as realistic, we advise that you allocate the cost to the month in which it was launched, because there is no other way in which to see the month the program launched in RCA reporting in the three reports that utilize cost timeframe and do not offer membership status timeframes.


Although you can choose to enter multiple period costs within a single month in Marketo, there is no reporting benefit to doing so. The descriptions entered in Marketo are not visible in RCA reporting and you are not able to see the individual costs per month. All of the reports show sums of period costs across the given time period. For this reason, it is simpler for the Marketo user to enter the sum of the costs for that month in one single period cost entry in the Marketo program rather than breaking them
out into multiple entries, which has no effect on reporting.


How should we manage period cost for ongoing programs and/or programs with no variable costs?

For programs with no variable costs, such as most web form and email programs, we advise adding a period cost of $0 or $1. Whether you choose $0 or $1 only impacts what you see in the cost-related columns in reporting. If you select $0, you will see dashes or N/A messages. If you select $1, you will see very large, essentially meaningless numbers or $0 instead.


For ongoing programs, we recommend setting up multiple period costs when you do the initial setup of the program. For example, if I have a web form that will be live on the website for the entire year, when I build the program, I can add 12 period costs of $0 beginning with January. This will ensure that the program’s new names and successes are always available in your monthly and quarterly reports.


What if I do not want to enter period cost manually?

While you can enter period costs manually, it is also possible to populate period cost using the REST APIs for programs. The Update Program API call allows you to pass in cost information to an existing program. You can also create a program via the API using the Create Program API call, at which point you could choose to pass in the cost.

One of the more laborious parts of setting up the Dynamics integration is figuring out which fields you want to sync over. Once you do decide that, you have to actually match them up in the Marketo interface so you make sure you select the right ones.



This can be especially challenging when you have many fields with very similar names. Does this look familiar to anyone? (How many phone fields does one CRM need?)

So here's the trick. Click on the purple column header where it says Name and Type. You can actually add in "Id" to the view . This shows you the schema name, which you can match up against your CRM system.

Then it looks something like this:

I wanted to share a few more email scripting examples with you.

Example 1: This script lowercases a string (in this case First and Last Name) and then properly capitalizes it.


(I think the previous example I gave only capitalizes the first letter, so if you had mixed case or all capitalized letters, it is not as good as this one.)

#set ($fname = ${lead.FirstName.toLowerCase()})

#set ($lname = ${lead.LastName.toLowerCase()})

$display.capitalize($fname) $display.capitalize($lname)


Example 2: This script adds a date 14 days in the future onto a token being used in an email.


## Access Velocity's calendar object

#set($x = $date.calendar)

## Format date

#set($current_date = $date.full_date)

## Add 24 hours (hours=int code 10 - see list below)


## Show result



Example 3: This script gets the current date from the calendar object, converts it to a date and then reformats it to the format highlighted in yellow.


#set ( $todayCalObj = $date.toCalendar($date.toDate("yyyy-MM-dd H:m:s",$date.get('yyyy-MM-dd H:m:s'))) )

#set ( $dateObj = $date.toDate("yyyy-MM-dd", $todayCalObj) )

#set($dateFormatted = $date.format("MM/dd/yyyy", $dateObj))


RCA allows you to create a dashboard using saved reports. When you load the dashboard, each individual report in the dashboard runs on its own and displays the result. However, you can also add interactivity to these reports. You do this using functionality called prompts. Here’s how you set them up.

Step 1:  Create a New Report with Filter Parameters

In order to create dashboards with prompts, we first need to create reports that can respond to dashboard prompt values. That is achieved by creating reports with filters and assigning a parameter names to those filters. These named filters are then linked to dashboard prompts to achieve dynamic filtering of report data using prompt values.

Here is an example of a Program Membership report with a filter on Region:

Step 2: Create a Dashboard with Prompts

Below are general instructions for adding prompts to your dashboard:

  • Create a new Dashboard or in the dashboard page, choose Edit (the pencil icon), which will make the Objects pane appear at the bottom.
  • Under General Settings, choose Prompts. The Prompts pane appears on the right. No prompts are listed if this is the first time you are assigning prompts.
  • To display a prompt toolbar to users of the dashboard, enable Show Prompt Toolbar. The prompt toolbar appears at the top of the dashboard.
  • Click the Add button in the bottom to start adding prompts. The Prompts dialog box appears.
  • In the Prompts dialog box, enter a display name for the control label - Region.
  • Enable Display Name as Control Label if you want users to see the display name in the prompts toolbar.
  • In the Control box, click the format for the prompt options. For example, you can choose the Drop Down control if you want a list that appears when users click the first option.
  • Ensure that Static List is selected under Type. Note that although Static List is not the only option, we don’t support Metadata Lists.
  • Add data values to the Static List.
  • In the Data box, click Add. The List Value dialog box appears.
  • In the Label field, enter the option name as you want it to appear to dashboard users.
  • In the Value field, enter the parameter source name (could be same as Label).
  • Add labels and values for each parameter you want to filter. Click Ok to exit the List Value dialog box.
  • You can add the option All. This option drops the filter from the report and shows all values.
  • In the Control Properties box, under Initially Selected: choose which item you want to appear first in the prompt list. Choose Use First Value to set the default to the first value in the list, or you can choose Specify if you want a specific value to appear first.
  • Click OK.

Step 3: Linking Reports to Dashboard Prompt

  • In the Objects pane, choose the title of the report you want to filter. Click the Parameters tab and choose the correct Source for the parameter from the list. The source should be the name of your prompt.
  • Click Apply.
  • Save the Dashboard. Now this report will respond to Dashboard prompt selection. When you select from the prompt options, the reports will automatically update to reflect these filters.

On certain occasions you may wish to append information to a URL in Marketo. This is often the case when you’re appending parameters for the purposes of tracking in analytics tool.


Whenever you are adding parameters that include lead or program tokens, you need to make sure to do this properly so you do not mess with your ability to track link clicks in Marketo.


If the parameters are fixed (meaning the same for everyone in the program), you can do this with a program token. But you do not always get the same results.

Here’s the tokens I set up to test adding program tokens:


And here are the combinations of these tokens that I inserted into my emails:

<p><a href="http://{{my.Website URL}}">Full URL</a></p>

<p><a href="{{my.URLParameters}}">Parameters Only</a></p>

<p><a href="http://{{my.BaseURL}}{{my.URLParameters}}">Base + Parameters</a></p>

<p><a href="{{my.BaseURLwithHTTP}}">Base with HTTP</a></p>

<p><a href="{{my.BaseURLwithHTTP}}{{my.URLParameters}}">Base with HTTP + Parameters</a></p>


The first three resolve to this:


The fourth one resolves to this:


The last one resolves to this:

You will notice that in this last set up the mkt_tok that allows us to track email link clicks is not appended to the URL in this case. Basically, what this means is that if you are adding multiple tokens into the URL, you need to ensure the HTTP is pulled out of the text tokens and is added directly into the HTML code.


Now, let’s imagine that we want to add in program tokens as well as lead tokens. Perhaps we want to include the person’s lead ID somewhere in the URL.


Here's the token I inserted into my email:

<p><a href="http://{{my.WebsiteURLwithLead}}{{lead.Id}}">with Lead ID</a></p>


This link resolves to (note the lead ID in yellow):


What if I want to add two non-program tokens into my URL? Well, aren’t you getting fancy.


<p><a href="http://{{my.BaseURL}}{{my.URLtoIndustry}}{{company.Industry}}&amp;utm_source=1166&amp;utm_medium=email&amp;id={{lead.Id}}">with Industry and Lead ID not all Tokens</a></p>


This link resolves to:


What if I change the format and put all of the extra information into program tokens?


<p><a href="http://{{my.BaseURL}}{{my.URLtoIndustry}}{{company.Industry}}{{my.URLafterIndustry}}{{lead.Id}}">with Industry and Lead ID</a></p>


This link resolves to:


As you can see, you get identical results.



As long as you have the http:// pulled outside of the text token, you can append program and lead/company tokens to URLs (and yes to append system tokens also). Note that this is not how email script tokens will work, but that’s a topic for another time.

For those who have gotten the best practice instance from Marketo, you may have noticed that the demographic scoring campaigns are set up to run only once, while the behavior scoring campaigns are set up to run once an hour, once a day, or every time. Inquiring minds might wonder why. After all, it's technically possible for demographics to change - someone might change location, get a promotion, or expand into a new industry.


This is mostly a case of the 80:20 rule. Out of your entire database, only a very small percentage is going to experience changes to the demographic criteria in a given timeframe. Often when those changes happen, they don't actually change the score someone would be given. For example, let's imagine that you have a campaign set up to trigger off a Job Title change and you have two tiers of Job Titles, one for C-level and one for Director level. Imagine you start standardizing your job titles from Dir to Director. This is a change that will trigger the demographic scoring campaign.  However, it will not impact the actual point value the person is assigned. It will just run a bunch of people through a campaign for no reason.


The second reason we don't rescore demographics is the complexity. Not only do I need to give you new points if your title changes, but I need to add or subtract the difference between the old and new values. So if you got 10 points before and now your job title is worth 15 points, I technically need to increase your score by 5 points. I can do this by analyzing the change to identify the difference, by subtracting 10 points and then adding 15, or by resetting your demographic score completely and reevaluating every demographic criteria. Whichever option you choose, you end up building a lot of extra campaigns that are, again, running with minimal impact. Just taking up extra processing space in the system.


You might wonder how big of a deal this really can be. Well here are some numbers from a client who shall remain nameless. They took the approach of resetting someone's demographic score completely any time a value changed and then rescoring the entire thing. In a 30 day period, they had 12,000 people added to the list for reevaluation who received no resulting change in their demographic score. They had 100,000 people 'change employee size' from <50 to 1-50, as the result of standardization from Salesforce, but which you can clearly see would result in no change to the score. Even worse, these kinds of campaigns tend to be triggered using Request Campaign, so every lead is running through individually in the trigger campaign queue, which is typically where you'd want your most important, time sensitive campaigns to be. Not how I usually describe demographic scoring campaigns.

Last, but certainly not least, the implications on your lifecycle. Let's imagine a record had just hit 50 points, our threshold for MQL. Then something gets updated and now their demographic scoring goes down by 5 points. They're now at 45 points. Should you claw them back and make them not an MQL anymore? Are we now saying they aren't qualified? What if sales is already working on them?


Long story short - scoring demographics once gives you the biggest bang for the buck, with the least amount of headache. That is why our best practice is to set those campaigns to run once per lead.

We all have some reports in Marketo that take a while to load. Many people will open them in a tab and just come back to them after lunch. I, however, am super impatient and when I want something, I want it right now. Plus I also have a bad short term memory and tend to forget what I was waiting on and only realize at the end of the day when I shut down and see this report in a random tab.


So here's a quick tip to get those complex reports fast:

  • Set up your report settings as you would normally but do not go to the Report tab to load the report.
  • Instead, click on Report Actions > Save As and give your report a name.

  • Then when it refreshes, you'll see a new tab for Subscriptions. Click on New Report Subscription and set up a subscription for yourself. It's really irrelevant what settings you choose.

  • Then click the little email icon next to your name. This will send you an email of the report as soon as it generates.


Generally I find that this is faster than waiting for the report to load and it will also work in situations where you just can't get the report to load in the UI at all because of complex filters, etc.

One frequent question we get asked is "why does RCA show X when this other place shows Y?" To understand this, you need to know what some of the rules are around what is included or excluded from the various types of reports, which is admittedly not obvious. You can work on your mind-reading skills or you can refer to this handy cheat-sheet:


Lead Analysis

  • This report only includes active leads. Any leads that were deleted or were the child record in a merge (for the rest of this post, referred to as merged leads) are not seen in this report.
  • This shows the current information (as of the last ETL, so generally within the last 24 hours).


Opportunity Analysis

  • This report includes active opportunities. Any deleted opportunities are not seen in this report. It is not necessary for an opportunity to have a contact associated to it to be visible here, regardless of the attribution mode you're using.
  • This report shows only active contacts. The definition of an active contact depends on the type of attribution you're currently using:
    • For Explicit Mode: An active contact is one where a contact is associated with the opportunity in CRM.
    • For Hybrid Mode: An active contact is one where a contact is associated with the opportunity in CRM. If there are no contacts associated to the opportunity, any contacts associated to the account that the opportunity is associated to are considered active contacts.
    • For Implicit Mode: An active contact is one associated to the account that the opportunity is associated to.
    • For all modes: Any leads that were deleted or were the child record in a merge are not seen in this report.


Model Performance Analysis (Leads)

  • All flow metrics do include metrics for deleted and merged leads, since they are counting transitions, not people.
  • All balance metrics show the number of people in a stage at a specific point in time.


Model Performance Analysis (Company)

  • Since this is done at the account level, if an account has one contact in MQL stage and one contact in SQL stage, the company will be seen in both stages.
  • All flow metrics refer to the count of unique accounts, based on account name.


Program Membership Analysis

  • Programs must not be operational to show up here.
  • Programs must have at least one member to show up here.


Program Cost Analysis

  • Programs must not be operational to show up here.
  • Programs must have at least one member to show up here.


Program Opportunity Analysis

  • Programs must not be operational to show up here.
  • For a program to qualify for FT attribution towards opportunity creation:
    • The lead must be acquired by the program before or on the opportunity creation date.
    • The lead must be associated to the opportunity.
  • For a program to qualify for FT attribution towards opportunity closed won:
    • The lead must be acquired by the program before or on the opportunity closed date.
    • The lead must be associated to the opportunity.
  • For a program to qualify for MT attribution towards opportunity creation:
    • The lead must reach success in the program before or on the opportunity creation date.
    • The lead must be associated to the opportunity.
  • For a program to qualify for MT attribution towards opportunity closed won:
    • The lead must reach success in the program before or on the opportunity closed date.
    • The lead must be associated to the opportunity.


Program Revenue Stage Analysis

  • Programs must not be operational to show up here.
  • You must have a revenue model active.
  • This will include any leads acquired by the program and in the revenue model.


Email Analysis

  • This includes emails sent out from Marketo (not most Sales Insight emails).
  • This does include activities for deleted and merged leads, but only up until the point of the ETL. Once the lead's deletion is passed over to RCA, future activities associated to that record are not included in the report.

There are five main ways a new lead can be created in Marketo:

  • Manually in the lead database
  • Through list import
  • Through form fill-out
  • Through creation in CRM as a lead or contact
  • Via the API

Two of these methods automatically dedupe on email address: list imports and form fill-outs. There are several pieces of Marketo functionality that work better when you do not have duplicates. As such, we recommend that whenever possible, new records from marketing are created in Marketo via list import or form fill. This also allows for better tracking on the acquisition of new leads and reporting on marketing-sourced or sales-sourced leads. Here's a table showing the recommended method for entering data based on its source:


Lead Source

Recommended Entry Point into Marketo/CRM

Marketing event

Via import into Members tab of the Event Program in Marketo

List purchase

Via import into Members tab of the List Purchase program in Marketo


Via form fill-out in Marketo or on your website, but posted into Marketo via API post

Sales activities – small quantities

Via manual creation in CRM

Sales activities – larger quantities

Via import into CRM by a user who understands how to do it properly OR via import into Marketo into a program dedicated for CRM leads (to ensure that these are accurately attributed to sales and not marketing)


Whenever possible, you should import directly into the program using the members tab within the program. When you import into the members tab, the program status will be defined as part of the list import. This process also automatically assigns the acquisition program for any new leads to that program. However, when you import directly into the program, rather than into a static list, all members must be given the same program status. If, for example, you have a list of event attendees and no-shows, you should split these into two separate .csv files and import the attendees and no-shows separately.


When you import into the program and not into the members tab, you will need to set program membership and acquisition program for all of the leads separately. Generally, this is done either manually via a Change Data Value flow step or through a smart campaign based on membership of a specific static list.


Importing into a static list instead of a program should only be used for leads that were not acquired through a marketing activity, such as data that already exists in your database, which you just want to add to a static list.


One of our other consultants created this image, which I think is a great summary:



To create a user defined (custom) measure in RCA, right click and select User Defined Measure. You can then choose the type of measure you wish to create. For this example, we’ll be using a Calculated Measure, which allows you to take the metrics already available in the report and use basic math (addition, subtraction, multiplication, and division) to create a new metric.


You need at least one metric in your report in order to create a user defined measure, but it does not need to be one of the measures you plan to use to define your measure.

Once you have a metric in your report, right click on the column header for the metric (the blue cell) and choose User Defined Measure > Calculated Measure.

Since you can’t see soft bounced numbers in RCE email reporting, in this example, we’ll be creating a measure for this. We’ll use the assumption that any email that was sent, but not delivered or hard bounced was soft bounced.


To bring over a measure for use, click on it on the left and then select the arrow in the middle to bring it over to the right side. You can type the math symbols yourself or use the selection box on the bottom.

Now you will see a new column with your custom measure for soft bounces:

Inquiring minds who read my last post on generating a custom field that stores the CRM GUID might be wondering why anyone would do that. Is it even useful? Well, I am about to show you one reason why you'd do that.


By default, alert emails sent out of Marketo using the {{SP_Alert_Info_Token}} do not include a link to the CRM record if you are using Microsoft Dynamics.


However, you can manually generate a link to the CRM lead record that will resolve correctly. Here’s how:


First, you need to find the URL to a lead record. The approach for doing this varies based on the version of CRM you're on.


Here's the method for on premise:

Go into CRM and copy the URL of a lead record, e.g. The highlighted part in yellow is the GUID, which is the identification number of the record in CRM.


Here's the method for online:

Open the lead record. Click on the …

Click on Email a Link:

This will generate an email with the link:

This part highlighted in yellow is the GUID:



Second, you need to have a custom field in Marketo that stores the GUID, which varies by whether it's a lead or a contact. See my blog post here on how to do this.


Third, create an alert email. Add in the text you want to display and hyperlink it to a modified version of your CRM link in which you replace the GUID highlighted above with the token to your Marketo custom field. In this example, the token is {{lead.mkto_GUID}}:

<a href="{{lead.mkto_GUID}}%7d&amp;pagetype=entityrecord">Link to CRM Lead Record</a>


Then, send yourself a sample and you will see that clicking on this link opens up the lead record directly in CRM. Now you can use this in your alert emails.


Important Note: The URL is not exactly the same for leads as for contacts. If some of your records that you're sending alerts on are leads and some are contacts, you will need to change the green highlighted part based on the Microsoft Type. If so, you may need to vary the alert emails based on the CRM type.


In this example, etc=4 is for a lead and etc=2 is for a contact. Please confirm that this is the same with your CRM URLs, as this may vary with different Dynamics versions.