Tiny Review and the Perils of Facebook Login
Jan 29, 2012
Dick Brouwer
6 minute read

“I would rather drink piss like Bear Grylls than log in with Facebook” – Tiny Review user

Startups always face unexpected hurdles delivering a product. I wanted to write about one that we faced early on at Tiny Review.

Background

The Tiny Review iPhone app was launched in November 10th, 2011. It was a true minimum viable product (MVP), and the only way to use it was to login with Facebook. Our plans were to stay below the radar and iterate on product, but a week after going live, Apple featured Tiny Review prominently in the App Store. We got a lot of downloads and attention, but supporting the traffic and community took up all of our attention from building product.

Why We Chose Facebook First

There were a few, very specific, reason we chose to require Facebook Login at first.

  • There are only two of us working on the product, and only one working on the code. We needed a way to manage the quality of content, without devoting a lot of hours to developing a moderation system. We thought Facebook users would be less likely to post questionable content if their real identity attached.
  • We also wanted to limit brands from coming on the platform, until we had a more robust service for them. If a lot of businesses began using Tiny Review to promote themselves, it would be nearly impossible to nurture a community of real, authentic users.

Initially, requiring Facebook login paid off. Content posted was high quality, and we didn’t see any body parts. Sign up conversion started out greater than 80%, meaning that more than 80% of the people who downloaded our app, signed in with Facebook. But over the first 6 weeks conversion dropped to 50%. It bears repeating: almost half of the people who downloaded our app never used it because we required Facebook. And people LOATHED it! We had a lot of five-star reviews from people who raved about the app, and almost all of the one-star reviews were people lampooning the Facebook requirement.

Why Facebook Only Was a Mistake

In the words of one user, “[He] would rather drink piss like Bear Grylls than log in with Facebook.” But why? Our user research revealed:

  1. People don’t trust Facebook. Too many people have been burned by spammy Facebook apps that spammed their friends, stole their data, and provided no utility in return. Tiny Review of course didn’t do that and we went out of our way to tell them, but it didn’t matter. Users don’t trust Facebook.
  2. It made changing login options after the fact much more difficult.Once you have an existing user base that has authenticated with Facebook, it is difficult to get them to switch to username/password authentication (they would have to create a new account, and force link this to Facebook after). The only way to avoid hairy account sync issues is to get users to create a username and password first, then link with external services like Facebook/Twitter. If I log in with Facebook first and the next time I log in I use Twitter, none of my existing data will be there (it’s a new account). If you create a unique username for a user upfront, it becomes trivial to link accounts together.
  3. Requiring Facebook lead to a lot of bad reviews. In fact, we mostly have 5-star ratings from users that love the app, and 1-star ratings from users that refuse to authenticate with Facebook. Reviews are important, and we take them seriously. They do not go away, and there is no way to reach out to those users to let them know that you acknowledge their issues and you are trying to resolve them. One of the ways that we tried to address Facebook trust issues is with a a page that explained in plain english how we use their data AND why we request each type of permission, and we put that link next to the Facebook login button. This is the way that we tried to capture the issues that the users might have had, so that they did not leave an anonymous rating in the App Store.

This is not to say that requiring other methods of authentication are any easier. Asking for a username and password on signup is one thing, but typically you would need more information like first and last name, email, profile picture, etc. Every extra field you ask users to complete in the signup process will lower your conversion ratio. Furthermore, with email signup we don’t know who your friends are so we can’t give you a social/more personalized experience. As a developer you want to get the first impression right, and the more data you have about a user the easier that becomes.

Adding Twitter Authentication on iOS applications is also a tough nut to crack. SSO with Twitter sounds simple, especially with the iOS 5 Twitter integration, but it’s anything but simple:

  • iOS 4 backwards compatibility is still a requirement. About 70% of Tiny Review users have migrated to iOS 5, but 30% is too large a number to ignore.
  • ‘Easy’ Twitter SSO on iOS 4 requires XAuth special permissions from Twitter. You have to email Twitter to get these. Getting these special permissions can take a while, in some cases a few weeks in other cases you may not get them at all.
  • Single Sign On (SSO) with iOS 5 requires Reverse Auth Permissions from Twitter, so you need to email them again. This is only required if you need to have access to make authenticated calls on behalf of the user on your server. We need this.
  • The app needs to support multiple flows for both iOS 4 and iOS 5. A user that is still on iOS 4 will need to have a much different login flow, than a user that has is using iOS 5’s Twitter integration. Building additional login screens to accommodate both workflows is not always an easy or straightforward task.
  • Twitter authentication doesn’t give email, so if you need the user’s email address you need to build out an additional signup step.

Conclusion

If you make a mobile or social product, and its success depends on growth, you must focus on removing ALL barriers to usage. Restricting login to one platform works against this basic idea. Even with your MVP, the login options must be thought out. This doesn’t mean that you need to require more than Facebook, but you need to have put thought into this and have a good reason for making the login choices you end up making. Once the product goes live and traffic rushes in, it becomes ever more difficult to focus on building, adapting, and iterating the product. You have to turn your attention to a host of other issues: user feedback, scaling, content moderation, bug fixing, community management, press, investors, (and in our case) complicated localization, etc.

Advice: If we could do it again, we would ask for username/password first. This hasn’t really been talked about, but we think there is definitely a best-practice for mobile-signup: always make users signup with email/password, and then have them link additional accounts (FB/Twitter, etc). You’ll save yourself a lot of headaches later.

Other startups face similar issues. For example, Little Blag Bag, wrote a related blog post about Facebook Connect signup conversion. Conclusion: 30% refuse to authenticate, 30% don’t like it but eventually give in, 40% doesn’t care.

EDIT: there is a discussion on HN going on: http://news.ycombinator.com/item?id=3604981



comments powered by Disqus