The unexpected costs of third-party login
For app developers, Login with Facebook is less beneficial and more work than you think
Taylor Hughes is a co-founder at Cluster, which builds web and mobile apps that enable users to create private sharing environments for groups, travelers, classrooms, and more.
People have been signing up for Cluster for almost two years now. We’ve watched dozens of new users sign up during live user tests, and we’ve analyzed our signup data and answered countless support inquiries to glean a pile of insights.
When we first launched in February 2013, we offered one simple login option: Login with Facebook. We made the decision in a hurry — actually, we did everything in a hurry — and didn’t fully grasp the long-term implications of our choice. This initial design did not go over well. (More on that later.)
Eventually, we added more federated login options, and we created our own login system to support both email and SMS-based accounts — this added a lot of complexity not only to our backend, but also to the user experience in general.
In the end, something simpler was probably in order for Cluster — something like SMS-based auth — but of course at that point we hadn’t read this post yet.
The promise of social login
Using a third-party login provider allows users to skip filling out the same tedious details they’ve filled out a million times before.
Whether it’s Facebook, Twitter, LinkedIn or Google, users probably already have an account, and in theory we can short circuit the signup process and make everything better by shacking up with one of the big guys.
The main benefit is that the user’s profile information is probably already complete — it’s virtually unheard of to come across a Facebook profile without a photo, for example.
Beyond that, you might immediately get access to a fully-formed friend graph. If you’re building a service that involves public sharing, this is a huge win — apps like Tiiny can launch and immediately display content from friends who signed up earlier that day.
So that’s totally awesome. Forget making users go through another sign-up process: Just add an SDK and a little extra authentication secret sauce to the backend and you’re good to go.
But it’s not all sunshine and rainbows.
Facebook baggage and unexpected user expectations for your product
As a developer, Facebook authentication does not get you much these days beyond a user’s profile information and a readonly list of existing friends.
Facebook makes it incredibly difficult for developers to do anything with users’ friends’ contact information directly. For example, sending invitations through Facebook is nearly impossible: You can pop up a native “Send Facebook message” dialog, but you can’t send a message on a user’s behalf. Posting to walls is also incredibly difficult and requires a ton of configuration, not to mention optional user approval.
But people don’t know that. Most Facebook users still remember the Farmville days, when third-party developers could easily fill your feed with updates, requests for participation and whatever else they wanted.
This causes a ton of hesitation around the Login with Facebook button: Some people avoid it like the plague, other people are “okay with it” — but in either case, people are acutely aware of it.
As a result, something really interesting happens when people choose to log in with Facebook: Many people turn beliefs about what they think developers can do into expectations for what your product should do: Many people are confused when you can’t invite a friend through Facebook with the touch of a button.
“Why do you need access to my contacts? I signed in with Facebook!”
When your app can’t do what users think it should do, there’s a whole lot of explaining to do — and users might end up disappointed in your product.
Unexpected technical costs
Implementing third-party login seems easy at first. Every login provider’s how-to page makes it seem extraordinarily simple: drag and drop a button in Xcode, right? But it’s never as simple as it sounds.
The most vexing issue for us has been Facebook’s complicated session lifecycle. When we first launched, this was the cause of innumerable headaches. The documentation is difficult to navigate, much of it is out of date, and it changes so often that most of the StackOverflow answers are irrelevant.
For posterity, I wrote a brief technical aside on the topic: The right way to implement Facebook login.
But it’s not just Facebook. The Google SDK was the #1 source of crashes in Cluster for iOS for several months due to a bug somewhere in the depths of their code that we couldn’t put our finger on. (Upgrading eventually fixed it, but we still don’t know the root cause.)
Inevitably, you end up having to work around the peculiarities of each SDK and deal with tons of shit as more and more edge cases come through your signup flow. (Look forward to inconsistent profile data, backend downtime and unannounced changes — it’s a lot.)
Long story short, don’t assume that the technical cost of these integrations is anywhere near zero.
You can’t get away with just one kind of social login
Cluster’s initial public launch was a pretty simple MVP, and we didn’t think much about new user onboarding at the time. The first thing a user saw was simply a blue screen with a big fat “Login with Facebook” button on it.
This login screen drew ire from a surprising number of users in App Store reviews. People were absolutely vitriolic about our only sign-in option, and demanded more. Our star rating suffered for months — and that rating is very important as folks evaluate your offering in the App Store.
In order to stop the bleeding, we immediately launched a new version with another button: the “I Don’t Want To Use Facebook” button.
Most people who clicked “I Don’t Want To Use Facebook” ended up using Facebook anyway after reading our pathetic “Coming Soon” disclaimer — but we got hundreds of signups on the “Email Me When You Fix This” list.
Within a few weeks, we shipped a new UI featuring “Login with Facebook” and “Login with Email” buttons — and a few months later, we added “Login with Google” to the mix.
In the end, with two “Login with X” buttons and a manual signup form below, most of our signups come from filling out an email address and password: Almost 45% of our new users opt for the most tedious option. (The next-most popular method is Facebook login, followed by Google.)
Users won’t remember how they signed up
As it turns out, supporting multiple sign-in options adds a tremendous amount of complexity. Instead of an interface where a user can only do one thing — even if it means filling out a tedious form — people have to stop and think about options.
This leads to another unexpected side-effect: When logging back in, lots of people forget how they signed up for your service in the first place, and they end up trying the wrong method.
Worse, long-lived mobile sessions exacerbate the issue. When users log in again months later, it’s like rolling the dice.
This results in support emails from users who are very confused about why all their content is missing after upgrading phones — or users wondering why, when they login on the web site, none of their stuff appears.
It’s easy to think of the benefits of adding more third-party logins — but the implications are a lot farther reaching than your authentication backend. Complexity will almost certainly lead to user confusion down the line.
The end
In the end, I would not suggest jumping into the “Sign in with X” bandwagon without closely considering the costs and benefits.
For our product, it turns out that making a user sign up is not a huge barrier to entry. People are used to signing up for services already, and it’s the most commonly used signup method in our service even in light of quicker options.
But of course, YMMV. Good luck.
Thanks for reading this! Any thoughts? If you enjoyed this article, I would really appreciate you hitting the recommend button below. Connect with me on Twitter @taylorhughes with any comments or thoughts.
