Archive for March, 2010

Android Advances on iPhone

March 25th, 2010 4 comments

AdMob released it’s February 2010 Mobile Metrics Report.  In the two horse iPhone-Android race, Android has continued its growth to represent 32% of the AdMob ad requests.  As argued earlier (Android Catching iPhone), AdMob ad requests are a forward looking indicator of which OS platform is likely to be of the most interest to Entrepreneurs in the mobile sector.  It continues to look like the momentum is with Android.

Of February 2010 iPhone & Android AdMob ad requests, Android represented 32% of the total.


Mobile Apps vs Mobile Sites, Wired Internet Historical Analog

March 22nd, 2010 No comments

As noted in my last post, there is an interesting battle for developer and user mind share looming between mobile Apps and mobile Sites (mobile optimized web services that are accessed via a browser).  There may be something to learn from the recent comparable historical analog we have seen unfold in the wired PC Internet.

Remember that for the first 20-ish years of the PC industry, there were only applications.  Recall that Microsoft held a choke-point in the PC kingdom, and made a huge fraction of the profits in the PC application category.  Remember when no one would start, or fund, a PC application business because of Microsoft’s demonstrated ability to subsume that company’s application within some existing Microsoft application?  Recall how Microsoft, in their rush to catch and crush Netscape, installed the ubiquitous and essentially choke-point-free browser platform. (In an amusing bit of historical irony, this is strikingly similar to the rushed PC effort at IBM in the early 1980s, which installed Microsoft and Intel into controlling positions in the PC industry.)  That new, ubiquitous, and choke-point-free browser platform is what allowed the Internet to flourish.  Look at the companies/services that have arisen to date in the wired Internet, along a couple of key attributes.

Wired Internet, Sites & Apps Value Creation

One key take-away from the table above: while both Apps and Sites existed in the wired Internet, the overwhelming majority of value created in the wired Internet came from the Sites end of the Apps-to-Sites continuum (there is no really clean line between the two), and only a tiny fraction came from Internet connected Apps.  Where on the Apps-to-Sites continuum might we expect the bulk of the value creation to happen in the mobile Internet?  There seem to be four important differences between the wired and mobile Internet when addressing this question.

(1) OS Diversity.  In the wired Internet there were relatively few underlying operating systems that an application developer had to build to if they wanted 80% of all potential users to be able to use their application.  Even still, exploiting the installed base of browsers made for much more value creation for Sites over Apps in the wired Internet.  The OS diversity problem is at least an order of magnitude more difficult in the mobile world, and while there is likely to be a reduction in the number of mobile OS’s out there, each new release is another version to port/test for an App developer.  This would tip the scales even closer to the Sites end of the Apps-to-Sites value creation continuum.

(2) Hardware capability diversity. In the wired Internet, there were only modest differences in the functionality differences between PCs and only a limited amount of non-PC functionality got subsumed into the PC.  This led to a fairly uniform set of capabilities for the browser to support.  The mobile phone has been subsuming a lot of other functional bits for a long time now (see the figure below).  Sure, HTML5, plus something like PhoneGap, allows the browser to be a fairly ubiquitous pre-installed platform, but if one wants to take advantage of the cutting edge hardware capabilities, one almost always has to use native applications to do so.  This would tip the scales toward the Apps end of the Apps-to-Sties value creation continuum, especially for point offerings that took advantage of a specific hardware functionality; it would only be a small move along the continuum toward Apps for more offerings that weren’t tied to a specific hardware capability.

Where one needs access to specific hardware capabilities is one of the few situations where a mobile App-based approach should beat out a mobile Site-based approach.

(3) Browser Diversity. While HTLM5, plus something like PhoneGap, allows the browser to be a powerful pre-installed platform, it hasn’t happened yet, and the diversity of interests among the various handset vendors and mobile operators may prevent it from happening as quickly or as ubiquitously as we hope it will (especially without some impending disaster to force it to happen).  Recall that the early days of the wired Internet explosion had only a few versions of Netscape and Internet Explorer with the overwhelming majority of the market share.  You would have to make a long list of mobile browser releases to get to an equivalent market share in the mobile Internet.  And, the early wired Internet browsers were much simpler, which allowed for easy and fast development.  This would tip the scales noticeably to the Apps end of the Apps-to-Sites end of value creation continuum.

