Does your unsubscribe process work? Are you sure?

I stumbled across an interesting problem today.
A company I bought something from a while back added me to their newsletter. They seem to be having trouble making sales this quarter, as they’ve gone from an occasional email every few weeks to bombarding me with increasingly desperate offers in the past week or two. So I do what most recipients do in that situation (well, the ones who don’t just mark the mail as spam, anyway). I click the unsubscribe link.
I get a perfectly normal, standard unsubscription page, with a nice, prominent “Unsubscribe from all” button with good text explaining that that will remove me from all of the companies mailing lists. No requirements to log in, set dozens of checkboxes or provide a password I don’t have. So far this is a textbook example of a good unsubscription process.
I click the button. Nothing happens. That’s not good.
So I grab one of the people I know over at that ESP and we start looking at it. He clicks the button, and it loads a new page saying that I’ve been unsubscribed from all of the companies mailing lists.
A bit more testing shows that the unsubscription works if you use Internet Explorer or Firefox, but not if you use Safari. The cause of the bug was threefold:

  1. the unsubscribe button used javascript and ajax and hidden form hacks to do exactly the same thing a standard html form would do, but in a more complex, fragile way
  2. the webserver customized the content of the page it sent based on the browser being used – and if that browser were something other than Firefox, Internet Explorer or (probably) Chrome it sent broken content missing a bunch of javascript
  3. nobody had tested the unsubscription page, at least not using Safari

If this were a software development blog post I’d focus on points 1 and 2, but we’re mostly an email blog so I’m just going to look at point 3.
 

If your unsubscription link only works in Internet Explorer and Firefox, it doesn’t work for a quarter of recipients. If it only works in those two, plus Google Chrome, it doesn’t work for about 13% of recipients.
And if it doesn’t work, people are going to mark it as spam – and you really don’t want that.
It’d be nice to rely on your web development group to use robust web coding techniques, and to QA all parts of your website exhaustively across different browsers, but if you’re not actually doing the web development yourself you likely don’t have much visibility into what they’re doing. For much of your web interface that’s just fine – it’s used by customers, and if they find a browser-specific bug they’ll contact support. Unsubscription handling is a bit different, though, as it’s mostly used by people who aren’t your customers – and there’s potential for bigger problems.
It’s worth asking your developers about what browsers they QA with, but it’s also pretty easy to do some basic testing yourself. Test it with Firefox, Chrome and Opera – they’re free to download, if nobody in the office has them installed already. Grab an iPhone and try with that – that’ll both test that it works with Safari, and that it’s usable on a small screen. Just sign up for the list, get an email, copy the unsubscription link into each browser’s address bar and test that the process works.
 

Related Posts

Suppressing email addresses: it's good for everyone

Every sender, big or small, should have the ability to suppress sending to any particular email address. They must, absolutely, be able to stop sending mail to anyone for any reason. Not only is this a legal requirement in every jursidiction that has laws about email marketing, it’s just good business sense.
What happens when marketers fail to be able to suppress email addresses? At some point they’re going to mail someone who gets annoyed enough with them to make it public that they are too incompetent to run an email program.
This happened to the folks over at spamfighter.com recently. They have been spamming Neil Schwartzman (spamfighter, Executive director of CAUCE North America, Director of Standards and Certification at ReturnPath) since somewhere in 2007. Yes, really, 2007. Neil has asked them politely to stop spamming him. He’s explained he’s not actually using their software. They appear to be incapable of running a suppression list, despite telling him 3 times that they have removed his address.
Showing much more restraint than I would have with a sender who couldn’t stop sending me email, Neil gave them years to fix their process before blogging about his experiences. Instead of fixing their broken process they instead responded to his blog post insisting their mail wasn’t spam because they weren’t sending Viagra mail or 3rd party offers.
We can argue about the definition of opt-in, we can argue about whether registration is permission, we can argue about a lot of things, but when the recipients says “stop sending me email” and a sender says “we’ll stop sending you email” and then fails to actually stop sending email I think the recipient is fully justified in calling the email spam. Sorry spamfighter.com, your process is broken and your inability to fix it 2 years after the brokenness was brought to your attention does not give anyone a good impression.
Every email sender should have the ability to stop sending mail to recipients. If that’s not currently possible with your technology, it should be a very high development priority.

Read More

TWSD: My lunch is not spam

My ISP information page occasionally gets trackback pings from various blog posts. This week one of the trackbacks was from a blog post titled “One man’s Spam is another man’s lunch.” The theme of the blog post was that email marketers are poor, put upon business people that have to contend with all sorts of horrible responses from recipients, spam filtering companies and ISPs.
Since the poster took the time to link to my blog, I thought I’d take the time to look in detail at his post and talk about how likely it is to work.

Read More

CAN SPAM compliance information in images

A fellow delivery specialist sent me a question this morning.

Read More