Email Address Shelf Life

DJ Waldow

Imagine the following (very real) scenario:

Your boss sends you a file that includes 50,000 email addresses. You import the list into your account (merging it with the rest of your house file) and “blast away.” Within minutes your IP address is blocked at several major ISPs.

What went wrong? All 50,000 email addresses are customers who’ve purchased in the past and opted-in. Upon sign up, you included a link to your privacy policy. You even have another file that lists the date and IP address associated with each opt-in. So, what happened?

On the surface, it appears that you’ve done it all by the book. You’ve satisfied the law (read: CAN-SPAM). You’re not a spammer. Why did this happen, if these are your customers?

Upon analyzing these subscribers, you uncover the following information about the 50,000 emails in the file:

  • 50% purchased over a year ago, but haven’t received an email since that first purchase.
  • 25% purchased in the past 6 months, but haven’t received an email since that first purchase.
  • 25% are repeat buyers (their last purchase < 1 month ago), but haven’t received an email in 6 months

Over the years, in speaking with prospects and/or clients, I’ve heard the entire gamut of list maintenance “strategies” from single opt-in, to double opt-in, to double-opt-in plus in-person signature/confirmation.

The question that is not asked nearly enough – both from ESPs and internally is:

When was the last time this subscriber was sent an email?

Mark Brownlow of Email Marketing Reports posed a similar question in March of 2008, Can email love survive a three-year gap? If you dig into the comments on that post, I argued that, “a 3-year hiatus between email communications is about 2 1/2 years too long.”

My guide is based on a continuum (see below):

shelf life

What are the risks?

  • Honeypot/SpamTrap emails: An instant red-flag for ISPs
  • Hard Bounces/Invalid Recipients: One metric used by ISPs to determine list health
  • High complaint ratios: Another metric used by ISPs

The three risks all negatively impact deliverability, getting emails into the inbox. But what about your brand? What about your customers? If you continue to send email to customers that is random and unexpected, there will be consequences.

DJ Waldow
Account Manager at Bronto

7 Responses to “Email Address Shelf Life”

  1. Been in that situation and when the boss says do it your kind of stuck doing it even if you know the repercussions. I’d be interested in a follow-up of reasons to talk the boss out of doing this or what is the best way to do something like this that you know you shouldn’t. 🙂

    Are there ways to qualify the addresses before sending?

    Reply
  2. Great post! The timing is uncanny – I wrote on the same topic (http://www.viget.com/engage/wrestling-with-big-old-lists/) before I saw this. In my case it’s a client, not the boss, getting me tangled into this dilemma. I can see from the client’s perspective that those email addresses seem valuable, but when you get down to it the risks are huge. Thanks for spelling it out, DJ!

    Kyle – my post has a link to a ‘validator’ – though I don’t know much about such services.

    Reply
  3. Would staggering the deployment or “blast” help? Could you segment out the different subscriber types you described? (ie send the first batch to the most recent time lags, then send to the next time group etc)?

    Reply
  4. 5 Tips for Testing Emails [Video] « Site2Next

    […] is too long to wait to email someone. The Bronto Blog has an interesting article on the issue of “email shelf life.” Enjoyed reading this post? Subscribe to the RSS feed and have all new posts delivered straight […]

    Reply
  5. Like others, I wish there was lots more discussion here about identifying problems & managing them as I offer a newsletter syndication service and it’s getting tricky.

    PS AOL link isn’t right anymore.

    Reply

JOIN THE CONVERSATION

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">