The tech trades are beginning to fill with treatises and musings on the topic of location data. From the emerging silos between location data providers to calls for an Open Database of Places, what’s clear is that making the mobile experience relevant for where a consumer is and when they are there is vastly more difficult than just getting a GPS fix from a phone.
Take for example the silos problem – in essence, the creation of walled location data-gardens with no interoperability across location-based services. “Why doesn’t Plancast know that I’ve been to Starbucks on Tripit…” and other more humorous views on the topic highlight the problems that result from attempting to aggregate different location-based services into a unified consumer experience in the physical world. While it should be simple, the many different ways of expressing places in the world make this a very complicated problem.
Reviews on Yelp!, rewards on Foursquare, business pages on Facebook and the folks I’m following on Twitter—all referring loosely to the same places (but with different ways of referring to those places)—should be brought together in a way that works seamlessly and is updated in real time on my phone… Yet a simple example from New York City highlights one of the many problems with location data and actually doing this: “1 Bryant Park”, “1095 Avenue of the Americas,” and “Aureole Restaurant – 135 W. 42nd Street” are all in the same building, but which one do I check-into? Alternatively, if Starbucks wants to attach a mobile coupon or offer to a store in this building, they need to associate it correctly with that store location, regardless of how it is referred to across many different applications (from Foursquare to Facebook), which may all have a different ways of identifying this particular location.
The oft-touted solution to this problem is the creation of a universal database of places to which all LBS companies can contribute. While this altruistic approach makes sense in theory, unfortunately location data is not like open-source software: not everyone participating in the location ecosystem will benefit. Smaller companies with unique location data do not get anything out of sharing it—and the ambition of some of the larger players in our space pushing their unique ID systems is an attempt at locking developers into their content so that we all have to work through them for monetization.
So until the ideal universal database emerges, Placecast has taken a different approach. We’ve opened access to our platform to share tools for cleaning and managing location data (which solve the 1 Bryant Park and Starbucks problems described above) through our free Placecast Developer Portal” MatchAPI solution. As part of MatchAPI, publishers and developers can share their location data with one another by simply matching their IDs—not giving away their unique content.
At the end of the day, what we should all be focused on is building great experiences and monetizing them—not hoarding location data. The way to achieve this is by reducing the friction that stands in the way of sharing location data, so that advertisers from large brands to neighborhood stores can deliver marketing to their customers on their phones. Sharing IDs is a simple first step.
For more interesting reading on this topic, check out:
Why check-ins and like buttons will change the local landscape by Tyler Bell
http://radar.oreilly.com/2010/05/check-ins-like-buttons-will-ch.html
Location 2012: Death Of The Information Silos by Robert Scoble in Techcrunch:
It’s Time For An Open Database Of Places by Erik Schoenfeld also in Techcrunch
http://techcrunch.com/2010/04/17/open-database-places/
Eddy’s Sofa And The Nightmare Of A Single Global Places Register posted by Gary Gale
http://opengeodata.org/eddys-sofa-and-the-nightmare-of-a-single-glob
