Home Resources Blog

Blog Post

“The Reporting & Segmentation Tools Are Amazing”

I’ve been using Campaign Monitor for two years now for all Applied Language’s outbound email campaigns. The tools developed are far and above anything I could ever expected at such a great price. The reporting and segmentation tools are amazing and I recommend it to everyone I know who works in Marketing. Richard Michie, Head of Marketing & PR Applied Language

Blog Post

Email Standards: Join Our Facebook Group

Right now we’re working on the new website for the email standards push that kicked off recently. That site will include a section on how you as a web designer can get involved and help improve the situation. One simple step you can take right now, if you are a Facebook user, is to join our Email Standards Project Facebook Group. It’s a really fast and easy way for you to show some support for what we are all trying to do, and it will also help us connect with people who might be helpful. The recently crowned King of Web Standards, Jeffrey Zeldman, has joined already, saying “I hope all standardistas on Facebook will join in this effort”. We’d love to see you there. Join the Email Standards Project group on Facebook.

Blog Post

Email Testing Just Got Easy!

I’m rapt to announce that our brand new design and spam testing feature I mentioned last week is now available in all accounts. Email testing just went from a lot of work to the single click of a mouse. If you missed the original announcement, this new feature generates screenshots of exactly how your email will look in all the major email clients before you send your campaign. Not only that, but it also runs your content through 8 key spam filters and in most cases tells you exactly what you need to fix if you fail it. All this for just $10, or 1,000 credits. Here’s a screenshot of what you can expect for each report you run: By clicking on any of the screens above, we’ll show you full size screenshots under different scenarios such as images on, images off and even how your email looks in the preview pane. Here’s a sample spam filtering report, which tells you which filters you failed and why. We even provide warnings if you pass a filter since there’s value in knowing what spammy words or content structure have an affect on those filters. Of course, this new feature isn’t meant to completely replace our simple testing tools – you can still send a test email to any address you like. But if you’re working on a new template design or need to be sure you’re not going to get filtered as spam, these reports really do provide you with piece of mind. To run your own reports, simply head into Create/Send then click on Design and spam testing to get started. You can also read a little more about the reports and some answers to common questions. We hope you like it, and please leave us any feedback or suggestions you might have below.

Blog Post

Automatically Generate Inline Styles

Update Campaign Monitor now moves styles inline for you automatically – you no longer need to run your HTML email campaigns through an inliner like Premailer prior to send. That’s good news! Creating HTML emails that render well across multiple email clients is complicated by programs like Gmail that strip out CSS styles from the head, and only support inline styles (like <p style=’font-weight:bold;’>A bold paragraph<p>). Our base templates don’t use inline styles because that makes them too inconvenient to easily modify – much simpler to change the design first then apply inline styles at the end. Campaign Monitor customer Alex Dunae has done us all a big favor by writing a sweet Ruby script that accepts a URL, and automatically generates and applies inline styles from the CSS in the head of that page. The script is called premailer and is available for use right now. It won’t always work (with complex CSS cascades), but for most cases it saves you a ton of time. So now you can just build the page in your normal way, then have all the inline style drudgery done for you automatically. As an additional benefit, premailer also checks your CSS against our own guide to CSS support and warns you of possible issues. It’s a great piece of work, and well worth a look. Alex is even planning to release the source code soon.  

Blog Post

Coming Soon: Single-Click Design and Spam Testing

As I mentioned in my original call for standards support, “getting an email to display consistently in all of the popular email clients is by far the most frustrating part of the job”. Our dedicated site for the push towards standards in email is coming along nicely, but we’re also well aware that things won’t be improving overnight. To keep everyone sane in the mean time, we’re putting the finishing touches on an awesome new feature that lets you do incredibly detailed design and spam testing with a single mouse click – all before you hit the send button. Here’s a sneak peek at some of the cooler bits… Screenshots in all the major email clients See screenshots of exactly how your email will look in up to 18 of the most popular email clients like Outlook 2007, Windows Live Hotmail, Yahoo, Gmail, Lotus Notes, AOL and many more. Image blocking and preview panes included As you know, most of the popular email clients sport image blocking and preview panes these days. Not only will we take screenshots of your design, but we’ll take multiple versions with images on, images off and even how your design looks in the horizontal or vertical preview pane. You’ll have every angle covered. Your email tested against popular spam filters and firewalls Instead of just scanning your content for “spammy words”, we’ll pass your email through real spam filters and tell you exactly why you failed. On top of popular desktop spam filters, we’ll also run your email through a number of key spam firewalls – the gatekeepers for most ISP’s and large corporations. Cheaper than doing it yourself This new feature won’t be free in your account, but will cost $10 (or 1,000 email credits) for each detailed report. This will include dozens of screenshots in all the major email clients and your email being run through a range of popular spam filters and firewalls. It isn’t something you’ll use for every campaign you send, but if you’re working on a new design or making some big template changes, this is a great way to get piece of mind in minutes. As we’ve explained before, proper email testing takes time. Serious time. We’ve got test accounts at all the major ISP’s and have a few test machines to check different spam filters – we know how painful testing is. I’ve been playing around with this new feature internally for the last few weeks and I have to say, I’m never going back. We’re hoping to launch this some time in the next 2 weeks, and I’ll post an update here as soon as it happens. If you’re an Aussie heading to Web Directions tomorrow, make sure you swing by the Freshview booth for a sneak peek at this new feature in action.

