Confirming website registrations

Confirming email addresses during a website registration process is a good practice. It stops people from creating fake accounts, abusing  resources and using that site as a mechanism for harassment. But simply sending out a confirmation mail is not sufficient to prevent problems, particularly when everything about the process assumes that unconfirmed registrations are actually valid and not problem accounts.
I’ve had a couple recent experiences with companies attempting to use email confirmation, but failing pretty miserably. In each case a website set up a process where a user could register an account on the site. Both sites required confirmation of the registration email addresses as part of the process. But in each case there were some major failures that result in non-customers getting email.
Tomorrow I’ll talk about those two specific cases. I’ll also provide specific suggestions on how not to fall into the same trap and actually send opt-in email.

Related Posts

Confirmed opt-in

I spent the morning in multiple venues correcting mis-understandings of confirmed opt-in. The misunderstandings weren’t so much that people didn’t understand how COI works, but more they didn’t understand all the implications.
In one venue, the conversation centered around how small a portion of deliverability the initial subscription process affects. Sure, sending unwanted, unexpected email can and does cause reputation problems, but merely using COI as a subscription methodolgy doesn’t automatically give a sender a good reputation or good delivery. Senders using COI as a subscription practice need to also need to send relevant and engaging mail that their recipients expect to receive. They need to handle their bounces well and purge or re-engage inactive subscribers. They need to keep their complaints low and their responses high.
How you manage subscriptions is only one factor in reputation schemes, and even if the subscription method is COI other factors can negate any bonus involved.
The second conversation involved Ken challenging me on the comment I left on his quiz yesterday. I said COI wasn’t foolproof and he challenged me to explain how. I did, and he’ll be following up next week.

Read More

Evil weasels and random monkeys

I’m doing testing on a new release of Abacus at the moment, so I’m in a software QA (Quality Assurance) frame of mind.
One of the tenets of software QA is “Assume users are malicious”. That’s also one of the tenets of security engineering, but in a completely different way.
A security engineer treats users as malicious, as the users he or she is most concerned about are crackers trying to compromise their system, so they really are malicious. A QA engineer knows that if you have enough users in the field, making enough different mistakes or trying to do enough unusual things, they’ll find all the buggy little corners of your application eventually – and crash it or corrupt data more reliably than a genuinely malicious user.
As a QA engineer it’s easier to personify the forces of chaos you’re defending against as a single evil weasel than a million random monkeys.
In the bulk email world the main points where you interact with your users are signup, confirmation, unsubscription and click-throughs. Always think about what the evil weasel will do at that point.
Signup

Read More

Troubleshooting Yahoo delivery

Last week Jon left a comment on my post Following the Script. He gives a familiar story about how he’s having problems contacting Yahoo.

Read More