Ask HN: Conversion rate increase with a Facebook sign-on? | Hacker News Reader

Ask HN: Conversion rate increase with a Facebook sign-on?

24 pointsmsencenb31 comments

I am considering implementing a Facebook sign on in addition to the usual registration and was wondering if any HNers could share their experience with doing so. Did you see a significant increase in sign-ups?

View on HN

if signups are your metric, then I would guess you'd see an increase.

however, as others have mentioned on HN, by reducing friction you increase the amount of "tyre-kickers" - people who just want to check things out and leave.

that's not such a bad thing if your cost-per-user is negligible, or you have some kind of post-signup campaign in place (e.g. an email after inactivity that tries to "reactivate" the user).

in those situations, the more people you can expose your company to, the better. I'd wager that many startups don't implement Facebook signin because of the engineering overhead that could be spent on sexy new features.

Do you have any basis? I mean we all know the theory why it might, but I'm not convinced?

wellll ok, the real answer is:

It depends on your execution.

In general, reducing friction will increase signups. That's hard to argue against. The only situation where reducing friction will reduce signups is where you seemingly reduce perceived value by doing it, but again, that all depends on execution.

Facebook connect sign in could be executed in a couple of ways:

1) Click a Facebook button. Click approve. Boom, you're registered in your app.

2) Click a Facebook button. Click approve. Get redirected to another signup form and have to fill in more data. Click "Send". Oops, there was an error with your form input, please enter a valid email address. Fill in data. Click "Send".

I can say with confidence that (1) will increase signups, but (2) will hardly move the needle.

It depends on your execution.

We tested this with http://www.reedge.com for a client that integrated the facebook login on the checkout page of a Magento shop. I remember that Around 8% more finished the checkout compared to when we did not show the facebook login option.

The problem was we did not test the actual login, just having the option. The client did not give us details on revenue/turnover or hoe many people actually used login of facebook.

It was a health product on the US market.

"I'd wager that many startups don't implement Facebook signin because of the engineering overhead that could be spent on sexy new features."

How much time is really spent integrating FB Connect?

The fact that it requires learning a new API makes it a non-trivial feature, engineering-wise IMO.

I wouldn't have deemed it trivial, but the part I quoted made it sound like the associated workload was pretty heavy.

I haven't looked into the API or what it takes to integrate it, but I assumed (bad habit, I know) it wouldn't necessarily be rocket science. Aren't most API's relatively simple to use compared to the actually building of an app?

Plus, if it causes a huge increase in users and tire-kickers, it seems an app would get more chances to show off their sexy features anyway.

After looking at the docs it doesn't appear to be incredibly hard.

I think the most non-trivial thing would be integrating with the current site sign-on. Issues such as an existing users that decide to sign on with facebook (which is linked to a different e-mail address) could become a problem on the backend.

As long as it isn't your only authentication method I don't see harm in adding it.

I'm extremely turned off by sites that want me to sign-on, with the only option being Facebook, because I've had enough of sites demanding irrelevant permissions they obviously don't need (you need my email, not to be able to post to my wall). If I really want to sign up for something I'll do that and 'fix' the permissions in Facebook but it really peeves me.

Last time I tried it I saw a significant decrease -- as much as 50% lower signups as tracked with Google Website Optimizer.

Really? Was it your only login option or in addition to your usual? Also how much traffic were you seeing (aka was it statistically sound?)?

To clarify: Facebook was shown as the default login option, with a site-specific login available with a Javascript toggle. My test compared which login option was the default. I don't remember the specific numbers (had a lot of traffic though). Google Web Optimizer had given a 95%+ indication that the FB login was performing poorly. So I'd acknowledge issues with the test, but these numbers were convincing enough that I made the site-specific login the default from that point forward. What I did not test is whether having FB login as an option helps or hurts total signups. I suspect that this only helps but can't give any numbers.

Clearly there are lots of caveats, and the results of any experiment are going to be informed by your site, audience, and so on.

