Where do you even start?
From designing emails to tracking metrics, the modern email stack is surprisingly complex. With so many moving parts how do you keep track of it all?
At Sendwithus we feel your pain. That’s why we designed this guide which will take you through every step of the process.
Each category is broken up into subcategories and includes our suggested services, some of which are open source.
Scroll down to get started.
Making something pretty in photoshop is one thing, translating that into an email is another matter entirely.
First step to designing emails: turn your designs into code.
If you choose to write your own templates from scratch, here’s a handy guide to get you started on coding responsive designs. You will also want to use something like Premailer to automatically inline your CSS.
If you want something a little more user-friendly, but still want to be hands-on with the code, there are editors that are made specifically for email design. Two of our favorites just happen to be Sendwithus, with its powerful code editor and real-time visual preview, and the Dyspatch visual editor, which allows users of all skill levels to build great emails using pre-coded, drag-and-drop content blocks.
Now that your template is set, you need to stash it somewhere until it’s time to send. The biggest stumbling points here are usually administrative. How do you maintain a set of templates that are stable, but not stale?
Updating your templates, especially for larger teams, can create a lot of problems. If you’re going the DIY route, you can manage them with the rest of your code, but this requires the email team to understand Github or whatever you use for version control.
Automating anything you can is the key to keeping your email design workflow in order. You will want a system like the Grunt Email Design Workflow project. It automates a lot of the process that we’ve covered so far, as well as stuff we’ll get to later like testing and sending (and even pushing to Sendwithus.)
Personalization data you want to use in your email can be merged in in two ways: it can be pulled from your customer database (in the case of a newsletter or batch email) or pushed with the event trigger (usually the case for transactional.)
Formatting Dynamic Content
Typically, you’ll use some sort of templating language to organize the data you pass to be used in your email. Jinja has a really straight-forward intro to data manipulation in the docs.
Pushing dynamic data is done through whatever you are using to trigger your email sends. A lot of people use a centralized event handler like Segment, but this can also come from an analytics platform like MixPanel or an event relay like Zapier.
Testing and Rendering
Now that you have everything in place, it’s time to make sure it works.
To test your rendering in any of the huge variety of emails clients, we recommend Litmus. It’s the industry standard in cross client compatibility. That said, never underestimate a simple test send to a couple of inboxes.
Now you need to make sure your triggers work. This depends a lot on your setup; if you’re sending events through something like Segment, you can watch the calls in their debugger. An engineer of ours also developed Insomnia, which is a really cool tool for testing API calls. This is a great way to ensure that an event you send will be properly parsed and digested.
So you have your bulletproof template ready to merge in dynamic data and render on any client known to man.
Now you just have to send it and make sure it gets there without getting marked as spam.
There are a couple of basics you need to cover when setting up sending through a new domain. SPF records are just a list of servers that are allowed to send email from your domain. DKIM records are a public key that clients can use to verify that an email was actually sent by you.
Choosing an ESP
We have a policy of ESP neutrality here, but there are some criteria you want to keep in mind when making your choice:
- Template Management – Some ESPs, like SendGrid have built-in template storage for transactional emails.
- Deliverability – In addition to supporting SPF and DKIM, you want to make sure your ESP can handle the volume you want to send. It’s tough to beat SparkPost in that arena.
- Dev-friendliness – It’s also a good idea to make sure your chosen ESP can output your analytics events in a way that you can make use of. MailGun is really good at this.
Most ESPs will give you analytics on your sends, bounces/deliveries, opens, and clicks. But what do you actually do with that information?
The most common metrics for measuring a successful email are Open Rate and Click-to-Open Rate (CTOR). Beware anything labelled as “Click Rate” that doesn’t distinguish between the two. Some ESPs will also remove sends to those who have unsubscribed from the total. We’ve got a help doc that goes into some more detail on these points.
It’s also important to have a system in place for tagging links in your emails so that, when they click through to your site, you can track their behavior to make sure your conversions and revenue are in line with your open and click metrics.
This can be as simple as just always using the same UTM tags, but as you scale it’s worth tracking down to the individual template and link clicked.
Testing and optimization work a little differently for marketing and transactional emails. Typically, for a marketing email, you’ll send a small test to a subset of your list, then send the winning version to the rest – a batch test. With transactional, though, you get to run multiple rounds of testing on every email, what we call “continuous testing”.