Automobiles and computers were so simplistic in their first 10 years that today we have a hard time looking back and appreciating just what a leap in technology they were at the time. Like all technology, they benefited from the iterative process, slowly adapting to changes in allied technologies, consumer demands, and infrastructure. Today both cars and computers have components in them that did not even have names 10 or 20 years ago. Before they could be added to these products, they had to be thought about and given names so that they then could be optimized and adapted to various uses.

Today the technology of monetization design is literally in its first years of creation. The concepts can be quite complex, but in talking about them we use broad terms like "free-to-play," "microtransactions," and "pay-to-win" to explain things that would be difficult to explain in detail. The good of this is that others can have a general idea of what you mean without a long academic discussion.

If a developer says "I am going to replace the subscription in my game with microtransactions," then we can all nod and pretend we understand what the developer is saying. We can also pretend the developer understands what they are saying. The downside to this simplification is that often no one in the conversation understands what is going on at a level that can be applied to product.

Here, I am going to attempt for the first time to put a majority of the monetization design language I have been developing over the last four years in one short article. All of these terms have been used in my other papers on gameful.org and here on Gamasutra, but never in one place.

I cannot understate the importance of a unified language for this space. Its importance goes beyond intellectual discussion. The whole "subscription vs. microtransaction" paradigm is so limiting that it is crippling our industry. There are not two ways to monetize a game. There are millions, limited only by our imagination and our ability to articulate our ideas to our fellows.

What is a Subscription?

Generally, this is a recurring charge for service. In games, it usually means you pay one fee monthly and get the entire game 24 hours a day, seven days a week. To be clearer, I describe this as the Unlimited Use Subscription Model. The weaknesses of this model are profound, and go beyond the scope of this article.

Any part of your game can be charged for in a recurring fashion, for any duration you set. You can have as many modules of your game as you like charged for in a recurring fashion. I call these limited subscriptions microsubscriptions. Microsubscriptions can be used to gate content access, boosts, time, or any other feature you can think of. There are two primary advantages to offering multiple microsubscriptions in your product:

This allows the consumer to tailor your product to their needs. You can't, and should not, want to try to predict how each consumer will use your game. Make it flexible enough to appeal to the widest possible audience.

This allows you to continue charging for your game service, and thus maintains your revenue stream beyond the first month.

The end result is you capture the biggest possible slice of each consumer's available gaming budget.