Marketo Success Series: Email Templates

Jon_Chen · ‎06-15-2021

Hello Marketing Nation,

Welcome back to the Marketo Success Series! In this series, we partner with Marketo Champions and Champion Alumni to fully explore how some of our most celebrated Marketo experts are using Marketo Engage to drive success. In this edition, we teamed up with Marketo Engage Champion Alumni Edward Unthank and Courtney Grimes to go over how to create and prototype your email design, defining modules and editable areas, and more.

Email templates are the heavy lifting code that allows your marketing team to shine. By setting up a technical email structure that powers your emails with clean code that works on all devices, marketers can focus on messaging and strategy instead. When we spend more time on making puns in subject lines and less on how an email renders on a certain service, everyone wins. Well, except people who hate puns.

At their core, email templates are simply HTML and Marketo-specific markup that powers what a marketer can build with when using the Email Editor. Because of their importance, they're an item worth taking the time to do right the first time. Every email that you build will be built on top of an email template. If you have one consistent brand that is consistent and robust, you can run all of your marketing emails off of a single master email template. Email templates in Marketo are built to be modular. They use the same foundational design building blocks while providing marketers the ability to customize individual designs.

Creating and Prototyping Your Email Design

When deciding what sort of email template to design, first take a look at the messaging you're sending today or would like to send in the future. Do you stick to short, simple messages? Are you looking to do long, complex newsletters? Do you have a B2B audience that's still using Outlook or a B2C audience who can take advantage of newer email technology? Make a list of criteria your emails need to have to help steer your design process. A good email template should have a long shelf-life for your organization.

A good email template:

Embodies your unique aesthetic tailored to your company’s brand,
Incorporates a broad range of customizations including local variables, modules, global variables, and dynamism, and
Limits off-brand customizations and the need for deep technical knowledge from a marketing operations specialist.

If you're looking for inspiration, check out sites like Really Good Emails to get an idea of what content and structure you'd like to have for your own messaging. Make some sketches of what your company's emails should look like in terms of structure and circulate them around not just your marketing department, but other key areas of your business such as sales and customer service. They'll have unique perspectives that come from interacting with the recipients of your emails. Likewise, if you have any customer advocates, ask them what they like about your emails today and what they'd like to see. You may even want to show them a few rough drafts of what your designs could look like in the future.

Gather requirements for things that your email template: Will you need to swap logos or colors for flexibility? Will you need to embed any tracking codes or other technical items to bake into your code? Who will be creating emails in Marketo and how comfortable are they with HTML? Can they go behind the curtain to tweak items as needed or are they going to stick to using the visual editor? All of these and more will affect how you choose to build out your email template and may influence its design.

Once you've nailed down what looks and layouts make sense for your company, you'll then need to translate that look and feel into working code.

Taking Your Email From Sketch to Code

Coding HTML email is old school.

Think back to 1999, when web developers called themselves “webmasters” and used Frontpage, WYSIWYG editors, and tables to mark up their websites. As such, email coding uses an odd mix of modern and very ancient techniques.

The reason for this is simple: Different email providers and email clients have different ways of rendering HTML. Because HTML emails essentially need mini web browsers to render, they have different web rendering engines similar to popular browsers. Clients like Apple Mail, Outlook for Mac, and Gmail Android use Webkit, the same code that powers Chrome and Safari. Thunderbird uses a variant of Firefox's rendering engine. Older email clients have older rendering engines, and even newer email clients tend to lag behind their web browser counterparts. Some web clients, such as Gmail and Yahoo, insert their own code into emails (and will strip certain CSS properties to maintain consistency on their webmail platform) but otherwise render using whatever web browser you use.

Microsoft Outlook, since 2007, has used Microsoft Word as its rendering engine. Try telling your company's main web developer that they have to design all of their websites so it renders correctly when you open it in Word and watch their respect for you grow tenfold. As a result, Outlook can be one of the hardest clients to design for and often dictates the rules you put in place for your email coding and design.

Microsoft Outlook is basically the Internet Explorer 6 of email.

When you're working with email, you'll need to go back to the basics for coding designs that work across all of these clients and their variations. You should code like it’s 1999 and stick to tables. This means:

Using <table> instead of <div>
Defining HTML colors #FFFFFF instead of #FFF (or more realistically in the case of white, #FEFEFE — some email clients reject using 100% white)
Using padding to adjust your box model instead of margin
Aiming for CSS2.1 instead of CSS3 and HTML4 instead of HTML5
Using per-property markup such as background-color instead of background
Using HTML attributes instead of CSS to manipulate the style
Adding inline CSS instead of style sheets or <style> blocks

