分析手机游戏的标准游戏玩法和IAP参数（一）

夜行的猫仔

作者：Andy Savage

在接下来几周时间里，我将发布一些关于游戏玩法优化和用户转换的分析例子。我将使用一个现实游戏作为案例，即《Ancient Blocks》，你能在App Store中找到这款游戏。

acient blocks(from gamedev)

本文的报告是使用Calq，你也可以使用其它服务或自己创造这些参数。这系列文章是致力于分析“测量什么内容”而不是“如何进行测量”。

常见的关键业绩指标（KPI）

不管是哪种类型，所有手机游戏的高级KPI都是相类似的。大多数开发者的KPI将包含：

第一天，第七天以及第三十天的用户留存—-玩家回到游戏中的频率。

DAU，WAU，MAU—-每日，每周和每月的活跃用户，关于活跃玩家基础的测量

用户LTV—-玩家的终身价值（游戏邦注：通常情况下是基于各种龄组，性别，位置，用户获取广告活动等等元素所决定）。

DARPU—-每用户每日平均收益，也就是每个活跃用户每天所创造的收益。

ARPPU—-每付费用户平均收益，对于LTV的测量，但它只计算部分用户所花费的钱。

同时也存在一些特定的KPI。这将帮助你着眼于游戏中一些独立的部分，从而更好地完善它们。你的最终目标将是通过完善更多的游戏子集而更好地完善高级KPI。

用户留存

用户留存是指测量玩家在一段时间后回到你的游戏中的频率。第一天的用户留存是指隔天有多少玩家回到游戏中，第七天的用户留存意味着七天后回到游戏中的玩家。用户留存是衡量你的游戏粘性的重要指标。

衡量用户留存比衡量收益还要重要。如果你的用户终身价值不是很突出，但却拥有很棒的用户留存，那么你便可以在之后做出进一步的完善。但反过来的话情况可能就不是那么乐观了。基于较低用户留存的应用很难获得盈利。

当游戏在进行迭代时（游戏邦注：添加/删除某些功能，或调整现有的功能），用户留存便能够用于检查这些改变是否具有积极影响。

活跃的用户基础

你可能听说过“每日/每周/每月”活跃用户。这些是呈现出你的活跃用户基础规模的产业标准。例如WAU是指玩了7天游戏的玩家数量。使用DAU/WAU/MAU测量能够帮助你轻松地衡量用户是处于发展，收缩还是平稳状态。

活跃用户测量需要与用户留存数据一起进行分析。如果你拥有许多新用户，但却失去了同样比例的现有用户，那么你的用户基础便是基于平稳状态。

游戏特定的KPI

除了常见的KPI，每一款游戏还带有特定的额外参数。这可能包含了游戏中玩家的进程（如关卡），游戏机制，平衡参数，病毒性传播以及分享循环等等数据。

你同样也需要衡量大多数用户旅程（用户在游戏中与不同路径的互动，如开始新游戏的菜单），如此你才能够去优化它们。

就像在《Ancient Blocks》中，游戏的特定参数包括：

玩家进程：

完成了哪些关卡。

玩家是否重玩了一个更复杂的难度。

关卡难度：

玩家尝试了几次才完成一个关卡。

玩家在一个关卡中花了多少时间。

玩家在完成一个关卡前使用了多少道具。

游戏内部货币：

用户什么时候花费游戏内部货币？

他们使用游戏内部货币购买什么？

玩家在购买前通常会做些什么？

游戏内部教程

当玩家第一次开始游戏时，他们通常会看到一个教授新玩家如何游戏的互动教程。这通常是玩家对于游戏的第一印象，所以你需要好好完善它。糟糕的教程会破坏你的第一天用户留存。

《Ancient Blocks》拥有一个10个步骤的教程去教会玩家如何游戏（垂直拖动砖块直至它们能够对齐）。

目标

关于教程的数据收集需要呈现任何需要完善的领域。通常情况下这些领域都是玩家受困，或花费较长时间的地方。

识别教程中任何阻塞点（即玩家受困的地方）。

迭代这些教程步骤以完善转换率（玩家成功走到游戏最后的比例）。

参数

为了完善教程，你需要定义一套针对于教程的参数。关于《Ancient Blocks》，我们需要的关键参数是：

通过每个教程步骤的玩家比例。

真正完成教程的玩家比例。

玩家花费在每个步骤的时间。

在完成教程后继续游戏的玩家比例。

执行

calq(from gamedev)

