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.
- 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.
- 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:
- 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
- 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.
- 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:
- 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!
21 Comments
.png)