Sign up: Double opt-in still best practice? What about mobile?

Question

Everybody knows the normal registration process:

1. Fill in sign up form
2. Wait for email
3. Click confirmation link in email
4. Done (signed in & confirmation by email)

IMO this process works because people are used to it but it isn't very elegant because it breaks the user's flow. The same process on in a mobile app would look something like this:

1. Fill in sign up form
2. Wait for email, switch to email app
3. Click confirmation link in email
4. Browser opens and shows confirmation page
5. Switch back to app
6. Type in sign on information
7. Done

This is just painful (even more so if the email address used for the sign up isn't the one that is used on the mobile's email client).

I see two main alternatives but both have some issues:

1. Don't require a confirmation by email, just sign in the user immediately. Main problem: We can't be sure if the email address is correct (other than syntax).

2. Don't require immediate confirmation: Let the user confirm his email address in the next 7 days or so and sign him in immediately. Main problem: Still can't handle wrong email addresses

Are there any other alternatives or more elegant ways to handle registrations?

Answer 1

Let's say the user just cannot receive email on their mobile device - for example those that deliberately do not want to be contacted by email - those on a limited data plan - or those without the inclination or technical know-how to setup email.

For whatever reason, there are going to be people who fit that category. So ask yourself if you want to actively include them as new sign-ups - or deliberately exclude them.

I'd be inclined to actively include them and let them confirm the email at their convenience.

Then between signup and email confirmation (whether it's from desktop or mobile it doesn't matter), their account is put in a 'pending' state.

If there's anything secure or that involves sharing, distribution, or in any way involves other people or large volumes of data, or anything that physically costs your business, then this is disabled until email is confirmed, but basic features should still be enabled in this pending state.

This 'pending' state should be displayed clearly but discretely somewhere with the ability to quickly see why the user's state is pending and not fully signed in.

That information would include something along the lines that

• an email has been sent to dev@null.com and is awaiting confirmation
• and with the option to change the email address that was used
• and also an option to resend a confirmation (which happens automatically if you change the email address).

So this is an informal, accepting and flexible mechanism that should adapt to most situations.

Those that confirm straight away won't see the pending state displayed.

Those that don't confirm right away will be gently reminded, but there's no pressure to do so immediately.

Those that continue to use the service for longer without receiving an email can easily check the pending state to make sure the right email address was used.

After a week or so, you might highlight the status somehow and show a suitably apologetic message to say it doesn't look like the user has confirmed the email and would they like to check the email address or send the confirmation email again.

All of this of course assumes that the types of activity your service provides are not all those that really you need to confirm the email address before they are allowed.

Answer 2

I am working on an project right now in our company where we're facing just the same issue where we need a different approach. ATM the sign-on process is the known one:

1. register
2. check mail
3. click to confirm, set password and enjoy

(the SaaS logs you in automatically after you entered your password -- I've seen "flows" doing it worse by letting you log-in by typing your name / password once again after you just entered your password for the first time...)

Now I created a new approach (keyword: onboarding) which will allow the user to instantly start using the SaaS after entering a log-name / password (name = e-mail), but with some functions being locked till the user confirms his account via e-mail.

This is due to security reasons, since the user will be able to use online banking functionality and we don't want fake users fooling around with the service.

Tumblr's onboarding process is some kind this way: You enter your mail, get instant access so you can look around. However, using advanced methods (post comments etc.) you need to confirm first.

Answer 3

Something to consider is why you need the user's e-mail address:

1. To add them to a mailing list
2. To make it possible for them to reset their password
3. To e-mail them future promotions

E-mail addresses don't serve as a unique identifier in the sense that one person can have multiple e-mail addresses. So, the only reason to have the user's e-mail address is if you plan to contact them via e-mail.

With that consideration in mind, you could take the approach that reddit takes. Users can sign up without an e-mail address. Accounts that have verified e-mail addresses are given a "trophy" (similar to a badge here at SE) stating such, but that's the only difference between a verified and unverified account.

Considering that verifying your e-mail address before ever being able to use a service is annoying, it serves as a barrier to registration. Requiring an e-mail address actually lowers the amount of registered users you will have on your service, particularly if your service doesn't already have an established reputation.

In short, unless your company is losing something significant by the user not verifying their e-mail address, there's not much reason to require verification.