Marketing will always need campaign parameters. Product analytics should not absorb them into the event name. songkran_splash_add is a charming fossil six months later. cart_item_added with a property for campaign is boring and still queryable after the next brand refresh.
The same rule applies to UI copy. Buttons change. “Gold tier” becomes “Atlas,” then something in Thai, then back. If the event is named after the label, every rebrand breaks historical paths. Name the state or the act: subscription started, pause requested, identity verified. Labels can live in properties if you truly need them.
Owners, not vibes
In the Event Taxonomy Atelier we require an owner for each event family — a named person, not a Slack channel. Deprecation has a date. Adding a new event requires a one-line purpose and a downstream consumer. If nobody will read it in a journey report, it does not ship.
This sounds bureaucratic. It is cheaper than discovering, mid-Atlas Desk, that iOS fires view_item on every scroll tick while Android fires it once. That particular mess has appeared in three cohorts. Naming is not a prelude to the real work. It is the work that makes path analysis possible.
A small test
Print your top forty events. Cross out any name that would confuse a new hire who joined after the last rebrand. Cross out any name that includes a season, a celebrity, or a squad. What remains is your candidate contract. Everything else is either a property or a candidate for deletion.
Journey Atlas module one is this exercise, stretched over two weeks with critique. If you only need this slice, take the Atelier and skip the rest of the flagship.