Limiting access before email address is confirmed

Question

I'm making a directory site and I'm considering having the following setup for email confirmation:

1. After registering, user has x hours to confirm their email. They're sent immediately to the next step (profile creation), with a constant message on the side urging them to confirm.

2. Before confirming, they're limited to making changes to their profile only. They don't show up in the directory, and they can't interact with anyone yet. The reasoning is that if they signed up with someone else's email, they can't defame that person in any way. However, if it is their email, then they can do the initial steps (profile creation).

3. After x hours, if not activated, then they are locked out of their account, and treated just as they would be if they had to activate right after registration (i.e. they can't log in and see a "Please activate" message).

4. If after y hours they still haven't activated, then the account is deleted.

---

The advantage is that the person gets to already commit time and effort to the site before having to confirm anything. I think that this would diminish the number of people who register and don't bother confirming. Also, the lack of interaction with other users helps prevent defamation in case of stolen emails.

Are there any hidden dangers to watch out for with this approach? Have any other sites implemented something similar?

Answer 1

Letting users jump right in is great -- nobody likes clicking refresh in their email client until a confirmation comes in.

I'm not sure about #3 though. It seems a bit harsh and off-putting, and what if they just forget and don't try to log in again before the time limit is up?

Perhaps instead have a very visible progress bar at the top of the screen, and have one of the milestones be activating the account.

After x hours send a friendly email reminding them to confirm (or their account will be deleted in y hours/days).

After y hours/days, delete the account and send them an email about that as well.

Answer 2

You should really ask yourself whether your primary goal is to obtain signups or to obtain fewer but better quality signups.

Typically if you do not allow the user to access the site, you'd be risking the user going elsewhere and potentially abandoning the registration process - people's memories are fickle and the mental disconnect that being forced to abandon any progress with the site causes can be enough to send them elsewhere. You're right to flag up the emotional investment that comes with entering information, and that's likely to be a catalyst for increased signup rates.

There are a couple of reasons why you'd stop people from progressing before verifying. If there are costs to you of storing their information, then you may want to try to reduce those by making sure accounts are verified before accepting data from the user. Alternatively if it's really important to you that only the people who care about your service use it, then the mental hurdle is likely to ensure this - you may end up with users who are more highly engaged with your service in this case. However, you would have to accept that some users would simply not bother to continue with the site.

My advice, without knowing your exact goals, would be to do what you're doing - immediately send the email, but allow them to access non-critical areas of the site in the meantime. Dead accounts are usually not much of a cost to a service, whereas ensuring that you maximise volume of signups is usually quite important.

Answer 3

Some variation on this pattern (where e-mail validation is not a blocker to registration or using the site) is becoming more common. For example Quora has that pattern. I think stackexchange does too.

I've not done testing with variations of this scheme so I don't have hard numbers, but my hunch is that it will help.

Not so much because it will make it more likely that people will validate their email, but because it will stop email validation blocking users from continuing and then possibly abandoning the registration process.

The only down side that I can see is that it turns a linear registration process into one with two separate strands (the normal registration, and email validation). That additional complexity may cause problems, but I'm guessing that they would be outweighed by the advantages.