A game sends a lot of signals: a level started, a bike was bought, an ad finished. For years our habit, like most studios, was to add a signal wherever it was needed and worry about the rest later. It worked until it did not.
One definition, many destinations
We now treat every event as a small, written contract:
- a name that never changes,
- a list of parameters, each with a type and whether it is required,
- a plain-language note on when it fires,
- and a separate choice of which tools receive it.
The important part is the last one. The game sends one event. Where it goes (an analytics tool, an ad network, our own reports) is configuration, not code. Switching a tool on or off, or renaming an event for one tool, never means shipping a new build.
Flows, not lists
Single events tell you little. We group them into flows: the ordered steps a player takes through something like a first session or a purchase. Writing a flow down shows gaps at once: the step that has no event, or the branch nobody thought about.
Validate before you trust
An event is only marked as validated once someone has seen it fire in a real build with the right parameters. Until then it is a plan, and dashboards built on it carry that caveat.
Why this matters to players
Better definitions mean fewer mistakes and faster fixes. When a feature misbehaves, we can see what happened instead of guessing, and we can do it without collecting more than we need.
Next in this series: why collecting data nobody reads is a cost, not a free option.
