Event design and naming

Play this lesson

Did the editor work?

Shard Garden's level editor shipped a month ago. Kai asks a simple question: how many players share a level they built? Nobody can answer. The game sends click, btnPress2, LevelShared and share_level, four names for overlapping things.

That week Theo joins the studio as a data analyst: someone who turns what players do into numbers the team can trust. Theo's first job is deciding what the game records.

What an event is

An analytics event is a record that something happened in the game: a name, a time and a few details called parameters.

level_shared, with level_id: "lv-88a1" and method: "link".

Priya's telemetry, from the Observe stage, says whether the game is healthy. Analytics events say what players do with it. They describe the game's own actions, never who a player is.

Quick check

The level_shared event should include the player's real name, so Theo can count shares.

Show the answer

False

Counting shares needs the event, not the person. Events describe what happened in the game. A name adds risk and answers no question Theo has.

The naming rules

Shard Garden sends its events with Google Analytics for Firebase. Its rules:

Name check

Which event name follows Google Analytics' rules?

  1. garden_defended
  2. Garden Defended
  3. 1st_garden_defended
Show the answer

garden_defended

Names may not contain spaces and must start with a letter. garden_defended uses only letters and underscores, and starts with a letter.

One pattern for every name

Segment, a company whose tools collect analytics data, names events with an Object Action pattern: the thing, then what happened to it. Its advice: pick a convention and stick to it.

Theo picks lower case with underscores: garden_defended, level_published, level_shared.

Google Analytics also has recommended events with fixed names and parameters. For games there are level_start, level_end (with success), tutorial_complete and share. Google's reports understand those, so Theo uses them where they fit.

The tracking plan

A tracking plan, in Segment's words, says what events to track, where they live in the code, and why they matter. It should be the single source of truth for data collection.

Theo's plan is a table with one row per event: when it fires, its parameters, the question it answers, and who owns it.

level_shared | the share link is created | level_id, method | "Do players share their levels?" | Theo

No question, no event.

Quick check

Kai wants a button_tapped event for all 140 buttons in the game, "just in case". What does the tracking plan say?

  1. Add only events that answer a question someone has, like level_shared
  2. Add it, because more data is always better
  3. Add 140 separate events, one per button
Show the answer

Add only events that answer a question someone has, like level_shared

Every event in the plan answers a real question. Events nobody asks about cost money to store, bury the useful ones and collect more than the studio needs.

Bug hunt

share.js, on three platforms
// weblog('level_shared',  { level_id: id });// Androidlog('Level_Shared',  { level_id: id });// iOSlog('level_shared',  { levelId: id });

Theo counts level_shared, and every share from Android is missing. Which line is the bug?

  1. Line 5
  2. Line 2
  3. Line 9
Show the answer

Line 5

Names are case-sensitive, so Level_Shared is a separate event. Line 9 has a smaller bug: levelId instead of level_id, so iPhone shares arrive without their level.

From a phone to a table

The tracking plan is ready. Now millions of events leave phones, browsers, Steam and consoles every day, and all of them have to arrive somewhere Theo can ask questions.

Bolt says: Next: the pipeline that carries every event home.

Fact-checked 11 October 2026