Reading the numbers

Are players staying?

Our two games, Hyper Shards and Garden Defense, are live, and players keep showing up. LiveOps is a loop of plan, build, release, measure and learn. This lesson is the measure part: how is the game really doing, and did our last update help?

We answer with analytics: the game counts events like "level started" or "level finished". It counts what happens in the game, never names, addresses, photos or chats. Games for kids have extra privacy rules, like COPPA in the US (Stage 4 covers it in Keeping player data safe).

The big numbers

• DAU, WAU and MAUDaily, weekly and monthly active users: how many different people played in one day, in the last 7 days, and in the last 30 days. Each person counts once, however often they played.
• RetentionOf the players who started on one day, how many came back on day 1, day 7 and day 30?
• ChurnThe share of players who stop playing in a period, the flip side of retention. 1,000 played in September and 300 of them never played in October: 30% monthly churn, so the other 70% were retained.

A group of players who installed on the same day is a cohort. If a cohort of 100 installs on Monday and 30 play again on Tuesday, Day 1 retention is 30%. Stickiness is DAU ÷ MAU: 2,000 ÷ 10,000 = 20%, so a typical monthly player shows up about 6 days a month.

ARPDAU (average revenue per daily active user) is one day's revenue from ads and purchases ÷ that day's DAU. Made-up example: Garden Defense earns $60 on a day with 2,000 DAU, so ARPDAU = $60 ÷ 2,000 = $0.03.

Where do players quit?

We can count how many players reach each level of Garden Defense. Studios call this a funnel, because it gets narrower as players drop out:

• Level 1: 100 players
• Level 3: 90 players
• Level 4: 85 players
• Level 5: 40 players

Between level 4 and level 5, 45 of 85 players quit. That is more than half! Maybe a pest is too strong, or the goal is confusing. The numbers tell us where to look. Playtesting tells us why.

Crash reports

When the phone version of Garden Defense crashes, a Firebase tool called Crashlytics (made for Android and Apple apps, not web games) sends a crash report: the device, the version of the game, and a stack trace, the list of functions that were running when it broke, down to the line of code.

Studios watch the crash-free users rate. 99.5% sounds great, but it means 5 in every 1,000 players hit a crash. We fix the crash that hits the most players first. One crash on an old tablet matters less than one hitting thousands of phones.

Change one thing, then measure

Say we slow the level 4 pests, change the map and add a reward, all at once. More players finish! But which change helped? We can't tell.

So we change one thing. Remote Config (a Firebase tool that changes game settings from the cloud, with no new release) gives a random half of players enemy_speed = 2.0, while the other half keep 2.5. Then we compare. This is an A/B test. Good tests split players randomly, use enough players (a few dozen can fool you), and run a full week, because weekend players behave differently.

Next: switches in the cloud

Honest numbers tell us where to look. To try a fix on half the players, or switch on an event for everyone, without waiting for a store update, we need Remote Config. That is the next lesson.

Later, in Stage 10, retention also tells us what one player is worth in money: unit economics.

Bolt says: A good rule: if you wouldn't want a game to know it about you, don't collect it about your players.