应用进展_解释的标准事件：第2部分

应用进展

So far in this series, I’ve introduced the concept of Standard Events and waded into the pool to describe the Onboarding group of events. This time, we’re diving deeper, taking a close look at two more groups: Application and Progression.

到目前为止，在本系列文章中，我已经介绍了标准事件的概念，并涉足描述了Onboarding事件组。这次，我们将进行更深入的研究，仔细研究另外两个组： Application和Progression 。

应用程序组中的事件 (Events in the Application Group)

At some level, your game is simply an application. I mean, sure, it’s a lot more than that, but there’s a key thing to think about that anyone creating almost any application would want to consider: can users find their way around? Generally speaking, even the most challenging game should have an easy-to-use interface. Here are the events we associate with Application.

在某种程度上，您的游戏只是一个应用程序。我的意思是，当然，它还远远不止于此，但是有一点要考虑的关键是，几乎所有创建任何应用程序的人都想考虑：用户能找到解决方法吗？一般而言，即使是最具挑战性的游戏也应具有易于使用的界面。这是我们与Application关联的事件。

Event name	Parameters	Purpose
screen_visit	screen_name	Player visited a UI screen
cutscene_start	scene_name	Player started a cutscene
cutscene_skip	scene_name	Player skipped past a cutscene

活动名称	参量	目的
screen_visit	屏幕名称	玩家访问了UI屏幕
cutscene_start	scene_name	播放器开始过场动画
cutscene_skip	scene_name	玩家跳过过场动画

那么我们在回答什么问题呢？ (So what questions are we answering?)

As I mentioned last time, every event you track should be tied to questions you want answered. The key question here is “are my players finding what they need?”

正如我上次提到的，您跟踪的每个事件都应与您想回答的问题联系在一起。这里的关键问题是“我的球员在寻找他们需要的东西吗？”

screen_visit

Within this context, the screen_visit event is pretty straightforward: you use it to map which UI screens your players go to. The screen_name parameter can be any of the values defined under the ScreenName enum (e.g., ScreenName.Settings, ScreenName.MainMenu, ScreenName.Hint). If you can’t find the screen you’re looking for under ScreenName, sorry you’re out of luck and must now despair.

在这种情况下， screen_visit 事件非常简单：您可以使用它来映射玩家进入的UI屏幕。所述 SCREEN_NAME 参数可以是任何的屏幕名枚举下定义的值 (例如，ScreenName.Settings，ScreenName.MainMenu，ScreenName.Hint)。如果找不到您要查找的屏幕，请使用 ScreenName ，抱歉，您不走运，现在必须绝望。

Just kidding! You can always just replace the enum with a good, old-fashioned string.

开玩笑！您总是可以用一个好的老式字符串替换该枚举。

// Both of these work

AnalyticsEvent.ScreenVisit(ScreenName.Settings);

AnalyticsEvent.ScreenVisit("character_selector");

// Both of these work

AnalyticsEvent . ScreenVisit ( ScreenName . Settings ) ;

AnalyticsEvent . ScreenVisit ( "character_selector" ) ;

Note that one “screen” we generally don’t include here is your game’s store. We think of the store not as UI, but as an intrinsic part of your game’s monetization process. As such, we have a separate store_opened event which we’ll cover in the final blog post in this series.

请注意，我们通常不包含在其中的一个“屏幕”是您的游戏商店。我们认为商店不是用户界面，而是游戏货币化过程的内在组成部分。因此，我们有一个单独的store_opened事件，我们将在本系列的最后一篇博客文章中进行介绍。

cutscene_start and cutscene_skip

cutscene_start和cutscene_skip

These events are a sort of specialized form of screen_visit. Usually a player enters a cutscene involuntarily (e.g., at the start or end of an important level). But do they actually stick around to watch? Knowing how often players skip out can be important, not least because we put a lot of time and effort into making these scenes, and we’d like to know whether all that effort was worth it! More importantly, perhaps, if we deliver crucial information as part of these scenes that players are bypassing, we might need to consider alternative ways to deliver that important content.

