Blog · Event Taxonomy Studio
Event taxonomy mistakes that break cohort comparisons
A designer renames “Confirm booking” to “Review trip.” Engineering renames the screen class. Someone “cleans up” booking_confirm_tapped to trip_review_tapped in the same candidate. Last quarter’s cohort — people who confirmed but never paid — can no longer be joined to this week’s build. The chart is not empty by accident. You deleted the join key.
Analytics QA for App Releases spends an impolite amount of time on names. In Event Taxonomy Studio we treat a rename as a breaking schema change, same as dropping a column in a warehouse.
Three mistakes that keep recurring
1. Synonyms without aliases. iOS emits add_to_cart, Android emits cart_add. A blended funnel looks 40% smaller on one OS. The fix is not a clever report. It is one name on the contract, or an explicit alias table with an owner.
2. Properties that change type. amount as number on 4.17 and string-with-baht-symbol on 4.18. Warehouse numeric casts drop the new rows. Your “conversion fell” story is a type error.
3. Screen names as event names. When navigation IA changes every quarter, your historical cohorts die. Prefer stable verbs (checkout_started) with screen as a property, not as the event identity.
The diff ritual
Before freeze, export last production taxonomy and diff against the candidate. Anything added, removed, or type-changed gets a row: owner, migration (alias / dual-write / accept break), and whether last quarter’s board still works. If nobody will dual-write for one version, say so on the gate memo. Dual-write is cost. Silent break is also cost, just paid later by a confused PM.
SQL-light teams struggle here; that is the reservation we already print on reviews. Budget a data partner for the diff week, or accept that some historical charts will be decorative.
The grammar we use in class is part of In-App Event Taxonomy Studio and week one of Release Signal Lab.