Blog Post

Thank You for Your Help with Our Call for Email Standards

We announced our intent to create email standards and asked for your help with establishing a baseline for support. The response has been outstanding. We’ve heard from the web-design community—your help has been invaluable and we’re ready to take action. In the coming weeks we will be developing a website dedicated to this movement based on the consensus of those who participated. Upon going live we will announce it here on the Campaign Monitor blog, so keep your eyes peeled. We are working to finalize our acid test and will collect final data on how our suite of email clients performed. This will be the foundation for our call to email-client developers for standards support. Again, thank you for your kind words of support and participation. Together we can make a difference for web designers who design/build emails and for those who receive them. Onward…

Blog Post

Making It Easy for Your Hotmail Recipients to Unsubscribe

We mentioned a few months back that the Hotmail folks were about to launch a very cool new feature that allowed your recipients to unsubscribe directly from the Hotmail interface. As you know, if a subscriber no longer wants to hear from you they’ve got 2 options – mark it as spam or try and find the unsubscribe link. This new feature goes a long way towards reducing false positive spam complaints by encouraging your recipients to take the unsubscribe option instead. If you’ve ever received spam complaints from your Hotmail recipients, you’ll know just how important this is. Here’s what your Hotmail recipients will now see: When your subscriber clicks the unsubscribe link, they’ll be redirected to your unsubscribe confirmation page, just like they would if they clicked the regular unsubscribe link in your email content. The best part is, you don’t need to do anything to set this up, it will work automatically for all your Hotmail recipients. The unsubscribe option will be visible to every subscriber that’s marked you as a safe sender (or added you to their contacts). Luckily this is a very easy process in the new Hotmail interface and is likely something a subscriber will do for any newsletters they subscribe to. Here’s a quick screenshot of how this looks for all new senders. The moment “Mark as safe” is clicked, the unsubscribe option will be available in any emails you send them. Props need to go to Microsoft for being the first major ISP to implement this great standard.

Blog Post

Scheduled Maintenance Late Saturday Night through Sunday Morning

Apologies for the short notice, but we’ll be taking the Campaign Monitor application offline for a total of 8 hours between 8.30pm this Saturday night and 4.30am Sunday morning (US Central time – see this in your own time zone) to make some key hardware upgrades and add some additional layers of redundancy to both Campaign Monitor and MailBuild. Don’t worry, the maintenance will have zero impact on your subscribe forms or campaign tracking, everything will purr along as usual – you just won’t be able to log into your account. If you’ve scheduled any campaigns to be delivered in this time-frame, they’ll be sent as soon as the application is back online. Update: The updates have been completed successfully and as of 12.30am we’re back online. Thanks for your patience everyone.

Blog Post

How to Personalize Your Permission Reminders

