Email is complicated.
And surprisingly enough, it's rarely given the attention it deserves - especially considering the foundational role it tends to play in marketing automation. For people who are new to Marketo, or new to email marketing, it can be a hard nut to crack - as I see it, for two main reasons:
- Email requires a multitude of skill sets - a good email relies on good copywriting, graphic design, UX design, HTML and CSS, analytics, and more.
- Email is constantly evolving - technology moves quickly, and as email clients, devices, operating systems, deliverability and networks do, so does best practice.
If coding isn't really your jam, you don't really find design comes naturally to you, or you're just really stretched (aren't we all?) then getting your head around it all can be a real challenge. But it isn't impossible.
The first step is not falling prey to the many myths surrounding email. So, here's a breakdown of five myths I hear (and see in action) most frequently...
MYTH #1: EMAIL & WEB DEVELOPMENT ARE THE SAME.
Nope. Email really is a whole other beast, and will still be a learning curve for those with experience developing for web. There's a reason why people joke that email code looks like it's from the 90s… because a lot of it has to be. Where web typically tests across a handful of browsers, operating systems and screen sizes, there's far more to contend with in email. Litmus estimates that every email send has (conservatively) 15,000 possible renderings (see their exploration of why email rendering is so complex). Just look at:
- How varied CSS support is in Campaign Monitor's Ultimate Guide to CSS;
- The long list of specific recommendations in Email on Acid's Email Development Best Practices;
- Really Good Email's New to email coding? Here's where to start.
With so many variables, each their own unique and often unpredictable quirks, creating a robust and reliable email email template can be challenging for even the most patient of developers.
Key takeaway: If you want truly great, responsive, consistent and on brand emails, you have to be prepared to invest in creating and maintaining them - whether by hiring an experienced email developer or someone with the ability to grow that skill set (combined designer/developer roles are common), training internally, or hiring an experienced third party.
MYTH #2: I DON'T NEED A CUSTOM EMAIL TEMPLATE
Well... actually, you probably will. This isn't to say it's something everyone needs out of the gate - but there's a tipping point on the maturity curve where, really, you probably do need to invest in designing and developing a bespoke email template.
Marketo's starter templates are called “starter” templates for a reason. After a while you'll probably start to find them limiting, and frustrating. But frustration is good - it means you've developed a sense of what you do and don't want in a template; from a design perspective, and from an in-editor usability perspective. The particular needs of each use case are entirely unique - and the best way to meet them is with a custom template.
Your in editor experience is critically dependent on your email template - the vast majority of complaints I've heard about the editor are not the result of inherent flaws in the editor itself, but problems with the template. Going custom can enable you to...
- Fully customise the look and feel of your emails;
- Run all your emails on a single “master” template (making updates much easier) by including a variety of flexible modules (see: Add Modules to your Email - Marketo Docs - Product Documentation);
- Utilise Marketo's email syntax to enable greater in-editor experience;
- Include My Tokens to maximise efficiency and ensure consistency;
… and much, much more.
But: make sure either you or the developer/third party you work with is specifically experienced in Marketo. You'll get the best results by considering not just best practice dev, but also in-editor usability - someone with strong experience is more likely to have a good sense of where modules should start and end, which kind of Marketo variables (see: Email Template Syntax - Marketo Docs - Product Documentation) are best suited in different spots, which sections may need to cater to dynamic content, etc.
Key takeaway: Don't expect starter templates to cater to advanced use cases, and do expect to invest in a custom template at some point - just get it done by someone experienced, and expect the template to be continuously added to and evolved over time.
MYTH #3: OUR EMAILS WILL LOOK EXACTLY LIKE THE DESIGN
We wish it were so... Unfortunately, unless your designer(s) are familiar with the ins and outs of HTML & CSS support in email, or you're okay with emails being completely image based (hint: you shouldn't be) then… yeah. No.
If you're looking at creating a custom template, or even just working on a custom element within a single campaign, it's really beneficial to ensure the designer knows the complexities of email, or that they're in close contact with someone who does. Even better if they're the one who will develop the template. Not only will it save you a lot of time (and potentially money) in revisions at the end of the process, it'll also save a lot of disappointment if people fall in love with a concept that can't reasonably be executed, or simply isn't best practice.
Now - none of this is to say that your emails can't be beautifully designed. It's more to say that you'll benefit from being mindful of what limitations exist - and how you can work around (or with) them. For example…
Limitation: Not all clients accept custom fonts.
Best Practice Solution: Provide custom fonts for the clients that can accept them, with closest possible resemblance fallbacks for those that can't. Avoid or minimise heavily stylised fonts where possible (both for legibility and fallback reasons). In cases where a specific font is really important, images (with alt text!) can be used, but should always be kept to an absolute minimum (preferably headlines only) - live text is always preferred.
Progressive enhancement is always good to be thinking about here: just because 20% of your audience are using a client that doesn't support a feature doesn't mean you shouldn't enable it for the other 80%. Provide those features to those whose clients do support them, and make sure the fallback is graceful for those whose clients don't. So… It's also helpful to know what your database's client split is (Gmail, Outlook, etc)! It'll start to dictate what features you work hard to enable, vs which you avoid like the plague.
Key takeaway: involve email/dev experts in the design process, and aim for a balance of what's practically achievable and what's beautiful - but always within the context of how email clients are actually represented in your database.
MYTH #4: SENDING A SAMPLE TO ME + A COLLEAGUE = TESTING
It's... not a particularly rigorous test. While it's better than nothing, if this is all the testing you're doing, you're probably missing a lot. We've already covered here how complex email is, and how many different possible renderings a single email can have. If you're using Outlook 2016 on Windows and your colleague is using Gmail on Chrome, you're only looking at a tiny tiny percentage of the possibilities - and it's entirely possible that you're not looking at the clients that are most heavily represented in your database.
In an ideal scenario it'd be every email you send - but at least every template, and any emails with custom dev, at a minimum of 1x test per month - should be tested using email testing software (Email on Acid and Litmus are two of the key players in the market here).
There's a few major benefits to this (though they'll vary according to tool/subscription)...
| You can test... | Why this matters... |
| How your emails look across a large number of clients. | It gives you the opportunity to fix those breaks and ensure your emails look consistently good. |
| Whether your subject line and preview text are following best practice, and be able to preview how they appear in different clients. | Identifying issues here can directly impact your open rate. |
| How your email looks in text only, with images disabled, and for colour blind users. | Accessibility is becoming increasingly important in email, with many suggesting it will quickly become a critical factor in deliverability and compliance. |
| How long your email will take to load for most users, and be able to see the size of each individual file. | Load speed can have a significant impact on the overall performance of your email, so checking your file size and ensuring you're using appropriate file formats, compression, and scaling settings is not only massively important, it's also actually pretty easy. Check out this guide from Demand Lab. |
| Whether your emails are at risk getting flagged as spam due to missing/incorrect settings, content, sender reputation or IP issues. | Deliverability is complex (check out Send Grid's guide for some insight). While these tools are not always going to be perfect, they'll help you keep tabs on whether things are going wrong and can also help you get a sense of why. |
...and plenty more!
With the right subscription and tool, you can also use additional analytics to get more insights into what clients are most heavily represented in your database, and how people are engaging with your emails.
Key takeaway: if you're not using an email testing tool, you may be sending broken or sub-optimal emails without realising it - a relatively small investment in a testing tool could improve your email performance and increase your confidence & performance significantly.
MYTH #5: I DON'T NEED TO KNOW ANY OF THIS.
I'm going to assume that if you're reading this, it's because you're interested in creating great emails - if so, you should definitely know these things.
Email is complex and constantly changing - but for many of us that's part of what makes it kinda fun. You don't need to be an expert in all of the above, but you having at least a peripheral and conceptual understanding of both what they entail and why they matter will help you make major strides towards creating great emails, every time.
BONUS TIPS!
Because I can't end a post about email without mentioning some of these other points...
- Don't expect to copy+paste your HTML from a past system into Marketo and have everything work like magic. Every email editor - including Marketo's - has specific requirements in order to enable functions. Marketo's syntax is simple and powerful - and you'll notice the difference if it's missing!
- Don't edit the code of individual emails! Editing the code (outside of editable areas) breaks emails from their templates, and prevents any template updates from being applied to them.
- Minimise the number of templates you have. Creating a new template for every product, every channel, or every send? Chances are, you're missing a major opportunity to optimise.
- Use Tokens! If you're not utilising tokens within your emails - especially My Tokens - start! They're a great way to control things like brand colours, unsubscribe links, copyright dates, legal disclaimers, etc. But...
- Test your tokens! Don't be the person who sends emails that say “Hi DUMMY.”
- Be cautious with velocity script if you're not familiar with it. Velocity is an incredibly powerful way to enable awesome functionality in marketo. But with great power, comes great responsibility… use it carefully!
- Ask Community for help - within reason. Community is a great resource for advice and support, but don't forget that this is a volunteer community of users! Ask for help pinpointing problems, advice on best practices, but don't expect people to develop whole modules or provide complete strategies.
- Help community help you! If you're looking for help from community, you're more likely to get assistance quickly if you provide as much information as possible from the get go - including screenshots and full code where relevant.
P.S. Enormous thanks to the fab minds that contributed to this post, especially Juli James, Sydney Mulligan, Courtney Grimes, Josh Pickles & Amber Hobson.
24 Comments
.png)