Method
Event taxonomies before models
Identity Flowcore journal · pre-reading for the Event Taxonomy Intensive
A predictive model is a very expensive way to memorise a messy dictionary. If checkout is spelled three ways, if “purchase” sometimes means intent and sometimes means settlement, the classifier will learn those accidents and call them signal.
In the lab we refuse to train until the dictionary can answer five questions for every event you plan to use as a feature or a label: who fires it, on which identity grain, at which clock, what the properties mean, and when it was last changed.
Start with verbs the product actually owns
Marketing likes abstract nouns: engagement, loyalty, delight. SDKs like whatever the last contractor typed. A usable taxonomy is built from verbs the app can observe without interpretation: opened_session, viewed_sku, started_checkout, payment_succeeded, payment_failed, pushed_promptpay, handed_to_line.
If you cannot point to the screen or the API call that emits the event, it does not belong in the training table yet. Derived metrics can wait.
Version in public
Silent property changes are how last quarter’s model becomes this quarter’s mystery. We keep a one-line changelog: date, event name, what changed, who approved. Deprecations get a sunset date, not a hopeful comment in Slack.
Aliases are allowed for a quarter, then they die. “purchase_v2” living forever next to “purchase” is not sophistication; it is two sources of leakage waiting to meet.
Kill zombie events
Events that still arrive from a forgotten screen inflate denominators. Before any hazard model, we plot volume by app version. If an event only exists on builds older than six months, it is a historical curiosity, not a feature.
Then, and only then, model
Once the dictionary is boring, prediction work becomes smaller and more honest. That is the point. The Cohort Signal Lab compresses this pass into week two because most teams arrive with folklore, not a ledger.