Event taxonomies survive when teams can read them

A taxonomy is shared language

The purpose of an event taxonomy is not to make a tracking plan look orderly. It is to help people describe behavior consistently over time. A good name is predictable to the engineer implementing it and legible to the analyst querying it months later.

Choose one grammatical pattern and use it deliberately. Object-action names such as report_shared group related objects well. Action-object names such as shared_report read naturally. Either can work; mixing both creates needless translation.

Properties carry the useful context

Avoid encoding every detail in event names. A stable search_completed event with properties for source, result count and filters is easier to analyze than dozens of narrowly named variants. Define expected types, allowed values and when a property may be absent.

Governance can stay lightweight

Give one person authority to approve schema changes, include analytics in release acceptance criteria, and keep a visible changelog. The best governance process is small enough to be followed and explicit enough to prevent accidental drift.