Archive for April 2013

Over on the Deliverability blog, Andrew Kordek has posted a piece discussing situations where COI doesn’t make sense. While I agree with Andrew’s basic premise – there are, absolutely, instances where COI, even in one-to-many communications, isn’t needed and may have a negative effect – the examples Andrew has chosen to highlight don’t support his thesis. Let’s dive into them, in reverse order.

The registration process consisted of creating a username and password (with CAPTCHA), filing out a long form with information, followed by another page where I had one pre-checked box for one newsletter and then a choice of 7 unchecked boxes for other email publications (with cadence/frequency info and examples) followed by a “confirmation of choices” page and ending with a welcome email which had all of my email choices dynamically assembled within the email. The permission purists or organizations who claim that COI is the ONLY way to acquire an email address would say that this is not enough.

So… signing up on this website is hard and requires a lot of work, so COI shouldn’t be needed? Those two thoughts are tangential. They don’t cross at all.

As much as we want to believe that people, in general, are good, there are any number of people who will try to put someone else’s email address into a web form for a million reasons. They may be a competitor trying to affect your reputation. They may not want email from you at all, but want access to your site, so they give you an address that they think they’ve made up which just happens to belong to someone else. They may legitimately typo the address – I mistype my own company’s domain name at least once a day, and I’ve been here almost a year and a half. None of the things Andrew called out that this site does will protect that site from any of these things.

There is some good advice in what Andrew wrote; there’s also some bad advice, and some things Andrew didn’t even touch on.

CAPTCHA – all that does is “prove” the submitter’s not a bot. It doesn’t verify that an address hasn’t been misspelled, and it doesn’t stop determined individuals from putting in addresses that aren’t theirs.

Pages of publications to choose, with a confirmation page – this is a fabulous idea. Presenting immediate feedback showing what the user has chosen to receive and how often they should receive it is an excellent example of transparency.

Welcome email – also a fabulous idea. This is an opportunity for the website to remind the recipient to add them to an address book, or perform any other step required to facilitate inboxing, and to make sure they know when they might expect to receive emails.

Where does this advice miss? Well, nothing’s been done to make sure the user hasn’t mistyped (accidentally or purposefully) their email address. Playing that tune may make me a “permission purist” but confirming signups helps prevent typos, and minimizing typos goes a long way towards keeping your IP reputations clean, as Laura over at Word to the Wise has mentioned several times. Andrew also glosses over another great use of that confirmation page / welcome email combination – drive the user back to your website (after checking their spam folder) if they haven’t gotten their welcome mail in a relatively short period of time (say, 2-3 hours) so they can check that they haven’t typoed the address. You may not have to COI, but every step you take to bring typos to the user’s attention is one less possible ding to your reputation.

COI would make sense in a retail POS situation where the clerk is asking for email to send the receipt.

Well, no. If all you’re doing is mailing a single receipt, COI makes no sense. You probably want to take care to minimize Personally Identifiable Information, or anything else sensitive that might appear on the receipt, but you shouldn’t need COI for this. On the other hand, if you’re planning to store that email address in some way to send future receipts without input (for example, when I swipe my credit card to make a purchase at the Apple Store down the block, my receipt is immediately emailed to the email address associated with my App Store ID), then you should probably confirm that address in some way. The deciding factor here is “how many emails am I sending this person?” – if the answer isn’t “just one”, you may want to confirm the address.

To me, this is a wonderful opportunity for the company to send out a really fantastic confirmation email which could highlight the benefits of the program, tell a wonderful story incorporating things such as social proofing, give a discount and ask the recipient to confirm.

Yes, absolutely. Using an emailed receipt to drive folks to your newsletter subscriptions is a great idea. Hey, you’ve already got their address; if they subscribe to your newsletters from a link in a receipt, that’s awesome. You probably don’t need to COI those newsletter subscriptions, either, since the act of clicking the link in the email they’ve already received indicates engagement.

In fact, organizations could probably get away with send [sic] 2 or 3 of these emails, but should stop sending anything after X times (there is no “best practice” here) if the recipient does not confirm.

And, again, no. One transaction, one receipt with accompanying “Hey, do you want to receive other emails from us?” request. If you’re sending more than one email without being sure that you’re sending it to the right person, you run a real risk of typos biting you right in the reputation.

COI is a tool. Its purpose is to help you insure that the person asking you to send email to an address has the authority to make that request. It doesn’t make sense in every email-sending context – there are lots of cases where it could be intrusive and unnecessary. But if you’re contemplating sending multiple emails to an address, it’s one great way to make sure they’re the recipient you think they are.