This article continues on from my previous articles (Part 1 and Part 2). In this article we will be looking at using analytics to optimize in app purchases in our example game "Ancient Blocks". As before, the example game featured in this article is available on the App Store if you want to see the game in full. The reports shown in this series were produced using Calq, but you could use an alternative action based analytics service or even build these metrics in-house. This series is designed to cover "What to measure" rather than "How to measure it".

Optimizing in-app purchases (IAPs)

The goal of most mobile games is to either generate brand awareness or to provide revenue. Ancient Blocks is a commercial offering using the freemium model and revenue is the primary objective. 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. Our goal here is to increase the average life time value (LTV) of each player. This is done in 3 ways: 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 will need to measure include:

• 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.

Implementation

Most of the required metrics can be achieved with just 4 simple actions, all related to purchase 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).

[table] [tr][th]Action[/th][th]Properties[/th][/tr] [tr][td]Monetization.IAP[/td] [td]

• 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).

[/td] [/tr] [tr][td]Monetization.FailedIAP[/td] [td]

• 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).

[/td] [/tr] [tr][td]Monetization.Shop[/td] [td]

• 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.

[/td] [/tr] [tr][td]Monetization.Spend[/td] [td]

• 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 the games (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.

[/td] [/tr] [/table] 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). This is done automatically with the SDK where supported.

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 (or even just playing the game) go and make a purchase with real world currency. Typically around 1.5 - 2.5% of players will actually make a purchase in this style of freemium game. The store-to-purchase conversion rate however is typically much lower. This is because the store is often triggered many times in a single game session, once after each level in some games. 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.

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 process needs some adjustment. When the designers of Ancient Blocks modify the store page and the prompts to trigger it, they can revisit this conversion funnel to see if the changes had a positive impact.

IAP failures

It's useful to monitor the failure rates of attempted IAPs. This can easily be measured using the Monetization.FailedIAP action from earlier. You should look at why payments are failing so you can try to do something about it (though some of the time it might be 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. 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). 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 acquisition campaigns (e.g. the number of impressions compared to 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. This technique can also be used to measure other in game actions that are not revenue related. It's extremely useful to measure engagement and retention by aquisition source for example.

Series summary

This 3 part series 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 the core KPIs (retention, engagement, and user LTVs), but to do this you wil need to measure and iterate on many smaller game components.
• Metrics are often linked. Improving one metric will normally affect another and vice versa.
• Propose, test, measure, and repeat. Always be adding refinements or new features to your product. Measure the impact each time. If it works then you refine it and measure again. If it doesn't then you should rethink or remove it. Don't be afraid to kill to features that are not adding any value!
• Measure everything! You will likely want to answer even more business or product questions of your game later, but you will need the data there first to answer these questions.