Android wins a battle, but the real war is just beginning

Not a week or two goes by without the folks at Google trumpeting some stat or other of Android’s unstoppable march towards complete and utter Mobile Domination.

This week we saw stats published from Comscore announcing that Android had taken the lead in smartphone market share in the US for the first time (click here).  From October 2010 to March of this year Android’s share jumped over 7% to a whopping 31.2%.  That’s gotta have a lot of engineers over in mountain view feeling pretty smug.  Cue applause

Yet the truth is that for all for all the hype, Android is still a long way from winning the war.  Although development on Android is at record heights as are submission of apps to Market, GetJar and others there are still some serious skeletons in the closet.

Of the last 20-30 developers I spoke with at GDC, MWC and other conferences over the past few weeks, only one was leading with Android for their development.  This is by no means symptomatic of the overall ecosystem of developers but they all had one thing in common: they complained about the inability to properly monetize Android as a platform and many voiced concern over discovery of their apps as well.

Monetization of apps in general continues to be significantly higher on iOS then on Android. Take a look at the comparison published by HIS Screendigest last month:

As you’ll notice, Apple still commands over 80% of app revenues last year and although that’s down more then 10% vs. 2009, Android Market’s revenues are no better then Ovi’s (or is that Microsoft Marketplace or Microsoft Ovi or whatever….).

What’s more concerning is looking at revenues per handset / user.  According to Digitimes, Android handset sales totalled 55 million units in 2010, which was jump of over 560% from 2009.  The delta in revenues on apps was over 800% but revenues per handset were only $1.85 per user vs. $37.9 per user on iPhone (assuming 47 million iPhones sold last year).  Now don’t forget that developers get only 70% of that revenue so on Android you can buy yourself a tall latté (no cream) while you can at least pay your water bill if you’re an iPhone developer.  So if you’re a VC funding that next great app start-up well…

Show me the money

The fundamental problem on Android remains the payment system (Checkout) and the lack of in-app billing.  Although Google has announced it will unveil IAB at Google IO in May they remain on mute about where it will be available, on which carriers and the economics of the deal.  Naturally, developers remain in suspense.  It’s been estimated that 47% of games revenue on IOS are now generated by IAB, which has come from next to nothing in the past year or so.  However, the key difference remains that on IOS IAB is still a 70% revenue share.  Most likely it won’t be this high on Android.  Why?  Because if Google offers IAB using carrier billing unless they are able to keep the same revenue shares they currently have with carriers (Google 10% / Carriers 20% estimated using Checkout) then the out payments (net payments after carriers take their share) could be significantly worse.  Take a look at out-payments provided by 3^rd party provider Fortumo for an idea:

So in this picture carriers take a whopping 60%+ before Google even sees a dime.  The alternative is to use Google Check-out (ie Credit Cards) for IAB transactions. This may improve out payments to developers but it will cause a drop off in conversions to purchase.  I spoke with a developer with apps on both the App Store and Android Market and he said that for the same app IOS had a 10x factor in revenues.  Check-out will only be used by some people (18+ for starters in the US) and outside the US credit cards see much lower usage on average.

Why is this important?  Early last year I published some research we did at GetJar showing that content was the number 3 most important factor in determining handset purchases among GetJar users.  More important then form factor, battery life, or screen resolution.  However, the key to great content is that at some point developers need to make money.  You can do a million activations a day but unless those are in the right markets where consumers have disposable income and payments are frictionless and reasonable then developers can’t make money and the reality is they have to pay rent, eat and buy clothes as well.

To date Google has resisted developer attempts to use alternative solutions to it’s own in-house billing solution (Check-out) despite it’s obvious flaws.  Although a number of solutions exist out there, many developers remain confused about whether they can or should use a non-Market billing solution for their apps.  Amidst this confusion they remain, like a flock of faithful devotees, waiting at the foot of the mountain for Google to deliver the perfect solution.  In truth, it will get better but there won’t be a deluge of money pouring out of the Android ecosystem anytime soon. 

Discouraging developers from using alternative billing methods though is like offering Diners Club at Walmart as the only way to pay for your groceries.  Vendors know consumers have other ways to pay but go hungry because Walmart won’t accept Visa or Mastercard.  It’s not good for consumers and not go for suppliers.

Android was originally conceived as an Open ecosystem and that was part of the reason developers, OEM’s and carriers embraced it.  Yet as its market share has increased it’s become more closed (let’s not even mention AT&T’s pre-historic stance on non Android Market app distribution). This isn’t a long-term approach to building a thriving ecosystem.  Google still has time to fix this and make sure those vendors don’t go hungry. They should look to partner more with others who can help them improve distribution and monetization and move away from the “not invented here syndrome”.  This race will be a long one and competitors like Microsoft have shown that with money, a good product and a strong ecosystem that rewards publishers (Xbox anyone?) the race is won by those who keep running and not those who sprint in the beginning.