Field notes
Naming events so next quarter still understands them
Event names rot when each release invents its own vocabulary. A light taxonomy discipline keeps customer behavior readable months later.
Business applications accumulate events the way warehouses accumulate boxes without labels. A release ships vague click labels, another ships conflicting submit names, and six months later nobody can reconstruct the customer path without asking the engineer who left.
We ask teams to name events after the customer action, not the control. Prefer invoice_approved over green_check_click. Attach properties that describe context the path will need later: role, plan, entry surface, and whether the action succeeded.
Ownership matters as much as naming. Every event should list a product owner who decides when it can change, and an engineering contact who knows where it fires. Without that, taxonomy workshops produce a beautiful spreadsheet that drifts within one sprint.
If you inherit a messy catalog, do not rename everything at once. Freeze a core set of journey-critical events, document aliases for the rest, and retire duplicates only when you can prove both fire for the same action. Continuity beats neatness when you are trying to compare behavior across releases.