Example case: Analytics for a mobile game - Ancient Blocks (Part 3)

This week continues on from our last blog post (Part 2). As before, the example game "Ancient Blocks" is available on the App Store if you want to see the game in full.

Optimising in app purchases (IAPs)

Typically the goal of a mobile game is either brand awareness or to drive revenue. Ancient Blocks is a commercial offering and revenue is the primary goal.

The game has an in game currency called "Gems" which can be spent on boosting the effects of in game power ups. Using a power up during a level will also cost a gem each time. Players can slowly accrue gems by playing. Alternatively a player can also buy additional gems in bulk using real world payments.

![](/content/images/2014/10/GameExample-IAP-Screen1.png) ![](/content/images/2014/10/GameExample-IAP-Screen4.png) ![](/content/images/2014/10/GameExample-IAP-Screen2.png) ![](/content/images/2014/10/GameExample-IAP-Screen3.png)

The goal is to increase the average life time value (LTV) of a player. This is done by converting more players into paying customers, making those customers pay more often, and increasing the value of each purchase made.

Some of the metrics we want to measure are:

  • Which user journey to the IAP screen gives the best conversions?
  • The number of players that look at the IAP options but do not go on to make a purchase.
  • The number of players that try to make a purchase but fail.
  • Which items are the most popular?
  • The cost brackets of the most popular items.
  • The percentage of customers that go on to make a repeat purchase.
  • The customer sources (e.g. ad campaigns) that generate the most valuable customers.


Most of the required metrics can be achieved with just 4 actions.

  • Monetization.IAP - When a player actually buys something with real world cash using in-app purchasing (i.e. buying new gems, not spending gems).
  • Monetization.FailedIAP - A player tried to make a purchase the transaction did not complete. Some extra information is normally given back by the store provider to indicate the reason (whether that be iTunes, Google Play etc).
  • Monetization.Shop - The player opened the shop screen. It's important to know how players reached the shop screen. If a particular action (such as an in-game prompt) generates the most sales, then you will want to trigger that prompt more often (and probably refine its presentation).
  • Monetization.Spend - The player spent gems in the shop to buy something. This is needed to map between real world currency and popular items within the game (as they are priced in gems).
Action Properties
  • ProductId - The number / id of the product or bundle being purchased.
  • MaxLevel - The highest level the user has reached in the game when making this purchase.
  • ScreenReferrer - Identifies the screen / prompt / point of entry that eventually triggered this purchase.
  • $sale_value (added by trackSale(...)) - The value of this sale in real world currency.
  • $sale_currency (added by trackSale(...)) - The 3 letter code of the real world currency being used (e.g. USD).
  • ProductId - The number / id of the product or bundle that failed to be purchased.
  • Response - A response code from the payment provider (if given).
  • Message - A message from the payment provider (if given).
  • Screen - Which shop screen this was (such as the main shop, the IAP shop etc).
  • ScreenReferrer - Identifies the screen / prompt / point of entry that resulted in the shop being displayed.
  • ProductId - The number / id of the item being spent on.
  • Type - The type of spend this is (Item Upgrade, Cooldown, Lives, etc).
  • Gems - The number of gems (in game currency) being spent.
  • MaxLevel - The highest level the user has reached in the game when making this purchase.
  • ScreenReferrer - Identifies the screen / prompt / point of entry that eventually triggered this purchase.

In addition to these properties Ancient Blocks is tracking range of global properties (set with setGlobalProperty(...) detailing how each player was acquired (which campaign, which source etc).


A great deal of insight can be made using the actions defined above.

IAP conversions

One of the most important metrics is the conversion rate for the in game store, i.e. how many people viewing the store go and make a purchase with real world currency.

In a typical freemium game of this style, around 2% of players will actually make a purchase. However, the store to purchase conversion rate is typically much lower as the store is often triggered many times in a game session. If a game is particularly aggressive at funnelling players towards the store screen then the conversion rate could be even lower - and yet still be a good conversion rate for that game.

To measure this in Ancient Blocks a simple funnel is used with the following actions:

  1. Monetization.Shop (with the Screen property set to "Main") - the player opened the main shop screen.
  2. Monetization.Shop (with the Screen property set to "IAP") - the player opened the IAP shop (the shop that sells Gems for real world money).
  3. Monetization.IAP - the player made (and completed) a purchase.

![](/content/images/2014/10/GameExample-IAP-Funnel1.png) ![](/content/images/2014/10/GameExample-IAP-Funnel2.png)

As you can see, the conversion rate in Ancient Blocks is 1.36%. This is lower than expected and is a good indicator that the whole process needs refining. As the authors of Ancient Blocks modify the store page and the flow, they can revisit this conversion funnel to see if the changes were positive.

IAP failures

It's useful to keep an eye on the failure rates of attempted IAPs. This can easily be measured using the Monetization.FailedIAP action from earlier.

It's good to look at why payments are failing so you can try to do something about it - though a lot of the time it's out of the developers control. Sharp changes in IAP rates can also indicate problems with payment gateways, API changes, or even attempts at fraud. In each of these cases you would want to take action pro-actively.

![](/content/images/2014/10/GameExample-IAP-Failures1.png) ![](/content/images/2014/10/GameExample-IAP-Failures2-1.png)

The reasons given for failure vary between payment providers (whether that's a mobile provider such as Google Play or the App Store, or an online payment provider such as Paddle). Depending on your provider you will get more or less granular data to act upon.

Comparing IAPs across customer acquisition sources

Most businesses measure the conversion effectiveness of aquisition campaigns (e.g. the number of impressions vs the number of people that downloaded the game). Using Calq this can be taken further to show the acquisition sources that actually went on to make the most purchases (or spend the most money etc).

Using the Monetization.IAP or Monetization.Spend actions as appropriate, Calq can chart the data based on the referral data set with setGlobalProperty(...). Remember to accommodate that you may have more players from one source than another which could apply a bias. You want the query to be adjusted by total players per source.

The results indicate which customer sources are spending more, and this data should be factored in to any acquisition budgets.

Final summary

This 3 part example study is meant as a starting point to build upon. Each game is going to be slightly different and it will make sense to measure different events. The live version of Ancient Blocks actually measures many more data points than this.

Key take away points:

  • The ultimate goal is to improve core KPIs (retention, engagement, and LTV), but to do this you often to drill down and measure many smaller game components.
  • Metrics are often linked. Improving one metric will normally affect another and vice versa.
  • Propose, test, measure, and repeat. Always add refinements or new features to your product. Measure their impact each time. If it works then you refine it. If it doesn't then you should rethink or remove it. Don't be afraid to kill to features if they are not adding value!
  • Measure everything! You will likely want to answer even more questions of your product later but you will need the data there to answer these questions.