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.
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.
|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|
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?”
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.
Just kidding! You can always just replace the enum with a good, old-fashioned string.
// Both of these work
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.
cutscene_start and 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.
These events take a scene_name parameter: simply an arbitrary string so we can tell one cutscene from another.
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.
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.
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.
|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.|
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?
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.
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_fail, level_quit and 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
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.
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.
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.
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.
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.
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.
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.
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;
4 코멘트코멘트 구독
코멘트를 달 수 없습니다.