作者：Anders Drachen

近年来，游戏分析学已经引发人们极大的关注。

研究玩家对游戏公司的商务、设计等各个部门都非常有帮助，应此要求，有必要向游戏开发人员介绍这种分析技术。游戏分析学也因此逐渐成为行业的商业智能中的重要领域。通过遥测技术、市场调查、QA系统、基准测试等各种来源获得的定量数据成为商业智能管理、决策的重要参考。（请点击此处阅读本文第2部分）

将分析学引入开发过程时，有两个重要问题要考虑，一是追踪什么，二是如何分析获得的数据。选择收集什么资料的过程叫作特征选择。特征选择是个困难的任务，特别是当针对的是用户行为时。决定追踪什么用户

行为并没有唯一正确的答案或标准模型；相反地，我们要根据不同的目标选择不同的策略；例如，改进用户体验或增加赢利。在本文中，我们将概述与游戏玩家分析学有关的基本原理，其中特征选择是重点。首先，我们会概述可追踪的用户数据的类型，然后介绍特征选择的过程，即在什么地方如何选择什么来测量。最重要的是，本文并不针对免费游戏或在线游戏——分析学适用于所有游戏。

分析学的数据

游戏分析学的数据来源主要有三种：

1、性能数据：这些是与技术和硬件有关的数据，尤其是在线或持续型游戏。普遍的性能指标包括游戏在客户端硬件平台的执行帧率或游戏服务器的稳定性。

2、过程数据：这些是与开发游戏的实际过程有关的数据。游戏开发或多或少是一个创造性过程，但仍然需要监控，即估计任务量和制定计划等。

3、用户数据：这是最常见的数据来源，这些数据来自玩我们的游戏的用户。这里，我们既把用户当作消费者（收益来源）也当作玩家（与游戏产生特定交互活动的对象）。我们计算与收益有关的指标如每用户平均收益（ARPU）、日活跃用户（DAU），或者执行与收益有关的分析如用户流失分析、用户支持性能分析或微交易分析时，我们称游戏用户为消费者。

当研究人们与游戏系统、系统的组件以及其他玩家如何产生交互作用（游戏邦注：主要是游戏内行为如平均游戏时间等）时，我们称游戏用户为玩家。本文针对的是这类数据。这三类数据不包含一般的商业数据如公司市值、公司收益等。我们不把这类数据当作游戏分析学中的特定领域，而是把它归入商业分析学的一般范畴中。

游戏分析学的数据来源层级图(from gamasutra)

用户数据的指标

过去几年，已经有不少人提出分类用户数据的不同方法。从自上而下的角度看，开发导向型的分类法是很实用的，因为它可以在三种不同利息相关者的这三个方向上过滤用户指标：

1、消费者指标：包括用户作为消费者的各个方面——例如，消费者开发和留存的成本。这些指标对游戏的营销和管理以及游戏开发特别有意义。

2、社区指标：包括所有忠实程度的用户社区的活动，如论坛活动。这些指标对社区经理很有用。

3、玩法指标：与用户作为游戏内的玩家的实际行为（游戏邦注：例如使用道具、交易物品、探索游戏世界等）有关的任何变量。玩法指标对评估游戏设计和用户体验最为重要，但从游戏开发的收益链这个传统的角度上看，它通常不是优先考虑的指标。这些指标对从事游戏设计、用户研究、QA或主要研究用户实际行为的人员最有用。

具体分析

1、消费者指标：作为消费者，用户可以下载和安装游戏、在游戏内外商店中购买任意数量的虚拟商品、支付真钱或虚拟货币。与此同时，消费者与客户服务互动、提交漏洞报告、请求帮助、申诉等。用户也可以参与官方或非官方的论坛活动、登录其他社交互动平台，从这些渠道可以获取和分析关于这些用户以及他们的游戏行为、对游戏的满意度的信息。我们还可以收集消费者的国家、IP地址和甚至年龄、性别、邮件地址等信息。将这些玩家群体信息、行为数据相结合，有助于深入地了解游戏的消费者基础。

