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

A good program naming convention can help you keep Marketo organized since programs are automatically sorted chronologically in folders and reports. Consistent naming will also make it easier to search for programs, add an asset to a smart list or flow step, and filter by program name in a RCE report.

 

Here are best practices for naming your programs:

1. If you have set-up multiple workspaces, I recommend you start all program names with a workspace abbreviation. It will enable you to easily sort in your RCE reports by workspace.

  • Workspaces example
    • APAC
    • Default
    • EMEA
    • NAM

 

2. Include the program creation date or the date you are starting your event to make it easy to identify when you created or held the program. I recommend putting the year first followed by the month then day so your programs will auto-sort in chronological order.

  • YYYY for year
  • MM for month. Always include month so you can easily compare the creation date of two content programs in reporting.
  • DD for date. Always include the date for event programs so you can easily distinguish between multiple webinars with the same program name taking place in the same month.

 

3. Use a program abbreviation type if you would like to distinguish between two different types of programs using the same channel. I recommend having as few channels as possible to avoid confusion and having users accidentally choose the wrong one. If you want to make thing easier to read, spell out the entire program type name and don't use an abbreviation.

  • Examples:
    • Webinar = WB vs Webcast = WC
    • Seminar = SM vs Roadshow = RS

 

4. If you expect to over time build thousands of different programs and assets (Emails and Landing Page), I recommend including the Program ID in your program name. The Program ID can be found in the URL:

image2.jpg

image1.JPG

 

5. Always include a description of the program. Shorter is better and try to be as descriptive as possible. If the program is an in-person event include the location. If the program is for content include the content type (e.g. Whitepaper, Video, Case Study).

 

6. I recommend using separators instead of blank spaces in your program name. Dashes are preferred as separators over underscores or periods since underscores and periods become hard to see when hyperlinked. If you are planning to use the program name via a {{my.token}} in a URL parameter it is best practice to include no blank spaces in your program name. A blank space in a URL parameter can cause a problem. If you aren't planning to use the program name in a URL parameter than blank spaces after the date make the program name a bit easier to read.

  • Example of a program name with no blank spaces: NA-2016-01-15-WB-Getting-Started-Webinar-4545
  • Example of a program name with blank spaces: NA-2016-01-15-WB Getting Started Webinar 4545

 

7. Putting it all together. I recommend you go from the highest level to the most specific in regards to Workspace and Creation Date. I like to put the program abbreviation after the creation date of the program but some people like to put it before the date. I like putting the Program ID at the end since it will be a unique number for every program and it won't impact naming consistency if users forget to add it.

 

Workspace Abbreviation-YYYY-MM-Abbreviated Program Type-Program Description-Program ID

 

Examples with spaces

  • NA-2016-01-TS CES Tradeshow (Tradeshow located in the North America workspace held in January 2016)
  • 2016-01-15-WB Getting Started Webinar 4545 (Webinar held on January 15, 2016 with a Program ID)
  • APAC-2016-01-12-SM Discovery Center Seminar - Beijing 1324 (Seminar in the APAC workspace held in Bejiing on January 12, 2016 with a Program ID)
  • 2016.01-WP Gartner Magic Quadrant White Paper (Gated content program created in January 2016. The month is included so when you review membership and success between two programs it is easy to identify which is the older program)

 

8. Be realistic and consistent. It is more important that you make it easy for everyone to name programs the same way then to have a complicated structure which is hard to use or follow.

 

One final thought, consider how you want to filter your programs in RCE using Program Channel, Program Name and Tags when you develop your program naming convention.

 

Link to Checklist for Attribution Reporting.

Here is the process to move a program which has members to a new workspace. The solution retains program membership, the membership date, program status, the success date, acquisition and acquisition date.

 

In this example we are moving a program from the 'Default' to the the 'NAM' workspace.

 