追踪教程步骤便是直接使用基于行动的分析平台—-就像我们使用了Calq。《Ancient Blocks》使用了一个名为“教程步骤”的行动。这一行动包含了名为“步骤”的特定属性，以说明玩家处于哪个教程步骤中（0指代第一个步骤）。我们同样也想要追踪用户在每个步骤所花费的时间。为了做到这点我们还添加了名为“持续时间”的属性。

行动

教程步骤

属性

步骤—-当前的教程步骤（从0开始，1，2，3依此类推）。

持续时间—-玩家完成步骤的时间（以秒为单位）。

分析

分析教程数据其实很简单。我们可以通过创造一个简单的转换漏斗而获得大部分参数，即漏斗的每一步就等于教程的每一个阶段。

完整的漏斗能够一步步地呈现出整个教程的转换率。在此我们可以轻松地看到哪个步骤“流失”掉最多用户。

正如你所看到的结果：比起其它步骤的99%转换率，第四步的转换率大约是97%。所以这预示着你需要完善这一步。尽管只有1个百分点的差别，但这可能意味着你每个月在这一步骤上会损失1千美元的收益。如果是一款更受欢迎的游戏，差别将会更大。

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

Standard Gameplay and IAP Metrics for Mobile Games

By Andy Savage

Over the next few weeks I am publishing some example analytics for optimising gameplay and customer conversion. I will be using a real world example game, “Ancient Blocks”, which is actually available on the App Store if you want to see the game in full.

The reports in this article were produced using Calq, but you could use an alternative service or build these metrics in-house. This series is designed to be “What to measure” rather than “How to measure it”.

Attached Image: GameStrip.jpg

Common KPIs

The high-level key performance indicators (KPIs) are typically similar across all mobile games, regardless of genre. Most developers will have KPIs that include:

D1, D7, D30 retention – how often players are coming back.

DAU, WAU, MAU – daily, weekly and monthly active users, a measurement of the active playerbase.

User LTVs – what is the lifetime value of a player (typically measured over various cohorts, gender, location, acquiring ad campaign etc).

DARPU – daily average revenue per user, i.e. the amount of revenue generated per active player per day.

ARPPU – average revenue per paying user, a related measurement to LTV but it only counts the subset of users that are actually paying.

There will also be game specific KPIs. These will give insight on isolated parts of the game so that they can be improved. The ultimate goal is improving the high-level KPIs by improving as many sub-game areas as possible.

Retention

Retention is a measure of how often players are coming back to your game after a period. D1 (day 1) retention is how many players returned to play the next day, D7 means 7 days later etc. Retention is a critical indicator of how sticky your game is.

Arguably it’s more important to measure retention than it is to measure revenue. If you have great retention but poor user life-time values (LTV) then you can normally refine and improve the latter. The opposite is not true. It’s much harder to monetise an application with low retention rates.

A retention grid is a good way to visualize game retention over a period

When the game is iterated upon (either by adding/removing features, or adjusting existing ones) the retention can be checked to see if the changes had a positive impact.

Active user base

You may have already head of “Daily/Weekly/Monthly” Active Users. These are industry standard measurements showing the size of your active user base. WAU for example, is a count of the unique players that have played in the last 7 days. Using DAU/WAU/MAU measurements is an easy way to spot if your audience is growing, shrinking, or flat.

Active user measurements need to be analysed along side retention data. Your userbase could be flat if you have lots of new users but are losing existing users (known as “churn”) at the same rate.

Game-specific KPIs

In addition to the common KPIs each game will have additional metrics which are specific to the product in question. This could include data on player progression through the game (such as levels), game mechanics and balance metrics, viral and sharing loops etc.

Most user journeys (paths of interaction that a user can take in your application, such as a menu to start a new game) will also be measured so they can be iterated on and optimised.

For Ancient Blocks game specific metrics include:

Player progression:

Which levels are being completed.

Whether players are replaying on a harder difficulty.

Level difficulty:

How many attempts does it takes to finish a level.

How much time is spent within a level.

How many power ups does a player use before completing a level.

In game currency:

When does a user spend in game currency?

What do they spend it on?

What does a player normally do before they make a puchase?

In-game tutorial

When a player starts a game for the first time, it is typical for them to be shown an interative tutorial that teaches new players how to play. This is often the first impression a user gets of your game and as a result it needs to be extremely well-refined. With a bad tutorial your D1 retention will be poor.

