Has anyone experimented with using LinkedIn connect as the exclusive method
for creating accounts / customer information request forms?
I\'m working on a side project for a friend and it\'s a standard SaaS signup,
free 30day trial, pick a plan, blah blah blah.
Aside from the standard challenges associated with streamlining customer
sign-up flows we\'re trying to improve the quality of registration data
while also making it easier for clients to sign up.
I was just wondering if any of you all had done some a/b testing on a
regular sign-up forms vs. LinkedIn to see if this is a viable approach.
- Thanks, Derek
Derek Dukes | 415-828-5781 | @ddukes
I\'m working on an implementation of this right now. We\'re actually relying
primarily on LinkedIn for account creation and authentication, since our
app is a personal networking service - direct registration is secondary.
One problem I\'ve seen generally with LinkedIn/Facebook signups is the
overlap (or lack thereof) between the app\'s desired/required registration
fields and the data returned from the partner\'s API. When they don\'t
overlap there\'s an (occasionally) awkward second-step to the signup process
that many users find off-putting. People are starting to expect one-click
signups when they come in via a social platform. To compensate, we\'re
experimenting with a post-signup data gathering intersticial that picks up
anything we need that LinkedIn can\'t give us. So far so good.
I\'m working on a site right now that uses LinkedIn as the only social signup, though it also provides a username/password signup. *Completely unrelated to that experience* and just from my own private philosophy:
Require the *minimum* possible that you need to get someone into your site. Make it as simple and quick as possible -- that\'s generally a social signup. And then after they\'re through the door and using your product, if you want more information, give a little to get a little. "We\'re having this contest..." or "Provide your email address to connect with all of your Gmail contacts..." etc.
^-- Not scientifically validated, just the way that I see the world.
I\'m working on an implementation of this right now. We\'re actually relying primarily on LinkedIn for account creation and authentication, since our app is a personal networking service - direct registration is secondary. One problem I\'ve seen generally with LinkedIn/Facebook signups is the overlap (or lack thereof) between the app\'s desired/required registration fields and the data returned from the partner\'s API. When they don\'t overlap there\'s an (occasionally) awkward second-step to the signup process that many users find off-putting. People are starting to expect one-click signups when they come in via a social platform. To compensate, we\'re experimenting with a post-signup data gathering intersticial that picks up anything we need that LinkedIn can\'t give us. So far so good.
Also, even in a B2B setting, don\'t ignore Facebook as a potential login
option. Even on B2B sites, we only see about 50 - 60% adoption of LinkedIn
when other options are presented, and not everyone has a LinkedIn account.
Also, Salesforce has an Identity API - that might be interesting in B2B
Could you elaborate on the acceptability of FB in a B2B setting? Right now our consumer-facing app uses FB to authenticate but I\'m looking at enterprise use cases and was assuming that FB wasn\'t an option. While salesforce is the first target we\'re supporting and we already connect via OAuth, we\'re not actually using for user login. I\'m actually scratching my head about what to use because we\'re not tied to salesforce and I really don\'t want to implement our own user id/pwd. In my fantasy world, we could just continue to use FB! (Yes, I realize other people\'s fantasy worlds are inhabited by supermodels.)
On Jan 16, 2013, at 9:34 PM, Cory Huff <coryh...@gmail.com> wrote:
> Like Cory suggested, you might want to check out Janrain.com - or
> Oneall.com - esp. if you want an easier way to support multiple
Concerning the "77% of web users prefer using social login..." Do you gather any data that differentiates a Web User who is shopping on amazon or costco for a new shirt from a Web User who is working on saleforce or apptio on behalf of their employer? I can not envision any circumstance where an employer would allow a user to use their personal social web account to login to a business application and act on behalf of the employer.
If linkedin is compromised and my shirt purchasing history and credit card number are stolen that is a vastly different issue then if my employers sales prospects and customer lists are stolen.
Since Derek\'s original request was for a B2B Sign-up Flow I would think any social login or login that belongs to the individual would be off the table. Login credentials that are used to conduct actions on behalf of an employer should be the property of the employer provided to the employee for a specific business purpose.
My two cents....
Brad Simmons -- ArivX
On Jan 16, 2013, at 9:32 PM, Cory Huff wrote:
Brad - yes, that\'s a whole different ball of wax, isn\'t it?
That 77% stat is purely a generalized stat about web users. You can
download the white paper to read about methodologies of the research.
You can use social login in a business application setting. Janrain
actually has a few customers who have installed social login on desktop and
web-based applications for business use. There are specific security issues
that Janrain has addressed similar to what you\'ve outlined here.
My recommendations have all been generalized. If I knew more about specific
use cases, I might make different recommendations.
WRT the data you\'re getting back from linkedin, does it seem to be a data
permissions issue or that the user hasn\'t actually filled in their linkedin
profile with the right data? Roughly what % of users experience this \'lack
According to the LinkedIn API there should be pretty good data returned
(assuming you have permission and it\'s there)
- Thanks, Derek
Derek Dukes | 415-828-5781 | @ddukes
On Tue, Jan 15, 2013 at 11:59 AM, Michael Sattler <mich...@sattler360.com>wrote:
I work at Janrain for my day job as a Digital Strategist advising people on
social login and registration strategies. 77% of web users prefer using
social login over traditional registration, especially in mobile.
I agree with Eric Rogness that you should be asking for the minimum data to
get the user registered. This usually means just first name, last name, and
email address. Getting the user in your database is the most important part
- you can get the rest of the data later.
There are two follow up ideas I\'d recommend.
- Use conditional logic to show users only the form fields that are
required for registration after the social authentication happens. Thus, if
you get their first and last and email address, but you also want them to
give you a job title, then only show them the job title field.
- Progressive profiling. This is a term that we use at Janrain to describe
the process of getting users to give you more information over several
experiences instead of all at once. Asking for a small set of data up front
gets them in the door. For access to additional features, you ask them for
a little more data. Don\'t ask them for permission to share until they
actually perform a sharing action. If you want deeper data, do a contest or
giveaway of some sort and require giving up that data as part of entry.
There\'s all kinds of things you can do here.
Hope this helps.
BTW, you might want to check out the free version of Janrain\'s social login
product, Engage. Perfect for handling social login as a startup.