App unbundling, search and discovery
There’s been a pretty clear story for the past couple of years that the dynamics of smartphone interfaces drive unbundling of services.
The main reason is that single-purpose applications have an advantage on smartphone interfaces. On a desktop website, you could always add a feature as a new tab on your site navigation, and clicking that was easier than going to another web site. But on mobile, all apps are just two taps away, while there is very little room for links to more features in any given app’s home screen – they quickly get shoved into the ‘hamburger’ menu, and soon after fall into the ‘hamburger basement’, down below the bottom of the screen. This gives startups scope to unbundle features from larger companies’ products, and also means those companies themselves unbundle their apps into separate single-function apps.
This effect is even stronger for social applications, where a lot of the unbundling conversation focuses, since the smartphone is itself a social platform quite unlike a desktop web browser. All apps can access the address book, giving them a ready-made social graph, and the photo library, reducing the hassle of uploading to different sites, and push notifications, removing the hassle of checking lots of different sites. This is why we have dozens of social apps that have passed the 1m, 10m or even 100m user milestone.
Finally, of course, driven by all of these dynamics, all smartphone apps by their nature unbundle services from the web browser itself, 20 year after Netscape launched.
All of this seems inevitable and inherent in the nature of the platform. It’s the reason why Facebook has moved from a de facto monopoly of social on the desktop to being merely the leader on mobile, buying the occasional breakout unbundler while experimenting with its own suite (‘constellation’) of different apps searching for new use cases
However, looking at the Chinese internet market is always a great way to challenge your belief in what’s inevitable, and in this case both Baidu Maps and WeChat, amongst others, are thriving on exactly the opposite approach – bundling multiple services into one app. (WeChat and Baidu Maps are a bit different, so I’ll focus on Baidu)
Hence, in Baidu Maps you can not just find a restaurant but book a table or order home-delivery. You can find where a film is showing and choose a seat. You can order a cab, with cabs from all the services in your city shown together on the map and the order going to be best offer. You can book a hotel room or a cleaner. Most of of these services are provided through embedded third-parties – Baidu is doing deals with other Chinese internet companies to provide this. WeChat (which now has close to 400m MAUs), is doing much the same, but of course starting from a chat experience rather than a maps experience.
In both cases, the aggregations make a fair amount of sense on their own terms – finding a cinema, taxi or restaurant are location-based activities and they’re also social activities. But the functionality is being flipped upside-down: in the USA a taxi app or a restaurant app will have an embedded map, but in China the map has embedded restaurants and taxis – and lots of other things. Equally, on Yelp you can message friends, but in WeChat you’re already in the messaging app.
This changes the layer of aggregation. By default, the iOS and Android interfaces aggregate at the app launcher level – you have a screen of different icons for different services, though to some extent notifications are becoming another OS-level aggregation. Anything that hasn’t been unbundled from the web is in the browser, where it is in turn aggregated by Google. Apps like WeChat and Baidu Maps move the service aggregation layer up the stack from the home screen, bundling it within a single app. Conversely Siri and Google Now (and arguably Microsoft’s Live tiles) are in different ways about moving it down the stack into an OS-level service. But the interesting thing is that changing the aggregation model also enables new types of discovery.
In the app launcher layer, any direct service discovery (as opposed to marketing, word of mouth etc) is limited to the app stores. When they launched this worked adequately, but with over 1m apps in each of the iOS and Android app stores this model is clearly now broken. Just as Yahoo’s hierarchical directory didn’t really scale after 1996 or so, so too app stores have not scaled as a discovery platform. Further, though there are lots of ways that the execution of the app stores could be improved, this still ultimately boils down to saying ‘Yahoo’s home page should be better’ back in 1996. Indeed it should have been, but the answer was still PageRank. And we have no analogue of PageRank for mobile apps.
Google Now and Siri, moving down the stack, address discovery by removing the whole question of ‘which app/site/service addresses this need?’ Now tries to infer from your general activity what you might want to be told about, while Siri tries to use natural language to answer your question. Both are focused on an answer rather than a specific service – ‘sports scores’ rather than ‘ESPN’ (even if ESPN proves the actual answers). But the problem with both is that underlying answers are provisioned in an essentially manual process. Google Now, in particular, looks like Google’s most automatic and magical product, but in fact it’s all editorial. Someone has to decide that Now will support cricket, and then someone has to sit down and code the cricket module. And If no-one has done rugby yet, you won’t get rugby – Now can’t work out what rugby is from watching your web browsing. Siri has similar constraints: HAL 9000 didn’t have a list of things you could ask him. This does not scale to the whole internet.
The general issue here is that any aggregator of services that offers a set of essentially hand-crafted approaches will inevitably run out of room in the metaphorical hamburger menu, just as the app store home pages can only showcase a few dozen apps at once and Yahoo’s home page could only showcase a few dozen services. Or, indeed, Apple’s Sherlock ran out of tabs. This doesn’t scale to the internet. PageRank did and indeed the web did.
The Baidu Maps model addresses this problem by narrowing scope to a specific domain, location, such that the discovery (hopefully) flows out of a natural pre-existing context. You don’t need to know about restaurant booking services or download the app, but you also don’t need to know if Baidu Maps has an AI that can do restaurant bookings (as you would need to know that Siri connects to OpenTable): bookings are an organic extension of the context you’re already in. You’ll already be searching for restaurants on the map, but now ‘make a booking’ will appear.
That is, searches within maps are naturally constrained – there are only so many use cases (a dozen? two dozen?) where a service integration might make sense. So Baidu can make a maps app that’s an order of magnitude better because it contains within itself every possible maps-based use case, and nothing more. And those use cases can be hidden until you search – you don’t need to find space for a ‘cleaners’ button – you can just show that module when people do that search, as they will.
WeChat comes at this discovery issue from the other direction: the social foundation of the app means that services can come to you thRough friends or through subscriptions to channels, but the point is the same – you don’t need to find space on the screen for every single service for people to find them. For Facebook, the model would be to drive traffic out into stand-alone apps (or a web view), with the partnership being only an advertising one – for WeChat the dynamic is perhaps closer to the original Facebook platform on the desktop.
One way to look at this, I think, is that you trade app discovery challenges for feature discovery challenges. That is, in an app with only one or two features it’s easy to see what you can do, but hard to discover that app in the first place. Conversely in an app with hundreds of millions of users but also lots of integrated features, feature discovery becomes the challenge, and the opportunity.
Changing discovery is one thing, but the other interesting thing is how much happens inside the app. There are two structural things that the desktop web has that the mobile app ecosystem lacks. On the web:
- You can link to any resource
- That resource will be there – you don’t need to install anything.
These aggregator apps are tackling both problems: they have discovery models to allow you to get to the resource (e.g. social or local context), and the resources are loaded within the app – no need for a new app install. This isn’t happening on the web, as such, but it has some of the same dynamics – within, obviously, those limited domains.
It’s interesting to contrast this with the deep linking initiatives from Facebook and Google. Facebook offers a way to drive traffic to your app from social and Google from search, and Google is experimenting with, for example, a link to Uber from within Google Maps. The problem is that if the app isn’t there then you fail back to HTML, and if HTML was good enough then you wouldn’t have bothered deep linking in the first place. But on the other hand, you can’t integrate everything – we already have a way to do that. Hence, the Facebook and Google moves (and also Line’s) disaggregate apps, but use identity, deep links and search as an aggregation layer that is closer to the web and might be more scalable.
That is, you can bundle things into an app that has distribution, but there’s a limit to how many both for practical and discovery reasons. If you use context (maps, social) you can address the discovery problem but this works best in constrained contexts. If you don’t bundle, your features are easy to discover (because your app only has one feature) but you give up those opportunities for discovery and fall back on raw search, social sharing or the app stores.
And for all that we talk about the problems with apps and the lack of PageRank, one cannot really describe the desktop web as a prelapsarian paradise of simple and easy discovery. The web is a neutral, transparent and unmediated platform, and smartphones are not, but neither are Google or Facebook.
Hence, as Lenin put it, the question is ‘Who, whom?’ Who has the traffic, and to whom do they give it? Mobile shuffled the deck, but it doesn’t alter the problem.
The other interesting comparison here is with Yahoo and AOL. The portal model failed pretty comprehensively in the 2000s, with category killer sites springing up and AOL and Yahoo and the other would-be portals falling far behind. So when smartphone apps came along we already had a dominant unbounded model that transferred pretty directly: we unbundled services from the browser, but the services themselves were already unbundled from Yahoo.
In China, though, we see a model in which the portals didn’t disappear. For a lot of different reasons, the Chinese internet is based on much more horizontal than vertical competition: where we have vertical category killers (Google, Amazon, eBay) China has giants that are each leading in one category but strong in others, and competing aggressively with each other across every category. On mobile, Baidu Maps and WeChat are showing a systematic concept of the app as, well, a portal. Is this what Yahoo might look like on mobile now if it hadn’t spent a decade asleep?