Finding the right tuning in your game will always be a key element of its success. Every value you put in the game – prices, wait times, XP cost, missions required to unlock a feature, etc. – will have an impact on your user experience. Two of the most important aspects of your game – where an appropriate tuning will be the most impactful – are prices and progression. By prices I mean the in-game currency cost to acquire something (IAP price point are a slightly different beast). By progression I mean the time/effort/actions required to attain a specific level or unlock a specific feature via in-game actions (not via purchase). To a certain extent both will impact the monetization and engagement experience of your game. But prices will have a more direct impact on monetization, just like progression will have a more direct impact on retention/engagement. This post is going to focus on pricing.

How to think pricing (and how AB tests can fit into that)

Where do AB tests fit into the search for the best price? In theory AB tests will always be the best option. But in practice that’s not the case. If time were not a factor and you were operating in a vacuum, then AB tests would always be the way to go. But that’s simply not the reality you are working with. AB tests are a good option to optimize prices in some cases, but not in every case.

First, from a practical point of view, running AB tests costs time and resources (i.e. installs). You probably have deadlines to go worldwide or release a new feature, and you can’t always afford to run an AB test. For example, you can’t release you Halloween content in December because you had to wait for the results of your AB test – neither can you spend 10x in UA to get the test results before Halloween. AB tests that involve pricing (and indirectly revenue) require a large quantity of users and/or long periods of time to provide reliable results. If you want to set the price of a consumable, or any other item users purchase relatively frequently (for example a commonly used speedup or the featured gacha in an RPG game), then an AB test is an interesting option. On the other hand, if you are dealing with one-off permanent items – once the user has purchased it s/he cannot purchase it again – then conducting an AB test might not be practically feasible. So, from a practical point of view you simply cannot AB test every price point in your game. You need to have a few guidelines to set your in-game prices that don’t require an AB test.

Second, from a theoretical point of view, you are not operating in a vacuum. Your game might not be undergoing any changes. But your game is only part of the equation. The key to your success will reside in the way an audience appropriates your game – the way it takes it and makes it its own. It’s not your game that is generating revenue. It’s the game-audience articulation. While your game might not be undergoing any changes, your userbase is constantly changing. Users’ preferences change and evolve with time, seasonality, trends in the mobile market, etc. Users don’t react the same way during Halloween, Christmas, weekends, etc. I’m not convinced running an AB test in June for your Halloween content will provide you will reliable results. The results of your test 2 years ago might not still hold true today. Some individual games change user expectations and redefine the criteria of success in mobile games: Clash Royale contributed to a redefinition of user expectations when it comes to PvP – just like you probably can’t release exactly the same FPS game before and after Fortnite. We’re making products where the cultural and subjective components are key – we’re not conducting reproducible physics experiments in a controlled environment. AB tests will account for changes in your game – but they can’t account for changes in your userbase.

That’s why when your game has been live for a little while (and you have data at hand), the best way to determine the right in-game price is to see what your users are already doing and spending on (and how much).

Look at your customers to tune in-game prices

Tuning the prices in your game can have a huge impact on your monetization performance. Once we agree the best way to determine the right price is to see what your users are already doing and spending on (and how much they are spending), the next step consists in looking at who is spending, on what, at what price point, and how often.

The first thing you want to do is clearly identify the spending categories that matter the most for you. And in order to do that, you need to look at what percentage of users are spending in each category, and how much spending occurs in each category. And this is where carefully determining which group of users you will be looking at is crucial. In order to best tune the price points in your game, you need to be looking at intentional spending (which is not the same as rational spending). That implies you don’t want to be looking at what all users are spending on. When you look at spending across your whole game – meaning looking at engaged and non-engaged users together, customers and nonpayers – then the spending patterns of the majority will dominate. And most likely, the majority of your users are nonpayers.

It’s important when you observe your spending pattern that you only look at your customers (a user who has purchased an IAP at some point in the past) for 2 reasons – and that’s especially the case if the valuable items in your game are purchased with a “hard currency” which is difficult to acquire without buying currency via an IAP. First, the hard currency of your nonpayers is worth nothing. Customers spend $$$ for their hard currency. You can attribute a dollar value to the hard currency they are spending (incidentally if you can set that field in your database you should – that can also help you recognize revenue). The dollar value of your nonpayer gems is 0. By and large nonpayer spending does not impact revenue. Second, non-payers by definition have no external influx of currency (via IAP). The only currency they have is the one they get via in-game actions. That means non-payers spending behavior is much less intentional than the spending behavior of customers. Nonpayers don’t purchase what they want as much as they purchase the few things they can afford.

If you were to look at which categories drive spending, you can see how including (or not) non-payers changes the overall picture.

 

If you were to only look at the spending of non-payers, then it would appear that the very high-price hero is marginal and not contributing much. But when you focus only on your customers (those whose hard currency actually has a dollar value), then you see that’s not the case. More generally, when you look at customer spending you see that the relative importance of low price-point items is smaller, and the relative importance of high price point items much bigger. And the same applies when you look at spending reach: the percent of users who are spending in each category.

 

