Skip navigation
All Places > Products > Blog > 2019 > June
2019

Marketing Nation members, I’m thrilled to announce a new addition to my team, Jonathan Chen. Jon will be taking lead as Community Manager and, as such, will be working with all of you to ensure our Community remains the best community ever!

 

Here’s Jon’s message to you:

 

“Hello Marketing Nation,

 

My name is Jonathan, and I joined Marketo last week as a Community Manager for the Marketing Nation Community. I am so excited and grateful to be a part of such an innovative and quirky team at Marketo and can't wait to engage you all with interesting topics and ideas to further expand your knowledge of Marketo. Before joining this team, I was a product marketer at a prominent enterprise headset company, where I helped expand its innovation business by developing scalable marketing programs and communities to drive awareness and advocacy. I often used Marketo in my previous job to develop monthly consumer newsletters and quickly fell in love with the highly sophisticated, yet surprisingly intuitive platform. Of course, I learned that Marketo has countless solutions for every use case and was blown away by the Community's respectful users, vast database of creative ideas, and snappy responses to even the most complex of questions. The Marketing Nation is truly one of a kind, and it's because of every single one of you. From the daily posters to the occasional lurkers, know that I am here to support you on your Marketo journey. There are many great projects planned for the Community, and I can't wait to show you what's in store in the coming months. Please feel free to reach out to me at jonchen@adobe.com any time you have a question, complaint, or concern - I'm here to help!”

 

Jonathan Chen, Marketo Marketing Nation Community Manager@@@

 

Please join me in welcoming Jon to the most amazing nation of marketers on earth!

 

Janet

I recently received a request from a customer who was trying to update a person's email address via the API. He was trying to use the Create and Update Lead API, and because the lead had a new email address, he was getting a duplicate person record created with the new email address. What he wanted was to update the existing Person record with the new email address instead.

 

 Since I have had this question a few times, I thought it would be helpful to write a blog post about it.  The steps to follow are below, but...spoiler alert....the answer is to use the Sync Leads Using Post endpoint instead.

 

 In order to update the right Person record, I'll need the Marketo Person ID for that person.  I can get that using the Get Leads By Filter Type endpoint like this: 

 

 

Once I have the id of the Person record, I can call the Sync Leads Using Post endpoint to update that record. As you can see from the screenshot below, I’m passing in an action of “updateOnly” and  “id” for the “lookupField” value. Then I can pass the information in the “input” that I want to be updated; namely email in this case.

 

To verify that the email address was changed, I can make the  Get Leads By Filter Type call again and pass the new email address. 

 

Finally, there are several ways to get the person id that you’ll need to do this with.  You can either do a Bulk Lead Export if there are a lot of them or you can call Get Leads by Filter Type if it's a one-off, and you need to look it up by email address. 

 

Many of our customers have complex business requirements that require more than what the baseline Marketo data model can support. That's why we have Custom Objects in Marketo. Custom Objects allow the customer to support more advanced data models in Marketo, but there are some best practices to follow when using them.

 

Measure Twice. Cut Once

 

When you first design your Custom Object, we advise to take your time and get all of the fields correctly defined before you approve the object. The reason for this is data contiguity. When you approve the custom object, Marketo creates a table in the database for that object definition.

 

If, at a later time, you decide that you need another one or more columns, and you simply add them and approve the object again, the additional columns will not be stored in the same table as was created in the original object definition. Going forward, you'll have data in two different tables for that object, which will require Marketo to use a join whenever it access that object. This can have an adverse effect on the speed of data retrieval from Marketo instance, impacting script execution, data access via the API, and even the user experience in the Marketo web UI.

 

As an alternative, you could always drop and recreate the Custom Object with the correct columns, but then you would have to migrate the data from the old Custom Object to the new one which adds a level of complexity that most of our customers don't want to get into. The best option is to get it right the first time; like woodworkers say: "Measure twice. Cut Once."

 

Recreating a Custom Object

Just in case you find yourself in a position to need to rebuild your Custom Object, here are the steps you'll need to follow to do it correctly: 

  • Stop any third-party integrations that are using the Custom Object via the API.
    • This will prevent any third-party systems from trying to access the Custom Object via its API while you're rebuilding the object.
  • Remove all references to that object in filters, flow steps, smart lists etc. 
    • This will prevent any trigger campaigns from executing based on your work.
  • Write down the exact spelling of the Custom Object.
    • So you can recreate it later
  • Delete the Custom Object 
    • Depending on how many rows of data are in the Custom Object, you may have to ask support to do this.
  • Wait for about 15-30 minutes to allow Marketo to confirm that the Custom Object is fully deleted
    • This ensures you can recreate the object with the same API name.
    • If you just delete and recreate the object with the same API name, the recreate can fail.

 