(4) Head start. Since the iPhone App Store launched in July of 2008, and Android and BlackBerry followed suit within a year, mobile Apps have become the key way that people think about the mobile Internet.  The existing App-oriented momentum and collective mindset can be a powerful thing–even though many of the “mobile Apps” out there are really just glorified bookmarks for mobile Sites.  The real question is whether or not the currently shipping smartphone browsers are “good enough” to meet the needs of the most popular offerings, and this is likely to vary by category of offering.  For example, for real time games, the need for taking advantage of the specific capabilities of each hardware platform would seem to indicate that the balance will be heavily tilted toward Apps.  But, for turn based games, which are much less likely to need to take advantage of hardware specific capabilities, Sites would seem to hold the advantage.  Generally, this would tip the scales noticeably to the Apps end of the Apps-to-Sites end of the value creation continuum.

Bottom Line.  From a value creation perspective, the wired Internet precedent is tipped massively toward the Sites end of the Apps-to-Sites continuum.  But, in the mobile Internet, there is tremendous momentum behind mobile Apps; for many categories of offerings, it will be necessary to use Apps to take full advantage of the hardware capabilities; and, the mobile Internet lacks the level of uniformity in browsers that the wired Internet enjoyed in its early days.  These lead one to believe that for certain categories of offerings (such as real time games, things needing to access/control the underlying hardware, etc.), the value creation will be moved very much toward the App end of the Apps-to-Sites continuum.  But, for all the other offerings, most of the value creation should still be on the Sites end of the Apps-to-Sites continuum.  And, since most companies are started by us Engineer-types, too many will believe that they really need to take advantage of the underlying hardware capabilities, and chose an App-based approach, when they would have been better served with a Site-based approach.


Mobile Apps vs Mobile Sites, The Looming Battle

March 21st, 2010 2 comments
Mobile Sites, Mobile Apps, Functionality & Reach

Mobile Apps and Mobile Sites trending toward similar Functionality and Handset Reach (adjusted by TAM).

In the midst of the explosive growth, tremendous success, and phenomenal media coverage of Mobile Apps, there is an alternate open delivery path that isn’t getting the attention that it probably deserves: web sites optimized for the mobile browser experience. For want of a better name, I’ll call these Mobile Sites. This looming Apps vs Sites battle for the mind share of developers and users will be one of the most interesting things to watch in the near term future of mobile.

Mobile Applications (downloaded from iPhone App Store, Android Market, BlackBerry App World, etc.) have the clear advantage in terms of functionality, but the relative differentiation versus Mobile Sites is diminishing over time. Mobile Sites have the clear advantage in terms of Handset Reach (adjusted to be % of Total Available Market for your mobile startup’s brainchild), but this differentiation relative to Mobile Apps is also diminishing over time.

More thoughts on the looming Mobile Apps vs Mobile Sites battle in subsequent posts.

Aside number one. It is important to adjust Handset Reach on the basis of market opportunity for your startup. Not all mobile subscribers are created equally. Don’t make the mistake of equating a $5/month ARPU pre-paid subscriber in a developing country with a $100/month ARPU post-paid smartphone subscriber in a developed country–the latter probably represents substantially more than 20X the monetization potential for your startup.

Aside number two. Note that Voice and SMS are the forgotten Universal Clients in mobile. As noted in Five Open Paths in Mobile, while circuit switched calls and good old text messages have limited functionality, they have tremendous reach and just about everyone with a mobile phone knows how to use them. If your business model requires ubiquity (eg, any model primarily dependent on viral user acquisition), these are tremendously attractive platforms to work on top of.


No Mobile Pay Per Call Advertising Cos?

March 11th, 2010 2 comments

Quick update to my Mobile Pay Per Call Advertising post.

Well, I’ve poked around a bit, but I can’t seem to find any mobile-only (or mobile-mostly, or mobile-more-than-just-a-little-bit) Pay Per Call Advertising companies.  It seems that the folks who enable this in the online world are paving their cow paths with mobile tweaks to their existing online offerings.  It doesn’t appear that anyone has come up with an approach that is inherently mobile.  If you know of one, please drop me a line.


“Failures” of the App Store

March 4th, 2010 No comments

Applications have been the biggest news in the mobile world for some time. It’s been a huge success for Apple, and are a core part of what made them the most profitable handset vendor in the world just a few years after entering the industry! But, there has been a lot of complaining about the ability of app makers to make money. The oft-cited issues include:

  • Difficulty of discovery.
  • Low, and declining average app prices.
  • Unwillingness of end users to pay (ie, they just want free apps).
  • Piracy of paid apps.
  • Copycat competitors.
  • Difficulty/Delay/Capriciousness of app development/approval process.