You can get further perspective on this is you look at what percent of your installs are making a transaction, and at what price point. What percent of your installs have spent hard currency within x days of installs? What percent have made a purchase at a price point of 5 gems or more, of 10 gems or more, etc.? The price point of your items will be one of the most important factors in determining spend patterns of your non-payers: both in terms of reach and in terms of total amount spent. And because the vast majority of your users are most probably non-payers, looking at the spending behavior of all your users means your evaluation will be strongly biased towards low price points.

 

In the example above, very few non-payers will ever purchase something that is priced at 20 gems or more. But that’s simply because non-payers don’t have a gem balance high enough to afford it. When you look at spending across all your users, you are not looking at intentionality. You are looking at affordability. That’s why when looking at prices and spending, looking only at customers will help you assess more accurately what is driving your revenue, and what prices you can optimize (and how). [If you want to be thorough, you can choose to go one step further and focus on your customers who have displayed a minimum level of engagement – such as customers who returned to the game after 7 days of install]

Optimizing your price points for your customers

Once you’re clear on which group of users you want to be looking at to optimize prices, you need to focus on a few key aspects. To be consistent you also want to be looking at spending occurring within a given time frame (for example, customer spending within 14 days of install):

• What percent of customers are spending on a category
• What percent of total spending occurs in each category
• What is the average price point for each category
• How many average purchases in each category
• How much total currency is spent by a buyer (by a user spending in that category)

 

Ultimately you want to be keeping all these metrics in mind when considering your spending categories and your prices. If you wanted to display things in a more visually intuitive manner, you can have a grid that distributes spending categories across spending reach and average spend per buyer.

 

There are 3 ways to increase spending in a category: increase reach, average price point or average purchases. You always want to be keeping overall spend in the back of your mind. If you increase spending in one category at the expense of another, and overall spend doesn’t increase, then your tuning is probably not achieving its goal.

First you got to determine what can be materially improved. If the category involves something that can only be purchased once – or a finite number of times – then you need to take that into account. If there are only 2 very-high price heroes available for purchase, then your improvement plan shouldn’t aim to increase average purchases to 3. Provided items in a category can be purchased an infinite number of times, the number of average purchases per customer will usually reflect the price point of an item – even for payers (remember probably 40% or more of your paying users only ever make one IAP). Generally, if a category has high reach and a high number of average purchases, you are probably looking at a low price point item (if not, congratulations!). If you have a low price point item with high reach and low average purchases per buyer, that’s a strong indication what your selling is not appealing. Imagine for example a low price point consumable which provides a questionable advantage.

Stated differently, you can play with price-points to increase the reach or the spend per buyer – with the ultimate goal of increasing overall spending. The general rule (for pricing like pretty much any other aspect of your game) is you’ll always be more successful if you try improving what’s easiest to improve. You’ll always be most successful if you try to reinforce existing behavior – rather than trying to create new behaviors or modify existing ones. With that in mind, you can look at the grid again.

 

It’s easier to reinforce existing trends than to try to create new ones. That means, if you’re dealing with a high reach high purchase category, you should be comfortable making a big relative increase in price point. The average price point of the very low speedup is 4.3. Increasing it to 6 or 7 represents a high relative increase, but a very modest increase in absolute terms. And the price-point corresponds to the reality of the user’s spending experience. Small absolute increases in price point will have a low to moderate impact on reach and average purchases. But if you are talking a high reach high purchase category, then that 50% increase in price point can have a big impact on overall spending.

On the other hand, if you are dealing with a spending category that has a low/moderate reach but spending is very high then another approach is warranted. You are presumably dealing with a very engaged segment of customers – they are by definition not deterred by the high price point. It will usually be much easier to get a very high-spending user to spend more. The reach might decrease – but because this category of spending caters to your biggest fans, an absolute increase in price point will only have a low impact on reach. Increasing the price point from 144.3 to 170 represents an increase of 25 gems (only an 18% increase in price point) but that increase won’t be enough to significantly affect reach or purchases per buyer. On the other hand, it will have a big impact on average spend per buyer.

The weapon category offers an interesting problem: should you try to increase reach (by reducing prices) or give up trying to get more customers to buy weapons and more out of those willing to spend? This is the kind of case where you won’t have one size-fits-all type of solution. A lot will depend on the specificities of your game and the item in question. If it’s an item that can only be used I a peripheral game loop which only a minority of users engage with, then trying to get more customers to buy weapons will probably not work. In that case you should try to focus on getting more from your buyers than getting more buyers. But assuming that’s not the case, and weapons have a use throughout the game, increasing reach by high relative decrease in price point (“high decrease” being 20/30%) could help you get more overall spend in that category.

Finally, looking at the grid will also highlight spending categories that might not even be worth bothering with. It will be difficult to improve a category where both reach and average spend are low – such as is the case with the second very low-price speedup. Despite all your design efforts, some features, items, categories just won’t resonate with your userbase. Part of the optimization process also consists in knowing what is not worth investing time and effort into. This way of looking at spending and prices will not only provide pointers on how to improve – it will hopefully also make a bit more evident the improvements that will have a low ROI.