Want to learn how to code your own HTML email campaigns? You've probably Googled all kinds of web pages that give you countless "what works, what doesn't" charts. But instead of focusing on specific tactics, let's go over some fundamental principles.
In this article:
Multipart Email Delivery
What makes HTML email so hard for most people is not the designing and coding part. It's actually delivering it properly. You can't just attach your HTML file and images to an email and send it. When people open the HTML file, your images will all be broken (because their email program has stored them in a temporary folder somewhere on your hard drive.
Even if you do manage to get your HTML email to display properly, there will be some recipients who can't (or won't) view HTML email in their email programs. So you need to send your HTML email along with a plain-text alternative version of your message. Then, your recipients' email programs will automatically determine which format to display. In the early days, email marketing services would call this "HTML email sniffers." As in, "our solution comes with sniffers that automatically detect which version to display for your recipients." The truth is, the "sniffer" is on the recipient side, not the sender. It was just easier to explain that way. Nowadays, just about everybody can receive HTML emails. Some still choose not to.
So how do you properly send an HTML email along with a plain-text alternative version? Simple. You send it in "Multipart/Alternative MIME" format. If you're a programmer, this is where the gears in your brain start spinning. So go ahead and bookmark this web page, so you can come back to it later. Now, go on and Google "multipart alternative" and figure out how to send them from your own server. You may find some PHP or Coldfusion or ASP scripts out there. You may even find a way to rig Outlook or Thunderbird to send multipart messages. Go ahead and get it out of your system now. Then, when your ISP shuts you down for sending too many emails from your account and hogging up all their bandwidth, or when you realize that properly cleaning bounces and unsubscribes and tracking opens and clicks is a lot of work, or when you get blacklisted because your server wasn't reputably configured, come back to this page.
Back again? Cool. By now, you've learned that delivering HTML email is the hard part, and it's not what you were hired to do. That's the part you want to outsource to an email service provider (ahem, like MailChimp). Email service providers (the good ones) work alongside ISPs and anti-spam groups and maintain their servers for deliverability.
So you can design and code your own HTML emails. Just use an email service provider to handle delivery. FYI, MailChimp comes with built-in templates, but also lets designers use their own code.
Like I said earlier, coding an HTML email is basically like coding a web page. Only you've got to do it the old fashioned way. Remember back in the 90's when there were no WYSIWYGs yet, and you had to code everything by hand? Remember the Internet Explorer vs. Netscape wars? Remember how you had to test your work over and over and over again? HTML email is a lot like that. Times 10.
- The most important thing (if you wish to preserve your sanity) is to keep it simple. Focus on your message, not your craftiness.
- Images should be posted on your publicly accessible web server. In your code, use absolute paths to point to them. Attachments are often stored in randomly named temporary cache folders by some email programs. They also hog a lot of bandwidth (especially when they bounce) so attachments are not the way to go.Tip: One common mistake is to post your image files on an intranet, extranet, password-protected server, a secure server that's extremely slow, or a free hosting site (images my not show due to bandwith issues). Post images on your fast, public-accessible web server.
- TABLES and SHIM.GIFs are your friend. Keep it simple, because email programs use different HTML rendering engines. Some of them use Internet Explorer, Firefox, or in the case of Outlook 2007, Microsoft Word (what a headache!). Some of them use their own proprietary renderers (Lotus used to do that, which is why you'll find lots of old rants on out there about Lotus and HTML email problems).
- Don't code your emails too wide. Most people view messages in their preview panes, which are narrow and small. Don't ask me if you should code for 1024x768 screens or 800x600. Puh-lease. This is email we're talking about here. The preview pane in AOL 9 is less than 200 pixels wide, my friend. Think small. The templates we design at MailChimp are never more than 600 pixels wide, or they're fluid-width.
- Test how it renders. Your email will display differently in all the different email programs out there. So testing is a must. And we're not talking about IE, Firefox, and Safari. We're talking about Outlook, Outlook 2007, Outlook 2003, Outlook Express, Thunderbird, Apple Mail, Eudora, Lotus, Gmail, Yahoo!Mail, AOL, AOL Web, Hotmail, MSN, Comcast, Earthlink, and on and on and on. How to cope? Keep it simple. TABLES. 600 pixels wide max. You can also test how your email renders in major programs with the MailChimp Inbox Inspector.
- Think like a spam filter. You have to consider spam filters and spam firewalls when you code. It's pretty obvious that spammy words like "Viagra" or "V14GR4" will get you spam filtered. But spam filters also look for stuff like, "do you have too many images, and not enough text?" If you're sloppy with your code, you'll look like a sloppy spammer. See: How spam filters work.
- 99% of your CSS won't work (especially not in the browser-based email services like Gmail, Yahoo!Mail, etc.). That means no CSS-positioning, DIVs, etc. Before you ask me for a detailed list of what works and what doesn't, just remember this (it'll save us all a lot of time): When your email is opened in Gmail, for example, the CSS in your HTML email could potentially override the CSS on the rest of their page. So they disable a lot of it. Inline CSS is safer, and plain-old FONT tags are safest (code like it's 1996, remember?). Or check out MailChimp's CSS inliner tool.
Email Open Tracking
If you're sending HTML email, chances are you're doing it for marketing of some sort. If that's the case, you probably want to track opens and clicks. This functionality is built right into email marketing solutions like MailChimp, so you really don't have to do anything. But it helps to know how it works.
To track an "open" in an HTML email, you'd embed a tiny, 1x1 pixel transparent .GIF at the bottom of the message. Some people call this a "tracker image" or "web beacon." Actually, you probably don't want it to be 1x1 pixels, because that's a little too common. Some anti-virus packages automatically block images that are 1x1, because they know it's a beacon. Anyways, whenever your recipient opens his email, the tracker image is downloaded from your server (and you can count that as an open). This is why most people will tell you that you can't track opens unless it's an HTML email, and why open tracking must be taken with a grain of salt. That's only partly true.
It's true that only HTML email can have embedded tracking images. But you can track "opens" from a plain-text email too. MailChimp lets you enable click-tracking in your plain-text emails. Whenever someone clicks a link in their plain-text email (or if they leave images turned off while viewing your HTML email) we can track that as an "open."
That brings us to click tracking. You've probably already figured this one out. Just use redirect scripts. MailChimp automatically converts all links in your emails to point to our redirect scripts. When a recipient clicks your link, they're redirected from our server to your original URL (in the blink of an eye) and we track the click. That helps us generate nice little campaign reports telling you which links your recipients clicked most.
I can't just teach you how to code and deliver HTML emails without telling you at least a little bit about proper list management. If you've made it this far, you're probably the type of do-it-yourselfer who is managing your own email list in some database on your server. Right? That's fine, but if you don't manage your list properly after every campaign you send, you could get blacklisted by ISPs and anti-spam groups.
Here's what you need to know about managing your email lists:
- First of all, don't send mass email marketing to any lists unless the recipients gave you permission. The key word there was "marketing" not "transactional email" or "personal messages."
- After every campaign you send, you will get bounce backs. There are two overall types of bounces. A "soft bounce" means the recipient was "temporarily unavailable" (account overquota, server down for maintenance, etc). A "hard bounce" means the email was undeliverable. The account has expired, it never existed, etc.
- You should remove hard bounces immediately, because if you keep sending emails to a server, after that server has told you repeatedly "hey buddy, that email doesn't exist here!" they will most likely start blocking your future messages (and telling other servers out there what a jerk you are, and that you're probably an infected zombie).
- If an email soft bounces 3 campaigns in a row, they say you should clean it from your list. That's best practice, But we've found that if you send daily emails, you're going to lose A LOT of subscribers while they're on vacations that last more than 3 days. Even if your list is huge, and you can afford to lose a few subscribers like that, you'll probably get annoyed at all the "hey, I'm not getting your emails anymore" complaints.
- Unsubscribe requests should be handled immediately.
- For more information on proper list management, check out these suggestions from MAPS.
By the way, you can setup a list in MailChimp, and we'll manage it for you (removing bounces, handling unsubscribes, etc). Then, you can totally customize the signup form and opt-in process to match your branding. Or, use our API to pass opt-in data directly from your website to MailChimp.
|Was this article helpful?||
|What can we do to improve your experience with articles like this?|
At this time, we are unable to reply to any responses, but we'll use this information to keep the site up-to-date.