apps

Search, discovery and marketing

 

"However vast any person’s basic reading may be, there still remain an enormous number of fundamental works that he has not read"

Italo Calvino

Erasmus is said to have been the last person in Europe to have read everything. He lived just at the point that printing took off, and so it was in his lifetime that it ceased actually to be possible to have read everything. Some time later there was presumably also a last person to have heard of every book, or every book worth reading - in the 18th century, perhaps. Then, sometime in the past few decades, it also became impossible to have heard every good song. It is still possible, just, to see every good film, but the so-called 'golden age of television' means it's harder and harder to watch all the great shows. 

This is not a problem of search or availability, but a problem of too much availability, and of course the internet magnifies this a thousand-fold. Paradoxically, the internet makes it possible to get anything you've ever heard of but also makes it definitively impossible to have heard of everything. It allows anyone to be heard, but how do people hear of you?

The first attempt online was Yahoo's directory - an editorial home-page and a directory of every single website, organized by category. This sounds like a joke now - "there was a website that listed every single website that there was". Yahoo actually worked pretty well when there were 20,000 websites, just as a book shop with 20,000 titles works pretty well. But the Yahoo directory peaked at 3.2m sites and at that that point it definitely didn't work - you can't possibly scroll past that many entries (though it lingered on in a half-life until Marissa Mayer shut it down this year). And in the meantime, Google invented PageRank, coming at the problem from an entirely different direction. Suddenly, search worked, and that seemed like the answer. 

Today, app stores look a lot like the Yahoo of 20 years ago, and they don't work for the same reasons - you can browse 20,000 apps but not a million. Hierarchical directories don't scale. And so while it's easy to make a list of things that Apple and Google should fix on their app stores, that misses the point - it's like making a list of ways that the Yahoo home page should have been better. You might have been right but the answer was still Google. (I suspect that the same applies, just a little, to the current moves towards app search and deep linking, incidentally. PageRank uses the signal of links between pages - the ability to link of itself is only half the picture.) This is one reason mobile messaging apps are so hot - because they might become acquisition and discovery channels. 

However, I think our preoccupation with the problems of apps and app stores and with the ways that they broke Google masks a deeper issue - that Google didn't really solve the problem either. Or rather, it moved the problem. Google is very good at giving you what you're looking for, but no good at all at telling you what you want to find, let alone things you didn't know you wanted. Like Amazon, it's essentially a passive product (which is why Now is so interesting). It relies on waiting for you to find out what you want somewhere else, in some other way, and then it gives it to you. No-one complains that ‘I put my book on Amazon and no-one can discover it there’, but that’s really no different to saying ‘I put my app in the app store and no-one can discover it there’, or indeed 'I made a web page and no-one came'. 

So Google moved the problem from 'I want to find this and can't' to 'yes, but what do I want to find?' That is, 'What should read next?', 'what lamp would I like?' or 'where should we go on holiday next weekend?' are not valid search queries. And that's just for problems you know you have - the most interesting businesses are often things you'd never given any thought to. What search would you do that would tell you about Lyft, Instacart, Pinterest, AirBnB or Evernote if you had no idea that they existed?  (This prompts the question, indeed, of what didn't or couldn't work before 2007 because search was the dominant model.)

One of the clearest places to see this problem of ‘too much’ is Yelp. I’ve been fascinated by how many companies are effectively trying to unbundle Yelp, despite that fact that (unlike Craigslist) it’s a modern technology company that does most of the things one would expect it to. But where people unbundling Craigslist generally try to peel off a category and deliver a modern experience, the people going after restaurant listings are often doing so with constraint. That is, instead of giving you every single restaurant that’s within 2 miles and that lots of people liked, they give you 10 restaurants. YPlan gives you one, and just one, thing to do tonight. People are attacking crowdsourced universal scale with constraint, curation and personal preference. 

Looking at these companies, it strikes me that actually, saying that ‘Yahoo’s directory didn’t scale’ misses the point. What we’re really seeing is a trade-off between two problems. You can have a list, solving discovery and recommendation, but once the domain gets big then your list is either unusably long or partial and incomplete (and perhaps uneconomic to maintain). Or you can have a searchable index of everything but you’re on your own working what’s good and finding things you didn't know to search for. Time Out is an interesting attempt to sit in the middle of that scale - enough coverage to be quasi-universal, and to promise something good nearby wherever you are, but also enough curation that you don’t just get 5,000 listings all with five stars.  ProductHunt is an attempt to use community to surface quality at scale, as is Pinterest (both are a16z investments). In contrast, Canopy uses hand-curated selections on Amazon. The question for all of these: do you filter crowdsourcing down enough to get quality, or scale up editorial to get coverage, or you give up on coverage and do a purely curated product? 

