The app ecosystem and the fungibility of users

Posted on September 18, 2012 by Eric Benjamin Seufert

I was asked recently to answer a question on Quora about building a mobile user base without spending (much) money. For indie app developers, the rising CPIs (costs-per-install) represent an existential threat: without a massive budget, a game can't gain much traction, and without initial traction, the studio can't finance the development of future titles. So what does a small studio without a marketing budget do to build a user base? The answer to that relates to the fungibility of users.

First, a definition: fungibility within the context of a mobile app user means the user can be moved from one of a developer's apps to another without much resistance. This isn't an industry standard definition; I stole it from finance and have never heard it used in gaming before. But I think the concept makes sense when considered from the perspective of an app developer, especially a game developer: if I make games, and those games are slightly similar, a user from one of my games is at least more inclined to like another of my games than a new user acquired at random (eg through an ad network).

Why are users fungible? Because only a minority (26%, based on this study) churn out of an app after one use, which means that the majority of users give an app developer at least one opportunity to cross-promote its other apps before deleting the original (assuming the app developer doesn't cross-promote on a user's first session). This is a substantial revelation: it means a user has a non-zero probability of transferring to another app within the developer's app ecosystem if that user doesn't delete the original app after her first session. That non-zero probability reduces effective CPI: any one user acquired could potentially install another of the app developer's apps, given the developer is effectively employing cross-promotion.

Which brings me back to the question on Quora: the best way to build a user base without a substantial marketing budget is to leverage this phenomenon (each user might install multiple apps) by building out an ecosystem of apps. Because users are fungible, once a user is brought into the ecosystem, they're more likely to stay in the ecosystem than an outsider; as a result, accumulating a user base over time is more economical than attempting to develop a massive user base with individual apps relying on acquisition campaigns.

I cite Fatify in the Quora answer as an example of this strategy in action. Fatify is a free app that manipulates an image of the user's face to make them look fat. That's it; the app has one, simple purpose, and it's totally free. This is a feeder app: it has broad appeal and brings users into the developer's ecosystem. Once in the ecosystem, the developer very masterfully cross-promotes its other -- paid! -- apps to the user: Oldify, Stache-ify, and Baldify. They all do basically the same thing, but they cost $0.99 to download. And whether or not the user buys these other apps, he probably keeps Fatify on his phone -- in other words, he remains in the ecosystem. When the Fatify developer releases its next title -- perhaps Hipsterify, Gothify, or Lady Gagaify -- it will be able to cross-promote the new app to this user the next time he Fatifies himself or one of his friends.

A developer's ecosystem, at a large enough scale, can abate its need to engage in paid acquisition campaigns, which is obviously a huge competitive advantage over developers that have to buy all of their users for new apps. The indie developer just beginning to grow a user base needs to understand this concept in order to avoid wasting money on acquisition campaigns down the road -- a broad, evergreen, single-function feeder app can not only direct traffic to existing apps, but it can also be the entry point of those same users for the developer's future apps. Under certain circumstances, one user transferred between three apps can be worth just as much as three users, each directed individually to different apps.