Journal · 9 min · Studio desk
Event taxonomies that survive a rebrand
Rebrands are where App Analytics goes to die quietly. A product named “Vault” becomes “Atlas”. Someone updates the button copy. Someone else updates the event. Six months later you have three names for one object and a funnel that cannot be compared with last winter.
The schema is not the brochure
Display names may change. Object names in telemetry should freeze. In Event grammar we use a simple rule: the event speaks in objects a developer would recognise in the codebase, not in the campaign of the month. “plan_selected” can survive a rename of the plan page. “atlas_cta_tapped” cannot.
Marketing will ask for the new word in the dashboard. Give them a display alias. Do not give them a new event unless the object actually changed.
Alias, then freeze
When you must rename, pick a freeze date. Before that date, old names remain the source of truth. After it, new names are required in code, and the warehouse (if you have one) maps both. Publish the freeze in the same letter as the taxonomy, with an owner. If there is no owner, there is no freeze, only hope.
We have marked tracking plans where every event was “updated for the new brand” in a single sprint. The historical series became a rumour. The cheaper path is boring: keep the old verb, add a property for surface copy if you truly need it, and wait until the next major object change.
A sentence per event
If a new joiner cannot read a one-sentence definition without the ticket history, the name is not done. This is the slow week people complain about in Voices. It is also why onboarding events still matched the live product a year later for one Bristol team. Speed is available. Continuity is the scarce thing.