My overarching view is that apps have been made much more popular and successful than they would have otherwise been because of Apple’s tremendous facilitation of the ecosystem. But, let’s take each of issues listed above in turn.

Difficulty of discovery. Really? If you make a super duper awesome website, do you expect visitors to just come rushing in? Heck no. You’ve got have some means for folks to learn about your site; it’s got to compelling/sticky enough that you retain those users; it’s got to be a good enough user experience that folks are willing to say positive things about it to their friends; you might need to grease the wheels of that virality; and you might want to pay for some early traffic. Be thankful that the app stores provide both a search and directory/browse capability, which is comparable to what you might hope to have on the Internet for discovering your website. Just because you think your app is great, doesn’t mean the app store owes you a living.

Low and declining average app prices and lack of willingness for users to pay. Is it realistic to expect an up-front perpetual license model is going to be the best way to monetize a mobile application? Just because this approach is the one that Apple initially chose to enable (presumably because it is a direct analog of selling songs in iTunes), why would anyone think this is the best way to monetize an app? Think of how ludicrous this is using the Internet analog. Would you expect someone to pay up-front to access a site? Only in a very small set of cases. Or, think how difficult the up-front perpetual license model is from the perspective of the historical analog of selling a software package on retail shelves or in online stores. Only a small number of titles can be successful in those distribution channels with that monetization model, which requires the end user to know A PRIORI that they’ll like the product more than the cost of the product. This can only work with lots of Word of Mouth, the Nth chapter of a known series, or a lot of marketing spend. Admittedly, this is often the hardest question of creating a successful mobile business: what is the best means for monetizing it? Up-front perpetual license (games, and rarely anything else), in-app purchases (seems much more promising), advertising (need a TON of usage, a super-valuable audience, or some means by which the users reveal their buying intent through the normal use of the app), or “other” (lots of fail, a few great approaches).

Piracy of paid apps. This is a big problem, and it was seriously undercutting the ability of even the most popular paid apps to generate income. So, Apple addressed this with in-app purchasing, which makes piracy much more difficult to do. It also enables a whole new set of monetization approaches that seem much more promising than an up-front perpetual license.

Copycat competitors are the flip side of the ease/cheapness of creating mobile apps. There are only two solutions here. (1) Develop low volume apps that don’t ever generate enough attention that anyone bothers to copy them. That can be a great strategy for sole proprietor type developers, but it’s harder to see how this would work for a venture-backable scale of business. (2) Build barriers to entry for the inevitable copycat competitors. This is obviously easier said than done, and generally requires the barrier mechanism to be built into the business model.

Difficulty/Delay/Capriciousness of App development/approval process. Nothing is perfect. Sure, Apple injects more 3rd party process than putting up a website.  And, there is always the risk that Apple will decide to banish your category for some good or lame reason (R-rated content, geo calls used only for ads, using unsupported APIs to detect WiFi signals). But, when compared with deploying a mobile app through a mobile operator or through a handset vendor, or through a retail or online store, this is development and distribution nirvana. Apple has legitimate strategic reasons for wanting to control the apps that make it into the app store. If you want to do something Apple doesn’t allow, then deploy on Android; if your app becomes popular enough that it becomes a reason for people to jailbreak their iPhones, Apple will capitulate.


Mobile Pay Per Call Advertising

March 1st, 2010 No comments

MobileRinging PhoneI’ve become interested in mobile pay per call advertising, based on a couple of simple high level observations:

  1. Many types of businesses are naturally phone-based in their new business generation process.  Think pizza shops, plumbers, lawyers, and pretty much any other type of business that would naturally advertise in the Yellow Pages.
  2. Historically, online pay per call has been has been hamstrung by the need for the end user to switch from the PC to the phone (by dialing a number on their PC screen, or entering their number on their PC and getting called back).  It seems like this PC-phone context switching would lose a majority of the potentially interested callers.  But on a mobile device, the user is just a simple click or finger touch away from making a phone call.  It seems like this would have a dramatic positive impact on Call Per Impression ratios.

Google has recently relaunched their click-to-call capabilities (Google’s Jan 2010 Announcement) on high-end smartphones.  ReachLocal sits in a strong position to use its direct sales force to interface between Google (and other publishers) and the many disparate enterprises interested in generating inbound phone calls. Perhaps a transition from Online Pay Per Call to Mobile Pay Per Call is modest enough that the existing online players will dominate in the adjacent mobile space, but I can’t help but wonder if there is a mobile-specific approach that is more effective than what has been tried by the online players to-date.