Ancient Blocks has a simple 10 step tutorial that shows the user how to play (by dragging blocks vertically until they are aligned).

Goals

The data collected about the tutorial needs to show any areas which could be improved. Typically these are areas where users are getting stuck, or taking too long.

Identify any sticking points within the tutorial (points where users get stuck).

Iteratively these tutorial steps to improve conversion rate (the percentage that get to the end successfully).

Metrics

In order to improve the tutorial a set of tutorial-specific metrics should be defined. For Ancient Blocks the key metrics we need are:

The percentages of players that make it through each tutorial step.

The percentage of players that actually finish the tutorial.

The amount of time spent on each step.

The percentage of players that go on to play the level after the tutorial.

Implementation

Tracking tutorial steps is straight-forward using an action-based analytics platform – in our case, Calq. Ancient Blocks uses a single action called Tutorial Step. This action includes a custom attribute called Step to indicate which tutorial step the user is on (0 indicates the first step). We also want to track how long a user spend on each step (in seconds). To do this we also include a property called Duration.

Action Properties

Tutorial Step

Step – The current tutorial step (0 for start, 1, 2, 3 … etc).

Duration – The duration (in seconds) the user took to complete the step.

Analysis

Analysing the tutorial data is reasonably easy. Most of the metrics can be found by creating a simple conversion funnel, with one funnel step for each tutorial stage.

The completed funnel query shows the conversion rate of the entire tutorial on a step by step basis. From here it is very easy to see which steps “lose” the most users.

Attached Image: GameExample-Tutorial-Funnel2.png

As you can see from the results: step 4 has a conversion rate of around 97% compared to 99% for the other steps. This step would be a good candidate to improve. Even though it’s only a 1 percentage point difference, that still means around $1k in lost revenue just on that step. Per month! For a popular game the different would be much larger.

Part 2 continues next week, looking at metrics on game balance and player progression.(source:gamedev)

夜行的猫仔

作者：Andy Savage

在本文中我们将着眼于使用分析学原理去衡量并完善我们所列举的《Ancient Blocks》的游戏玩法。就像之前所提到的，你可以在App Store上找到这款游戏。

本系列文章的报告是使用Calq，你也可以使用其它服务或自己创造这些参数。这系列文章是致力于分析“测量什么内容”而不是“如何进行测量”。

衡量你的游戏玩法

显然，游戏玩法是手机游戏成功的重要元素。如果游戏玩法一点都不有趣的话，不管图像或音效多么出色，你的游戏也是一无是处。

不同类型游戏的游戏玩法也不同。就像我们所列举的《Ancient Blocks》是一款基于关卡的益智游戏，所以我们在此所收集的参数也是基于此。如果你要遵循本文去调整自己的游戏，你可能需要相对应地调整一些参数。

游戏平衡

游戏平衡非常重要。如果游戏太过简单的话玩家便很容易感到无聊。而如果游戏太过复杂的话玩家便会受挫并彻底退出游戏。我们应该避开这两种情况。

对于《Ancient Blocks》，我们将记录的最初游戏参数是：

完成第一个关卡的玩家比例。

完成前五个关卡的玩家比例。

未完成任何关卡便退出游戏的玩家比例。

玩家在通过一个关卡前重新玩这个关卡的次数。

玩家玩每个关卡平均花费的时间。

玩家通过每个关卡所使用的道具数量。

玩家为了通过每个关卡所移动的砖块数量。

玩家为了通过每个关卡所触发的砖块爆炸次数。

执行

这款游戏非常简单，我们可以通过3个行动获得许多有用的数据：Gameplay.Start指玩家开始游戏的一个新关卡。Gameplay.Finish指玩家完成一个关卡（不管他们是成功还是失败），Gameplay.PowerUp指玩家在玩一个关卡时使用《Ancient Blocks》的一个特殊道具（游戏邦注：炸弹，颜色移动或放慢速度）。

Gameplay.Start

关卡—-玩家玩的关卡数（如第七个关卡）。

难度—-玩家当前玩的关卡的难度设定。

Gameplay.Finish

关卡—-玩家玩的关卡数（如第七个关卡）。

难度—-玩家当前玩的关卡的难度设定。

持续时间—-玩家完成这个关卡的时间（以秒为单位）。

成功—-玩家是否通过关卡，还是被打败了。

道具—-玩家使用一种特殊道具的次数。

砖块—-玩家在这个关卡中移动了多少砖块。

发射—-玩家在这个关卡中触发的发射（匹配一系列砖块）数。