2、社区指标：如果有条件，用户之间会产生互动行为。这种互动行为可以是玩法上的（如通过游戏机制进行战斗或合作），也可以是社交上的（如游戏内聊天）。玩家-玩家的互动可以发生在游戏内，也可以发生在游戏外，或二者混合——如通过“分享到Facebook”的功能发送炫耀新装备的信息。在游戏内，玩家可以通过内置聊天功能互相交流；在游戏外，玩家可以使用即时会话工具如TeamSpeak或Skype，或者通过游戏论坛来沟通。

这类玩家之间的互动活动形式是重要的信息来源，具有广泛作用。例如，通过分析免费游戏的用户社区的社交网络，可以知道哪些玩家有很发达的社交关系网——这类玩家有助于创造良好的社交环境，从而留住大量其他玩家（相当于MMORPG中的公会领袖）。与此类似，聊天日志和论坛帖子可以提供关于游戏设计的问题的信息。例如，从在线游戏的聊天日志中抽取数据可以发现漏洞或其他问题。监控并分析玩家-玩家互动行为在任何情况下都是重要的，因为多玩家，特别是对于致力于创造和支持稳定型玩家社区、采用在线商业模的游戏，包括许多社交在线游戏和免费游戏。这些例子只是冰山一角，收集、分析和报告关于玩家-玩家互动行为的游戏指标是可以轻轻松松就写出好几本书的话题。

3、玩法指标：这个用户指标的亚类可能是目前在使用中的游戏遥测技术中最广泛记录和利用的一类。玩法指标主要用于衡量玩家行为：导航、道具和技能的使用、跳跃、交易、奔跑等玩家在虚拟的游戏环境（无论是2D还是3D）中的活动。当玩家在游戏中做某事或某事发生在游戏中的玩家身上时，有四种信息可以记录：发生什么？在哪里发生？什么时候发生？与谁有关？

玩法指标对游戏设计特别有用，因为设计师可以通过它了解几个关键问题，例如是否有哪些游戏世界区域使用过多或过少、玩家是否按设计意图使用游戏功能、和是否有拖延玩家进度的障碍等。在游戏开发的任何阶段仍至游戏发布以后，都可以记录这些游戏指标。

在一次游戏过程中，玩家可能产生上千种行为——每一次玩家在游戏系统中做出行为，游戏就必须产生回应。玩家活动的准确评估可能包含按秒来测量的各种行为。例如，在典型的MMORPG如《魔兽世界》中，测量玩有行为可能包括记录玩家角色的位置、当前命值、精力值、魔法值、法术效果的影响时间、主动行为（奔跑、挥动斧头等）、状态（战斗、交易、探索等）、NPC敌人对玩家的态度、玩家角色的名字、种族、等级、装备、金钱等等——所以这些小信息都要从安装的游戏客户端流向收集服务器。

从实用的角度来说，你可以把玩法指标进一步分类成如下三种类型（为了使你的指标更容易搜索）：

游戏内：包括所有游戏内活动和玩家行为，如探索、经济行为、使用物品等。这类信息最主要来自用户遥测技术。

界面：包含所有玩家与游戏界面和菜单发生的互动活动。这包括设置游戏变量如鼠标灵敏度和显示器亮度。

系统：系统指标包括游戏引擎及其亚系统（AI系统、自动事件、MOB/NPC活动等）对玩家活动产生的反应。例如，如果玩家角色移动到怪群的仇恨范围内，怪群就会攻击玩家角色，或者当玩家角色满足预设条件时，就会升到下一级。

综上，从游戏用户（或游戏服务）中得到的可能测量工作量也许会大得惊人，通常我们应该把目标确定为记录和分析最必要的信息。这个选择过程存在偏好，但通常必须避免数据过多，以确保分析工作的可行性。

整合分析

在选择要监控的特征和评估要采用的策略时，往往会对收集什么数据产生偏见，特别是当分析工作没有确定的根据时。如果那些负责分析的人不能与利益相关者交流沟通，那么极有可能遗漏关键信息，同时分析也实现不了全部价值。

