Economy telemetry worth instrumenting before you need it

The economy questions that matter arrive suddenly. Purchases dropped, is the economy loose. This event felt too generous, was it. Players are stuck at this point, is it a cost problem or a difficulty problem.

Each of those is answerable in an afternoon if the right things were recorded and unanswerable at any price if they were not. The events involved are cheap and there are fewer of them than most teams expect.

The one event that carries most of the weight

If you record nothing else, record every change to a player's currency balance as a separate row: which player, which currency, how much, in which direction, caused by what, and what the balance was afterward.

That single event answers a surprising share of the questions. Summed by cause, it tells you every source and every use in the game and their relative sizes — the list most teams do not have. Summed by player, it gives you balances over time. Differenced across a date range, it tells you whether the economy is inflating.

The two fields that get left out and are the most useful are the cause and the resulting balance.

The cause — which quest, which event, which purchase, which shop item — is what turns an aggregate into a diagnosis. Without it you know currency went up and cannot say from where, which is precisely the question that gets asked.

The resulting balance saves you from reconstructing state by replaying every transaction in order, which is slow, error-prone, and impossible if any event was ever dropped. Recording it makes each row independently meaningful.

What to record around a purchase

A purchase event on its own tells you what was bought. What makes it useful is a small amount of context about the moment it happened.

Where the player was — which screen, which progression point, what they had just been doing. This is what lets you distinguish a purchase driven by a specific obstacle from a browsing purchase, and those behave differently enough that mixing them makes both unreadable.

What they held at the time. A purchase by a player with an empty wallet and a purchase by a player who already had plenty are different decisions, and the balance at purchase time separates them.

Whether it was their first. First purchases are a different population and a different event, and flagging them at write time is much easier than inferring them later across a table that may have gaps.

The offer events that are usually missing

Studios record which offers converted. Far fewer record which were shown, and almost none record which were seen and rejected as distinct from ignored.

Recording the shown event — offer, player, moment, context — is what makes conversion a rate rather than a count. Without it you know how many people bought and not out of how many, which makes every comparison between offers invalid.

Recording engagement separately from dismissal is the second one. A player who opened an offer and closed it evaluated your offer. A player who dismissed it in under a second did not. Merging these makes it impossible to tell a pricing problem from a placement problem, and those have opposite fixes.

Neither of these needs to be elaborate. Two events with the same shape as the purchase event, plus a flag.

See what we instrument on the economy side →

The progression markers that make everything else readable

Economy data without progression context is hard to interpret, because the same number means different things at different points in a game.

Recording when a player reaches each significant progression step — with a timestamp and their currency state at that moment — costs very little and makes the economy data legible. It is what lets you say "players arriving at this stage typically hold about this much", which is the baseline every economy question compares against.

It also converts a difficulty question into an economy question and back. A step where players stall might be too hard or too expensive, and the balance they were holding when they arrived is what tells you which.

What not to bother with early

The instinct when writing this list is to record everything, which produces volume nobody queries and cost nobody budgeted for.

Per-frame or per-action telemetry is rarely worth it for economy questions. The decisions you are trying to understand happen at the level of sessions and transactions, not inputs.

Derived values are worth skipping too. Anything you can compute later from the raw rows should be computed later — recording a player's lifetime spend as a field means it is wrong the moment anything is backfilled or corrected, and you already have the transactions.

And elaborate schemas designed to anticipate future questions tend to age badly. The events above are useful because they describe what happened rather than what someone thought would be interesting, and that property is what makes them still answer questions nobody had in mind when they were added.

The reason to do this early is not that it is hard later. It is that the data does not exist retroactively. A question about what happened last quarter can only be answered by instrumentation that was running last quarter, and that is the shape almost every important economy question takes.

Talk to us about economy instrumentation →