Gameplay.PowerUp

Id—-玩家所使用的道具的数字Id。

关卡—-玩家玩的关卡数（如第七个关卡）。

难度—-玩家当前玩的关卡的难度设定。

之后—-当玩家使用了一种道具时他们在关卡中待了多长时间（以秒为单位）。

分析

基于上述的三个行动，我们能够更深入地分析玩家的行为和游戏平衡。

早前的玩家进程

玩家最初的体验不仅是关于教程，还可能延伸到前几个关卡中。进程率是关于前几个关卡是否平衡的重要指标，不管玩家是否真的理解那个告诉他们如何游戏的教程。

在《Ancient Blocks》中，玩家完成每个关卡所需要花费的时间较短，所以我们将透过前10个关卡分析玩家最初的进程。为了做到这点，我们可以创造一个对话漏斗去描述玩家在前10个关卡中的旅程。该漏斗需要10个步骤，即针对于这前10个关卡。我们将分析的行动是Gameplay.Finish，它代表完成一个关卡。

每个步骤都需要一个过滤器。第一个过滤器需要关卡Id去过滤步骤到正确的关卡上，而成功属性中的第二个过滤器只需要包含通过的关卡便可。我们并不需要在进程统计中包含失败的尝试。

funnel(from gamedev)

所有的游戏都将随着关卡的增加而伴随着自然的下降速度，因为并非所有玩家都想要进入更深层的游戏中。有些人并不想玩你的游戏—-我们的追求都不同，这也不是什么坏事。然而如果某些关卡拥有高出我们期待的掉落速度，或者比起前面的关卡拥有突然掉落的设置，那么这些关卡便有可能导致游戏的失衡。如果关卡太难的话便会失去乐趣，或者玩家有可能不能理解自己为何要不断前进。

关卡完成率

玩家进程并不能呈现成体概况。玩家可能会在完成关卡前多次尝试这个关卡，而转换率并不会告诉你这一情况。我们需要着眼于玩家玩每个关卡的次数以及真正成功完成这项关卡的次数的比较。

举个例子来说吧，让我们着眼于《Ancient Block》的第三个关卡。我们可以着眼于玩家玩这一关卡的次数并将其分解为成功与失败两个部分。我们将再次使用Gameplay.Finish行动，并使用过滤器去呈现第三个关卡。这一次我们将通过成功属性去呈现成功率并划分结果。

game example(from gamedev)

基于《Ancient Blocks》的设计规格，第三个关卡拥有75%的成功率。就像你所看到的结果那样，这有点困难，虽然也不是太过困难。适当转变关卡参数能够帮助我们更轻松地实现目标。

中止回合

衡量早前游戏玩法的一个有帮助的参数是比较开始一个关卡的玩家数量，而不是完成这个关卡的玩家数量。这对于在教程关卡结束后进行衡量非常有帮助。如果玩家只是退出游戏，那么可能是因为他们不喜欢游戏，或者在哪个地方受挫了。

我们可以使用较短的对话漏斗对此进行衡量。即使用Gameplay .Start行动，之前文章提到的教程步骤行动（如此我们便可以只瞄准那些已经完成了教程的玩家）以及Gameplay.Finish行动。

aborted sessions(from gamedev)

上述所呈现的结果是64.9%（这是漏斗中第二和第三步之间的结果）真正完成了教程的玩家继续完成了关卡。这意味着有35.1%的玩家退出了游戏。这一数值高于我们的预期，即表示游戏失去了许多玩家。这也是帮助《Ancient Blocks》设计师做出进一步完善的重要参数。

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

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

By Andy Savage

In this article we will be looking at using analytics to measure and improve gameplay for 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”.

Measuring gameplay

Gameplay is obviously a critical component in the success of a mobile game. It won’t matter how great the artwork or soundtrack is if the gameplay isn’t awesome too.

Drilling down into the gameplay specifics will vary between games of different genres. Our example game, Ancient Blocks, is a level-based puzzle game and the metrics that are collected here will reflect that. If you are following this series for your own games then you will need to adjust the metrics accordingly.

Attached Image: GameStrip.jpg

Game balance

It’s imperative that a game is well balanced. If it’s too easy then players will get bored. If it’s too hard then players will get frustrated and may quit playing entirely. We want to avoid both scenarios.

For Ancient Blocks the initial gameplay metrics we are going to record are:

The percentage of players who finish the first level.

