Hybrid Onboarding Guide

The term "hybrid onboarding" refers to a technique that is used to improve the user registration rate on a website by leveraging a number of Internet standards including OpenIDOAuth and Portable Contacts.  This combination has been used to increase registration rates to as high as 90%.  In the documentation below we will show screenshots of an example flow, and then describe the changes that are needed to a website to support this flow.

Lets look at an example.  If you are a Gmail user that gets an invitation to use Plaxo or Facebook, you used to be asked to perform the traditional process of creating a new account with yet another password, and then you might be asked to provide the password of your E-mail account so Plaxo or Facebook could lookup the list of or you friends.  However now a Gmail user who clicks on such an invitation sees a page like the ones below:

Clicking the one button on that page takes the user to a page at Google that looks like the following:

If the user gives consent for this information to be shared, then they are sent back to Plaxo or Facebook, and they have now finished the key registration steps.

This type of registration process used to involve 10+ steps, including requiring the user to find one of those "Email validation" messages in their inbox.  In the future if the user goes back to Plaxo or Facebook, then they can usually login by simply clicking a button and there is no need to enter a password.

While this industry effort started out with a goal of improving security, we ended up showing that there is huge value to website operators supporting this type of password-less hybrid onboarding.  While Plaxo showed the first successful results in early 2009, other companies like Facebook are now using the same model because of the business value it creates for them.

Website Changes
While the technologies used for this flow are all standards based, the methods for how to combine them to achieve this success rate are not obvious, and took awhile for the industry to refine.  Here is a summary of some of the best practices for this hybrid onboarding technique.

  • The technique is primarily for websites with an existing login system based on E-mail addresses
  • It also assumes the website will send E-mail to users who are not yet registered, whether it is through traditional E-mail marketing or social network invitations
  • The website owner then needs to choose a small set of E-mail providers such as Yahoo and Google who support these standards
  • Whenever the website sends E-mail to a user at one of those providers, any hyperlinks that promote registration at the website should be modified to communicate the E-mail address (or at least domain) of the user back to the website's registration page
  • If the registration page detects a user from one of these domains, it should NOT start the traditional process of asking the user to enter a password, password confirmation, and E-mail.  Instead it should prominently show a single button that says "Sign up with your Google Account" where Google is replaced with the name of the E-mail provider
  • If the user clicks that button, the website should use the OpenID protocol to ask the E-mail provider to authenticate the user, provide their Email address, and optionally ask for access to their address book using the hybrid OpenID/OAuth protocol and the Portable Contacts API.    More details about this flow is available on the OpenID blog
  • Once the user returns to the website, it can create an account entry for the user.  The website can also mark the E-mail address as verified without having to send a traditional "Email verification" link to the user.  If the website received the user's permission to access their address book, it can now download it and look for information about the user's friends.
    • In the unusual case where an account already exists for that E-mail address, the website can simply log the user into that pre-existing account.
  • For any newly registered user, the website should then display a page that confirms the user is registered, and indicates how they should login in the future
  • To make the login process simple, the website should modify their login box to include a button/logo for each of the trusted email providers it supports
  • If a user clicks the email provider button, they can again be sent to that provider's site using the OpenID protocol.  When the user comes back, the website can either detect that they previously registered, or if it is a new user, the website can create an account for them on the fly.
    • In some cases the account may already exist for that E-mail address, but it was not initially registered using OpenID.  In that case the website can simply log the user into that pre-existing account.

One limitation of this model is that it requires adding a button/logo for each trusted E-mail provider, and obviously there is a small limit to the number of buttons that can be added without causing usability problems.  However, there are some more scaleable approaches described in this document on user experiences for Federated Login.  Both Yahoo & Google host E-mail (and OpenID endpoints) for many other domains other then @yahoo.com and @gmail.com.  By using a more scalable UI, it is possible to get the benefits of hybrid onboarding with a larger set of users.  In Yahoo's case, this include ~50 domains that have some Yahoo association such as @yahoo.co.uk, @yahoo.in, @yahoo.ca,  @ymail.com, @rocketmail.com. etc.  It also includes domains they host for broadband partnerships such as @att.net @verizon.net @sbcglobal.net, @btinternet.com, etc.  In Google's case, the other major domain they run is @googlemail.com, but in addition the Google Apps service hosts more then a million domains, including mail for many schools & ISPs.  Information about how to integrate with those domains is available at OpenID API for Google Apps Accounts.