这些事件是 screen_visit 的一种特殊形式。通常，玩家会非自愿地进入过场动画(例如，在重要关卡的开始或结束时)。但是，他们实际上会坚持观看吗？了解玩家退出的频率非常重要，这尤其重要，因为我们在制作这些场景时花了很多时间和精力，而且我们想知道所有这些努力是否值得！更重要的是，也许，如果我们在玩家绕过的这些场景中提供关键信息，则可能需要考虑其他方式来交付重要内容。

These events take a scene_name parameter: simply an arbitrary string so we can tell one cutscene from another.

这些事件带有一个 scene_name 参数：只是一个任意字符串，因此我们可以区分一个场景。

我收集的应用程序事件该怎么办？ (What should I do with the Application events I collect?)

Since the key question we’re asking is “are my players finding what they need?”, one of the most obvious things we do is simply graph my screen visits in the Data Explorer.

由于我们要问的关键问题是“我的玩家是否正在找到他们需要的东西？”，所以我们要做的最明显的事情之一就是在Data Explorer中简单地绘制我的屏幕访问情况。

In this example, we can see all the screens that our players visit, and how frequently. This gives us a rough idea whether all the important screens are in use, and how frequently. One thing our dashboard can’t do at present is break these parameters down by unique users, which would be useful (since raw counts can be skewed by a few particularly eager players). But there is a way to overcome that obstacle.

在此示例中，我们可以看到玩家访问的所有屏幕以及访问频率。这使我们大致了解所有重要屏幕是否都在使用中以及使用频率。我们的仪表板目前无法做的一件事是由唯一用户分解这些参数，这将很有用(因为一些特别渴望的玩家可能会扭曲原始计数)。但有克服障碍的方法。

With Raw Data Export, (a Pro-only feature), we can download events to our own database to perform queries that would be difficult or impossible to do on the dashboard. It’s outside the scope of this post to walk through that process. For the present, I just want to make the point that querying these events against unique users would help us to identify whether a significant segment of our users are having trouble finding certain screens.

借助Raw Data Export (仅适用于Pro的功能)，我们可以将事件下载到我们自己的数据库中，以执行难以或不可能在仪表板上执行的查询。本教程的内容超出了本文的讨论范围。就目前而言，我只想指出一点，针对唯一用户查询这些事件将有助于我们确定大部分用户是否在查找某些屏幕时遇到问题。

进步组中的活动 (Events in the Progression Group)

Progression describes the act of our players advancing through the game. Tracking these events helps us understand how difficult the game is, and where players get stuck.

进度描述了玩家在游戏中前进的行为。跟踪这些事件有助于我们了解游戏的难易程度以及玩家卡在哪里。

Event name	Parameters	Purpose
level_start	level_name (and/or) level_index	Player started a game level
level_complete	level_name (and/or) level_index	Player finished a game level
level_fail	level_name (and/or) level_index	Player failed out of a level
level_quit	level_name (and/or) level_index	Player quit out of a level
level_skip	level_name (and/or) level_index	Player skipped a level
game_start		Player started a game
game_over	level_name (optional), level_index (optional)	Player finished a game
level_up	new_level_name (and/or) new_level_index	Player increased their level rank or tier.

活动名称	参量	目的
level_start	level_name(和/或)level_index	玩家开始游戏关卡
level_complete	level_name(和/或)level_index	玩家完成了游戏关卡
level_fail	level_name(和/或)level_index	玩家失败了
level_quit	level_name(和/或)level_index	玩家退出一个关卡
level_skip	level_name(和/或)level_index	玩家跳过了一个关卡
游戏开始		玩家开始游戏
游戏结束	level_name(可选)，level_index(可选)	玩家完成游戏
升级	new_level_name(和/或)new_level_index	玩家提高了他们的等级等级或等级。

我们在回答什么问题？ (What questions are we answering?)

Progression events answers various questions about the player’s journey through our game. Questions such as:

进度事件回答了有关玩家在我们游戏中的旅程的各种问题。问题如：

