Entries Tagged 'geo' ↓

One of the most important developments of the web 2.0 era is the proliferation of full featured, bidirectional APIs.  APIs provide a way to “federate” web services from a single website to a distributed network of 3rd party sites. Another important web 2.0 development is the proliferation of web Apps (e.g. Facebook Apps). Apps provide a way to make websites “extensible.”

The next step in this evolution is to create web services that are both federated (APIs) and extensible (Apps).

In my ideal world, the social graph would not be controlled by a private company. That said, Facebook, to its credit, has aggressively promoted a fairly open API through Facebook Connect. Facebook has also been a leader in promoting Apps. For Facebook, creating extensible, federated services would mean providing a framework for Facebook Connect Apps – apps that extend Facebook functionality but reside on non-Facebook.com websites.

Consider the following scenario.  Imagine that in the future a geolocation data/algorithm provider like SimpleGeo takes Facebook Places check-in data and, using algorithms and non-Facebook data, produces new data sets, for example: map directions, venue recommendations, and location-based coupons. The combination of Facebook’s data (social graph and check-ins) and SimpleGeo data/algorithms would create much more advanced feature possibilities than either service acting alone.

With today’s APIs, if, say, Gowalla wanted to integrate Facebook plus SimpleGeo into their app*, they would basically have 3 choices:

1) Embed Facebook widgets in Gowalla.  These are simple iframes (effectively separate little websites) that don’t interact with SimpleGeo.  Gowalla would just have to sit and wait and hope that Facebook decided to bake in SimpleGeo-like functionality.

2) Pre-import SimpleGeo data. This significantly limits the size and dynamism of the SimpleGeo data sets and doesn’t incorporate SimpleGeo algorithms, thus severely limiting functionality.

3) Host an instance of SimpleGeo’s servers internally.  This requires heavy technical integration, undermining the main benefit of APIs.

In a world of extensible APIs (or “API Apps”), Gowalla could instead send Facebook data back to SimpleGeo.  The data flow would look something like this:

(Note how there are three parties involved – @peretti calls this a “data threesome”). This configuration is much simpler to integrate – and potentially much more powerful and dynamic – than the other configurations listed above.  You could implement this today, but it would create user experience challenges.  For example, Gowalla would be sending Facebook data to a 3rd party (step 3), which might (depending on the data sent) require explicit user opt-in. Things become more onerous if SimpleGeo wanted to share its own user data with Gowalla. That would require an additional oAuth to SimpleGeo (authorizing step 4).

Allowing websites to be federated and extensible will open up a whole new wave of innovation.  Ideally some spec like oAuth could include the multiple authorizations in a single authorization screen.  Facebook could also do this by allowing 3rd parties to be part of the Facebook Connect authorization process.  Inasmuch as Facebook’s seems to be trying to embed their social graph as deeply as possible into the core experiences of other websites, allowing extensible APIs would seem to be a smart move.

* I have no connection to any of these companies (Facebook, Gowalla, SimpleGeo) and have no knowledge of their product plans beyond their public websites.  I am imagining functionality that Gowalla and SimpleGeo might include someday but for all I know they have no interest in these features – I just picked them somewhat arbitrarily as examples.

A huge challenge for user-generated websites is overcoming the chicken-and-egg problem: attracting users and contributors when you are starting with zero content. One way to approach this challenge is to use what Geoffrey Moore calls the bowling pin strategy: find a niche where the chicken-and-egg problem is more easily overcome and then find ways to hop from that niche to other niches and eventually to the broader market.

Facebook executed the bowling pin strategy brilliantly by starting at Harvard and then spreading out to other colleges and eventually the general public.  If Facebook started out with, say, 1000 users spread randomly across the world, it wouldn’t have been very useful to anyone.  But having the first 1000 users at Harvard made it extremely useful to Harvard students.  Those students in turn had friends at other colleges, allowing Facebook to hop from one school to another.

Yelp also used a bowling pin strategy by focusing first on getting critical mass in one location – San Francisco – and then expanding out from there.  They also focused on activities that (at the time) social networking users favored: dining out, clubbing and shopping. Contrast this to their direct competitors that were started around the same time, were equally well funded, yet have been far less successful.

How do you identify a good initial niche?  First, it has to be a true community – people who have shared interests and frequently interact with one another.  They should also have a particularly strong need for your product to be willing to put up with an initial lack of content. Stack Overflow chose programmers as their first niche, presumably because that’s a community where the Stack Overflow founders were influential and where the competing websites weren’t satisfying demand. Quora chose technology investors and entrepreneurs, presumably also because that’s where the founders were influential and well connected. Both of these niches tend to be very active online and are likely to have have many other interests, hence the spillover potential into other niches is high. (Stack Overflow’s cooking site is growing nicely – many of the initial users are programmers who crossed over).

