Android economics : Part-2 - The Android Income Statement

Link to article

Interesting myriad of payout with an endeavour to keep the whole value chain incentivized !

Horace Dediu, Asymco
May 14, 2012

This is a continuation of the “Android Economics” series of posts. It deals with how revenues and costs are categorized for Android.

The following diagram shows an approximate representation of what Android’s “Income Statement”[1] would look like.

I’ll discuss the assumptions that are built into the model as I go along. I’ll begin at the upper left and move toward the lower right in the discussion.

The first thing to note is that sales from Google’s (formerly known as Android Marketplace) Play are not registered as revenues. This is because Google, like Apple, treats itself as an agent. Agency means that the revenues don’t “belong” to the agent but get passed on through to the primary beneficiaries. In the case of Play, Google passes 70% to developers (or content owners) and then distributes on average 25% to network operators (or carriers).

I emphasize on average because there are many cases where Play transactions are not handled by or don’t pass through operator billing systems. In those cases where operators are involved, it’s possible that they capture more than 25%. It’s not uncommon for operator billing to capture 45% of a transaction’s value. The reason for this is that there is significant collection risk on billing–far more risk than on credit cards. It would also imply that on some transactions Google may be paying out more than it receives.

This means that on average about 5% of Play content sales to be booked as revenues for Android.

This 5% ends up a quite a small amount if overall app sales are small. We don’t know the exact amount but anecdotal evidence from developers seems to indicate that they receive far more revenues from ad sales than from direct app income. Hence the size of the Android app sales is overall, modest. My estimate is that in 2011 there were about $330 million in gross app sales through the Android market. (Google estimated its sales to be 76 million for 2010 half way through that year.)

The bulk of revenues are therefore from other sources: Search, AdSense and AdMob. I’m modeling that overall revenues are based on a “revenue per device in use” multiplied by the number of devices in use. Google has publicly stated that they are targeting $10/device/yr. in revenues. This is probably ambitious as the amount was nearly that much in early 2010 but the number of devices bought by emerging market consumers exploded. As they are not actively targeted by Google’s primary customers (especially in China), the average revenue per phone is likely to be much lower. I estimated $6.5 on average for 2011.

However, even if we use $6.5 per phone per year, the total revenues are quite strong since there were likely more than 215 million users at year end[2]. That results in a total revenue base of $1.4 billion for 2011. Removing the app revenues results in about $1.38 billion from Search and AdSense and AdMob.

How to allocate revenues to these three businesses is mostly guesswork. I used a split of about one third to AdMob, 10% to AdSense and the rest to Search. If we assume this split then the next step is to consider how to allocate costs to these sources of revenue.

As discussed in the introduction to this series, the primary costs of sales for Search and AdSense are network operators and OEMs or phone vendors. They are the primary “channel” which ensure the flow of search terms to Google. As Google also explains, the channel receives revenue share–so-called traffic acquisition costs (TAC).

I used an overall allocation of 39% for TAC. Crucially, this includes the payments to developers for AdMob traffic. The rule of thumb I used was:

·                     Network operators get 20% of Search

·                     Developers get 50% of AdMob

·                     OEMs get the rest (of the TAC)

The resulting split is shown in the column above with the “Cost of Sales” at the bottom. There are also additional operations costs which are negligible.

After this 39% TAC (revenue sharing), Google needs to pay its operating expenses. This includes R&D, Marketing, Sales and Legal costs for the Android division (including AdMob). You can see the approximate values in the column labeled “Operating Expenses”. This operating cost amounts to about 27% of sales, with R&D at 14% and Marketing at 9%. These rather high fixed costs make sense as there is a significant development work underway for Android.

Finally, after these costs are allocated, the remainder is the contribution of the division. This comes to about 34% of revenues which is called the operating margin. Google has to attach depreciation from data centers and other costs as well as taxes before placing this into earnings.

Considering the agency structure, the overall cost structure of Android looks like this:

When playing with the assumptions, it becomes clear that the model is most sensitive to the revenue per device and total devices in use. The profitability is entirely dependent on those figures as variable costs are a percent of sales and fixed costs are limited by talent constraints.

For example, if revenues per device drop to $4.5/yr then the operating margin drops to 38%.

Now we can calculate some of the more interesting figures. For example:

·                     Android OEMs receive $0.76 on average per device per year

·                     Android Operators receive $1.07 on average per device per year (including Play)

·                     Android Developers, as a group, receive $1.94 per device per year (including Play and AdMob)

·                     Google receives a contribution of $2.75 per device per year from Android

Again, these figures are very sensitive to the revenue per device (currently assumed to be $6.5).

Because of the number of devices involved, these cash flows are an important part of the value network of mobile computing. The next step will be to assess how they affect the incentives, alignments and competitive stance of various platforms vying for a seat at the table of the future of information.

–

Notes:

1.             An income statement shows the sources of revenues and the costs associated with those revenues. It also shows the fixed costs (or costs which are independent of revenues so they don’t go up or down if revenues change). Finally it shows the operating income which is called contribution if it’s a division within a company. This contribution is still subject to taxes and depreciation before it’s recorded as earnings.

2.             I’m using Android installed base estimated based on daily activation rates as published by Google. I’ve discussed these estimates here. I’m using year-end estimates but subtracting retirements based on a two year device life.