因为分析人员来自不同部门，如用户研究、营销和赢利，这导致分析团队只服务或优先服务于自己的母部门。保证分析团队与所有团队保持交流，有助于缓和这种情况。这也有助于减轻另一个常见的问题，也就是分析团队因为不能接触到设计团队，被迫自行选择特征来追踪和分析，这样他们的工作就缺少游戏设计及其赢利模式作为根据。

甚至对于雇用业余分析人员的小开发者，这也可能是个问题。另一个典型的问题是，在没有分析团队参与的情况下，就决定追踪什么行为。这可能导致的结果是，在处理不必要的数据上浪费大量时间，或不得不记录额外的数据。团队之间良好的沟通也有助于缓和分析和设计之间的摩擦。

重要的是，分析应该与生产相结合——贯穿早期设计环节。应该在早期计划好要追踪什么行为和追踪的频率。这有利于确保分析对设计、赢利、营销等产生价值。永远不应该在测试之后才进行分析。如果是这样，分析学的作用就无异于用户研究，在理想的情况下，分析学应该贯穿于开发过程和游戏发布后。

特征选择

知道我们可以测量的用户行为有很多，但我们怎么选择？我们确实必须做选择吗？很遗憾，是的。在现实生活中，我们几乎没有可用于追踪和分析所有用户行为的资源，这意味着我们必须开发一种分析方法，能考虑到追踪、储存和分析用户遥测技术/指标所需的资源，和可获得的价值之间的成本-收益关系。还应该意识到在不同生产阶段和发布后所需的分析方法也是不一样的。例如，在开发的后期阶段，协调设计是关键，但许多与赢利有关的指标无法计算，因为目标受众还没开始消费。

我们将在下文中进一步讨论，但简单地说，根据这一系列推断，我们应该追踪、储存和分析的用户属性至少应该包含以下几点：

1、一般属性：所有游戏的用户都具有的属性（作为玩家和消费者）。对于任何电脑游戏，都可以随时收集这些属性形成的核心指标——例如，用户开始或结束游戏的时间、用户ID、用户IP、入口点等等。这些是所有游戏分析学数据集的核心。

2、核心机制/设计属性：这些是与核心玩法和游戏机制相关的必要属性（例如，与游戏持续时间有关的属性、花费的虚拟货币、杀敌数量等等）。确定核心设计属性应该直接以游戏的关键玩法机制以基础，且应该提供允许设计师推测用户体验（如玩家的进度是否符合设计、流量是否持续、死亡率、关卡完成、得分等）的信息。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Intro to User Analytics

by Anders Drachen

The science of game analytics has gained a tremendous amount of attention in recent years. Introducing analytics into the game development cycle was driven by a need for better knowledge about the players, which benefits many divisions of a game company, including business, design, etc. Game analytics is, therefore, becoming an increasingly important area of business intelligence for the industry. Quantitative data obtained via telemetry, market reports, QA systems, benchmark tests, and numerous other sources all feed into business intelligence management, informing decision-making.

Two of the most important questions when integrating analytics into the development process are what to track, and how to analyze the data. The process of choosing what to collect is called feature selection. Feature selection is a challenge, perhaps especially when it comes to user behavior. There is no single right answer or standard model we can apply to decide what behaviors to track; there are instead several strategies that vary in goals: e.g., improve the user experience or increase monetization. In this article, we will attempt to outline some of the fundamental concerns in user-oriented game analytics, with feature selection as an overall theme. First, we’ll walk through the types of trackable user data, and then introduce the feature selection process, where you select how and what to measure. Importantly, this article is not focused on F2P and online games — analytics is useful for all games.

Data for Analytics

The three main sources of data for game analytics are:

Performance data: These are related to the performance of the technical- and software-based infrastructure behind a game, notably relevant for online or persistent games. Common performance metrics include the frame rate at which a game executes on a client hardware platform, or in the case of a game server, its stability.

Process data: These are related to the actual process of developing games. Game development is to a smaller or greater degree a creative process, but still requires monitoring, e.g., via task-size estimation and the use of burndown charts.

User data: By far the most common source of data, these are derived from the users who play our games. We view users either as customers (sources of revenue) or players, who behave in a particular way when interacting with games. The first perspective is used when calculating metrics related to revenue — average revenue per user (ARPU), daily active users (DAU) — or when performing analyses related to revenue (churn analysis, customer support performance analysis, or microtransaction analysis).