Step 1 - Remove all associations to the program and assets inside the program from smart lists and smart campaigns outside of the program. You will not be able to move the program if it or any assets inside of it are being used. Also, you won't be able to move the program if any assets inside of it are referencing items outside the program like static and smart lists, smart campaigns etc.

 

Step 2 - Make sure you aren't referencing a form in the design studio.

 

Step 3 - Make sure any assets used in the program are referencing templates or snippets which are in a shared folder.

 

Step 4 - Create a new 'Temporary' lead partition and associate it to the 'Default' workspace which contains the program you want to move. The temporary lead partition will hold the members of the program while you are changing it's channel.

 

Step 5 - Create a smart campaign to move all the members of the program you will be moving to the new temporary lead partition.

 

Step 6 - Edit the temporary lead partition so it is no longer associated to the 'Default' workspace where the program is located. Associate the temporary lead partition to only the 'NAM' workspace. Once this is done you will notice that the program no longer contains any members.

 

Step 7 - Place the program you are moving in a folder and move the folder into the 'NAM' workspace. After you move the program you will see the members reappear retaining their original membership date, program success, acquisition program and acquisition date.

 

Step 8 - Run a smart campaign to move the program members back to the 'Default' lead partition. There will be no change in membership or program status.

 

Step 9 - Finally, delete the 'Temporary' lead partition.

 

Note: If you have records in a wait step in a smart campaign, when the records re-appear in the program they will still be in the wait step and will continue to flow through the steps in your campaign.

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. https://xrm.democompany.com/main.aspx?etc=4&id=%7b7EC64103-5EC6-E311-82EF-00155D05A92B%7d&pagetype=entityrecord 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:

<https://marketoconsulting.crm.dynamics.com/main.aspx?etc=4&extraqs=formid%3de3b6ddb7-8df0-4410-ac7b-fd32e5053d38&id=%7bB1AA71D0-45A3-E511-80E7-3863BB347A88%7d&pagetype=entityrecord>

 

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="https://marketoconsulting.crm.dynamics.com/main.aspx?etc=4&extraqs=formid%3de3b6ddb7-8df0-4410-ac7b-fd32e5053d38&id=%7b{{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.

 

https://xrm.democompany.com/main.aspx?etc=4&id=%7b7FC64743-5FC6-E311-82CF-00115A02A92B%7d&pagetype=entityrecord

I freely admit this is an esoteric topic, but trust me when I tell you when you need to use it, it's best not to mess it up. The use case is as follows.. suppose you have customers that might exist in some home grown external system with a unique PID (Person ID) that is not the marketo ID, and your business depends on that being unique. In addition, imagine some people in your database may not have emails (I know, I know, but this happens). Now imagine that you can have duplicate emails in Marketo.. but youll never have a duplicate PID.

 

An example would be when a caretake signs up for an account for someone else (Im leaving that intentionally vague).

 

In such a case you need to upsert data into Marketo, but you may or may not have email.. and you definitely dont have a Marketo ID. If you're using REST, its not a problem as you can specify a non email dedupe field.. but if you're using SOAP.. its not that simple. In that case you might consider using the "Foreign System ID".

 

Wait.. the Foreign System what?

 

It's true, this exists, and its documented, if rarely used, and its important you use it correctly. In the above use case you'd use the following two versions of an input XML to upsert a lead into Marketo.

 

In my humble opinion, Case 1 is more insteresting... because you're passing in the MarketoID and UPDATING the Foreign System Person ID.

 

