Is a user of a Facebook App really a user of your service?

I continue to grapple with all of the ramifications of building for Facebook.  On the one hand, I am in awe of the viral nature of the platform, and the big thinking that must have gone into building it.  But on the other, as a potential application developer, I am unnerved by the uncertainties and fine print.

One thing in particular is really bugging me.  What does it mean exactly to sign up a Facebook user for your application?  It certainly means something, but it’s clearly not the same as having a user sign up directly for your service.

Let’s consider the case of the iLike Facebook application.  As of today, iLike has 3.7M users.  This is a pretty impressive number for just a few weeks of being live.

But what does it mean?  The most important component of the iLike destination site is the download.  This download does two things: it hooks into your iTunes, providing you a sidebar which displays related music (that you can buy through the iTunes store), and it scrobbles your listening history back up to iLike’s servers, which is the foundation for how users with similar music tastes are matched to each other.

iLike for Facebook doesn’t offer the download.  Instead, it is utterly dependent on explicit actions like users specifying which songs they like, and which concerts they’re going to.  There’s also the quiz app – another explicit mechanism for iLike to collect preference / taste data.

So for iLike’s 3M destination site members, iLike is receiving a steady stream of implicit listening data with which they can use to recommend other songs, fortifying their affiliate revenue model.

But for the 3.7M Facebook / iLike members, it’s something else entirely.  The data being generated gets stale much quicker, as it's dependent on explicit actions by the user.

Furthermore, iLike is not acquiring new registrations through Facebook.  They don’t get the email addresses and demographic information that they get when a new user signs up through iLike.com.

So in the case of iLike, all users are not created equal.  An iLike.com user must be more valuable to iLike – significantly so - than a user of their Facebook app.

And there’s another issue for UGC Facebook applications.  Let’s consider the case of the Flixster movie rating app, which at the time of this post had about 2.4M Facebook users.  In theory, the Flixster Facebook app has the advantage of building value on top of the social map – specifically, users are creating valuable content in the form of movie reviews, which can be used to attract search engine referrals, earn advertising dollars, and even to license to third parties.

However, for those of you who have Flixster accounts and Facebook accounts, you probably noticed that the reviews that you post on Facebook don’t automatically post on Flixster.  It requires an explicit action by the user to synch their accounts, and to authorize Flixster to post on the user’s reviews on Flixster as well as Facebook. 

Why is this?  It’s because of the Facebook Developer TOS:

Notwithstanding the provisions of Sections 2.B.1, 2.B.2 and 2.B.5 above, if (and only if) the Applicable Facebook User for any Exportable Facebook Properties expressly approves your doing so pursuant to a Full Disclosure Opt-In, you may additionally display, provide, edit, modify, sell, resell, lease, redistribute, license, sublicense or transfer such Exportable Facebook Properties in such manner as, and only to the extent that, such Applicable Facebook User may approve.

So taking the case of Flixster, although they are getting incredible traction on Facebook, and presumably generating massive numbers of ratings and reviews, they can’t display / monetize this data back at home base without user authorization.

I would imagine that this data can be used in other ways.  Flixster can crunch it to learn more about movie viewing habits, and presumably use this info to improve their service and business model.

It’s also conceivable that a reasonable percentage of users who are both Flixster and Facebook users will take the time to synch their accounts.

But there is a worst case scenario where folks who are both Flixster and Facebook users don’t synch their accounts, and stop posting to Flixster entirely (now that they can enjoy the same functionality on Facebook).  In this scenario, Flixster remains responsible for the bandwidth costs of providing the service, but doesn’t get access to the content for SEO and advertising purposes.

In the case of users who are new to Flixster by way of Facebook, I’d have to think it’s unlikely that a significant percentage will open a Flixster account.  In this scenario, Flixster again is incurring the bandwidth costs, and again does not get access to the content or registration data.

When viewed in this light, it seems critical that Flixster (and other UGC widgets), to find ways to improve their conversion from Facebook app user, to destination site user.

Of course, there is the potential for Flixster to find a way to monetize its app on Facebook.  For the time being, app developers are able to keep 100% of the revenue.  However, returning to the TOS tells us that this could change at any time:

We reserve the right to charge a fee for using the Facebook Platform and/or any individual features thereof at any time in our sole discretion. If we do charge a fee for using the Facebook Platform or any feature thereof you do not have any obligation to continue to use the Facebook Platform or the applicable feature. However, if you do: (i) we reserve the right to specify the manner in which the fee will be calculated, the terms on which you will be invoiced and charged and the terms of payment; and (ii) any and all fees payable by you pursuant to this Agreement are expressed exclusive of all taxes and duties, including Value Added Tax (”VAT”) or any similar applicable sales tax.

User generated content sites typically track user stats as a way of recognition, in lieu of compensation, for its top contributing members.  A cynical part of me thinks that this is exactly what Facebook is doing to application developers by displaying the Recently Popular and Most Users of applications.

Because again – and I return to my original question – what does it mean to have a Facebook user of your app?  As a publisher, you don’t get the registration data, your app may very well be neutered by Facebook restraints (as in the iLike app or any Flash based app), you can’t display user generated content published on your app without additional authorizations from the user, and the rules regarding revenue can change at any time. 

Is this a user?  Is it not a user?  Or is it something in between, like a qualified lead towards a user?

The only thing that you get for sure if your app takes off is some big branding, the opportunity (for now) to monetize on Facebook, and a hell of a lot of bandwidth costs.

Of course, there is a possibility that your app will be so well received and so indispensable to the Facebook community, that Facebook will buy you.

In fact, in order to keep the apps flowing and continue to provide upside for app developers, I would suggest to Facebook that they start buying some of the apps that do well on their site.  The possibility of an exit might be enough to for some companies / developers to gloss over the other uncertainties related to building for Facebook.

Undeniably, Facebook has built something special and is providing a unique opportunity for developers to integrate their applications in a huge, gorgeously architected, incredibly viral community.  The tough part is figuring out what this integration means in the development of a company, and how to prioritize the Facebook opportunity against other distribution opportunities that exist.

*Update* I just stumbled across a post from Andrew Chen where he asks the same question.

Comments

[Michael St. Hilaire]

I too have been watching the Facebook stuff pretty closely. I signed up for the ilike widget in Facebook as well and I thought iwas interesting my FB profile not linkable, or importable from my normal ilike profile.

I emailed their tech support on this, and they said they are working on it. I don't know if that was a blowoff, or if they really are trying to link the two profiles.

Seems like the only 'exportable property' you have to abide by is the user ID on the main site. I'm not a programmer, so I don't know what kind of limitations the FB API has on accessing external sites to get info about your normal user base, but I would think it would be possible.

We are looking into building a Facebook app, but it would be critical for us to be able to use the data we collect on FB as if it were entered directly into our site. I would not bother to spend the time building something that isn't convertable both ways.

We're about building ONE community of Fliva users, not about creating two separate communities, one for FB and one for everything elde.

[lawrence]

I like the way you put this:

"We're about building ONE community of Fliva users, not about creating two separate communities, one for FB and one for everything else."

I agree that this is a big deal, especially as monetization tends to happen back at home base for most distributed services.

I've never been good at reading legalese, and I'm still not clear if synching home bases with FB user bases is prohibited, or just technically challenging.

[Brian Chaikelson]

I agree, and find that too often, Facebook Platform Applications that have destination websites try to do too much within the foreign Facebook environment.

Instead of trying (and often failing) to replicate their feature-rich destination sites within a facebook "frame", they should simply take advantage of Facebook's viral distribution features and drive traffic back to their site through a "dashboard" styled application.

I might imagine a simple app with headings including "Content by your friends on our site" and "Most active friends" which link to the relevant page on the external site.

This benefits Facebook too since it becomes a hub for users to quickly access content by friends on their favorite websites. Facebook serves as a "social website aggregator", which brings users back more often.

More on this in a recent blog post: http://www.mishmap.com/2007/06/19/avoid-fancy-applications-with-the-facebook-platform/

[lawrence]

Nice point Brian. I'm curious as to what these FB app user to site user conversion / click stats look like for some of these leading apps that also have destination sites.