I enabled the facebook connect for one month on my startup site and learned alot of things. First yes you will get alot of signups, but most will never return, never make a single contribution and only came to say they did. Second I will never do it again. The accounts as I said were of 0 value to the site or the existing users that had been invited. The invited users end up using more services and clicking through different parts of the site. They also care more about it when talking to others versus just being able to say they were there. Hope it helps.

Personally, I'm wary of sharing my facebook credentials with a site that I don't trust yet or don't peruse regularly. I'd rather fill out the details or actually use my twitter id instead as I'd consider that a throwaway compared to my facebook account. This paranoia just goes up considering that the vendor in question is Facebook, someone who doesn't have the cleanest record when it comes to privacy of data.

Have you implemented or thought of implementing twitter's Oauth functionality instead? I wonder how that'll work out for you.

I'm assuming he's talking about using Facebook Connect, which is based on Oauth, so the user wouldn't have to share their Facebook credentials with his site. (http://developers.facebook.com/docs/guides/web#login).

I agree with you that sharing your Facebook credentials or your email credentials (especially your email credentials) with another site is foolishly stupid.

I understand that user doesn't share credentials but usually, with facebook connect, the only method available to connect is where the site grabs a ton of information from facebook (name, email, profile interests, etc.) .. I'm not so sure I'd want to share it unless there's a reason to it..

e.g. Huffington Post asks for basic info (name, profile pic, gender, user id, list of friends and then some), access to my newsfeed, interests and likes, and my current city .. this is only to comment on a post .. it seems like overkill to me and as a result i wouldn't really use facebook connect in this instance.

I agree, I'm actually much more inclined to use my Google / Twitter accounts over Facebook. Maybe that's just a temporary thing.

I have been using RPX on my site to allow users to login through Facebook and Twitter. This is where a majority of my sign ups come from. It really depends on what type of site you have.

I don't get many return users from it but I do get some extra information which is useful in my case for statistics.

I am currently moving away from RPX in favor of using the services for Facebook and Twitter directly so I can do more with the user and with the data.

I have used rpxnow in several of my websites and it confused users more than anything else.

Only geeks are annoyed by the classic registration forms.

Is anyone else left scratching their head at how the facebook login overtook OpenID?

Nope, it makes perfect sense to me. Open ID made no sense to non-computer enthusiasts (and to plenty of the enthusiasts as well). Those same people all have Facebook accounts and probably visit Facebook multiple times a day. They trust Facebook, so clicking on it seems painless - and it's definitely effortless.

It doesn't make sense: everybody who have a Facebook login also have a gmail, so why not not just allow people to login with that?

Stackoverflow does exactly that. They have big buttons for all the major identity providers, including Google, Facebook, etc. and a text field at the bottom for manual openid login.

Personally I feel a lot better about Twitter + OAuth than FB, but that's just me.

As for why not use OpenID? Personally, I don't want to tie my Gmail account to a lot of things -- then people have my email! I don't necessarily want to tie my Facebook to them, either, but in the same breath some forms of OpenID can end up sharing more, depending...

This is why I get cranky when people implement Disqus, too -- old comments I made that were supposed to be anonymous but which had my email for the author, etc, are now pulled in and linked to a general identity months or years later. :(

Why would you feel better about Twitter + OAuth than FaceBook + OAuth (which is what the sign on component of FB Connect is)? From a technology perspective, it's the same protocol. Neither company has a good security track record.

(not criticizing BTW, just curious)

the twitter account could be a throwaway account and generally lesser risk of anybody getting too many personal details.. facebook, not so much ..

Because all the major sites/companies were too busy fighting to be the provider everyone uses and never got around to actually accepting anyone else.

But that isn't really an issue if you want to accept open ids on your site - it is actually a good thing, because the more providers there are the easier it is to find on that has your customers.

It was easier to understand (openwhat?) and use (less clicks).

I would suggest using OpenID, I've had much better experiences with that.

I added FB to Pikk and saw a mild uptick in signups. You also get the benefit of using users real names and images. It took about 4 hours of work or so to get it live. Hope this helps.

Kevin

Reply on news.ycombinator.com