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:
- 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
- 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
- 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.
Interesting article! I’ve noticed similar problems myself with one small ESP not filtering subscribe lists, so I’m receiving eshots twice each time from their client, quite respectable and old UK company.
I had an experience where I was redirected from the unsub page to the homepage of the mobile version of one sender’s site because I was visiting the unsub from a smartphone. Yet another thing to check…
Evan: you mean this: http://www.xkcd.com/869/ ?