There are some modern elements of web design you'll want to consider, such as using @media queries to make responsive designs for smaller screens, but most of what you'll be writing in terms of code wouldn't look out of place on a Windows XP machine.

With these design patterns, it's important to know all the ins and outs of coding specifically for different email clients. Each has its own quirks and unique ways of handling code: for example, AOL handles padding oddly and needs its own declaration, and forcing Outlook to render all images at 96DPI so users on Outlook 120DPI don't have scaling issues are two common corrections that need to be made in an email template.

As a result, the best way to approach building emails is to use a framework to start with—that is, a common set of CSS attributes and HTML used to create consistent results and code your emails faster. These have been built by a large email community in order to stay up-to-date with the ever-changing ways emails are rendered. Popular examples of frameworks include:

If you have the time and dedication, you can also create your own frameworks; for instance, at DemandLab we have an in-house framework called Vanilla. Alternately, you may want to look at the LaunchPoint ecosystem to find a service partner who can assist in working with you to build an email template.

Once you've started work on what your email code will look like, you'll want to consider Marketo's approach to email markup to help create the most user-friendly email experience possible.

Defining Modules and Editable Areas

First, a quick disclaimer: Marketo transitioned from an older version of its email editor to Email Editor 2.0 in 2015. This change alters the way marketers interact with emails to allow for a more structured definition of items like images and text areas, as well as introduces the concept of modules. We'll be talking about Editor 2.0 syntax throughout this section, but any older email templates using Editor 1.0 syntax are backward compatible with Editor 2.0.

Modern Marketo markup with Email Editor 2.0 provides a flexible array of options when it comes to structuring your emails. As such, you'll want to consider whether to make a fixed or modular email template.

A fixed template is exactly what it sounds like—a design with a structure that has predefined areas intended to be used and filled out every time. However, this comes with a tradeoff: if you're looking to add additional content or remove it depending on a send, you're stuck. The design is meant to be used in one way only. Modular templates, by comparison, provide pre-built areas you can add, clone, and remove as you see fit. Think of a stack of toy bricks where you can place one on top of another, remove it from the middle, or place three red and three blue bricks as you see fit. If you're used to other email providers, Marketo's module functionality is very similar to Stampready's module setup versus Campaign Monitor or MailChimp.

The majority of Marketo customers prefer to use modular templates, with good reason: the wide variety of modules you can make and use allow marketers to maximize their creativity. To set up a modular template, you'll need to first define the inner structure of your email—where you want your actual content to be as opposed to a header or footer—as either a <table> or <td> with Marketo's syntax. From there, you'll define your child <table> or <td> elements as modules. For example, if you have a table where the bulk of your content goes and want to define modules underneath it, you'd have a setup similar to the following:

<table class="mktoContainer" id="container" mktoName="Container">

<tr class="mktoModule" id="textModule" mktoName="Open Text Area"> [...] </tr>

<tr class="mktoModule" id="imageAndText" mktoName="Image and Text"> [...]</tr>

</table>

Or, alternately:

<td class="mktoContainer" id="container" mktoName="Container">

<table class="mktoModule" id="textModule" mktoName="Open Text Area"> [...] </table>

<table class="mktoModule" id="imageAndText" mktoName="Image and Text"> [...]</table>

</td>

All modules must live inside the .mktoContainer you define, and you may only have one container per email template.

When building modules, you can only have one module that spans the width of an email. That is to say, you cannot stack two modules side-by-side next to each other within a row as multiple columns. As such, if you want to create multiple, swappable variants of a design (such as the image on left, text on right, and text on left, image on right) you'll need to make multiple modules handling each variation.

It's also important to note that if you're looking at using dynamic segmentation when using your modules the modules themselves cannot be removed for certain segments—only the defined content areas within them can be changed. As such, you'll want to either come up with messaging for each segment or use a snippet (and corresponding snippet module), where content can be blanked out.

You'll notice that in the examples that there are predefined classes, ids, and a new attribute called mktoName; these three attribute/value pairs are needed to tell Marketo how to handle your code:

Classes are used to define what sort of item needs to interact with Marketo. In the above example, we used mktoContainer and mktoModule to note which of our tags were the module container and modules, respectively. This same setup is used for defining editable areas, as we'll discuss later.
For tags Marketo is handling, a unique ID must be assigned in line with HTML best practices. Do note that if you use a module multiple times, Marketo will assign a suffix to the ID of your module (e.g., "imageAndText6fb23ecd-2ae0-44a5-88a0-00a6f794ad68") to ensure each ID is unique. This is especially important to keep in mind if you plan to target modules with CSS; simply add an extra class after your Marketo class declaration to make sure your styling applies to every instance of the module.
Finally, a custom mktoName value is required. This is the user-friendly name that is displayed when using the email editor, whether as a module name itself or the name of the editable area. Be sure to use descriptive names to prevent any potential confusion.
By default, your modules will be added every time you create a new email. While this can be useful if you've defined header or footer modules, you may not always want this behavior. Simply add mktoAddByDefault = "false" to make the module available, but not show up by default. Likewise, if you are working on developing a new module or want to retire a module without removing it from code, you can add mktoActive = "false" to prevent it from appearing in the email editor.

Modules can be pretty diverse and serve a variety of needs, so experiment and see what combinations of modules make the most sense for your company.

Once you've defined your modules, you'll want to set up additional markup to handle where users should be able to edit. Some modules may not need any markup; for example, a module that inserts a line break will generally only have <hr/> as its content. However, when defining a place where users should be able to do any sort of open editing, the two main classes you'll want to look at are mktoText and mktoImg. In both cases, best practices are to wrap the area you want to be editable in a standalone <div> tag. For example, if you wanted to create a module that has nothing but paragraph text, you would create a module and editable area like:

<td class="mktoModule" id="textArea" mktoName="Text Area">

<div class="mktoText" id="mainTextArea" mktoName="Main Text Area">

<p>Lorem ipsum dolor set amet</p>

</div>

</td>

Note that you can include pre-populated content in your modules. In this case, the paragraph with Lorem ipsum would show up when someone brings in that module into the email. This can be especially helpful if you have content you know you'll use over and over.

It's also worth noting that when using the email editor, only text that has been defined in a mktoText module will carry over into the text version of your email. This means if you have items in places such as your footer that you want to have show up in the text version by default, you will need to make it an editable area even if you have no plans to edit something like your corporate mailing address.

The same <div> structure is recommended when defining an image area to edit:

<div class="mktoImg" id="thirdimgright3" mktoName="Right Image">

<a href="#"><img src="https://placehold.it/356x278.jpg" alt="INSERT ALT TEXT HERE" width="178" style="border: 0; width: 100%; max-width: 178px; height: auto;" /></a>

</div>

Here, you'll see that a <div> tag wraps an anchor tag and the image itself. This is the only way to create clickable images inside an email template, so unless you have an explicit need to define inline-displayed images, this markup is generally the way to go. Also worth paying attention to are the other attributes on the image tag itself. This provides pre-populated link URLs, style attributes, and alternative text, but can later be changed by the email user as needed.

Two other defined sections can be used in addition to images and text: mktoSnippet, which defines where you can place your pre-built snippets in an email, and mktoVideo, which will retrieve a YouTube or Vimeo video and create an image and link to the video. Advanced email developers may want to create HTML5 video embeds with an image and link fallback, but this markup can help users just getting started.

Your modules and design are limited to editable areas, but they can become turbocharged by using variables.

Using Variables Inside Marketo Templates

Marketo uses variables inside its email templates, which act a lot like the Marketo tokens you may be used to using. In fact, prior to Email Editor 2.0, some marketers would actually control their email's look and feel using embedded tokens! You first define them within the <head> section of your email template using <meta> tags, then use them as many times as you want throughout your template. Because they’re defined in the template, the end-user will be able to modify their values according to their rules. However, sometimes it's easier to show than tell, so let's jump into a real-life example.

For example, one of the modules on this email template, called "Feature with Image BG", is a table with background, some live text to edit, and a button. The design itself is pretty straightforward but translates to some complex HTML to make sure everything renders nicely across all devices.

As a result, this module is made with two editable text areas (one for the "New Report" area and one for the button), but also has six variables that are defined when you bring in the module:

The local variables you see defined are driven from <meta> tags defined in the <head> of this email template! You'll see a variety of options here: a color picker, a number counter, a boolean, an image definition, a number counter with the px suffix, and two dropdown lists of options.

Marketo provides a comprehensive list of variables in its Email Template Syntax documentation, which is definitely worth reading— you can also learn about other variables such as strings and HTML blocks—but for our purposes, we'll focus on this set. The meta tags that control these variables are as follows:

<meta class="mktoColor" id="calloutButton" mktoName="Callout Button Color" default="#EE7936" mktoModuleScope="true">

<meta class="mktoNumber" id="calloutButtonWidth" mktoName="Callout Button Length" default="160" min="100" max="360" step="10" mktoModuleScope="true">

<meta class="mktoBoolean" id="uppercaseValue" mktoName="Format as Uppercase?" default="true" false_value="initial" true_value="uppercase" false_value_name="NO" true_value_name="YES" mktoModuleScope="true">

<meta class="mktoImg" id="heroBackgroundImage" mktoName="Hero Background Image" default="[URL here]" mktoModuleScope="true">

<meta class="mktoNumber" id="heroBackgroundHeight" mktoName="Hero Background Height" default="250" min="100" max="500" units="px" step="25" mktoModuleScope="true">

<meta class="mktoList" id="heroBackgroundStyle" mktoName="Hero Background Style" values="frame,tile" default="tile" mktoModuleScope="true">

<meta class="mktoNumber" id="buttonWidth" mktoName="Button Length" default="160" min="100" max="500" step="10" mktoModuleScope="true">

Once again, you'll see classes defined (mktoNumber, mktoColor, mktoBoolean, mktoImg, etc.), a unique ID, and a mktoName attribute that's shown in the email editor as a friendly name. Other attributes you'll notice include:

Default: This sets what value should be pre-populated when an email or email module that uses the variable is first brought in. This can be a default hex color for color values, a predefined string or number, image value, picklist value, or HTML block depending on the variable
Min/max/step: When using mktoNumber variables, you can set an up a lower and upper boundary on what can be adjusted: you don't want someone to set up a 2000px wide button! To help users, you can also define steps or the increment in which you can tab up and down numbers inside the UI. For example, in the buttonWidth variable we've defined, there's a step of 10, so clicking the up arrow in the UI will take a number from 160 to 170; likewise, clicking down will remove 10 from the number. This can be overridden by typing in a number as well.
Values: When using mktoList variables, the values attribute defines all possible values that can be selected using a comma-separated format.
False_value/true_value/false_value_name/true_value_name: These four attributes allow you to define the label of the boolean you're toggling between (whether that's YES/NO, TRUE/FALSE, YELLOW/GREY, etc.) with false_value_name, and true_value_name, as well as the values you want to have that variable, populate once you switch the boolean in true_value/false_value.
mktoModuleScope: When defining a variable, you can choose whether it's a variable you would like to apply across the board or only to one email module. Using mktoModuleScope = "false" can be especially helpful when defining brand colors or commonly-shared attributes; otherwise, using mktoModuleScope = "true" will allow you to alter the settings of a variable with each module you bring in.

Variables are defined using ${variable_id} syntax and are drop-in replacements for the content you wish to alter with the variable. The actual markup for the button in the module pictured above looks like the following:

<table width="${calloutButtonWidth}" border="0" align="${buttonAlign}" cellpadding="0" cellspacing="0">

<tr>

<td style="background-color: ${calloutButton}; overflow: hidden;">

<table width="100%" border="0" cellspacing="0" cellpadding="0"> 

<tr>

<td height="45" class="mktoText button" id="buttonStuff" mktoName="Button" style="text-transform:${uppercaseValue}; font-weight:bold;  text-align: center;"><a href="#tbd" style="display: block; width: 100%; padding-top: 10px; padding-bottom: 10px; color: #ffffff; text-decoration:none">Aenean in dignissim</a></td>

</tr>

</table>

Here, you see four variables defined:

calloutButtonWidth: the number variable setting the width of the button
buttonAlign: the picklist variable defining whether the button should be left, center or right-aligned
calloutButton: the color variable defining what color the button should be
uppercaseValue: the boolean variable defining whether CSS should override the text to be in all-caps or not

And finally, we see the table cell defined as an editable area to place the link for the button itself. These variables can be repeated throughout both a single module, multiple modules, or the overall structure of the template itself.

As always, whenever you build out an email template, you should extensively test your design and code. In addition to using the preview and send sample functionality that's available for templates, you should test building actual emails with your templates for ease of use, reliability, and scaling. Using a Marketo add-on package such as the Email Deliverability Power Pack will allow you to see how your emails render in a variety of clients and situations.

The single most important thing you can do to master not only Marketo but front-end development as a whole is committed to learning and expanding your skillset: this is why we’ve included links to some helpful articles, tips and tricks, and more information about the topics we’ve covered today for you to review as you start your Marketo template journey.