Product analytics quickly lose their value when developers give the same things different names. Events such as click_button, signup_done and new_user may seem obvious today, but soon become incompatible and impossible to interpret. An event taxonomy provides a shared language.
Name behaviours rather than screen elements
Prefer an event describing the action and business object, such as report_exported, rather than blue_button_clicked. Interfaces change more frequently than intent. The name should remain accurate even if the button becomes a menu or an automation.
Choose consistent naming grammar
Define tense, word order, capitalisation and separators. A simple object_action or action_object pattern is enough, provided it is used everywhere. Keep examples and prohibited forms so the rule can be applied without interpretation.
Keep context in properties
The event states what happened; properties supply context, such as plan type, surface, version or initiation method. Avoid creating a new event for every minor variation. Equally, do not send free text or personal data without a clear need and controls.
Define ownership and a contract
Every event needs a description, trigger, permitted values, platforms, owner and status. The tracking plan is a contract between product, analytics and engineering. A change to a property or trigger should follow the same process as an API change.
Test before and after release
Check that the event fires once, at the correct time and with the correct values. Test failures, back navigation, repetition and different roles. After release, monitor sudden drops, spikes and the appearance of prohibited values.
Retire events without erasing history
When an event is replaced, record its end date, successor and impact on dashboards. Do not reuse an old name for a new meaning. Historical consistency matters as much as a clean implementation today.
This event taxonomy is an original analytics governance framework developed by DigitalNow.