Location-based check-in data on its way to becoming a commodity

Jeff Holden is cofounder and CEO of Pelago, maker of Whrrl. This post originally appeared on VentureBeat.com

Location-based “check-in” services like Foursquare, Gowalla, and my own service, Whrrl are becoming increasingly popular. These services allow mobile users to capture the places they visit in order to make their location visible to friends, to play location-based games (and earn badges or points) and to cash in special offers. While it’s still early days — Forrester recently published that only 4% of US adults have ever used a location-based mobile application — on the order of 20K users are joining just the top few services per day, with well over a million check-ins per day, and both figures are accelerating.

Just as Google Maps and similar apps have led to the commoditization of map technology, we’ll see check-in data eventually becoming a commodity as more and more such services arise and a couple of the big social network companies step in with open check-in platforms.

Future location-based startups won’t need to license their own global place listing data and build the technology to take a location fix and convert that in some fashion to a check-in. They’ll simply wire up to an API provided by Facebook, Twitter, Google or another platform provider to access that information. Such platforms are already starting to emerge, in fact, with Google’s and Facebook’s “Places” offerings. (One interesting question is whether some of the current location-based service players might get acquired by these platform companies as a part of this wave; there certainly has been no shortage of heat and noise there, but so far, no major player has been acquired. If such an acquisition does occur, I would expect the functionality to be integrated as an application standing on top of the platform rather than as the platform itself.)

In its most basic form (and I’ll stick primarily to place check-ins for the purposes of this discussion), check-ins would be supported by a simple cloud-based service that takes a location fix as input and provides a list of places as output along with a way for users to register a check-in at a specific place by a specific person. The service would, of course, include APIs for retrieving a person’s and place’s check-in state, adding new places to the database, and so on. This combination enables the most fundamental check-in capability while accruing all the data to the platform (which is clearly what the platform provider would want).

Things get quite interesting then, since such a platform could also offer syndicated and aggregated check-ins.

Syndicated check-ins would let a user check-in via one app and have that check-in propagate to a set of other apps, so that someone using, say, Whrrl to check in would automatically be checked-in also in Gowalla or Foursquare. Imagine that Facebook Connect offered new permissions: “Gowalla wants to access your real-time check-ins and your check-in history.”  (Some attempts have been made to offer services that syndicate check-ins, but they’ve been fatally flawed in that they’ve required the use of a new client that provided nothing more than basic check-in ability, and adoption of such clients has been negligible.)

Aggregated check-ins would provide an API to get at the anonymized aggregated check-in data (by place, time, demographic, etc) from all services publishing check-ins to the platform.

Obviously, with the appearance of an open check-in platform (or several), individual app companies won’t be competing anymore over the check-in experience itself (just like non-platform companies no longer compete on the basic map experience). A more interesting implication is that Facebook, Twitter and Google, as the platform providers, would likely pick off some key use cases to “own,” changing the competitive landscape for the social location-based app companies.

Let’s dig in a bit more.

Right now, we’re living through an acceleration of the check-in as a standard consumer behavior. Another way to think about this is that we’re transitioning from the unstructured status update to the structured status update. Rather than typing “I’m at Restaurant Zoe with Anne,” into a text box, Anne and I both check in to Restaurant Zoe. Similarly, if I’m currently watching “Inception,” I check into it rather than just typing it into a free-text box. Why does this matter?

Structured data opens up a whole new set of opportunities, because a single data element refers to a single real-world object. A trivial example is that you can see who is (and how many people are) checked into a particular place or movie or painting right now. But you can also ascribe semantics to structured data, like “this place is a movie theater” or “this film is in the sci-fi genre.” The result: structured data is far more useful for analysis than unstructured data. The reason Amazon.com can confidently say “people who bought item X also bought item Y” is because they have a catalog of structured items against which they capture transactions. In the case of place check-ins, this data is the real-world analog of a clickstream on the Web, which is a big deal.

Now, syndication and aggregation of this structured data has a big impact on the competitive playing field. For example, an application does not have to build up an aggregated database of check-ins itself. From its inception, it can leverage all the (anonymized) data from all the services for all of history, which kind of levels the playing field for certain use cases. Furthermore, with syndicated check-ins, an app can immediately get access to an individual user’s (non-anonymized) real-time and historical check-ins without the user ever having used that app to check in. (The user would need to authorize the syndication of his/her check-ins from other services to the new service, of course.) This would obviously help to address the check-in fatigue people are clamoring about today, but the combination of these pieces also enables powerful new use cases, like real-world personalized recommendations (serendipitous discovery), as I discussed in my talk at Where 2.0 in 2009.

All is not rosy, however. Some existing opportunities disappear in this new world. Why? Because the commoditizing here isn’t being driven by some benign standards-based organization. It’s being driven by Facebook, Twitter and Google, who (appropriately) have their own agendas with respect to check-ins. What that means is that along with the commoditized check-in capability will come a set of user-facing value propositions offered by the platform provider.

For example, given that Facebook popularized the unstructured status update, it would be extremely surprising if they did not aggressively pursue place-based friend finding (seeing where your friends are checked in). So, if you make a check-in product with friend-finding as a core value proposition, you’ll now be competing with Facebook on that front, probably at a significant disadvantage, since friend-finding is a network-effects-based use case and Facebook has the (vast) upper hand there. Facebook, of course, needs to resolve some privacy issues (for example, what if I don’t want to share my location data with my entire Facebook friend graph?), but they’re smart and issue-sensitized enough to sort that out quickly.

Ultimately, the commoditization of check-ins leads to a world in which the user experience becomes split in two: There will be a front-end experience, when the user is interacting with an app’s user interface directly on the phone, for example to actually check in — think of this as the “when they’re actually there” app — and a back-end experience, where the user’s data, probably from multiple services, is processed in a way that creates value and is presented via channels like the Web and email.

The battle for user “face time,” i.e., for the front-end experience, intensifies since there will be even more players in the space (lower barriers to entry created by the platform) and most of the user-visible value in social location-based apps today is demonstrated directly after the check-in. Earning points, leveling up, joining Societies, unlocking rewards, appearing on “the grid,” getting and creating recommendations and being presented with things from virtual items to venue-specific experiences to ads are all examples of post-check-in value. The applications that win at this face-time battle, which will be fought on a per-user basis, are the ones who’ll have the opportunity to provide these types of experiences and the monetization that follows.

The back-end battle is entirely new, and it will be much more exciting than it sounds based on the name. What is the user experience for product X if the user is not using X’s app to check in? It will come down to what value X can create based on the data, and a great example is personalized recommendations. Imagine a service that simply takes all your check-in data and the aggregate check-in data from all services and computes recommendations for you like “based on your visits to places A, B and C, you should try place D.”  That sort of service would not require you to be checking into it, but it would still offer a very compelling value proposition. Visualizations (heat maps, for example) and summaries/historical timelines of activity are other interesting examples here.

Of course, all of this is just my point of view, but I hope it sparks an interesting conversation. There’s a great deal to talk about.