My view has always been that game publishing should be about reducing risk for developers, giving them the means to achieve more -- creatively and commercially -- than would be possible independently. But many things have changed since 2005, when I published the first of around 75 games in a 15 year publishing career.
Mobile game publishing has always posed a different challenge, being such an ultra-competitive market, but there were at least a few publishers in the space -- including Flaregames -- trying to adhere to these same values.
This has been challenged by the emergence of a new form of mobile game publisher, focused almost solely on user acquisition. On the surface, these companies make a fair promise: they invest their capital and skills to scale your game, while you keep your IP and freedom. Their UA spend is paid back from revenues, so there's no risk for you -- or so it seems.
"These are talented developers being bled dry by some truly vampiric contract terms"
Dig into some of these deals, however, and you'll find several exploitative contract mechanics that are designed to suck revenues and autonomy from developers. I have seen firsthand how damaging these mechanics can be to a company.
These are talented developers being bled dry by some truly vampiric contract terms, brought to the brink of bankruptcy by deals supposed to help them grow. To help prevent more developers falling foul of such deals, I have identified four of the most exploitative publishing techniques and how they're used in combination against you.
1. Organic revenues as collateral for UA spend
The essential mechanic of these contracts is that the publisher will invest in user acquisition for your game, with a fixed return of ~1.2x on everything they invest. However, often hidden in Legalese are questionable definitions that entitle the publisher to recoup from all traffic -- not just that which provably comes from its UA.
This shifts the risk to you. If your game already has new organic installs worth $50,000 every month, the publisher would have 0% risk on getting back the first $50,000 it spends on UA each month. This can leave you worse off than you would have been without its intervention.
When UA scales, organic traffic does often increase. But the relationship is not linear, and often the effect wears off quickly as a game matures. Organic traffic also normally monetises less than UA traffic, so an increase in organic installs of 30% would only translate to 10% to 15% additional revenue.
If a publisher argues the need to take organic revenues into account in order to scale more, that's because its UA -- the reason you signed with them in the first place -- is not profitable enough to scale further. Your organic traffic should be neither collateral, nor a subsidy for the publisher's UA spend.
Solutions to protect yourself:
- Defining a binding direct Return on Ad Spend target (not a "soft goal")
- Excluding your current organic traffic as baseline from the UA payback
- Including only a fixed (small) organic uplift factor
2. One-sided budget decision authority
Tied in closely with the above point is the publisher's right to unilaterally decide how much to spend on UA. When the publisher is fundamentally incentivised to pursue a spending strategy that doesn't benefit you -- to spend as much as possible that still generates a 20% profit margin -- it is unhealthy to allow it sole authority over budget.
"Exploitative business models only exist for some time, and sooner or later this one will die out, too"
The conflict of interest is even worse if the publisher recoups from organic traffic: this would allow the publisher to settle for a UA spend that reaches 20% profit margin only by including the revenues from your organic users. This means unprofitable UA, subsidised by your organic income, and it moves your potential profit entirely into the publisher's pockets.
It is well known that on the same game, a higher volume of spend means lower profit margin. Going from a 1.2x return on UA investment to a 1.3x return with the same or higher scale -- the point at which you begin to profit -- is incredibly difficult, and only gets more so as the game matures.
So not only does a publisher under this model have no need to deliver higher returns, as long as it's comfortably pocketing its own margin, it also has very limited ability to do so -- no matter what it tells you. Leaving its budgets unchallenged under these circumstances is extremely unwise.
Additionally to the protections mentioned in the previous point, a veto right or a binding consultation requirement are clauses that can help protect you against exploitation.
3. Loss of control over your IP
When a publisher carries the majority of development risk, limitations over or even ownership of the game IP is a reasonable request. However, a publisher only taking minimal risk on a user acquisition deal does not justify them restricting in any way your freedom to utilise your IP.
"I hope that we can return to agreements between developers and publishers that are crafted in the interests of both parties"
It's reasonable if the publisher demands exclusivity for the specific UA channels they work on. It's unreasonable if they have broad distribution exclusivity but don't guarantee activity. Look out for clauses restricting distribution on other stores or platforms.
Any limits on "derivative works," or similar clauses restricting the developer's creation of "competitive" products, mean a developer effectively granting the publisher control over its own IP for the duration of the deal after carrying all the risk creating the IP themselves.
This might be reasonable if the publisher were offering more than just UA investment -- fronting all development costs, for example -- but it is certainly unfair in the context of these UA-focused deals.
4. Restricted termination rights
Particularly if any or all of the above mechanics come into play, as a developer you need an effective termination right if you're dissatisfied with the publisher's performance. A prolonged period without regular termination right is unreasonable.
But even in cases where the option to terminate is technically in the hands of the developer, it can be made incredibly difficult in practice thanks to forced and immediate payback of any UA spend the publisher has yet to recoup -- with their ~20% margin on top, of course.
This can keep you locked into unfavourable deals for a long time or force you to take an unpleasant cashflow hit. Worse still, the payback requirement is triggered even if the publisher terminates the deal.
Of course, the publisher has a right to recoup its investments, but a more reasonable way to do this would be to simply let the previous UA spend be recouped from revenues of the acquired cohorts as they mature after termination. Restricted termination, particularly in combination with the three clauses listed above, can also severely reduce the value of your company for a potential buyer or investor.
Unfortunately, the outcome for those working under these arrangements is clear: they will either die or be acquired very cheaply because it's their one lifeline. And what of the publishers pushing these deals? Exploitative business models only exist for some time, and sooner or later this one will die out, too.
So if you've been offered a publishing contract, I'd urge you to study it carefully for any of the hidden traps outlined above. If you're still unsure, the best approach would be to seek help from someone experienced in publishing contracts and who knows what to look out for.
I write this with the hope that we can return to agreements between developers and publishers that are crafted in the interests of both parties, with at least the ambition for both to reap the rewards. In its current guise, third-party mobile game publishing fails to fulfil even this most basic requirement.
Klaas Kersting is the Founder and CEO of Phoenix Games, an international family of games companies. UK developer Well Played Games became the first to join in May, with further acquisitions coming soon. The Phoenix team can be reached at firstname.lastname@example.org.