Don't Use Custom Objects as a Data Land Fill

Many of our customers do regular bulk exports of their data for storage in a data warehouse of some other third-party analytic system. If your Marketo instance is full of Custom Object data that is not, and never will be useful for that analysis, your exports will take longer and have a more significant effect on your API rate limits. 

 

To avoid allowing your Marketo instance to fill up over time with useless data, it's best to make sure to use your Custom Objects to store only data that is useful now, or in the future. Things you should not store in a Custom Object include:

  • Transient information  - Activity data should be stored in a Custom Activity instead
  • Order history - Consider purging old data from time to time
  • Any data that will not be used for marketing activities

 

Deletion of Custom Object Data

If, after following the steps above, you still need to purge data from your Custom Objects you can do this through the API. Use the Delete Custom Objects endpoint, and remember to batch your calls in order to do up to 300 rows at a time. This will save you from using up your API rate limit.

Email marketing is the foundation of a lot of marketing strategies. With the help of Marketo Champion Beth Massura, this edition of Marketo Master Class puts a magnifying glass on the role that tokens, templates, and snippets play in the creation of a marketing email to help you achieve actionable insights and greater efficiency.

 

  1.     What are the benefits of using tokens, snippets, and templates in emails?

 

There are a few different benefits to using these features. First, tokens, snippets, and templates provide consistency across email communications, which is really important from a brand standpoint. We want the recipients to recognize the emails as coming from a single organization, and having standardized templates and snippets helps with this.

These elements also make it a lot easier to manage global changes. I will never forget when we had to manually update our social media profile links across 400+ HTML email files (in a pre-Marketo system) twice within just a few months. What a pain! Now we can just update a small number of snippets and the updates will appear in all the email assets using them.

 

Templates can help increase confidence that the emails will render well. If the templates have been thoroughly tested across dozens of recipient browser/email client/device combinations, and users are working within the templates, it may be sufficient to test each individual email message across a smaller set of recipient setup variations instead of all of them.

 

Tokens, snippets, and templates also help users create emails more easily. It can be overwhelming to start from scratch every time, and would likely lead to errors. We have the most popular modules and snippets appearing by default in the template, so there is less work for users to set up their email.

 

  1.     What are different use cases for using snippets? 

 

Snippets are good for any block of content that you want to have standardized, but with multiple variations that can be substituted for one another: branding elements, contact information, executive bios, common product descriptions or disclosures, etc. You can set areas in the template that can be replaced only with snippets, or users can replace rich text areas with snippets.

 

We use snippets for brand lockups at the top of the email template as well as for the email footer content such as legally required links and information. We have a couple dozen different departments, programs, and research centers sharing our Marketo instance, and many of them have a variation of the main logo (for the header) as well as their own contact information (for the footer). The central marketing team manages all snippets in the Default workspace, organized into subfolders for each department. These subfolders are then shared to the respective departmental workspaces so they have access to only the header and footer snippets that they should use, and they don’t have access to modify any of the snippets themselves.

 

 

For the header logos, previously our central designers and developers edited the rich text section of an email asset to drop in a logo with the right dimensions and styling and just hoped that the group would remember to clone that particular asset going forward. Unfortunately this meant that if the group cloned the wrong email asset, they’d have to reach out to the designers/developers to replace the logo again. There were also a few users who deleted or replaced the logo in the rich text editor with one that didn’t meet brand guidelines. Offering a snippet “library” of the approved logos/lockups makes it easy for the user to select the one that’s appropriate for the context while maintaining the brand standards. We have set guidelines for the logo sizing, etc., so having the snippets centrally managed helps with that as well.

 

Example header snippet:

 

Additional header snippets are created for logo variations such as these:

 

Our footer snippets contain the contact information for the respective group, as well as the mandatory unsubscribe, preference, and privacy policy links for compliance and user experience purposes. Because much of this information is required by law, it’s imperative that we ensure all these details appear correctly on every single email. Using snippets helps us keep this consistent and avoid variance from the standard.

 