The second perspective is used for investigating how people interact with the actual game system and the components of it and with other players, by focusing on in-game behavior (average playtime, damage dealt per session, and so forth). This is the type of data we will focus on here. These three categories do not cover general business data, e.g., company value, company revenue, etc. We do not consider such data the specific domain of game analytics, but rather as falling within the general domain of business analytics.

Figure 1: Hierarchical diagram of sources of data for game analytics emphasizing user metrics.

Developing Metrics From User Data

Many people have proposed different methods of classifying user data over the past few years. From a top-down perspective, a development-oriented classification system is useful, as it serves to funnel user metrics in the direction of three different classes of stakeholders — for example, as follows.

Customer metrics: Covers all aspects of the user as a customer — for example, cost of customer acquisition and retention. These types of metrics are notably interesting to professionals working with marketing and management of games and game development.

Community metrics: Covers the movements of the user community at all levels of resolution, such as forum activity. These types of metrics are useful to community managers.

Gameplay metrics: Any variable related to the actual behavior of the user as a player inside the game (object interaction, object trade, and navigation in the environment, for example).

Gameplay metrics are the most important for evaluating game design and user experience, but are furthest from the traditional perspective of the revenue chain in game development, and hence are generally underprioritized. These metrics are useful to professionals working with design, user research, quality assurance, or any other position where the actual behavior of the users is of interest.

Customer metrics: As a customer, users can download and install a game, purchase any number of virtual items from in-game or out-of-game stores and shops, spending real or virtual currency,over shorter or longer timespans. At the same time, customers interact with customer service, submitting bug reports, requests for help, complaints, and so on. Users can also interact with forums, official or not, or other social-interaction platforms, from which information about these users, their play behavior, and their satisfaction with the game can be mined and analyzed. We can also collect information on customers’ countries, IP addresses, and sometimes even age, gender, and email addresses. Combining this kind of demographic information with behavioral data can provide powerful insights into a game’s customer base.

Community metrics: Users interact with each other if they have the opportunity. This interaction can be related to gameplay (combat or collaboration through game mechanics) or social (in- game chat). Player-player interaction can occur in-game or out-of-game, or some combination thereof — for example, sending messages bragging about a new piece of equipment using a post-to-Facebook function. In-game, users can interact with each other via chat functions, out-of-game via live conversation (TeamSpeak or Skype), or via game forums.

These kinds of interactions between players form an important source of information, applicable in an array of contexts. For example, a social-network analysis of the user community in a F2P game can reveal players with strong social networks — who are the players likely to help retain a big number of other players in the game by creating a good social environment (think guild leaders in MMORPGs). Likewise, mining chat logs and forum posts can provide information about problems in a game’s design. For example, data-mining datasets derived from chat logs in an online game can reveal bugs or other problems. Monitoring and analyzing player-player interaction is important in all situations where there are multiple players, but especially in games that attempt to create and support a persistent player community, and which have adopted an online business model, which includes many social online games and F2P games. These examples are just the tip of a very deep iceberg, and the collection, analysis, and reporting on game metrics derived from player-player interaction is a topic that could easily take up several volumes.

Gameplay metrics: This subcategory of the user metrics is perhaps the most widely logged and utilized type of game telemetry currently in use. Gameplay metrics are measures of player behavior: navigation, item and ability use, jumping, trading, running, and whatever else players actually do inside the virtual environment of a game (whether 2D or 3D). Four types of information can be logged whenever a player does something or something happens to a player in a game: What is happening? Where is it happening? At what time is it happening? And: Who is involved?

Gameplay metrics are particularly useful for informing game design. They provide the opportunity to address key questions, including whether any game world areas are over- or underused, if players utilize game features as intended, and whether there are any barriers hindering player progression. These kind of game metrics can be recorded during all phases of game development,as well as following launch.

Players can generate thousands of behavioral measures over the course of a single game session — every time a player inputs something to the game system, it has to react and respond.

