“An absolute delight that will make my job so much easier”

I just wanted to let you know how much I LOVE Campaign Monitor. I have been doing email campaigns for our clients for two years, using various software solutions including an in-house, custom-made solution that was supposed to do everything Campaign Monitor does. I have faced nothing but frustration with each campaign taking half a day to get together lists, upload templates and naming variables and etc. I have also introduced many errors into large email campaigns which could have been avoided with a simpler interface.

But using Campaign Monitor for the first time I spent less than an hour to complete a rush campaign. I was absolutely thrilled (and I don't often get thrilled with software unless it's Call of Duty or something)! Using this application is an absolute delight and will make my job so much easier. You have won a dedicated customer who will be referring this product to anyone and everyone who would have a use for it. THANKS!

Andrew Branch, Ideacog

Read this post Posted by David Greiner

How Windows Live Mail and Yahoo Mail Beta Shake Out with CSS

Moving past my angst at recent events, I have tested CSS support in two new webmail clients: Yahoo Mail Beta (YMB) and Windows Live Mail (WLM). The results are a nice blend of excellence and incompetence. Surprised? Didn’t think so.

Before I dive in, however, I’d like to preface this article with a particular point of interest. With the release of Outlook 2007 looming it feels oh so very awkward to report on how CSS is handled in other new clients. One might even give in to despair with the realization that irrespective of how a standards-based email renders across the board, it simply won’t fare well in a client used in many offices around the globe.

But from my perspective, it’s clear that we need to overcome this obstacle like other web standards of the past: we push the web community (browser/client developers and web designers alike) to embrace web standards in avoidance of regression. It’s a long road, but well worth the efforts. If we backed down from the parallel challenge with standards support in browsers, today’s web would be a very different place.

I also want to shed some light on the dark caverns of rendered markup in these new webmail clients. There is a current trend in webmail clients which employs a dizzying level of AJAX to make webmail look more like a desktop application. It’s pretty amazing what these developers have accomplished. Anyway, getting to the actual code of a message for viewing rendered markup was quite labor intensive. I owe my gratitude to Chris Pederick who put together the essential Web Developer extension for Firefox which enabled me to get to the source of my test messages.

Yahoo Mail Beta

Yahoo is a company dedicating itself to progress in web standards. I continue to see advances with CSS and accessibility on redesigned pages on their site and within their new products. (Go, Yahoo team, go!) The new YMB client is no exception. My tests revealed a webmail client with serious support for CSS. In fact, it’s the best webmail client I’ve tested. They prove that you can support CSS in a webmail client while maintaining security, speed and top features. Take a peek at its beautiful rendition of my test email:

[screen shot of Yahoo Mail Beta interface]

However, there is one highly unfortunate CSS property that Yahoo still considers to be problematic: position.

In previous articles I outlined how Yahoo Mail replaced all instances of position with xposition, thus rendering them inoperable. Now, however, Yahoo takes this approach to a new level. Instead of making the aforementioned modification, it strips the email of all instances of position. And not just in YMB, but in the original Yahoo Mail as well.

So with Yahoo Mail and YMB, all positioning is out the window. Hello float. All said, I think this is pretty minor in the scheme of things. Thanks, Yahoo.

Yahoo Mail Beta’s score: “excellence.”

Windows Live Mail

Where do I begin? I must give the WLM team credit for their advances in support for CSS, succeeding Hotmail by great strides. Not surprisingly, however, they have failed to offer support for many core CSS properties. In some ways this is worse because Hotmail’s handling of CSS-formatted emails yielded an acceptable email, comparable to a rich-text document. With a half-hearted attempt at CSS support, the result is problematic. Let’s take a look at where WLM falls down.

Margin

Good bye margin. Yep, it’s gone. Every instance. The most significant problems arise when we need to trim default margin to elements like blockquote and need to add to the default margin of elements such as a div:

[screen shot of Windows Live Mail interface]

After WLM eradicates my margin declarations, my blockquote encroaches on the sidebar. And note how all of the text is pushed to the left edge of the window because the margin I applied to my paragraphs and headers has been axed.

Albeit we still have padding, this creates its own complexities when working with even a moderate level of design.

Image Caching

Okay, email service providers, get ready to scream. Ready? When WLM opens an email it grabs linked images and downloads them to a local application-directory. So those tracking images you use to report how many times and email has been opened? You only get one hit irrespective of how many times a message is opened. Okay, let it out. Scream!

This is how it works:

src="/your/path/logo.gif"

Becomes:

src="ApplicationMain_11_data/logo.gif"

Why does WLM do this? Presumably to cache them for speed. Of course I’m giving them the benefit of the doubt here. (Don’t get comfortable, WLM team—I’m not finished with you.)

Personally, I think it’s a nice uppercut to all of us. But I’ll let you folks decide how detrimental this is to what we do.

