18 November 2025
Property dictionaries after a rebrand
Marketing gets a new voice. Engineering ships a string. Analytics inherits both, and the dashboard begins to contain synonyms that are not synonyms.
A property dictionary is a boring artefact until the week the plan names change. premium becomes plus, then Plus, then Plus (intro) because a growth experiment needed a label. None of these is illegal. Together they make “share of paid users” a matter of taste.
Version the enum, do not overwrite it
When a value changes meaning, add a version or a valid-from date in the dictionary, not in folklore. Old events keep old values. New events emit the new token. A mapping table — dull again — tells the warehouse how to roll them up for a board paper. If you overwrite in place, last year’s cohort charts become un-auditable.
Rebrands also rename SKUs in the app while receipts still carry the warehouse code. Decide which identifier is canonical for product analytics. The pretty name can be a lookup. The pretty name should not be the join key.
Free text is a junk drawer
We see plan_name collected as free text because “the CMS might add one”. The CMS will add one, with a trailing space. QA cannot test an open string. If you truly need an escape hatch, pair a closed enum with an optional plan_name_raw that analysts swear not to use in KPIs.
After a rebrand, schedule a dictionary freeze: two weeks where new values require a written ticket. It feels bureaucratic. It is cheaper than a quarter of dashboards that cannot agree whether Plus is paid.
This is the unglamorous half of app analytics. The atelier spends a whole week on it because the glamorous half — a retention curve — is downstream of these tokens.