Accurate measures of player activity can include dozens of actions being measured per second. Consider, for example, players in a typical fantasy MMORPG like World of Warcraft: Measuring user behavior could involve logging the position of the player’s character, its current health, mana, stamina, the time of any buffs affecting it, the active action (running, swinging an axe), the mode (in combat, trading, traveling), the attitude of any NPC enemies toward the player, the player character name, race, level, equipment, currency, and so on — all these bits of information simply flow from the installed game client to the collection servers.

From a practical perspective, you may want to further subdivide gameplay metrics into the following three categories (in order to make your metrics more searchable, for instance):

In-game: Covers all in-game actions and behaviors of players, including navigation, economic behavior, as well as interaction with game assets such as objects and entities. This category will in most cases form the bulk of collected user telemetry.

Interface: Includes all interactions the player performs with the game interface and menus. This includes setting game variables, such as mouse sensitivity and monitor brightness.

System: System metrics cover the actions game engines and their subsystems (AI system, automated events, MOB/NPC actions, and so on) initiate to respond to player actions. For example, a MOB attacking a player character if it moves within aggro range, or progressing the player to the next level upon satisfaction of a predefined set of conditions.

To sum up, the array of potential measures from the users of a game (or game service) can be staggering, and generally we should aim for logging and analyzing the most essential information. This selection process imposes a bias, but is often necessary to avoid data overload and to ensure a functional workflow in analytics.

Integrating Analytics

Bias is introduced in the dataset both by the selection of the features to be monitored and also by the measuring strategies adopted, and that happens to a large degree when analysts work in a vacuum. If those responsible for analytics cannot communicate with all relevant stakeholders, critical information will invariably end up missing and the full value of analytics will not be realized.

Analytics groups are placed differently across companies due to analytics arriving to the industry from different directions, notably user research, marketing, and monetization, and this can lead to a situation where the analytics team only services or prioritizes their parent department. Having a strong lateral integration — making sure that the analytics team communicates with all the teams, for example — helps to avoid this issue. This also helps alleviate the common problem that the analytics teams, without having sufficient access to design teams, are forced to self-select features to track and analyze, without having the proper grounding in the design of the game and its monetization model.

Even for a small developer with a part-time analyst this can be a problem. Another typical problem is that the decision about which behaviors to track is made without involving the analytics team. This can lead to a lot of extra time spent later on trying to work with data that are not exactly what is needed, or needing to record additional datasets. Good communication between teams also helps alleviate friction between analytics and design.

Importantly, analytics should be integrated from the onset of a production — all the way back in the early design phases. Early on it should be planned what kinds of behavior that should be tracked and with what types of frequencies. This allows for optimal planning of how to ensure value from analytics to design, monetization, marketing, etc. Analytics should never be slapped on sometime after the beta. In this way analytics is similar to other tools like user research, in that it ideally is embedded throughout the development processes, and after launch.

Feature Selection

Knowing that there is an array of things we can measure about user behavior, how do we then select among them? And do we really have to make choices here? Sadly, yes. In real life, we rarely have the resources to track and analyze all possible user behaviors, which means we have to develop an approach to analytics that considers cost-benefit relationships between the resources required for tracking, storing, and analyzing user telemetry/metrics on one hand, and the value of the insights obtained on the other. It is also important to be aware that the analyses needed during different stages of production and post-launch varies. For example, during the latter phases of development, tuning design is vital, but many metrics related to monetization cannot be calculated because purchases have not been made by the target audience yet.

We will discuss this in more detail below, but in short, by following this line of reasoning, the minimum set of user attributes that should be tracked, stored, and analyzed should include considerations as to the following:

1) General attributes: The attributes that are shared for users (as customers and players) across all games. These form the core metrics that can always be collected, for any computer game– for example, the time at which a user starts or stops playing, a user ID, user IP, entry point, and so on. These form the core of any game analytics dataset.

2) Core mechanics/design attributes: The essential attributes related to the core of the gameplay and mechanics of the game. (For example, attributes related to time spent playing, virtual
currency spent, number of opponents killed, and so on.) Defining the core design attributes should be based directly on the key gameplay mechanics of the game, and should provide information that lets designers make inferences about the user experience (whether players are progressing as planned, if flow is sustained, death ratios, level completions, point scores).
(source:gamasutra)