The Challenges of Location-Based Social Networking

Meetro, the location-aware instant messaging application - and company - has failed (or as my entrepreneur friends often like to say in such cases, it has "run out of runway"). Peter sent me a link to an inspiring TechCrunch guest post by Paul Bragiel, Meetro's founder, in which Paul has courageously shared the lessons he and his colleagues learned from this effort. Having failed - or run out of runway - in my own startup a few years ago, I don't see failure as any kind of stigma, and am glad that Paul doesn't either.

As someone who has been working for many years on ways to effectively bridge the gaps between the richness of our online lives (including our online social networks) and the physical spaces we share with others, I am saddened by the demise of Meetro. Paul and I exchanged some emails shortly after I wrote a blog post about Meetro's proximity-based instant messaging application in June 2005. I was excited for him and his team when they moved from Chicago to Palo Alto shortly thereafter, as their prospects seemed bright. However, I was also concerned about whether Meetro would ultimately succeed where Trepia had failed.

Paul hits the nail on the head in identifying the location problem (or the problem of constructing bridges between physical spaces and online communities):

Most importantly, there was a “location problem”. It’s really hard to grow a product that’s 100% focused on where you physically are. Tons of companies have tried this before and most of them have died. We, of course, were cocky and had to give it a try. There was just something so sexy about the idea that you could load up a piece of software and it would tell you about someone nearby who was interesting to you. Someone will crack this and make billions of dollars on it. I can only hope to be involved in some shape or form, since it’s an itch that hasn’t gone away for me.

He goes on to propose some scenarios or trajectories in which location-based social networking applications might succeed:

• As extensions of existing social networks with large numbers of members (e.g., MySpace, Facebook), to help overcome what we might call the critical mass problem. The privacy issues in going physical (or locational) are significant, but as danah has previously pointed out, Facebook does not seem averse to taking risks with users' privacy.
• Extending the service city by city, as Yelp has done. However, Yelp has not gone physical (yet), and so can scale more easily as an online service (with physical world referents). I don't know how many users they have, but they still may be shy of the critical masses needed to succeed with a physical location-based component.

Paul highlights the download problem: any application that requires any kind of download in order to run (vs., say, simply allowing a user to visit a web site) has a huge initial - one might say "inertial" - barrier to entry. As he notes:

... the dropoff that happened once people had to download and install Meetro was HUGE and didn’t help us at all. If I recall, it was something in the 80 to 90% range. It crushed adoption rates.

The Nokia Sensor application, which uses Bluetooth to enable proximity-based social networking via mobile phones (and which has one of the coolest Flash-based use-case scenario depictions I've ever seen), also suffered from the download problem - exacerbated by the fact that far fewer people are (or were) willing to download applications onto their phones than onto their laptop or desktop computers. I read somewhere that the application had been downloaded a million times - I'm not sure how many users that represents, nor how many downloads resulted in successful installs.

However, there was a bigger problem: searching for references to Sensor on blogs, forums and other social media sites just before I interviewed with Nokia in the summer of 2006 revealed that most people who talked about using Sensor reported that they never "saw" anyone else running Sensor, other than friends they were already with.

This is an example of another challenge that Meetro encountered, what Paul calls the "realtime" problem: the requirement that users of the system (Meetro or Sensor) be in synchronous proximity of each other, i.e., in the same place at the same time. My friend and former intern, Sean Savage, attempted to address this problem with PlaceSite (which also now appears to be defunct), a place-based, vs. proximity-based, social networking application in which there was some notion of asynchrony - who has been here recently, in addition to who is here (or near) now? Apparently, Meetro [eventually] incorporated some kind of asynchrony into their app:

I can still feel the magic of when I was on layover in the Denver Airport, I met one of our users, and we grabbed a beer. This is what I dreamed Meetro would be about all the time, but those moments were too few and far between. We did fix this in the end but it was too little too late. So, to anyone tackling this problem in the future, make sure you have some type of persistence built-in, be it “people here previously” or “most common visitors to the area” etc.

Paul proposes three promising avenues for future location-based social networking applications:

• Wait until the mobile / wireless operators have solved the location problem ... but after my experience working with Nokia, I know that building upon a carrier solution would require that carriers open up their location capabilities ... which would require a shift of policy and perspective that would be far more significant than the technology shift (for many carriers)
• Create an API to enable the application to work off of / in conjunction with another, more broadly adopted application (like AIM or Skype).
• Create an application that allows you to explicitly "check-in" with your location, like Dodgeball or Swarm ... but the requirement of an explicit action (sending a text message), vs. simply showing up, and opening up your laptop or waking up your phone, undermines the more natural, or at least implicit, awareness and interaction envisioned by Meetro (and all of the proactive display applications in which I've been involved).

One of the things I didn't quite understand when I first blogged about Meetro was how they managed their location-awareness. I was particularly curious, as many of my former colleagues at Intel Research Seattle were working on the PlaceLab project, creating a WiFi-based, privacy-preserving, location-aware infrastructure to support [Meetro-like] applications ... with the idea that "if you build it [the infrastructure], they will come [applications and users]". Paul shared some details in his post (and, as I suspected, it was closely related to PlaceLab):

When you launched Meetro we would scan for all the WiFi networks out there. We would then crosscheck what was out there with what we had in a huge global database (it had grown to 4+ million hotspots when we stopped). If it was in the database, then we would do some trilateration to figure out where you were. If not, we would ask you to enter your location. We would save this info and use it later to crosscheck and verify it against similar data.

However, as is clear from the lessons shared by Paul, the technology itself - the application and the infrastructure it uses - is only part of the puzzle. A number of other elements have to align in order to build a successful location-based social networking application.

Like Paul, I still believe there is great promise in this area, and I am grateful for his sharing the wisdom he has gained in efforts to fulfill this promise!