The percentage of players who finish the first 5 levels.

The percentage of players that quit without finishing a level.

The number of times a player replays a level before passing the level.

The average time spent playing each level.

The number of “power ups” that a player uses to pass each level.

The number of blocks a player swipes to pass each level.

The number of launches (block explosions) that a player triggers to pass each level.

Implementation

The example game is reasonably simple and we can get a lot of useful data from just 3 actions: Gameplay.Start for when a player starts a new level of our game, Gameplay.Finish for when a user finishes playing a level (the same action for whether they passed or failed), and Gameplay.PowerUp for when a player uses one of Ancient Blocks’ special power-ups (bomb, colour remove, or slow down) whilst playing a level.

Action Properties

Gameplay.Start

Level – The number of the level being played (e.g. level 7).

Difficulty – The current difficulty setting of the level being played.

Gameplay.Finish

Level – The number of the level being played (e.g. level 7).

Difficulty – The current difficulty setting of the level being played.

Duration – The duration (in seconds) the player took to finish this level.

Success – Whether or not the user passed the level (true) or if they were defeated (false).

PowerUps – The number of times a special power-up ability was used.

Blocks – The number of blocks the player moved during this level.

Launches – The number of times a player triggered a launch (matched a sequence of blocks) during this level.

Gameplay.PowerUp

Id – The numeric id of the power-up that was used.

Level – The number of the level being played (e.g. level 7).

Difficulty – The current difficulty setting of the level being played.

After – The amount of time (in seconds) into the level the user was when they used a power-up.

Analysis

With just the 3 actions defined above it is possible to do a range of in-depth analysis on player behaviour and game balance.

Early player progression

A player’s initial experience of a game extends beyond the tutorial to the first few levels. It is critical to get this right. Progress rate is a great indicator of whether or not the first levels are balanced, and whether players really understood the tutorial that showed them how to play (tutorial metrics were covered in the previous article).

For Ancient Blocks the time taken on each level is reasonably short and so we are going to analyse initial progression through the first 10 levels. To do this we can create a conversion funnel that describes the user journey through these first 10 levels (or more if we wanted). The funnel will need 10 steps, one for each of the early levels. The action to be analysed is Gameplay.Finish as this represents finishing a level.

Each step will need a filter. The first filter needs to be on the level Id to filter the step to the correct level, and a second filter on the Success property to only include level play that passed. We don’t want to include failed attempts at a level in our progression stats.

All games will have a natural rate of drop off as levels increase since not all players will want to progress further into the game. Some people just won’t enjoy playing your game – we are all different in what we look for and that’s no bad thing. However, if certain levels are experiencing a significantly larger drop off than we expect, or a sudden drop compared to the level before, then those levels are good candidates to be rebalanced. It could be that the level is too hard, it could be less enjoyable, or it could be that the player doesn’t understand what they need to do to progress.

Level completion rates

Player progression doesn’t provide the entire picture. A level might be played many times before it is actually completed and a conversion funnel doesn’t show this. We need to look at how many times each level is being played compared to how many times it is actually completed successfully.

As an example, let’s look at Ancient Block’s 3rd level. We can query the number of times the level has been played and break it down into successes and failures. We do this using the Gameplay.Finish action again, and apply a filter to only show the 3rd level. This time we group the results by the Success property to display the success rate.

The design spec for Ancient Blocks has a 75% success rate target for the 3rd level. As you can see from the results above it’s slightly too hard, though not by much. A little tweaking of level parameters could get us on target reasonably easily.

Aborted sessions

An incredibly useful metric for measuring early gameplay is comparing the number of people that start a level but don’t actually finish it – i.e. closed the application (pressed the home button etc). This is especially useful to measure straight after the tutorial level. If players are just quitting then they either don’t like the game, or they are getting frustrated.

We can use a short conversion funnel to measure this. By using the Gameplay.Start action, the Tutorial Step action from the previous article (so we can include only people who finished the tutorial already), and the Gameplay.Finish action.

The results above show that 64.9% of players (which is the result between the 2nd and 3rd step in the funnel) that actually finished the tutorial went on to also finish the level. This means 35.1% of players quit the game in that gap. This number is much higher than we would expect, and represents a lot of lost players. This is a critical metric for the Ancient Blocks designers to iterate on and improve.

Part 3 of the series will continue by looking at increasing revenue by optimising the user journey for in-app purchases (IAPs).(source:gamedev）

tianheww

学到东西了。。。。。感谢。。。。。。