One answer is that the machine will scale to solve the problem - you aggregate the opinions of the many (Yelp), or data about your purchases (Amazon) or perhaps you yourself (Google Now). Amazon’s failure to do this reliably makes me hesitate (one suggestion it gave me is above - I collect these), but more deeply, there are some questions, again, that just do not make good text search queries. I can ask Amazon for Owen Hatherley’s new book on Communist architecture and it’ll find it, and Google will give me reviews. But if I ask them “what should I read next?” then you quickly fall into the uncanny valley between data mining and the 'real', HAL 9000 AI that we don't actually have yet. That is, a machine can learn that I like architecture and history books, but that’s not the same as knowing that I will buy Owen Hatherley’s book but never Jacqueline Yallop’s book on Victorian utopian model villages, and we're not quite there yet. 

You can also see this challenge right now in both books and fashion. Amazon, after 20 years of ruthless execution, still only has under a third of the entire print books market. Most people buy most of their books in physical retail, because book shops are not just relatively inefficient end-points to a physical logistics network, but also filters and recommendation platforms. They’re high-latency but also high-bandwidth. Fashion, meanwhile, is going online very fast, but not through Amazon. Rather, dozens of companies are circling around the right models or recommendation, curation and discovery.

So, perhaps, a split might be:

  1. There is giving you what you already know you want (Amazon, Google),
  2. There is working out what you want (Amazon and Google's aspiration),
  3. And then there is suggesting what you might want (Heywood Hill). 

Perhaps this is just the next step in retail. Amazon let people in one-bar towns buy products that could only previously be had in big cities, but it doesn't let you shop the way people can shop in big cities - once you understand that physical logistics is a very small part of what shopping means (this can be hard to spot if you've only ever lived in the suburbs of the South Bay). Buying and shopping are not the same thing. That's what the new generation of internet retailers are trying to do - to scale curation instead of catalogues. 

