Email newsletter permissions. A life story

For the last few months I’ve been doing research about newsletters and how to develop a way to test them, or how to implement what it is already done.

I’ve been completely submerge into the subject, to the point that I’ve became mono thematic: I read, talk, think, write and sometimes even dream about newsletters.
So, it is not strange for me to meet new people, start talking about the weather and suddenly I hear them talking about newsletters. Somehow I managed to turn the conversation to the weather channel newsletter!
Then I turn on my “research mode” and start asking questions.
And most people seems to hate newsletters. Or dislike them at some level.
And usually (again, all this is anecdotical) the reason is because they feel as if the newsletter was taking advantage of them.
“I don’t remember subscribing”, “I can’t unsubscribe”, “I get too many emails”, “it is just spam”. Those were the most common topics.
So how come Newsletters are one of the best marketing tools on the web, with high ROI, and thousands of newsletters send every hour has such a bad reputation?
Well, I guess is just a couple of bad apples…
Or a lot of mistakes into good newsletters that makes the whole bunch look like those bad apples.
Here in Denmark there is one more problem regarding newsletters: There is pretty much no need for permission!
While some companies do apply the double permission, that is standard for most of the world, here one can start sending emails until the user gets tired without asking if they really want those emails.
You bought something online? you are now also subscribed.
You went to a conference? you are also a newsletter user now.
You woke up one day and look out the window? chances are, someone is using some database that has your email on it, and will send you information that you “might” need.
Well, Denmark is a small country with a great database system about the people living and working here. Everything is connected. Everyone can know everything (don’t think it is an Orwellian society, but there is a lot of information out there, and easy to be find).
So, the only thing needed to start sending someone a newsletter is to have their email address! I know there might be some laws about this, and it can’t be that easy to just start spamming everyone, but as a personal note, I receive newsletters from companies that I’ve never heard of or had any business contact with them.
So, I embrace, as a personal goal, to tell the developers, content managers and other people involved into sending newsletters to start implementing a double permission system. It is not hard and properly done is more beneficial for the company.
Some of the benefits are:
  1. The user knows what they are receiving, so they will open the email more often
  2. Higher visitor-to-sale ratio
  3. The list will be filled with better users. Those ones that already showed some interest.
  4. Better ISP reputation and less spam complains
This will help creating and growing a better mailing list, and will save you in case of legal problems. Remember, the user gave permission!
Some countries is mandatory to use them, while others (like in DK) is almost non-existing.
When it comes to designing the experience of the user, the double permissions process gives a head start, since the user will get, at least one email before getting the actual newsletter.
All this can be improved with little effort:
So, as a “sneak peak” of my soon to publish “Newsletters Best Practices” here my opinion of how  the subscription process should be:

Pemissions On Email Newsletters

And of course, here are some useful links about this subject:
From Benchmark Email, a short explanation of what are permissions.
And a couple of books about email marketing from Sitepoint: Jeanne S. Jennings “The Email Marketing Kit” and from Mathew Patterson “Create Stunning Email That Just Works

Leave a Reply

Your email address will not be published. Required fields are marked *


+ two = 5

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>