Conversion of Quotes

This one is rich. I hope you only want to use fonts with single names such as Helvetica or Georgia. CSS requires that when declaring a value for font-family, two-word names must be enveloped in quotes. So Trebuchet MS must be declared as follows:

font-family: "Trebuchet MS", sans-serif;

WLM says “no” to quotes in values, so the aforementioned sample becomes:

font-family: "Trebuchet MS", sans-serif;

This renders the declaration inoperable, rendering fonts to the browser default. So if our design employs Lucida Grande or Trebuchet MS, per se, we must either accept WLM’s presentation as is and proceed with our two-name fonts or compromise our design with a single-name font.

Background

WLM strips all instances of background. Good bye background images. While this is problematic for our pretty designs, it poses a threat to a more significant issue: accessibility. WLM strips the entire background declaration, which includes any colors therein. So if you have white text atop a colored background, you’re left with invisible content when WLM is finished beating you up.

There is hope, however, in that we can exchange shorthand for longhand when declaring background properties. So:

background: #c1d7ed url("img/bqTop.gif") no-repeat;

Becomes:

background: url("img/bqTop.gif") no-repeat;
background-color: #c1d7ed;

This enables us to retain background colors amid WLM’s background-image cleansing. The result, while less than satisfying, is more or less acceptable. Let’s compare.

My test as seen in Yahoo Mail Beta:

[screen shot of background-image success in Yahoo Mail Beta]

The same test as seen in WLM:

[screen shot of background-image failure in Windows Live Mail]

Headers

By default, headers (h1–h6) inherit font properties as previously defined in a style sheet. But with WLM, nothing is inherited. So it is important to redefine font properties as necessary. Fortunately the named value inherit does function within WLM. So font-family: inherit; works as intended. Phew.

ID Replacement

This is by far the worst of the lot, and is reminiscent of the .Mac problem I noted in a previous article.

Webmail clients have evolved to ensure that type selectors do not override CSS declarations for the client itself (a problem for which I have illustrated a considerate solution). The common solution on part of webmail-client developers is to add an all-encompassing div to an HTML email, give it an ID or class, then prefix all class- and id-selectors (from the email) with the ID or class from the new div.

So the CSS/HTML pair:

#Content { }
<div id="Content"></div>

Becomes:

#EC_Content { }
<div id="EC_Content"></div>

A reasonable solution if it were properly implemented. WLM and .Mac both have their faults in that they fail to appropriately match new parent div elements. Where WLM falls down is that it only applies its prefix in the CSS to the first ID/class selector in an element, leaving child ID/class selectors behind.

So the CSS for:

#Content #Primary {}

Becomes:

#EC_Content #Primary {}

But in the HTML:

<div id="Content"><div id="Primary"></div></div>

Becomes:

<div id="EC_Content"><div id="EC_Primary"></div></div>

Obviously this renders all child ID/class selectors inoperable. The good news is that WLM does not prefix type-selectors in either the CSS or the HTML. So:

#Content h1 { }
<div id="Content"><h1></h1></div>

Becomes:

#EC_Content h1 { }
<div id="Content"><h1></h1></div>

I think we dodged a bullet on that one.

Why webmail-client developers can’t get this right is beyond my comprehension. It is vitally important and is an obvious oversight which is now becoming commonplace.

Windows Live Mail’s score: “incompetence.”

In Summary

It comes down to this: Yahoo is leading the way with their support of CSS and web standards, while Microsoft has once again proven they are falling behind. I would gladly stand up and applaud Microsoft for development of a product which offers a high level of support for web standards. But with Windows Live Mail, this is a big “no can do.” As for the Yahoo team, allow me to celebrate your efforts. The first round is on me next time you’re in Portland.

Read this post Posted by Administrator - 28 Comments

The truth behind the Outlook 2007 change and what you can do about it

When I posted about Microsoft's decision to use Word instead of Internet Explorer to render HTML emails in Outlook 2007, I certainly didn't expect the storm of controversy and (sometimes) constructive discussion that eventuated. The post has already breached 300 comments and made the front page of Digg, Del.icio.us and Techmeme within a few hours. Heck, we even managed to land the number five spot on Alexa's fasting moving sites on the web. This is clearly a topic many of you are passionate about.

So why did Microsoft make this change?

In my post, I chanced a guess at Microsoft's motivations for this change:

By default Outlook uses the Word engine to create HTML emails, which it's done for years now. Perhaps Microsoft figured that in order to keep the look and feel of emails consistent between Outlook users they'd display emails using the same engine that created them.

As diplomatically explained by Molly Holzschlag, it turns out that this is exactly why Microsoft made the change. It has nothing to do with security or the remnants of an anti-trust decision. I'm not going to harp on about what I think about this decision - I can certainly understand Microsoft's motivation for making the change. It's been made, and the best thing for us to do now is deal with it and use our frustration to constructively encourage Microsoft to resolve the existing issues with the Word rendering engine.

