When we launched Alpha testing for Stormpath last year, there was a worthy debate about what would be the best signup flow. We wanted to ensure potential attackers wouldn’t be able to create dummy accounts and that we would be able to contact users reliably, but we also wanted an easy user experience. Signup workflows are fickle, hotly contested, and can present a security hole if you do them wrong, and we eat our own dog food and register users to Stormpath… using Stormpath. Figuring out signup best practices is important both for us and for our customers.
A few months ago, we upgraded the signup workflow. Despite asking for more information,the upgraded workflow increased our signup completion from 74% to 94%. Instantly. All we did was change the order of the four-step process.
This blew our minds, so we thought we would share the details so other web developers could build smooth signup processes, without compromising security.
The Old Workflow
Our original workflow was based on a hypothesis: the less information we required from someone up front, the more people would initiate and complete signup.
Here was our original flow:
- The user entered just their email address in a simple form and clicked a submit button. This sent them an email.
- The user opened the email and clicked a unique link to verify they owned that email address, and ostensibly were a human. This took them to a registration form page.
- There, the user filled out the info form (first name, last name, password, confirm password) and was redirected to the login screen with a success message (“Your account was created! Yay!”).
- [The account was instantly created on our system]
- The user could then login and merrily start building.
One of the biggest debates was where to put the “info form” – we didn’t want to scare users off with a big field of inputs right away. We thought if they saw 6-8 required fields, they would simply bounce. What was the minimum we could ask for? Stripe doesn’t even require account authentication to get into a sandbox. We decided to keep it stripped down and present it after a user had already expressed interest, e.g. given us their email address. There are good examples of companies who register accounts this way, Heroku among them.
75% of people completed this process, and while it was annoying to lose a quarter of users, we heard from advisors this was pretty much the benchmark and “not to worry about it as long as it’s over 70%. There’s always going to be some churn in the funnel, especially if people are popping between browser and email.”
But still, it rankled. Were we getting hit with a huge volume of dummy accounts? Had we been tagged by an ISP as a spammer? Were users just really turned off by account verification?
When we looked at the data, our unregistered users appeared to be legitimate humans (with names and emails associated with companies). We ran tests in EVERY email service and client. We set up and tested email workflows to tempt that 26% of unconverted users down the conversion funnel.
Nothing significantly moved the needle.
The New Workflow
When developer companies like New Relic start to frontload their signup flows, we pay attention. New Relic has a lot more users than we do, and they serve a very similar type of user. And interestingly, in 2012, they weren’t the only developer services company to change their signup workflow to put the info form in front.
So we rolled out a new flow:
- A user clicks a single ‘signup button’ on the website without filling anything in. This takes them to the new registration form page.
- The user fills in the info form. It is just like the old form but in addition to first name, last name, password and password confirm, we also ask for email and company name. Upon hitting submit, we send them an account verification email.
- The user opens the email and clicks the verification link, which sends them to the login page with a nice success message (“You’re ready to login! Yay!”).
- [The account is instantly created on our system]
- The user can login and merrily start building.
Did frontloading that nasty information form inhibit signup? No, not even a little. In fact, the bounce rate on the form DROPPED from 17% to 14%,even though users in the old workflow had already expressed an interest in signing up (by giving us their password), but new workflow users had not. Also, more importantly, signups are seeing healthy growth.
But the most shocking statistic: our completion rate increased from 74% to 94%. An additional 20% of intended users are making it from the first signup button through account verification and into Stormpath. That’s a 27% increase.
Hmm… does that mean 6% of our emails are landing in the spam folder? Or that 6% of intended users hate account verification? Nope. It means that 2% of users mistype their email address and we actually only have 4% dropoff in the funnel. This is the effective cost of account verification.
So, what were we doing wrong with the old workflow? There are several hypotheses. First, though they actually have the same number of steps, the new workflow feels shorter, because users only input data on one form.
We also believe users prefer to see everything upfront. They have done enough signup workflows in their years online to know that in the flow, there is a form, with a whole bunch of fields on it, lurking in wait. And they don’t like being surprised by it.
Another take: the new workflow requires users to invest effort into signing up, so they’re more keen to finish the process. In other models, it was trivial to sign-up, so we probably didn’t hold enough mindshare to keep them focused on finishing the process.
Caveat: when we launched GA, we changed other things: there were minor changes to the email text, and we reskinned our website. But the essentials of the flow remained very consistent, even down to the color of the signup and action buttons.
Why Account Verification?
Watch this space for a follow-up post on how to match your authentication requirements to your use case, but the short answer: account verification makes it harder for an attacker to load our system with dummy accounts. More importantly, if we have to offer you support in the future, send you an account alert, or contact you for any reason, account verification ensures that you have access to the email you signed up with. This isn’t necessary for every login system – it’s an optional feature in Stormpath that is not set by default. But because we hope to be the user plumbing in your app, it’s important to be 100% certain we can contact you. Again, not true for everyone, but really important for us.
That’s our story – let us know your thoughts on authentication best practices in the comments!