What are events in analytics?

What makes an event useful

An event should represent something a person did that indicates value, defined precisely enough that two people would agree whether it occurred.

Most event taxonomies fail on the second requirement rather than the first. `purchase` sounds unambiguous until you ask whether it includes refunds, renewals, gift purchases and failed payments that later succeeded. Six months later nobody remembers what was decided, and every analysis rests on an assumption.

Designing a taxonomy that survives

• Name for the action, not the screen. `checkout_completed` survives a redesign; `blue_button_tapped` does not.
• Fix a naming convention and enforce it — casing, tense, separator. Inconsistency splits one event into three.
• Use properties rather than new event names for variants. One `purchase` event with a `method` property beats four purchase events.
• Write down the definition at the point the event is created, including the edge cases.
• Version deliberately. Changing what an event means without renaming it silently invalidates every historical comparison.

How many is too many

Almost every mature product tracks far more events than it uses. Each one carries instrumentation cost, maintenance cost and a share of the ambiguity that makes people distrust the data.

The useful test is whether any plausible value of the event would change a decision. If not, it is a cost with no return, and removing it makes the remaining data more trustworthy.

For attribution specifically, privacy frameworks force this discipline anyway — you can encode only a few post-install signals, so choosing which few matters more than tracking everything.