Location based services like Foursquare started out focused primarily on dense cities like New York City where users are more likely to serendipitously bump into friends or use tips to discover new things. Facebook has such massive scale that it is able to roll out its LBS product (Places) to 500M users at once and not bother with a niche strategy.  Presumably certain groups are more likely to use Facebook check-ins than others, but with Facebook’s scale they can let the users figure this out instead of having to plan it deliberately. That said, history suggests that big companies who rely on this “carpet bombing strategy” are often upended by focused startups who take over one niche at a time.

Significant new technologies often emerge as “stacks.” You can look at stacks through a technological (e.g. OSI stack) or business lens. Here I am using a business lens, thus dividing layers by function and including things that aren’t technologies but have economic value, e.g. relationships with customers and users.

Normally stacks are constructed from the bottom up and some layers turn out to be valuable and others do not (Christensen argues compellingly that stacks tend to alternate between commodity and non-commodity layers).

The PC is a famous stack.  In the 80’s and 90’s the most valuable layers were the processor (Intel won), OS (Microsoft won), and applications (Microsoft mostly won with Office). Assembly of desktops became a commodity which Dell exploited (you can still make profits on commodity layers, you just need to take a low-cost strategy). The PC demonstrates how hard it is to predict which layers will become valuable: otherwise IBM would never have allowed Microsoft to own the OS.

The internet is another famous stack. In the 90’s a ton of investment went into the infrastructure layer – switches, fiber, CDNs etc. Innovation on that layer continues (particularly in wireless), but mostly the action has moved up the stack to web apps.

An interesting new, emerging stack is the “geo stack.”  The first layer is latitude/longitude location detection. This is mainly provided by satellites and GPS chips which seem to be getting so affordable they will be in every mobile device soon.

The next layer is connecting lat/long to human-understandable locations. Google Maps, NAVTEQ etc. do this by connecting lat/long to roads. Location-based apps like Foursquare, Gowalla, and Yelp do this by connecting lat/long to “venues.” It seems Gowalla is building their own venue database.  I assume Yelp has built their own.  I don’t know how Foursquare gets theirs. I suspect venue databases will become mostly a commodity as they are fairly inexpensive to build and once built mostly interchangeable.

The next layer is the relationship with the user, particularly getting a user’s permission to track her location.  Apps like Foursquare require explicit check-ins at each venue. Other apps like Loopt automatically check in for you. Building this trust relationship with users could be very valuable.

The next layer is what I’ll call “recommendations”:  giving useful advice to users based on their location.  Maps do this by providing driving direction, traffic info etc. Foursquare is doing this with “tips.” I think recommendations will be critical for geo apps to appeal to Normals.  Geo apps are currently wooing early adopters with badges, games, and the idea that you might have a serendipitous meeting with your friends at a bar.  I suspect these incentives won’t work for the broader population, but recommendations could.  Recommendation data is hard to build and vast, hence could be a very valuable layer. (I am biased here as Hunch is working on this layer).

Social graphs could be a geo layer. It’s rumored that Facebook will be adding venue check ins soon.  Facebook has by far the largest (opt in) social graph.  As the recent Google Buzz debacle demonstrated, it’s not obvious that the people you email with are the same as the people you friend on Facebook.  Perhaps the people you want to share your location with are different than the people you friend on Facebook. If so, there could emerge valuable geo-specific social graphs.

Finally, monetization could be a very valuable layer.  There are (at least) two parts to monetizing location. Getting local businesses to embrace the internet has been very slow going. Companies that make money on local businesses today (Yelp, Yext, ReachLocal) use expensive outbound calling and other “push” techniques to sign up local businesses. There remains a huge opportunity to supplant the yellow pages as the default advertising platform in local business owners’ minds. If apps like Foursquare can build up enough marketing / PR momentum that every restaurant, dry cleaner etc feels like they need to “get on Foursquare” this could finally open the floodgates for local business advertising.

The second part of monetizing location is facilitating and tracking offline purchases. 90%+ of purchases are still offline, although for many of those transactions people do research and make their decisions online. The internet doesn’t get paid for these transactions.  Companies like Milo (disclosure: I’m an investor) are doing interesting things in this space and I expect we’ll see a lot more activity on this layer soon.