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 [email protected] 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

In recent apps I have been trying a bit of a new format for keeping the flow of a user's registration in one piece:

1. User fills in form.
2. As soon as they enter an email address, I validate it and email a confirm code using ajax.
3. Before finishing the registration form, the code must be input.
4. Once they click done on the form, they are registered and verified.

This has worked quite well in taking a lot less time and keeping the flow of registration going.

It is absolutely necessary for us to have an email address for the registrant, so we need to verify it works. Otherwise we would not have a registration process.

I would love to make it possible to send an SMS with the code because hotmail seems to like to send us to people's spam folders. So I am working on that for future versions.

This workflow has had great reviews from the registrants saying the following:

• that worked so fast
• it is so annoying having multiple pages for a registration process, this made it so much easier

We have seen a lot less ditching of the process with folks who never finish registration

Answer 4

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.

Answer 5

Like other people suggested, it's a very good idea to let user's explore your app before email verification or give up email verification at all. But if you really need email verification, you may use the mobile's capabilities to improve the user experience.

1. Fill in sign up form.

2. Done. (Available features are still restricted.)

3. Your app checks emails in background, picks out verification details and enables more features.

If the mobile has no access to the verification email, the user may verify himself manually by clicking a link in the email.

Disadvantage: You need permission to read emails. On Android mobiles this is a all-or-nothing decision, because there are no optional permissions.