Continuous Testing

Give Recipients Options

• josh
• Jul 31, 2015

• Delivery Improvement

A few years ago I subscribed to a financial website that emails out articles about investing as well as a recap of your investments.  For the first few months I enjoyed reading these emails but as time went on, I found them less valuable and receiving them every other day they turned into a burden to clean up and deal with.
My options were to either unsubscribe or I could create a rule in Outlook to file away the emails to possibly read them later.

What I would really like is the option to define how often I would receive the updates.  If I’m actively looking to change my investments, I would want to receive the emails daily.  I would also like to have the option for either a weekly or monthly email.
The frequency of mailings should be tailored to the subscriber. Buying a new car? I may want to see emails and reviews daily.  Just bought a new blender? I want to receive emails for the first few days learning about the different features and recipes. The idea is to present options to each subscriber on what they prefer.  It’s better to treat subscribers as individuals rather than sending the same message to your entire list.
The newsletter I was receiving does not provide me with any type of control over how many times I receive the updates. The newsletter is also lacking a working unsubscribe link leaving me no alternative to clicking “this is junk”.
Senders should consider providing recipients with options:

Email saves trees!

• laura
• Aug 14, 2014

• Industry

The arrival of my first spam email was a bit of a shock. I’d been on the internet for years by that point and had never seen junk mail in my inbox. Of course, the Internet was a very different place. The web was still a toddler. There was no email marketing industry. In fact, there wasn’t much commerce on the web at all. Much of the “surfing” I did was using gopher and ftp rather than the fancy new web browser called NCSA Mosaic. To share pictures we actually had to send printouts by postal mail.
It wasn’t just getting spam that was memorable (oh, great! now my inbox is going to look like my postal box, stuffed full of things I don’t want), it was the domain name: savetrees.com. Built into the domain name was an entire argument defending spam on the grounds of environmental friendliness. By sending spam instead of postal mail we could save the earth. Anyone who didn’t like it was morally corrupt and must hate the planet.
Why do I mention this history? During a discussion on a list for marketers earlier this week, multiple people mentioned that email marketing was clearly and obviously the much more environmentally sound way to do things. I mentioned this over on Facebook and one of my librarian friends (who was one of the people I was email friends with back in those early days) started doing her thing.
She posted her findings over on the Environmental News Bits blog: The comparative environmental impact of email and paper mail. It’s well worth a read, if only because a lot of companies have really looked into the issue in great detail. Much greater detail than I thought was being put into the issue.
I shared one of the links she found, the 2009 McAfee study, with the email marketing group discussing the issue. (You may want to put down the drinks before reading the next line.) It was universally panned as marketing and therefore the conclusions couldn’t be trusted.
Anyone who pays any attention knows that nothing we do and none of the choices we make are environmentally neutral. Plastic bags were supposed to save trees from becoming paper bags, but turned into an environmental mess of their own.
Simple slogans like “email saves trees” might make marketers feel better, and may have gained Cyberpromo a strong customer base in the early days. But the reality is different.

The best time to send email

• laura
• Nov 6, 2014

• Industry

This subject comes up over and over again. Many senders are convinced that there is a best time to send email. Countless research hours have been dedicated to finding that best time to send email. Numerous blog posts discuss what the best time to send email is.
From my perspective, there are better places for senders to spend time than figuring out what the exact right time is.But, senders still ask when the best time to send mail is.
There are a lot of reasons I can come up with as to why there’s no best time to send email. But the really big one is that when you send a mail has no impact on when it gets delivered.  There are multiple steps between hitting the send button and the mail being delivered to the inbox totally outside the control of the individual sender.
Email is designed as “store-and-forward.” This means there are potential delays at multiple steps inside the process.
Sending queues are called queues for a reason. Emails are sent out individually, particularly when an ESP uses VERP as part of its sending. There is actually a time overhead for making a connection to a recipient server and sending the email.
Receivers have queues, too. They can only accept so many incoming connections at a time. They have limited resources to accept all the mail their users want.
Receivers may delay mail between accepting it at the MX and delivering it to the inbox. This isn’t ideal and it’s not usual, but it can happen.
Recipients using IMAP accounts may not check mail regularly. They may only collect mail a few times a day.
These are only a few of the reasons that send time doesn’t necessarily equate with delivery time. Of course, 99% of the time email is mostly instantaneous. The internet is robust enough that a message sent is delivered seconds later. I see it happen all the time, when colleagues and I send email during calls. But, when mail fails, it sometimes fails spectacularly. Back in the dark ages (of the early 90s) I had an email that took almost a year to get to the recipients. Best I can tell, it got stuck somewhere in the depths of a machine in the middle of the university mail system. Eventually that system fell over and someone noticed and rebooted it (maybe it was walled up somewhere?).  The reboot shook my message out of where ever it was stuck.