When you make a business call, you don’t just launch right into the conversation without introducing yourself, right? Instead you say something like “Hi, I’m Mathew, we met at the Widget Summit and you asked me to give you a call”. You should do just the same with your email newsletters. Over at Clickz, Stefan Pollard has a great article titled “There’s No Excuse for Trust Abuse“, about doing permission reminders the right way. His point is that a vague permission message — “your address was subscribed to our list” — can be even worse than none at all. It makes you seem lazy and possibly suspicious. Your message needs to be as specific as possible, to help people remember how they actually did ask for your emails. This is particularly important for lists that grow regularly, as new subscribers have no background of newsletters to remember you by. A great technique to make your reminder messages more specific is to keep track of exactly where addresses came from, and refer directly to that. You are receiving this email because you gave us your address at the Widget Summit in September. Or perhaps You are receiving this email because you subscribed on our website to the Widget Newsletter. With some smart use of custom fields, you can personalize that message for each subscriber. The first step is to keep track of where people came from. Create a custom field for your list called ‘source’ or similar. Now you need to fill in a value for ‘source’ for each person. If you are importing a file of new subscribers after a tradeshow, use ‘gave us your address at the Widget Summit in September’ as the source column for each subscriber record. For your online subscribe forms, make sure you have a hidden ‘source’ field prefilled with ‘subscribed on our website’ as the value, so that each time someone signs up using the form, the right value is set. Now in your campaigns, you can just insert something like this: You are receiving this email because you [source]. If you are no longer interested, you can <unsubscribe>unsubscribe instantly</unsubscribe>. It’s that easy. Now your permission reminder messages are much more specific, and they will be much more effective in showing people you are legitimate and serious about having their permission. You can also use that same source information to start segmenting your list and offering different things to different groups. Even though permission is not enough anymore, an accurate, specific permission reminder will go a long way to avoiding spam complaints, and help build up trust with your subscribers.

Blog Post

Help Us Form a Baseline for Standards Support

The response from my call to arms a few days back has been phenomenal. We saw some great comments, loads of inbound links from other designers and some very encouraging “how can I help” emails from many others. As I mentioned in the original post, an important part of moving forward is first establishing a set of baseline standards that we can encourage email client manufacturers to meet. This baseline is crucial as it will form the crux of our recommendations and hopefully shape minimum standards for email rendering across the board. It’s also something you can help with. Working closely with our resident email design guru Mark Wyner, we have established what we think is the core set of features that will form this baseline. What’s important to remember here is that we’re not crossing our arms and demanding perfect standards support. We’re simply asking for the more critical CSS standards to be supported so we can properly separate content from presentation and ensure a simple design will render consistently across all of the popular email clients. With this in mind, here’s the list so far: margin padding float/clear type-selector :hover background-image a:hover background/inline images font inheritance/sizing/line-height UL, OL, DL properties List-style-image background-image positioning borders different link colors content centering This is where you can really help make a difference. Please leave your own comments with anything you think is missing or might not be of crucial importance to standards support in email. Once we’ve received your feedback, we’ll make any amendments and get stuck into the testing/recommendations for each manufacturer. A new site bringing all this together isn’t far off either.

Blog Post

Why We Need Standards Support in HTML Email