This is also, very obviously, what Apple News and Apple Music are trying to do. Each of them approaches a data set in which the default answer is a million options and a search box. Each asks the question: "how do we take a commodity in a database (web pages, music tracks) and layer curation and recommendation in ways that are more usable and friendly than just giving people a search box and pushing them out of the door?" It's not as though this is a solved problem anywhere else. RSS (which actually powers Apple news) failed as a consumer technology  and following a magazine or musician on Facebook means you won't see more than one in ten of their posts (and I don't choose my friends for their taste in music, or book reviews). And you can't Google for 'what do I read next? I hesitate to declare that this can't work. 

Another strand here, which really does take us back to the beginning, is that I always thought the most useful part of Flipboard (now the last man standing of all the iPad news aggregators that followed the iPad launch, and superficially similar to Apple News) is not any of the formatting or design but the built-in directory of sites. If you want to see 15 sites about basketball, or typography, or hats or makeup, where would you find such a list? Yahoo did that once, and so did link rolls and web rings or, in another way, del.icio.us. (It's funny how many people keep trying to rebuild Yahoo - it didn't work out that well for Yahoo itself). Tumblr today provides one route into this, if you invest the time in surfing the topics, as does Pinterest. But you don't get that from Facebook or Google. 

Of course, once you give up on a universal search and a universal store - that is, Google and Amazon - as the only answer, then you've moved the problem again. There's an old Soviet joke that a man walks into a shop and asks “You don’t have any fish, do you?" And the shopkeeper says “No, we’re a butcher - we don’t have any meat. The shop next door is a fishmonger - they don’t have any fish”. So: where do you want to be hard to find? Do you want to be one of a million listings in Google or the app stores, or do you want to be one of ten or 100 listings in a carefully curated selection - but where that selection is one of a million listings in Google or the app store? 

All of this takes us to marketing. I sometimes tease my Xoogler colleagues by suggesting that if PageRank Really Worked, SEM wouldn't exist - if the links were always the right answer then no-one would click on search advertising. (Larry Page is fond of asking challenging questions, but that might be one step too far.)  Until then, though some companies can make it entirely through organic search or Facebook virality, most cannot. (Indeed, very often the mere fact that you've made these channels work for acquisition means they stop working, since your link advantage gets arbitraged away by imitators or Facebook decides you're taking just a little too much of the newsfeed.) For the rest of us, that means marketing. In effect, by removing all other constraints, the internet makes advertising more important than ever. 

The (lack of) app store metrics

Apple and Google both give headline statistics of how well their respective app stores are doing, generally at their summer developer conferences. These are rounded numbers at scheduled events and they're not always comparable, but they do give us a sense of what's going on.  

Last summer, at their developer events, both Apple and Google gave numbers for the money they had paid to developers in their respective app stores: $5bn in the previous 12 months for Google Play and $10bn for the iOS App Store. Given Android has double the user base of iOS, this meant that the average iOS user was worth around 4x the average Android user in app store revenue. 

This year Apple gave the same number - $10bn (more precisely, it gave a cumulative figure of $30bn this WWDC versus $20bn last WWDC). The lack of growth may be partly due to rounding but still implies that people are spending less on average, since the user base is still growing.  Google gave no number at Google IO but it gave one earlier in the year of $7bn. It looks as through Play is growing faster than iOS and might overtake it this year (unless Apple is rounding down very aggressively - certainly the uneven shape of the graph in 2013 is due to rounding).  

Screen Shot 2015-06-13 at 11.47.31 PM.png

Since Google Android has close to double the number of users, this implies that the average user is spending perhaps half as much as the average iOS user - a change from 1/4 a year ago but still a big gap. 

Meanwhile, this was the first year since 2013 that we could compare downloads.

Google Play had 50bn app downloads in the last 12 months and iOS had 25bn, with Play appearing to be growing faster. Since, again, Play has more users, this implies roughly the same downloads per user on Android and iOS. 

Incidentally, these numbers show annualized consumer spending on apps of around $25bn, and 75bn apps downloaded in the last 12 months. 

The future is mobile and apps, except that it isn't.

There are two charts that capture a lot of the way we think about mobile today. In the first, we see that mobile devices are approaching a majority of traffic, and in the second, that a large proportion of all web traffic (a majority in the USA in this instance) and the vast majority of mobile traffic is coming from apps rather than the web. 

However, if you're not careful you can get quite the wrong impression from these. 

First, look at where people actually use their devices. 

This is a picture that you see in all the relevant data (use of cellular versus wifi data, for example) - most use of 'mobile' devices happens at home or at work, or sitting down in a coffee shop - at any rate, not just while you're walking down the street or queueing at a shop. People use their mobile devices everywhere, and mostly, that actually means when they're sitting down. The fact that the IBM data above, like much 'mobile' data, actually includes tablets, is something of a clue - people obviously use tablets sitting down. But that's true of smartphones too. 

When we talk about designing for mobile use, we tend to talk in terms of building experiences that people can see in brief moments while they glance at their phone, because they're queuing or walking or waiting for a lift or whatever. By extension, that means that 'mobile' can - no, should - be a subset of the full experience. But actually, people do do that but they also, increasingly, spend half an hour burrowing though the web or into an app, while they're sitting at home, even with a laptop in reach. So the mobile experience needs to be complete. That might, paradoxically, mean that your total experience might need to be edited, to fit, but it's dangerous to pick a subset of your offer and put just that on mobile - it might be your only touch point. Conversely, one could argue that in some cases it's the desktop experience that should be a subset of the mobile one. 

Second, about that app share of use. The great majority of app use is of course Facebook and YouTube, and in fact, app use of the internet overall is highly concentrated into a relatively small number of highly successful apps. If one looks at how people use the web on the desktop, though, you see something very similar. Most people have perhaps 10 or 20 web sites that they visit regularly in a conscious, directed way - they type the URL or click a bookmark or (most likely) search for the service name. Everything else they get to though social or search. And on mobile, most people, again, have perhaps 10 or 20 services that they use regularly - except that on a smartphone those are apps. And everything else they get to through search or social - except that social happens as a web view inside the Facebook or Twitter app and so counts as 'app use' as well. 

That is, there's a very fat head to the distribution of use on both mobile and desktop, and on mobile that goes to apps while on the desktop it generally remains within the web browser. Apps unbundle the top services into their own apps. But the dynamic for everything else has changed less - it's still on the web, mostly. As I wrote here, if people have a relationship with your service such that they'll want to put your icon on the home screen - if they'll make a conscious choice to go to you - then you should have an app as well as a website. If you're in that category then everything has changed relative to the desktop internet. But if not, then the web, search and social are still most of the story. Hence, one of the interesting trends at the moment is the attempt to bridge the web with native, non-web experiences. We see that with Google Now and Facebook Messenger (desktop sites where you place an order while signed into Facebook can send messages to you in Messenger) and with a lot of what Google is thinking with Chrome. That's not really here just yet, though. 

Apps versus the web

There's an involved, technical and (for people like me) fascinating conversation in tech about smartphone apps and the web - what can each do, how discovery works, how they interplay, what Google plans with Chrome, how watches affect things, whether the web will take over as the dominant form and so on. 

But for an actual brand, developer or publisher wondering if they should do an app or a website, I generally answer that the calculation is much simpler and less technical: 

Do people want to put your icon on their home screen? 

Do you have the kind of relationship, and proposition, that people will want to engage with  enough to put your icon on their phone? If the answer to this is 'yes', then you should have an app - if only because the app store is the way to do that that people understand, and they'll look for you in the app store. Once that app is there, you can leverage all the interesting and sophisticated things that you might do with it, or you might manage the flow of information just like your website, but the app has to be there.

If you don't have that relationship, then all the clever things you can imagine you could do with Apple or Google's new APIs are irrelevant and your strategy should focus on the web (and social). (By extension, of course, there are some people legitimately wondering if they should have their own website - should a plumber be on the web or in Yelp?)

Meanwhile, you should have a website that works well on mobile regardless of whether you also have an app, and that site should give your complete proposition, since that of course is where links from Google and Facebook will take people. Too many companies present the potential customer with a website that says 'screw you, install our app', and then an app store page that says 'screw you, install our app', and then a first-run screen that says 'screw you, create an account/sign in with Facebook'. You do have to earn an install, I think. 

In either of these cases - whether you have an app and a website or just a website, you should presume that your customers will engage with you only on mobile. A large proportion of smartphone use happens on wifi and either at home or at work - people use mobile to snack, yes, but they also use it to do almost anything they do on the desktop internet. So your mobile proposition should not start from thinking 'what would people want when they're mobile?, but rather on 'this customer may only see us on mobile, so how do we shape our proposition to reflect that?". Indeed, as I wrote here, it's not mobile that gets the cut-down, basic experience - it's the PC. 

Mobile first

We've always thought about the mobile internet as a limited thing compared to the desktop internet, because of the constraints of hardware and network. Today, obviously, those constraints are a lot less than they were in the featurephone world, but it can still feel natural to talk of the PC as the most fully-featured version of the internet, and mobile as the place where you have to make lots of allowances for limitations of various kinds, just as for a smart watch. We make things 'mobile-first' because that's where the time and attention is, because that's where the use is and because mobile phones are in everyone's pockets and PCs (even laptops) are chained to desks, but it's still somehow a place with limits relative to the desktop. 

I'd suggest that we should think about inverting this - it's actually the PC that has the limited, basic, cut-down version of the internet. 

First, for 20 years the internet, on a PC, essentially meant a web browser, mouse and keyboard. There were other things happening around the margins, such as Skype and Spotify (and, for some people, email apps), but the web model was dominant. On a smartphone this is clearly no longer the case (which is why I sometimes call smartphones post-Netscape and post-PageRank). The interaction model is much more complex and sophisticated, and it continues to change all the time - Now, iBeacons, notifications, deep links, Apple Pay and Touch ID, keyboards and extensions and so on keep adding to and changing the options. Some of these new capabilities can get added back onto the PC, but many cannot, or arrive much later. 

Second, a smartphone knows much more than a PC did. There's an old computer science saying that a computer should never ask you a question that it should be able to work out the answer to; a smartphone can work out much more. It can see who your friends are, where you spend your time, what photos you've taken, whether you're walking or running and what your credit card is. The sensors, APIs and data that are available (with permission - mostly) to a service you want to use on a smartphone are vastly greater than for a website isolated within a web browser on a PC. Each of those sensors and APIs creates a new business, or many new businesses, that could not exist on a PC. 

The earliest and most obvious expression of this is the explosion of mobile social apps, almost none of which would have worked on a PC, yet which flourish on a smartphone because, as I frequently point out, the smartphone itself is a social platform - every app can see your friend list, access your camera, send you notifications and sit on the home screen two taps away from any other screen on your phone, so the friction of adopting them and of using more than one at once falls away.

But actually, one could generalize this beyond social - the smartphone itself is an internet platform in a way that a PC was not. On a PC the web browser was the internet platform, but on a smartphone it's the entire device and the browser is turned from 'the internet' to one icon, just a phone calls turned from the purpose of the device to just one icon.

That means that instead of thinking about the constraints of mobile - of the things you can't do because the screen is smaller and there's no keyboard - we should rather think of the PC as having the basic, cut-down, limited version of the internet, because it only has the web. It's the mobile that has the whole internet. 

Messaging and mobile platforms

One of the fundamental things that smartphones changed about the internet is that the smartphone itself is a social platform:

  • Every app can access your address book, getting an instant social graph. The phone number in particular acts as a unique social identifier
  • They can access the photo library and camera directly (and location), making sharing easy 
  • Push notifications mean you don’t need people to keep checking your site (or open emails).  
  • Every app is just two taps away on the home screen, which makes switching services easier, and also drives a trend for focused, single-purpose apps over apps that do everything - it's easier to find a feature as an icon on your home screen than as an option in a sub-menu of the Facebook app

So joining a new service from a different company is much easier than it was on the desktop and, crucially, using more than one at a time is also much easier. People can swap apps in and out for different behaviours or content types or social groups, on top of that underlying platform, and they do it all the time. And so there has been an explosion of apps trying to take advantage of this. Facebook bought two of the biggest, Instagram and WhatsApp, but it can't buy them all. 

Looking at all of these apps, I think there are three threads that we can pull out:

  • More or less plain vanilla person-to-person text messaging, with extras like group chat, pictures, stickers and voice clips etc added on. The big global winner so far has clearly been WhatsApp, which dominates outside the USA and East Asia (and is doing 50% more message volume than the entire global SMS system), but Facebook Messenger is doing pretty well too, mostly in the USA. I'd expect relatively little new innovation to happen here now, and most of it to be in the next two categories:
  • New pieces of psychology - new behaviors or attitudes that an app can enable or ride on. Sitting on that underlying social platform, an app that finds one of these can go viral. Examples include Instagram, Snapchat, Yo, Yik Yak, Secret or Meerkat. The challenge for these is to find a behavior that's different and compelling enough to create that growth, but not weird or specific enough to be a gimmick or a fad and flame out, or at least to evolve beyond that specificity once the growth is there, which one could argue Snapchat is doing
  • Platforms - messaging apps that aim to broaden the UX beyond pure person-to-person messaging into a development environment. WeChat is the big example here, with 500m users, almost all in China, while Line in Japan and Kik in the USA are also significant. 

The potential to turn messaging into a platform is the Trojan Horse that drives a lot of the excitement in the sector. It's one thing to sell stickers and quite another to sell users: can you use social to spread content and acquire users, and to solve the problem of app installation? Can it become the third runtime and the third channel on the phone, after the web and native apps?

The first big success here has been WeChat, which has 500m MAUs, almost all in China. WeChat has built a messaging client that's also a development environment, using web views and APIs so you can build services within the app that can access location, identity, payment and other tools from within the app. You can send money, order a cab, book a restaurant or track and manage an ecommerce order, all within one social app. So, like the web, you don't need to install new apps to access these services, but, unlike the web, they can also use push and messaging and social to spread. This is Facebook's old desktop platform, more or less, but on mobile. 

The common criticism of this approach is that this is 'just a portal', and that integrating lots of different services into one app is doomed in the same way that Yahoo on the desktop was doomed to be replaced by more powerful and focused single-purpose products. The more subtle version of this is that WeChat only works in China because the market structure is different - no vertical category killers (Google, Facebook, Amazon) and instead parallel, horizontal competition by large competing companies. WeChat is providing the 'primitives' that you can't get elsewhere. This may be true - but it may also be that WeChat (and similar products such as Baidu Maps, which also has deep service integration) show us what the rest of the world might look like if the big portals had executed better. That is, is this what Yahoo would have achieved if it hadn't gone to sleep for a decade? *

A lot of people thought that Facebook would clone this, but it's actually done something quite different. Rather than trying to turn Messenger itself into a development environment, it's opened it up to become a channel for anything else on your phone and the web. This means that it's addressing both the platform thread and the viral apps thread outlined above, and that rather than WeChat, it's going after the iOS and Android notifications panel. 

First, if you have an idea for a great type of content for messaging - a new piece of psychology that might go viral - your iPhone or Android app can now insert that directly into a thread inside the Messenger app, and your app can be invoked directly from within the Messenger app. Messenger has a list of featured apps (with links out to the App Store or Google Play) and, crucially, each piece of content posted into a message thread comes with a link to install the app - a viral hook. Facebook has made an API for the 'sticker button', and turned it into an acquisition channel for third party apps, and is now letting the entire internet compete for that slot, with itself as gatekeeper.

 The WeChat model achieves some of this, avoiding the app installation problem itself by putting everything into web views within the WeChat app, but that puts a cap on how sophisticated you can get - it's hard to make video clips with web apps. Facebook is trying to square the circle - rich native code to make cool stuff, yet no need for an app installation for it to spread. 

This is a great jujitsu move, and very seductive. Facebook is trying to co-opt the next Snapchat. Yes, the smartphone is a social platform that makes it easy to use multiple social apps, but you still have to get someone over the hurdle of installing the app in the first place, and they have to get all of their friends to install it too so that they have someone to send to.  Facebook is trying to bypass that - you can drop your content straight into the existing Messenger install base (600m MAUs). Now just one person can get a cool app and send messages to their friends even if their friends don't have it, and if it's cool enough they can tap on the link and install it too.

So acquisition is much easier, but they're Facebook's users, and always will be. And since there will be dozens of apps fighting it out for that slot, Snapchat and any other new stand-alone network will be competing against all of those apps - against the whole app store. This means that Facebook is trying to reset some of the dynamics I described at that beginning of this piece - it's trying to avoid the 'whack-a-mole' problem of having to buy cool new messaging companies (Instagram, WhatsApp) by getting those communication forms to happen inside Messenger instead, using Facebook's own social graph instead of the phone's address book.  And as I said, this is seductive - Facebook removes a major barrier to growth, but owns your users and has a history of ruthlessness in dealing partners who build on its platforms. Join, get growth 'easily' and give Facebook control, or stay out and struggle for installs against Facebook and all its partners as well. 

The second part of the Messenger announcement is just as interesting - Facebook will also let websites send messages directly into Messenger, without having their own apps installed on your phone, if you logged into that website with Facebook when you placed the order. So you can order shoes and get a message in Messenger that they're out of stock and be offered an alternative. This is another attack on email (and Gmail) and another attempt to pull your communications and commerce into the Facebook data platform. And again, if you do this you get richer and more engaging communication with your users, and don't need them to install your app, but your access is entirely controlled by Facebook.  

If you take all of this together, it looks like Facebook is trying not to compete with other messaging apps but to relocate itself within the landscape of both messaging and the broader smartphone interaction model. Facebook Home tried to take over the home screen and lock screen - Messenger is trying to take over the notifications panel, by pulling those notifications inside its own app, and to co-opt large chunks of future communications developments on the phone.  

This makes perfect sense - notifications themselves are becoming that third runtime. That pull-down panel aggregates activity from everything on your phone, and Google and Apple have made notifications actionable and given them payloads. One can already look at an iPhone or Android phone's notification screen and ask - 'where's the algorithm filtering this?' And in a sense, the notification panel fills the 'cross platform compatibility' role that some people would like to see in messaging - all the notifications for all my messaging apps show up there. More and more, one's primary interaction with any app, social messaging or otherwise, is a little pop-up with a button or two. So shouldn't that get a native, messaging-focused UI? Instead of replacing stand-alone apps with light-weight versions built inside a messaging app, is it better for rich, actionable messages from native apps to be aggregated into a notification panel? Once you have that runtime, do you need an actual stand-alone app on the actual phone itself, or can you send those messages - really, little applets, down from the cloud? Do you turn apps into messages and notifications, or messages and notifications into apps?

Meanwhile, smart watches (to the extent that they take off) reinforce a model of atomic units of content with a handful of possible actions, and of glancing at a few key items rather than submerging yourself in a dedicated UI. So after unbundling sites from the web browser into apps, notifications take things further, unbundling each unit of content or action - each verb or noun - into a separate atom. So you can order a car with a flick of your wrist and a tap or two, instead of fishing your phone out of your pocket, unlocking it, loading an app and navigating the UI. 

This obviously leads one to ask what the platform owners themselves are doing. Should this be done by Facebook or the platform owners (the same question as for deep linking last year)? Do Apple or Google introduce an algorithmic filter to manage the flow in the system-wide notification panel, and does that compare to Facebook's lethal power over newsfeed partners? They're some of the way there. Both Apple and Google have perfectly solid mobile messaging apps that are not development platforms in their own right, and have done a lot of work on notifications in their smartphone OSs yet clearly have lots more to do. And Apple already lets websites send push notifications on OS X, while Google is clearly pushing Chrome hard as a development environment and so notifications from the web there would also make sense. 

So we can see some building blocks, but we can also see obstacles. The obvious one is that neither has the kind of desktop social presence that would make it easy for them to drive personalized push motivations for web to mobile - you're not logged into anything from Apple or Google (pace Plus) when you shop on the desktop web. On the other hand, you're always logged in on Android, and Apple has shown plenty of hints that it might see TouchID as a universal identity platform, and of course, they do have your address book. So Apple or Google could easily let an app send a push notification to a friend who doesn't have that app. Meanwhile as mobile devices zoom past half of time spent on commerce sites and a third of the transaction value, a web identity platform might matter less. There are other interesting possibilities too, if one thinks where Now or Passbook might fit. 

The core issue across all of this, I think, is how much is still totally unsettled. We spent 20 years in which the mainstream internet experience was a web browser, mouse and keyboard, and over a decade in which Google was the way you navigated. Smartphones ended all that, but we haven't settled on a new model, and the idea we'll all revert back to the comfortable, simple model of the web seems increasingly remote. Even within messaging, the  model is still in flux. I wrote above about the search for new psychologies, but there are deeper architectural questions than anonymity or filters, which you can see in SnapChat's disappearing messages or Meerkat and Periscope's use of live. What will the next blow-up model be -  synchronous or not? One to one or one to many? Feed based or thread-based? Algorithmic filter or endless stream? Rich client or rich message? Runtime or deep links? That may be the real problem for Facebook - the next messaging thing may not be messaging at all. 

 

* As an aside, it's challenging for anyone outside China to have a firm view on WeChat given that almost no-one has actually used it - the most interesting features only appear if you run the app with Chinese language settings. I don’t read Chinese myself, and I’m always reluctant to have a strong view on a product I’ve not used, though this is a minority position.

App unbundling, search and discovery

"There’s only two ways I know of to make money: bundling and unbundling."

-Jim Barksdale

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? 

App store revenue

App store revenue is not an ideal way to scope the value of an ecosystem to developers. The majority of the revenue comes from games, mostly freemium using IAP, while a large proportion of the most valuable apps are offered for free and generate revenue through other means (Facebook or Amazon, for example).

However, it does give a pretty good proxy for the broader behavior of the users, and it also of course is very relevant for developers who do want to to charge. 

For the first time, Google gave numbers for app store developer revenue at IO this year, and in the latest quarterly results Apple gave (almost) like-for-like numbers: 

  • Google said it paid out $5bn to developers from Google IO in 2013 to Google IO in 2014 (a little over 13 months)
  • Apple said it has paid out $20bn to developers in total by the end of the June 2014 quarter, and at WWDC June 2013 it gave a figure of $10bn paid to developers (at the June 2013 earnings call a month later it then said it had paid out $11bn). So in the last 12 months, it paid out roughly $10bn. 
  • Google also said at IO that it has 1bn 30-day active Android users - the degree of precision is not clear. The iOS number is fuzzier: trailing 24 months' sales would be a little under 500m, but extending that to a three year lifespan would take it to over 600m. 

Obviously all of these numbers are rounded and were given at scheduled events, so need to be taken as imprecise. The fact that four different growth rates are involved also makes calculating ARPUs a little tricky.

That said:

  • In the last 12 months, on public numbers, Google has paid out roughly half of Apple - $5bn versus $10bn, on roughly double the number of devices. 
  • On a run-rate basis, annual gross app store revenue across iOS and Android is now $21bn. 

The chart below shows the public data points. 

The problem with this, of course, is that with only two data points from Google, we don't know the trajectory - if this is a steep curve the recent period might be pointing more sharply upwards. 

A further observation: if the current market dynamics remain, Google Android's user base will at least double in the next few years - the iPhone base is still growing, but it will probably not double. However, those users will be gained at progressively lower (much lower) device price points, and with significantly lower spending profiles. 

For more discussion of why the two platforms look different, see this post. 

Finally, just to make life easier, Play is not the only payment system you can use on Android, even Google Android. A material number of apps, mainly games and mainly in emerging markets, use other payment methods. So that number might really be somewhat higher.