14 March 2026 · Taxonomy

Event names that survive a reorganisation

When the growth squad is absorbed into platform, the first thing to rot is often the tracking plan. The names were written for a squad, not for an action.

Charts spread across a table during a review

In clinic we still see growth_onboarding_v3_cta sitting next to platform_home_impression. Both were accurate the week they shipped. Neither describes what a person did. After the reorganisation, the people who remember the joke in “v3” have left, and the warehouse becomes a museum of team names.

We ask students to rename in verbs: onboarding_completed, playlist_started, invoice_viewed. Properties then carry the experiment, the surface, and the app version. The packet stays stable; the grid absorbs the fashion.

A test we use on paper

Read the event name aloud without the property list. If a new analyst cannot guess the user action, it fails. If the name includes a squad, a quarter, or a designer’s first name, it fails. If it includes a screen that product has already redesigned twice, it fails.

This is slower than letting the implementation ticket name the event. It is also why Packet Ledger week 1 feels pedantic. Pedantry is cheaper than a tracking rewrite that coincides with a reorganisation — which is when rewrites usually get approved, and when they do the most damage.

What we do not claim

A clean dictionary will not prevent a merger, a new CPO, or a vendor migration. It will make the migration a mapping exercise instead of an archaeological dig. That is the whole argument.

Back to the journal