How difficult is our game?
我们的游戏有多难？
Where do players get stuck?
玩家在哪里卡住？
Which levels frustrate our users?
哪个级别使我们的用户感到沮丧？
How addictive is our game?
我们的游戏有多令人上瘾？

level_start

Levels are, of course, a common feature in many, many games. Sometimes each level has a name; sometimes they’re indexed; sometimes they occur perfectly linearly; and sometimes they can be accessed arbitrarily. However players get to the levels of our game, we want to track their progress. Do we want to track every level? Maybe or maybe not. Typically, we want to pay close attention to the first few levels. After that, it’s a little more dependent on the game. If my game has a total of ten levels, I almost certainly want to track them all. If my game generates levels procedurally which run into the thousands, tracking them all may simply hide useful information. You need to make some judgements about how much data is useful, and how much is simply noise.

当然，关卡是许多游戏中的常见功能。有时每个级别都有一个名称。有时将它们编入索引；有时它们完美地线性发生；有时可以任意访问它们。无论玩家达到我们游戏的水平，我们都想跟踪他们的进度。我们是否要跟踪每个级别？也许不是。通常，我们要密切注意前几个级别。在那之后，它更多地依赖于游戏。如果我的游戏总共有十个关卡，我几乎可以肯定要跟踪所有关卡。如果我的游戏程序性地生成了成千上万的关卡，那么对它们进行跟踪可能只会隐藏有用的信息。您需要对有用的数据做出多少判断，而仅仅是噪音就可以判断多少。

So don’t be too shocked, but we trigger level_start when a level…starts! We can pass either a level_index or a level_name parameter as part of this event.

因此，不要太震惊，但是我们会在一个级别…开始时触发 level_start ！作为此事件的一部分，我们可以传递 level_index 或 level_name 参数。

level_complete

The complement of level_start, level_complete is fired when the level is successfully completed. The level_index or level_name parameters should match level_start, so we can compare starts to completes for each level. One of the most important progression tools we’ll use is a level progression funnel is built from level_complete events and which I’ll describe below.

成功完成关卡后，将触发 level_start ， level_complete 的补码。该 level_index 或 level_name 参数应符合 level_start，所以我们可以比较开始完成每个级别。我们将使用的最重要的进度工具之一是根据 level_complete 事件构建的 进度进度漏斗 ，下面将对其进行介绍。

level_fail, level_quit and level_skip

level_fail，level_quit和level_skip

Each of these events describes an important alternative way a level can end: failure, quitting, or skipping. Identifying when a user fails, quits or skips a level can tell us a lot about what works and what doesn’t.

这些事件中的每一个都描述了一个级别可以结束的重要替代方式：失败，退出或跳过。识别用户何时失败，退出或跳过某个级别可以告诉我们很多有效的方法和无效的方法。

game_start and game_over

game_start和game_over

These “game” events are mostly intended for arcade-style games with a distinct fail-based ending. Pac-Man, Space Invaders, Donkey Kong, endless runners, arcade shooters…these all fall within this category. Send game_start when the player begins a play session, and game_over when they lose all their lives and the game has ended. You can use these counts to calculate the number of distinct game plays within play sessions.

这些“游戏”事件主要用于具有独特的基于失败的结局的街机风格的游戏。吃豆人，太空侵略者，金刚，无尽的跑步者，街机射击者……这些都属于这一类。发送 game_start 当球员时，他们失去了他们的生活和比赛已经结束开始播放会话，game_over。您可以使用这些计数来计算游戏时段内不同游戏的播放次数。

level_up

升级

Don’t confuse this event with level_complete. This event captures the notion of “leveling up” (i.e., when a player increases in rank). Capturing how players progress through level ranking can be a good indicator for player proficiency and engagement.

不要将此事件与 level_complete 混淆。该事件捕获了“升级”的概念(即，当玩家的排名上升时)。掌握玩家在等级排名中的进度可以很好地指示玩家的熟练程度和参与度。

我收集的进度事件应该怎么办？ (What should I do with the Progression events I collect?)