This is a post I’ve been meaning to write for a long time now. I’ve been delaying it purely because I wanted it to be perfect. I wanted to write with Zeldman-like virtue on why email, just like the web, needs to pay attention to web standards. Sadly, in the time between the idea for this post and actually getting it published, web standards support in email has gone seriously downhill. I can’t delay it any longer. My role at Campaign Monitor has given me a great opportunity over the years to research and speak to other designers at length about the standards issue. Each time the topic comes up the result is always the same – getting an email to display consistently in all of the popular email clients is by far the most frustrating part of the job. It’s a painful and always moving target that’s getting harder instead of easier. There’s really no justification for it and it’s about time something was done. Accepting the reality of email today Let me preface this by saying I completely respect everyone’s choice for the email format they prefer to send and receive. I also understand that it probably wasn’t the original purpose of email to go beyond one-to-one plain text messaging. I really do. This is one of the biggest reasons we encourage everyone to include a plain text alternative whenever they send a HTML email. But we need to be realists. Every popular email client supports HTML email and most use that format out of the box. Out of the box means it’s the format of choice for anyone outside of the design and early adopter community and there’s no indication that’s changing any time soon. No amount of angry comments on Slashdot singing the praises of Pine are going to suddenly force email client developers to drop HTML support. It’s just not going to happen. So, it’s not going anywhere and it’s broken. If we can all get past this point together, it’s obvious that the best path forward is to work with desktop and web-based email client manufacturers to improve how HTML emails are rendered, not argue amongst ourselves about personal preference. What’s wrong with the current picture? Today there are at least 10 popular email clients out there, each offering different levels of standards support ranging from perfect to virtually non-existent. I often hear comparisons between the current state of standards in email and the web circa 2000. While there certainly are some similarities, there are also some big differences. The web standards movement faced not only poor browser support, but also an uneducated design community. They had browser makers and designers to convince. Today we’re lucky enough to stand on the shoulders of these giants in a world where web standards have well and truly been embraced by browser developers and the design community alike. People want to build HTML emails using the same approach they build for the web. Another big differentiator is the fact that there were 2 or 3 browsers to consider back then and we knew exactly which web browsers were popular, making it much easier to know where to focus our energies. There is almost no data like this for the email world. Are more of my subscribers using Thunderbird or Apple Mail? It’s almost impossible to know. So, we’ve got 3 to 4 times more variations to cater for and we don’t even know which ones we should be targeting. Because of this huge variation in standards support, email designers have been forced into a corner. There have certainly been valid attempts at encouraging the use of web standards in email, of which I’m proud to say we’ve played a part. The W3C has even jumped on board in realizing something needs to be done here. With the recent and unfortunate news from Microsoft however, it’s been getting harder and harder to justify this approach. What we’re now left with is building for the common denominator. This means bandwidth hogging, image heavy emails with nested tables and font tags. Yes, I said font tags. I see hundreds of these designs being sent every day purely because it’s the only way to achieve consistent rendering across the board. Type in the URL of those creating these designs however and you’ll often find a beautifully coded standards compliant site. Email design truly is stuck in the dark ages. Revisiting the benefits of web standards Many of you are already well aware of the positives web standards offer, but I’ll focus on those I think are particularly relevant to email. It removes the guess work from email design – This is an instant win for designers and everyday email users alike. If all email client developers aimed for something close to web standards, you can design an email knowing it will work for all your subscribers. Stop and think for a second how awesome that would be. Your subscribers will win by no longer receiving garbled, hard to read newsletters because their email client doesn’t support standards. Faster loading and reduced bandwidth consumption – Well coded, standards compliant markup that separates content from presentation is generally much more compact than nested table and spacer-image based markup. Further to this, many designers have given up on rendering issues altogether and send purely image-based emails. This adds significantly to the file size and results in a poor experience for their subscribers because of image blocking. Make your email accessible to all – Using standards does not automatically mean your email will be readable to people with disabilities, but it’s certainly a great start. By separating content from presentation you’re making it much easier for everyone to access your email. Further to these intrinsic benefits of web standards, there’s another significant win that would follow. Using tables for layout is a dying art in the web design community. Many designers who started web design in the last few years have never even coded a table based layout, which is a good thing. The current email environment means a designer not familiar with the table based approach will need to learn a completely different way of creating a page if they want to send HTML emails. We’re fast approaching a fork in the road where email design will become a niche, expensive service that fewer designers can provide. Sure, a few designers win by being able to charge more for their work, but everyone else loses. Where to from here? This much is clear – arguing about HTML vs plain text or complaining about standards support in email isn’t going to get us anywhere. It’s time to get off our butts and actually help email client manufacturers to introduce better standards support. I also think it’s important to realize that these manufacturers don’t have a problem with web standards. Supporting standards might not always be the easiest option, in fact for web-based providers I’m sure it’s quite the opposite. It’s our job to demonstrate why they are important and then make them as easy as possible to embrace. We’ve been hard at work on this for the last few weeks, focusing on the following areas: Establishing a baseline of what standards we need supported in email – We certainly don’t expect perfect standards support across the board initially, but there are a number of key properties that we can encourage manufacturers to support sooner rather than later. Document the important changes each of the major email client manufacturers need to make in order to support web and related standards – Once we’ve established the baseline, we can put together a basic wish list of the changes each manufacturer will need to make to meet this target and then work with them in any capacity possible to help make this happen. Create a simple acid test that makes it easy to see if an email client supports this baseline – Much like WaSP’s Acid2 test, we should make it easy to see if these important standards are being supported by creating a simple test page that can be viewed in that email client to confirm at a glance if the baseline is being met. We plan on bringing this all together in a dedicated site launching soon. Obviously the more of us that can get behind this the easier the job will be. Even the king of web standards, Jeffrey Zeldman agrees (emphasis his): Learn how HTML mail works (or doesn’t) across as many platforms as possible, and work with the manufacturers to improve support for web standards. This is not my job. I did my job where web standards are concerned (you’re welcome!), and turned over The Web Standards Project to a new generation of leadership. And as I never send HTML formatted mails, not only is it not my job, I wouldn’t even be qualified to do it. But standardistas who are compelled by their clients to create HTML mails (or who choose to do so) are gently urged to do their part in diminishing wasted bandwidth and enhancing semantics. We’ll be posting more about this initiative soon, including how you can help make a difference. Jeffrey’s right, it’s not his job – this one’s up to us. Update: You can start helping right now. Check out the initial list of baseline standards that should be supported and add your own thoughts.

Straight to your inbox

Get the best email and digital marketing content delivered.

Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.

Subscribe

See why 250,000 companies worldwide love Campaign Monitor.

From Australia to Zimbabwe, and everywhere in between, companies count on Campaign Monitor for email campaigns that boost the bottom line.

Get started for free