What can you do?

Molly is currently working closely with Microsoft as part of the Microsoft/WaSP Task Force and points out this refreshing fact - Microsoft is prepared to listen.

Please comment as to your experiences and include any links to problem cases. I promise to make sure the top priorities and concerns get in front of the right eyes. Microsoft was very clear in letting me know that if we want a feature and need it and get an organized list to them, those issues will be addressed and prioritized as the new engine develops in response to developer needs, too.

As email designers, all we have to do is provide examples of our older CSS based designs that are now breaking in Outlook 2007. The obvious challenge there is that most of us don't have a copy yet (it's being released publicly next month), so these reports may take some time to trickle through.

At any rate, I encourage anyone who has noticed any discrepancies in their email designs using a pre-release version of Outlook 2007 to chime in on Molly's post with the URL of your email and a short explanation of what's breaking. If you don't have a copy yet, you can also test Outlook 2007 support using SiteVista, which we reviewed recently.

Read this post Posted by David Greiner - 102 Comments

All about email open rates

Our customers often ask us what 'open rate' means, and whether the open rate they are getting is any good or not. We've put together the following guide to open rates, which you will now also find in the help section of your account.

What is an open rate?

Open rate is a measure of how many people on an email list open (or view) a particular email campaign. The open rate is normally expressed as a percentage, and at Campaign Monitor we calculate it as follows:

Total emails opened divided by total emails delivered (i.e excluding any bounces)

So a 20% open rate would mean that of every 10 emails delivered to the inbox, 2 were actually opened.

How do you measure an open?

When each email is sent out, we automatically add a piece of code that requests a tiny, invisible image from our web servers. So when a reader opens the email, the image is downloaded, and we can record that download as an open for that specific email.

It is important to understand that the open rate is not a 100% accurate measure. Recording an 'open' can only happen if the readers email client is capable of displaying html with images, and that option is turned on. So if you are sending text-only emails, there is no way to record open rates (the exception is if they actually click a link). Similarly, people reading your html email without images showing will not be recorded as opens.

Another issue is that your readers may have a preview pane in their email client. That preview pane might be displaying your email automatically (and therefore downloading the images) without the reader ever having to click on it or read it.

So you should never take your open rate as a hard and fast number, because you can never know the true figure. It is much better used as general guide, and as a way of measuring the trends on your email campaigns.

What is a typical open rate?

Really, there is no typical open rate. The rate obtained for any list, or group of lists will depend on how it was measured, when it was sent, the size of the list and a zillion other potential variables. There is no shortage of benchmark numbers out there, but even between benchmark figures you will find big variation in the reported open rates.

So instead of giving a specific percentage, we've come up with the following chart.

Simple chart showing that most industries have average open rates between 20% and 40%

There are certainly some broad trends in open rates.

  • As list size goes up, the open rate tends to fall; possibly because smaller companies are more likely to have personal relationships with their list subscribers.
  • Companies and organizations that are focusing on enthusiasts and supporters, like churches, sport teams and non profits see higher open rates
  • More specific niche topics, like some manufacturing areas also typically have higher open rates than emails on broader topics

Why don't you just give me a number!

So what if you or your clients just have no idea of what is a reasonable open rate? Based on everything we have seen here at Campaign Monitor, and on the other research out there, the bottom line is this:

If you are getting an open rate between 20% and 40%, you are probably somewhere around average.

Very few lists of reasonable size are getting much above 50% open rates from normal campaigns. Your list may have some specific factors that give you higher rates; if so, well done.

However, don't expect to be getting 80% open rates. People are too busy, inboxes are too full and the measurements are technically limited. If, after all that, you are still interested in seeing specific figures, see the footer for some references you can browse through.

How can I increase my open rate?

There are a ton of elements you can vary to try to entice more of your subscribers to open up your emails. Here are just a few things you could try:

  • Experiment with your subject lines: Try including details about the content of the email right in the subject line, instead of using your standard subject.
  • Send on a different day: Are your subscribers too busy on a Wednesday morning to read your email, leaving it languishing down the inbox? Maybe a Friday afternoon email would be welcomed.
  • Get the important content up the top: Remember that many people will see a preview of your email before deciding to open it or ignore it. Make sure your email is recognizable, and that your key points are in the top third.

References:

The typical open rates in the chart above were derived from Campaign Monitor's own figures, in conjunction with numbers published by Mailchimp, Bronto and Mailer Mailer.

Read this post Posted by Mathew Patterson - 20 Comments
  1. 1
  2. 2
  3. 3

Sign up for free.
Then send campaigns for as little as $9/month

Create an account