A practical event taxonomy that survives product change
How to name events around user intent, keep properties useful, and prevent a tracking plan from becoming archaeology.
An event taxonomy should make a product legible. Too often it becomes a list of interface interactions that describes where someone clicked but not what they were trying to accomplish.
Begin with behavior, not screens
Name stable user actions such as report created or invite accepted. Screen names and button labels change faster than meaningful behavior. Put interface detail in properties only when it will support a known comparison.
Give every event a reason to exist
For each event, write down the decision or metric it supports, its exact trigger, required properties, and owner. If nobody can identify a use, do not collect it yet. Restraint makes validation and governance easier.
Review with real questions
Before implementation, walk through two or three likely analyses. Can you identify the first value moment? Can you separate creators from collaborators? Can you explain a missing event? This rehearsal exposes gaps more reliably than reviewing a spreadsheet row by row.
Keep change deliberate
Version the plan, record breaking changes, and review high-value events after major releases. A taxonomy is healthy when teams trust its meaning—not when it records everything.