Social Login Buttons Aren’t Worth It | MailChimp Email Marketing Blog

I stumbled across a very disturbing number in our analytics earlier this year. From April 12 to May 12, 2012, we had 340,591 failed login attempts. That’s the total number of times someone tried to get into MailChimp to get their work done and couldn’t remember their username and/or password, or simply mistyped. Think of how much wasted time and frustration that translates to. It’s impossible to calculate, but let’s just say it’s a lot. Of the people who struggled logging in, 68,145 had to resort to resetting their password, and 38,137 had to get a reminder about their username.

These numbers were depressing to the User Experience team. Surely we could do better, right? We set to work researching login design patterns to see what other apps are doing to grease the wheels. So many apps these days use social login buttons to “Log In With Twitter” or “Log In with Facebook.” These login methods are popular because with millions of users on these massive networks (as I pen this post Facebook has 955 million users, and Twitter has 500 million), many of whom log in each day (58% of Facebook’s users and 50% of Twitter’s users log in each day), adding social login buttons to your form should dramatically decrease the number of login failures. Click one button, and you’re in.

These compelling stats and sound logic convinced us (and so many others) that adding social login buttons to our app were essential to improving our depressing failure rate. So in May of this year, we added “Log In With Twitter” and “Log In With Facebook” buttons to the login form. Failure rates plummeted. From June 12-July 12 we saw 114,239 login failures—that’s a 66% decrease. Amazing! And there were 39,721 password resets, a 42% decrease. Holy cow! In the month that followed, failures dropped an additional 5%.

“I feel strongly about this.”

I was blown away and dumbfounded by the value of social login buttons. It was a big win for the UX team, and our customers. Then I got an email from Ben Chestnut, our CEO.

“The login screen is the first impression people have when they use our app, and their first impression is too many options. I’m always a fan of a measured approach, and I rarely ever dictate a big change like this, but I’m extremely repulsed by all the buttons and I want to restore simplicity. I feel that strongly about this.”

I was, um, not super happy to get that email. I presented my data, and made the case for keeping the buttons, but Ben wasn’t moved. Even though the social login buttons were bound for the grave, I did a little extra analytics footwork to see just how many people were clicking the social login buttons. I was shocked to see that just 3.4% of the people that visited the login page actually used Facebook or Twitter to log in. So what caused the huge drop in login failures then?

While researching login patterns in the wild, we also watched some users on our login page, and pinpointed a few smallish things we could change to make getting into the app easier. Our old login form told users, “Your username or password is incorrect,” when they may have the username right, but the password was incorrect. If you have 4 possible usernames and 4 possible passwords, you have 16 possible combinations between them—only one of which is correct. That means in this scenario, the user would have 15 chances to make an error when logging in. But when you know specifically that your username is incorrect, odds of failure drop precipitously.

The engineering team, ever mindful of security, argued that being generic about username and password errors makes it harder for bad guys to guess usernames by pounding the form with random words or email addresses. But after some further consideration, we decided that it was a false risk, as the username reminder form already tells you if a username exists, and is not a significant security risk for the bajilions of sites that have them.

So we split the username and password errors so the form would tell users exactly where their credentials are incorrect. And we added some better messaging in those errors, linking over to the forgot username or forgot password form giving people a better pathway out of the failed login loop. We made some other small changes too, but none that were likely to contribute to a big drop in the login error rate.

The secret to our success

So that big drop in login failures? It was all caused by better error handling and copywriting. That’s it. It wasn’t the social login buttons, though they did make a small contribution to our lower login failure rate. But if they help at all, why kill them? Even a 3.4% drop in failures is worth having them there, right? Maybe not.

Social login buttons can hurt brands

There’s been a great deal of bad press around both Facebook and Twitter as of late, tainting their brand perception, though not their user counts. The IPOs and APIs of other companies are beyond our control, but we place ourselves in a position to feel some of that bad brand juju when the logos of other companies sit next to ours on the most popular page in our app. There’s an implicit affiliation there. Call us control freaks, but we built this brand and we “feel strongly” about shaping its direction ourselves. One logo on our login page is enough. Who the hell wants their app to look like it was designed by NASCAR? Oliver Reichenstein made a case for ditching social share buttons a while back, and many of his arguments hold true here too.

Um, how did I log in last time?

We’re all using tons of apps these days on our mobile devices and desktops, many of which are using these social login buttons. Sometimes you log in with Twitter, sometimes with Facebook, sometimes with a username and password specific to that app. It’s hard enough to remember your username and password, let alone which service you should bloody use to log in. As you add login buttons to a page, you also add decision points for users, while creating visual complexity in your design. The marginal gains in login rate are chipped away by the additional cognitive load you’re adding for your users.

If you’re using Twitter and Facebook for signup too you’ve got a bigger problem. A user’s credentials are then bound to another account on another service that could be canceled at any time, breaking access to your app without the user knowing. Unless you require a username and password for your app then pair that with credentials from a social network, you’re creating opportunity for confusion and frustration for your users.

Social login buttons put security in someone else’s hands

What if Facebook or Twitter were hacked? Your social profile would be at risk (the sun would still rise tomorrow), but so would any other account on other services that are connected. That’s a little scary. Yes, Facebook and Twitter are good at security, but nobody, NOBODY, is perfect. Social login buttons delegate control of your users’ credentials to another service, rather than ensuring security yourself.

Is it worth it?

There’s a strong case to be made that as Facebook and Twitter have amassed such huge user bases we should take advantage of the fact that so many of their users are already logged in and just one click away from entering your app. I know that argument all too well, because I made it to my colleagues. We tried that experiment, and found that while there are some marginal improvements to login failure rate, they come with a price.

Do you want to NASCAR-up your login page? Do you want to have your users’ login credentials stored in a third-party service? Do you want your brand closely associated with other brands, over which you have no control? Do you want to add additional confusion about login methods on your app?

Is it worth it? Nope, it’s not to us.

Update: October 4, 2012, 11:15AM ET

Man, we’ve gotten some great comments on this post. Several people have pointed out the irony of our comment login system on this blog, and we laughed too. Yeah, we see the irony there, but I think it expands the conversation further.

Although the data and design philosophies we’ve presented here made a case for not using social login buttons on our app, we don’t want readers to take this as gospel. Some apps, as Matthew Smith deftly pointed out in the comments below, stand to gain quite a bit from them, especially if they’re targeted at individuals, not businesses as MailChimp is. Social logins also have some value on mobile, where recalling a complicated password is inconvenient, as Ed Lea and Erica Burnett mentioned in the comments. And Dorian Taylor gave us a great summary of the balancing act we all face when data and gut colide.

Blog comments, like the massive stack you see below, can be enriched by pulling conversations from Twitter and Facebook into one spot, letting people make their voice heard on many platforms quickly and easily. We’re using a WordPress plugin called Social that we developed with the fine folks at Crowd Favorite. It could not work without social logins.

Although we weren’t trying to be ironic or clever (read “stupid”) by following this post with social login buttons, it accidentally steers the conversation in a new direction. When is it appropriate or inappropriate to use social login buttons? Sometimes it makes a lot of sense, and other times it’s just not worth the trade-offs. But don’t use them because they’re on every other popular app. Use them because they serve a purpose for your business and your users.

It’s convenient to see answers to big problems in black and white, but truth almost always lies in shades of grey. I think this blog post has been popular because it questions common assumptions. It’s always good to question (even the conclusions we’ve arrived at here). That’s how we learn. That’s how we make better things.