The economics of mobile game publishing

Posted on April 15, 2013 by Eric


(The model referenced throughout this post can be downloaded here)

Supercell’s recent $100mm secondary financing round raises some interesting questions about how mobile game developers capitalize on a hit game. A title in the Top 10 grossing chart for the US can, as evidenced by a number of recent high-profile examples, generate upwards of $500,000 per day, but this capacity for revenue generation does not directly scale with enterprise value for the firm because these revenue streams are not themselves business units. Rather, in many cases, hit games are evaluated as short-term windfalls that 1) cannot be expected to persist permanently into the future and 2) are assumed to be non-repeatable (ie. a huge hit game is seen as an aberration, not the result of a product strategy that can be re-implemented in another game to the same degree of success).

In order to build sustainable streams of revenue out of massive hit games, some studios have begun engaging in publishing activities. The reasoning is clear:

  1. In most cases, Customer Equity (the aggregate total of all current and future Lifetime Customer Values) is the sole component of enterprise value for a mobile gaming studio. Brand Equity represents no monetary value; a mobile gaming studio (unless they have diversified into other revenue streams, as has Rovio) gains nothing in the present from a hit game in the past if those users have churned out of the ecosystem.
  2. Mobile game development is a long and resource-intensive process. And the success of a mobile game in development is difficult to assess, especially given the rapidly escalating competitive landscape of the mobile gaming marketplace and the brisk pace at which mobile technologies evolve. The present value of future cash streams attributed to a future release decreases drastically as the timeline for projection exceeds one year.
  3. Increased marketing costs have priced many small studios out of the user acquisition market. Publishing is the only viable launch option for studios without large cash reserves, absent incredibly virality.

The publishing model therefore sits at the confluence of the needs of studios sitting on large hits but with long-term product pipelines (ie. their next release date is more than nine months away, when the user base of the current hit is expected to have decayed substantially) and small studios sitting on games with great potential but without the marketing budget to seed their game with a large user base at launch.

The terms of a publishing agreement generally involve a revenue sharing component and a user acquisition component. The developing studio agrees to split revenues with the publisher (generally at a rate of 50% of net revenues) in exchange for a pre-determined acquisition budget to be spent by the publisher on the game (sometimes the revenue split will compensate for the acquisition spending, eg. 80% of the revenue goes to the publisher until acquisition spending has been recouped).

An agreement structured this way is no-risk for the developer because the game is guaranteed to receive users without any upfront costs (except for development costs, which are sunk). The structure of the agreement involves some risk on the part of the publisher, although the publisher would have thoroughly vetted the game in terms of its potential to generate revenue. In all, it is a good solution for a publisher starved for a destination for its current users (lest they churn out, requiring re-acquisition in the future) and for a developer starved for a marketing budget with which to launch a title.

The question that arises from these agreements is: on what criteria should a developer make the decision to go with a publishing agreement or not? What factors determine the prudence of the decision? And can this decision be modeled?

I have attempted to model the decision; the Excel spreadsheet can be downloaded here. I used as primary determinants of the decision six assumptions:


  • CPI (cost per install) is exogenous and set by the market; it can’t be influenced by the developer.
  • ARPDAU is a function of the game’s ability to monetize and is obviously a key component in calculating total revenue.
  • K-factor is the extent to which the game generates viral installs – more background information can be found here.
  • Monthly organic installs is an estimate of installs from non-viral, non-paid sources.
  • Monthly acquisition budget is the amount of money a developer is willing to spend on paid acquisition each month. This, combined with CPI, determines the number of paid installs acquired by the developer each month.
  • Net revenue reinvestment is the percentage of net revenue the developer is prepared to reinvest in the next month’s acquisition campaign (assuming that revenues are paid out at the end of the month and acquisition budgets are set at the beginning of each month). In other words, this percentage of revenue net of expenses, platform fees, and (when applicable) publishing split will be added to the monthly acquisition budget in the next month.

Adjusting the values of the assumptions illustrates clearly that revenue is driven almost entirely by virality, the acquisition budget, and the rate of re-investment; when k-factor is high, revenue growth increases at a compounding rate given constant ARPDAU, negating the need for any initial acquisition budget but justifying continued re-investment of net revenue through future paid acquisition. When virality is low, only a very high re-investment percentage allows the user base to grow (assuming organic installs don’t surge as a result of some external event, such as platform featuring).

The starting assumptions about the game used in the model reflect a mediocre commercial performer; an ARPDAU of $.10 is respectable but not exceptional, and a K-factor of 15% is strong but not overly viral. On the other hand, the terms of the publishing deal illustrated in the model are not favorable but not altogether unrealistic.

It should be noted that the only expenses considered in this model are those related to acquisition, not capital expenditures, salaries, travel and entertainment, etc. This is not a full financial model but rather an operational model describing a specific decision point.

The following six scenarios are examined:

$0 initial monthly acquisition budget with 25% net revenue reinvestment, no publishing deal

  • 52-week total net revenue: $182,969
  • Monthly revenue curve:


$0 initial monthly acquisition budget with 25% net revenue reinvestment, publishing deal (monthly spend=$20,000, revenue split after acquisition recoup=50%, revenue split before acquisition recoup=80%)
• 52-week total net revenue: $288,168
• Monthly revenue curve:


$5,000 initial monthly acquisition budget with 25% net revenue reinvestment, no publishing deal
• 52-week total net revenue: $251,915
• Monthly revenue curve:


$5,000 initial monthly acquisition budget with 25% net revenue reinvestment, publishing deal (monthly spend=$20,000, revenue split after acquisition recoup=50%, revenue split before acquisition recoup=80%)
• 52-week total net revenue: $318,642
• Monthly revenue curve:


$15,000 initial monthly acquisition budget with 25% net revenue reinvestment, no publishing deal
• 52-week total net revenue: $389,805
• Monthly revenue curve:


$15,000 initial monthly acquisition budget with 25% net revenue reinvestment, publishing deal (monthly spend=$20,000, revenue split after acquisition recoup=50%, revenue split before acquisition recoup=80%)
• 52-week total net revenue: $379,592
• Monthly revenue curve:


Examining different scenarios with the model under different game and publishing agreement assumptions reveals a few realities of the economics of game publishing:

  • Small developers with mediocre games benefit most from a standard publishing agreement.
  • Viral games need smaller marketing budgets with which to seed a user base. The acquisition budget contributed by publishers quickly diminishes relative to the developer’s capacity for acquisition through reinvestment with a viral game.
  • Games that don’t monetize to a high degree will suffer from a high pre-acquisition recoup revenue split.
  • Reinvestment into acquisition creates a compounding effect on positive revenue growth that reduces the relative contribution of publisher acquisition spend unless that spend scales over time.

Publishing in some cases is a Pareto optimal choice for both publisher and developer, but those cases conform to specific parameters. The degree to which a developer will benefit from a publishing agreement relates directly to that developer’s ability to generate viral installs and its tolerance for setting revenue aside for marketing expenditure.

  • Bill Gelpi

    Hi Eric, I really appreciate you putting together this model as we are evaluating whether or not a publishing deal makes sense for our project. However, I believe there may be an error with the model. Row 35 calculates monthly revenue by multiplying all installs by 30 then again by ARPDAU, this overestimates monthly revenue as it assumes total installs = DAU. You could substitute rev/install instead of ARPDAU, and multiply total installs by rev/install for a quick fix that should work for purposes of yearly estimates. Aside from that the model looks good, though I think there may be a few other factors that teams should consider in deciding on a publishing deal. Firstly, average LTV of an organic install differs from that of a paid user with targeted non-incentivized performing marketing having higher LTV than organics. Secondly, organic installs grow non-linearly with chart position implying that a small marketing budget may not net the same profit as a larger budget that can push a game to the top of the charts and boost organics. Lastly, teams should also consider the time and skill required to run your own marketing campaigns. If you do not have experience with performing marketing you should be cautious with running your own campaigns as they may not have the best ROI. Instead you could use a managed marketing service like Fiksu, however that will cost you a flat 20% fee of your marketing budget. On the other hand if you work with a publisher you have the advantage of leveraging their institutional knowledge on performance marketing. Net-net, for a small developer lacking the expertise in performance marketing and a large amount of capital I think it often makes sense to go with a publisher and invest your efforts in building better games.

    • ESeufert

      Hi, Bill

      I moved servers a while ago and lost all post comments in the process; I actually designed the model like that (DNU * ARPDAU * 30 = total revenue) on purpose. The 30 there serves as player lifetime (I had mentioned that in the comments that were lost); what I'm doing in this spreadsheet is not modeling daily revenue but modeling total lifetime revenue per cohort, realized on the cohort's first day. The reason for that is (at a conceptual level) I don't think player lifetimes would be drastically different if a marketing campaign was run by a publisher or run by a developer (obviously assuming, as you say, that they both used the same general quality mix of sources).

      As for the different LTVs by channel, I completely agree with your point, but this model doesn't assume any difference in channel mix between what a marketing team at a studio would pursue vs. what a publisher would pursue. That is, it assumes that, if the developer decided do use some mix of incentivized / non-incent traffic to reach X position, the publisher would do the same, and the blended LTVs would be the same. Since the purpose of the model is only to answer the "publish or don't publish" question (and not to estimate revenues), I think it's fair.

  • ESeufert

    Whoops. Fixed!

  • clam

    Hi Eric, just trying to download a copy of the excel file. The link doesn't seem to work anymore, it directs me to a page in Swedish. Can you re-post it or is there somewhere else I can find it? thanks

    • ESeufert

      Which link? The link at the start of the article works for me...

  • Alex Lim

    Hi Eric, thanks for the nice post! I can't seem to download the spreadsheet from the link given above. Can you please check it again? thanks again

    • Fiona Huang

      Sorry, my bad, the link on top of the article is working. Many thanks, Eric.