Case 1: NO Email

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mkt="http://www.marketo.com/mktows/">

   <soapenv:Header>

      <mkt:AuthenticationHeader>

         <mktowsUserId>${#TestCase#userid}</mktowsUserId>

         <requestSignature>${#TestCase#signature}</requestSignature>

         <requestTimestamp>${#TestCase#timestamp}</requestTimestamp>

      </mkt:AuthenticationHeader>

   </soapenv:Header>

   <soapenv:Body>

      <mkt:paramsSyncMultipleLeads>

         <leadRecordList>

            <leadRecord>

               <Id>3767415</Id>

               <ForeignSysPersonId>DEF1234</ForeignSysPersonId>

               <ForeignSysType>CUSTOM</ForeignSysType>

               <leadAttributeList>

                  <attribute>

                     <attrName>FirstName</attrName>

                     <attrValue>Ben</attrValue>

                  </attribute>

               </leadAttributeList>

            </leadRecord>

         </leadRecordList>

         <dedupEnabled>TRUE</dedupEnabled>

      </mkt:paramsSyncMultipleLeads>

   </soapenv:Body>

</soapenv:Envelope>

 

Case 2: With Email

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mkt="http://www.marketo.com/mktows/">

   <soapenv:Header>

      <mkt:AuthenticationHeader>

         <mktowsUserId>${#TestCase#userid}</mktowsUserId>

         <requestSignature>${#TestCase#signature}</requestSignature>

         <requestTimestamp>${#TestCase#timestamp}</requestTimestamp>

      </mkt:AuthenticationHeader>

   </soapenv:Header>

   <soapenv:Body>

      <mkt:paramsSyncMultipleLeads>

         <leadRecordList>

            <leadRecord>

               <ForeignSysPersonId>ABC123</ForeignSysPersonId>

               <ForeignSysType>CUSTOM</ForeignSysType>

               <leadAttributeList>

                  <attribute>

                     <attrName>FirstName</attrName>

                     <attrValue>Alicia</attrValue>

                  </attribute>

                  <attribute>

                     <attrName>Email</attrName>

                     <attrValue>Alicia@Test.com</attrValue>

                  </attribute>

               </leadAttributeList>

            </leadRecord>

         </leadRecordList>

         <dedupEnabled>TRUE</dedupEnabled>

      </mkt:paramsSyncMultipleLeads>

   </soapenv:Body>

</soapenv:Envelope>

 

The key it turns out is the ForeignSystemType. In order to properly upsert the lead, you NEED to tell marketo what the ForeignSystemPersonID is.. as well as the ForeignSystemType!

Can activity history be exported from one Marketo instance to another?

 

This is a question we often hear, since often times clients are up and running with their Marketo instance before they integrate with a CRM, or there’s a need to consolidate multiple Marketo instances.

 

So what’s the answer? 

 

In short, you can’t export Marketo activity history or Marketo campaign history from one instance to another. What’s the difference between activity history and campaign history, you might ask?

 

Marketo activity history is the information you find on the “Activity Log” tab on a Lead record in Marketo. Examples include, but aren’t limited to:

 

  • Clicked Link on Web Page
  • Added to List
  • Opened Email
  • Send email

 

To see a list of activities you can pop open the Activity Filter:

Activity Filter.png

 

Marketo campaign history is the information you see in the “Results” tab in a smart campaign and includes information like ID, Activity, and Lead Name, as pictured below.

 

Results.png

 

 

To repeat, you can’t export Marketo activity history or Marketo campaign history from one instance to another.

 

I’m disappointed! Do I have any options?

 

Marketo does provide a service that allows for the export of activities using the Marketo API.  But there’s a caveat - in order to import activities into a new instance custom activities need to be created; you cannot import into the standard activities. Still interested? Reach out to your engagement manager or support to learn more.

Update: The always full of random and interesting knowledge Kenny Elkington pointed out that there are actually fields in the UI that show this already! You can find this on the Microsoft Lead Field tab of the lead record in the fields called Lead and Contact (c) at least in my instance:

 

 

 

 

Now here's my original article, which is still mildly useful to know in case you want to have the GUID in the same field instead of two separate ones, I guess.

 

Here's one of my favorite little-known tricks. There's no "Microsoft Dynamics ID" field in Marketo, but you can actually populate a custom field in Marketo with the GUID from Dynamics using the SFDC ID fields. Here are some batch campaigns that could populate these for you:

 

For Lead Records

 

For Contact Records

 

 

If you want to use triggers, you can use Lead is Created (Source is Microsoft Dynamics) along with Data Value Changes (Microsoft Type is Lead or Contact) depending on which campaign you're editing).

When deciding whether to use multiple instances of Marketo or one instance split out by workspaces and partitions for various business units, there are several factors that impact this decision including:

  • There is an instance-wide limitation of 20 segmentations (soft limit) with 100 segments each (hard limit)
  • Dynamic content needs can potentially impact the data model by requiring additional fields or custom objects that will not be used by other groups
  • There is an instance-wide limitation of 10 custom objects with 50 fields per object (soft limit)
  • When on a shared instance, we need to maintain a single dedupe criteria, ideally based solely on email address
  • It is easier to share programs and assets within a single instance than across multiple instances
  • When in a shared instance, if we decide to use partitions, we may need additional API calls to upsert leads because we will first have to query the lead’s partition
  • In a shared instance, data and information can be shared on a single lead record based on interactions with multiple business units’ programs
  • In a shared instance, the data model must be unified across all groups
  • In a shared instance, all groups can benefit from custom integrations shared across the instance
  • CNAMEs have to be unique across all Marketo instances
  • Operational complexity and governance can increase with multiple instances, particularly in a centralized model

 

 

Benefits of Separate Instance

Benefits of Joint Instance

Able to take a customized approach to the data model for each group

Prompts business to identify and build a joint data model that addresses complex deduplication and data architecture requirements

No need to coordinate segmentation usage with multiple business groups

Utilizes existing and future integrations built into the central instance

Easier to manage data requirements, including custom fields and custom objects

Easier to share programs and create joint programs across business units

Less likely to hit instance-wide limitations, such as 10 custom objects (50 fields) and 70 segmentations (100 segments)

Single view of the customer/partner activity across marketing programs and websites owned by other groups

May require less API calls to load data, as we will not need to query partitions before upserting leads

CNAMEs can be shared by multiple groups

Easier to operate and govern for a decentralized team

Easier to operate and govern for a centralized team

Faster time to agree upon instance configuration and setup criteria, thus speeding up time to launch

Easier to troubleshoot, test, and support

Easier to share best practices

In Marketo Opportunities are linked to Leads via the Opportunity Person Role typically. You can peruse the Opportunity REST API here and see what's possible. Often times though, customers express that for their business case, Opportunities should be linked to Accounts (which I'll use interchangeably with "companies" from the Marketo perspective) instead, which poses a problem.

 

To address this, we have a hidden feature that can be turned on which enables a new filter called "has Opportunity Account" which enables you to pull back a list of leads that have an opportunity with and also have a given companyID. Note, however that this is ONLY available in Marketo instances that are not natively integrated with Salesforce or Microsoft Dynamics CRM

 

Cool! How Does it Work?

Im glad you asked. The basic data model is illustrated below.

Screen Shot 2015-12-03 at 9.17.54 AM.png

Fig 1 - Opportunities associated with Companies

 

So to get this to work there are a few things you need to know, do, and keep in mind.

 

  • There is currently no concept of a many to one relationship for companies to leads in Marketo
  • You must populate the list of Companies using the Company REST API.
    • This API is only available when you are NOT natively synched to Dynamics or Salesforce.
    • This API allows you to create a one to many relationship between Company and Lead, similar to the model in Dynamics and Salesforce.
    • The "externalCompanyID" you establish will serve as the link to the Opportunity and the Lead
  • You have a filter, but NOT a trigger, meaning you can create a smart list, but not trigger a campaign.

 

Once the Companies are set up properly set up with Leads, you can begin adding opportunities for those Leads using Create/Update/Upsert Opportunities being sure to add the "externalCompanyID".

 

That's it! youll then be able to use the "has Opportunity Account" filter to build a smart list!

Now lets move on to completing out many to many example. The example, as you may remember, is to model student enrollment in courses. Some terms I'll be using..

 

The "bridge" object Is the object that contains the data resolving the objects, the enrollment in this case. It tells us which lead is enrolled in which course, allowing many enrollments by many leases into many courses

The "edge" object is our standalone object. In this case, the course.

 

The example below may help. Here, the Opportunity Person Role is the "bridge" object and the Opportunity is the "edge".

Screen Shot 2015-11-02 at 10.50.06 AM.png

So lets continue by creating our enrollment object in marketo

 

Step 1: Create the Object

02.png

 

Step 2: Create Link Field #1 (to the Course Object)

03.png

 

Step 3: Link Field #2 (to the Lead Object)

04.png

 

Step 4: Create a Dedupe Field (EnrollmentID in this case)

Screen Shot 2016-01-14 at 11.22.13 AM.png

I really recommend thinking through what you want your objects dedupe fields to be. What makes the bridge object unique? In the case of the edge object its often just something like a course ID.. but for enrollment it might be EnrollmentID AND CourseID... or simply a GUID. Remember once you publish you cant change dedupe and link fields.. so think through it carefully!

 

Step 5: Publish The Object

05.png

This is how it looks...

06.png

 

That's all great.. but how do you use it? Great question. Under your triggers and filters you'll see the following

  • Added to Course (Trigger)
  • Was added to Course (Filter)
  • Has Course (Filter)
  • Was Not Added to Course (Filter)

 

The cool magical thing here is that when you select the filter... you can also see the bridge object! You can get a list of leads who have a Course with a certain instructor and also are enrolled in a program of study, for example.

 

Screen Shot 2015-11-02 at 11.37.03 AM.png

What happens to people in a wait step if you delete the wait step? This is really important to understand if you're planning to modify a live campaign after there are already members in it.

 

To test this, I added a lead to a flow as follows:

 

 

Once they were added to List 1 (and thus were in the Step 3 wait step), I deleted Step 3.

The new flow looked like this:

 

The question is, would the lead move on to Step 4, even though they had not yet gone through the Add to List step to be added to List 2? Or would they get added to List 2 even though that was now Step 3?

 

After the original wait period (from the deleted wait step) ended, the lead moved on to Step 4, even though they had never gone through the new Step 3.

 


Moral of this story: If you delete a wait step, leads will not go back and complete the flow action that takes its place. If you still want leads in that wait step to go through every flow action, you may be better off reducing the wait time to 1 minute and leaving it in.

In case you missed it, there was a recent change to custom object in Marketo.. they're now available to the end user in the UI! Here's a list of my blogs on that topic.

 

 

Well good news! We're finally getting Stand Alone custom objects, but its not EXACTLY what you might be thinking.. YET. Standalone custom objects currently exist to enable many to many custom objects in Marketo, which people have been asking about for a very long time. An example of the many to many relationship that you already know about is the Opportunity to Lead relationship, which is assisted by the Opportunity Person Role... but I'm getting ahead of myself.

 

In order to create a standalone custom object, the process is very much like creating a normal custom object. You just leave out the link field. The one I'll create here is a "Course" object, (Physics, Math, English, History, etc.)

 

Step 1: Create the Object

Screen Shot 2015-11-02 at 10.40.23 AM.png

Step 2: Add the Attributes

Screen Shot 2015-11-02 at 10.41.34 AM.png

Step 3: Publish

Screen Shot 2015-11-02 at 10.41.46 AM.png

 

Step 4: Wow!

Screen Shot 2015-11-02 at 10.41.58 AM.png

 

Look, Ma, no link field! You've created a fully standalone object in Marketo. We refer to this as an "Edge" Object. In part 6 of the Custom Object Blog Series, you'll learn why.

 

What are you using Custom Object for? Are you having success? Please tell us in the comments.