手机游戏的游戏玩法与IAP的标准参数（三）

作者：Andy Savage

在本文中我们将通过分析去优化《Ancient Blocks》中的应用内部购买。

优化应用内部购买（IAP）

大多数手机游戏的目标都是创造品牌认知或者收益。《Ancient Blocks》是一款使用免费模式的商业游戏，所以收益便是其主要目标。

这款游戏拥有名为“宝石”的游戏内部货币，玩家可以使用这一货币去提高游戏道具的效能。玩家在关卡中每次使用一个道具都要消耗一个宝石。玩家可以通过游戏不断积累宝石。与此同时他们也可以使用现实世界的货币购买宝石。

IAP screens(from gamedev)

在此我们的目标是提高每个玩家的平均终身价值。这将基于3个步骤：将更多玩家转变成付费用户，让那些付费用户更频繁地花钱，提高玩家每次购买的价值。

我们需要测量以下参数：

哪段用户旅程能够呈现出最佳转换率？

着眼于IAP选择但却未继续购买的玩家数量。

尝试进行购买但却失败的玩家数量。

哪种道具最受欢迎？

最受欢迎的道具的成本。

继续进行购买的玩家比例。

能够创造最有价值的用户的渠道（如广告）。

执行

我们可以基于4个简单的活动获得大多数参数，这些行动都与购买行动相关：

Monetization.IAP—-当玩家真正使用真钱在游戏中购买某些东西时（如购买新的宝石，而不是消费宝石）。

Monetization.FailedIAP—-玩家尝试着进行购买但却未能完成。商店供应者提供了一些额外信息去说明原因（iTunes，Google Play等等）。

Monetization.Shop—-玩家打开商店页面。知道玩家如何到达商品页面很重要。如果特定行动（如游戏内部推广）能够创造更多销量，你便需要更频繁地进行推广（可能需要完善其呈现）。

Monetization.Spend—-玩家在商店中消费宝石去购买东西。这需要连接现实世界的货币与游戏中受欢迎的道具（因为它们是以宝石进行定价）。

行动

属性

Monetization.IAP

ProductId—-产品或产品包的数量/标识。

MaxLevel—-用户在购买后到达的游戏中的最高关卡。

ScreenReferrer—-识别最终推动这一购买的页面/推广/准入点。

$sale_value—-这一销售在现实货币中的价值。

$sale_currency—-玩家使用的现实货币（如美元）的3个字母码。

Monetization.FailedIAP

ProductId—-产品或产品包的数量/标识。

回应—-来自付款者的回应代码。

信息—-来自付款者的信息。

Monetization.Shop

页面—-这是哪个商店页面（如主商店，IAP商店等等）。

ScreenReferrer—-识别最终推动这一购买的页面/推广/准入点。

Monetization.Spend

ProductId—-玩家购买的道具数量/标识。

类型—-这属于哪种消费类型（道具升级，降低速度，生命等等）。

宝石—-玩家消费的宝石数。

MaxLevel—-用户在购买后到达的游戏中的最高关卡。

ScreenReferrer—-识别最终推动这一购买的页面/推广/准入点。

除了这些属性外，《Ancient Blocks》还在追踪一系列全局属性，即关于如何获取每个玩家。他们能够使用SDK自动完成这一行动。

IAP转换

最重要的参数之一便是游戏商店中的转换率，也就是多少进入商店（或只是玩游戏）的玩家使用现实货币进行购买。

通常情况下在这类型免费游戏中大概会有1.5%至2.5%的玩家进行购买。因为在游戏的每个回合会多次出现商店，即在一些游戏的每个关卡之后。如果一款游戏在推动玩家前往商店页面上做得太过强势，那么它的转换率可能会降低—-但这仍然是游戏中不错的转换率。

为了测量《Ancient Blocks》中的IAP转换率，我们将基于如下行动使用一个简单的漏斗：

1.Monetization.Shop（将页面属性设置为“Main”）—-玩家打开主要的商店页面。

2.Monetization.Shop（将页面属性设置为“IAP”）—-玩家打开IAP商店（销售玩家需要用现实货币购买的宝石）。

3.Monetization.IAP—-玩家进行（并完成）一次购买。

conversion funnel(from gamedev)

正如你所看到的，《Ancient Blocks》的转换率是1.36%。这远低于我们的期待值，并预示着我们需要对此作出调整。当《Ancient Blocks》的设计师修改了商店页面并添加了推广时，他们便可以重新审查转换漏斗去明确这一改变是否具有效果。

IAP失败

监督有意的IAP失败率是必要的。我们可以使用早前的Monetization.FailedIAP行动进行测量。

你应该着眼于为何付费会遭遇失败，如此才能找到解决方法（游戏邦注：尽管有时候这并不受开发者的控制）。IAP的转变也预示着支付网关，API的改变出现了问题。在每个案例中你总是希望能够主动采取行动。

IAP failure(from gamedev)

基于不同的支付供应商（游戏邦注：不管是像Google Play或App Store这样的手机供应商还是其它在线支付供应商），失败的原因也会不同。根据供应商，你将获得或多或少的一些数据。

穿过用户获取渠道去比较IAP

大多数企业会测量用户获取活动的转换效能（如第一眼被吸引的用户数与真正下载游戏的用户数）。使用Calq能进一步明确推动更多购买的用户获取渠道。

如果能够恰当地使用Monetization.IAP或Monetization.Spend行动，Calq便能够基于参照数据并使用setGlobalProperty(…)去排列数据。你需要牢记认为更多玩家来自一个渠道而不是另一个渠道的话可能存在一种偏见。你可以通过观察每个渠道的整体玩家数去清楚疑问。

IAP sources(from gamedev)

根据结果你将清楚哪个用户获取渠道需要更多成本，这一数据也能够成为用户获取预算的考虑因素。你还能够使用这一方法去测量游戏行动中其它与收益不相关的内容。通过用户获取渠道去测量用户粘性和用户留存很有用。

总结

这三篇文章是你创造游戏的起点。每一款游戏都具有差异性，所以你将需要测量不同的活动与内容。就像《Ancient Blocks》的live版便测量了比文章中提到的更多数据点。

要点：

你的最终目标将是完善核心KPI（用户留存，用户粘性和用户LTV），而为了做到这点你就需要测量并在一些较小的游戏组件中不断迭代。

参数通常都是相互联系的。完善一个常数可能会影响到其它参数，反之亦然。

你需要不断进行计划，测试与测量。一直完善并添加新功能到游戏中。且每次都要检测效果。有效的话你就需要进一步完善它并继续检测。而如果无效，你便可以重新考量或彻底删除它。一定要勇敢地删掉那些没有任何价值的功能！

（ 本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转功，如需转载请联系：游戏邦 ）

Standard Gameplay and IAP Metrics for Mobile Games (Part 3)

By Andy Savage

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.

Attached Image: AncientBlocks-IAP-Screens.jpg

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

Action

Properties

Monetization.IAP

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

Monetization.FailedIAP

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

Monetization.Shop

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.

Monetization.Spend

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.

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.

Attached Image: IAP-Conversion-Funnel.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 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.

Attached Image: IAP-Failures.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). 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.

Attached Image: GameExample-IAP-Sources.png

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.( source:gamedev )