Quite a lot actually…probably more than I have room for in this short post. I’ve already mentioned a level progression funnel as a key tool, so let’s start there.

实际上很多……可能比我在这篇短文中所能容纳的更多。我已经提到了关卡进度漏斗作为关键工具，所以让我们从这里开始。

A funnel, as I mentioned in my prior post, is a simple but powerful tool that shows how far players get in some linear experience. If your game has linear levels, or any group of levels that all players pass through, you can create a funnel of that linear progress. It might look something like this:

正如我在之前的文章中提到的那样，渠道是一个简单但功能强大的工具，它可以显示玩家获得某种线性体验的程度。如果您的游戏具有线性关卡，或所有玩家都经过的任何关卡组，则可以创建该线性关卡的渠道。它可能看起来像这样：

In this funnel, we see our players moving through all 64 levels of our game. A couple things jump out immediately. First, virtually no players make it all the way through. That could be sign that our game is too difficult. Second, there’s a big drop after level 1. That might be an indication of a problem that needs fixing. It’s certainly a place where players leave the game in large numbers. (Don’t forget to compare your early level progress to your Day 1 and Day 7 retention rates…there’s a good chance these numbers are related!) The combination of Standard Events and their associated funnels can quickly point you to areas where your game needs attention.

在这个程序中，我们看到我们的玩家在游戏的所有64个关卡中移动。几件事立即跳出来。首先，几乎没有球员能一路过关斩将。这可能表明我们的游戏太困难了。其次，在第1级之后下降了很多。这可能表明需要修复问题。当然，这里是玩家大量离开游戏的地方。 (别忘了将您的早期游戏进度与第1天和第7天的保留率进行比较……这些数字很有可能是相关的！)标准活动及其相关渠道的组合可以Swift将您指向游戏需要的领域注意。

A similar funnel can be made from level_up events, offering a different indication of player engagement through their mastery of the game’s challenges.

可以通过 level_up 事件创建类似的漏斗，通过他们对游戏挑战的掌握来提供不同的玩家参与度指示。

We can also look into the Data Explorer for useful answers to our questions. If our game uses game_start, simply comparing the count of game_start events to Total Sessions Today gives us a useful average of gameplays per session.

我们也可以查看数据浏览器以找到问题的有用答案。如果我们的游戏使用 game_start ，只需将 game_start 事件的计数与 Today Total Sessions 进行比较，就可以得出每个会话的平均游戏玩法。

Similarly, we can compare level_fail or level_skip events with level_start events to calculate some useful ratios. We’d want a certain amount of these skips and fails, without which our game is likely too easy…but not too many, lest our game be too hard.

同样，我们可以将 level_fail 或 level_skip 事件与 level_start 事件进行比较，以计算出一些有用的比率。我们希望一定数量的跳过和失败，否则，我们的游戏可能会太容易了……但不要太多，以免我们的游戏太难了。

Finally (at least for the purposes of this post), we could do a world of good with these events in Raw Data: fails per level, skips per level, level-ups per level, state mapping of levels (for non-linear games), and so on.

最后(至少出于这篇文章的目的)，我们可以利用Raw Data中的这些事件来创造一个美好的世界：每个级别失败，每个级别跳过，每个级别升级，每个级别的状态映射(用于非线性游戏) )，等等。

再发表一则帖子，再发表两个类别 (One more post, two more categories)

In our next and final installment, we’ll cover the last two categories: Engagement and Monetization. The former is critical for understanding virality and “stickiness”, the latter for keeping the lights on! We’ll post about these critical Standard Events soon. Hope to see you then!

在下一期和最后一期中，我们将介绍最后两个类别： 参与度 和获利。前者对于理解病毒性和“黏性”至关重要，后者对于保持照明状态至关重要！我们将很快发布有关这些关键标准事件的信息。到时候见！

If you haven’t already, please check out the previous installments in the series;

如果还没有，请查看本系列的前几期；

Introducing Standard Events

标准活动介绍

Standard Events Explained: Part 1 – Onboarding

标准活动介绍：第1部分-入门