Example footer snippet:

 

 

  1.     What are some under-utilized tokens? How do you leverage program-level vs. folder-level tokens differently?

 

We use a token for the copyright year at the bottom of the email. Previously we had it as a text token on the top folder level for each workspace; we just had to update the values at the start of the year. But now we use an email script token (also in the top level folder) so the year is automatically updated:

#set($timeZoneObject = $date.getCalendar().getTimeZone())$date.format("yyyy", $date.getDate(), $date.getLocale(), $timeZoneObject.getTimeZone("CST")) 

 

It’s a system token rather than a program token, but program ID is added in small text at the very bottom of the email footer snippets. We found this would help us locate the associated program if we were forwarded an email and asked to troubleshoot why a person did/didn’t receive it or to create a similar email.

 

You would want to use folder-level tokens for items that should appear in every single program, such as copyright year. We also have a folder-level token for a tracking code with a default value that is then updated on each program; it is referenced at the end of every url in the email to tie into our web metrics system. We want a tracking code for every program, so even though the value has to be updated on each program, having the token there on the program by default is a good reminder to the user.

 

In the below example, the highlighted “20190610-WEB sample program” inherited tokens from the “BethM Marketing Activities” and “Web Content Programs” folders. It will not inherit tokens created on “20190615-EM sample program”.

 

Program-level tokens can be useful when it’s relevant only to a specific program type, such as “event registration url” for an event program. Because folder-level tokens are inherited automatically by all programs within that folder, it wouldn't make sense to have this type of token in a folder. If you did, it may appear in an unrelated newsletter program through token inheritance. While tokens can be deleted in a program, you can't re-inherit a token once it's been removed

 

  1.     How do you use tokens, snippets, and templates together to fit within a larger strategy? 

 

Tokens, snippets, and templates can be integral parts of a Center of Excellence! We created an all-in-one module-based email template to accommodate a wide variety of layouts for all kinds of emails: newsletters, event invitations, announcements, etc. The template also includes the two areas for the header and footer snippets as well as the tokens as mentioned previously. This template is then used for the email assets in our cloneable standard email send program and the nested email sends within an event program.



  1.     What are the most common pitfalls you see when people are trying to use tokens, snippets, and templates?

 

Make sure you involve stakeholders at the beginning of any initiative to develop standardized tokens, snippets, and/or templates - which ideally is part of the Marketo implementation - in order to gather all requirements before anything is executed. You don’t want to waste time developing a template module that no one will ever use, or to miss one that would be used frequently. While a template can be edited, it won’t push those updates to email assets already created from the template.

 

Creating a template involves HTML/CSS coding and Marketo-specific syntax to define editable areas. Make sure you are working with a developer who is familiar with this. Having HTML/CSS alone won’t allow users to edit an email asset created from the template.

 

All snippets to which a user has access will show up in the Insert Snippet dropdown menu; you can’t select which snippets will be options for area A vs. area B. We use naming conventions to distinguish between header and footer snippets.

 

 

When making changes to a snippet, be sure to update the text version as well. Unlike an email asset, it won’t carry over the edits.

 

Consider whether a piece of information would be best served within a token or something else, like a variable within a template module or even just typing the content directly into the email asset. It can be confusing to enter some email content in tokens on the program level and then other pieces within the email editor. Tokens might be preferable when the content is listed in multiple places and is likely going to change, so all references can be updated at once.

 

It’s definitely possible to create an email asset that solely references program tokens so you don’t have to go into the email editor at all to customize images, colors, text, and links. This “Mad Libs” method can work well for emails that are straightforward and standard in format, such as form submission confirmations. But the moment you want to add in something special, you’re going to have to enter the email editor anyway. And the tokenized method may not be as intuitive to those users who would be more comfortable entering/selecting the elements in a WYSIWYG context. (We are not currently using the “Mad Libs” method, but one of our departments did in the past.)

 

Example tokens for a fully tokenized email:

 

The associated email asset’s editor view; it isn’t pretty!:

 

The preview of the above email asset:

 

  1.     Are you planning to try anything new with these features?

 

One next step could be for us to put dynamic content within our snippets. For example we have regional campuses/offices for some of the school’s departments. Instead of having separate snippets for each region, we could have the snippet dynamically populate the regional address based on the recipient’s region segment.

 

 

_________________________

 

You can find more insightful content in the June edition of The Fearless Forum!

Filter Blog

By date: By tag: