Event maps
Three layers we separate before naming anything
Use this guide to prepare for a workshop or instrumentation review. Bringing clarity on these layers shortens the first day and reduces renamed properties later.
What the user is trying to finish
Examples: start trial, complete first purchase, renew subscription, unlock downloaded content while online. Phrase journeys in product language, not SDK method names.
Prepare before we meet
List three to five journeys that reach leadership reports. Note where current numbers already disagree between teams.
Where the server learns it happened
The function or job that commits the durable record — order row, entitlement grant, session renewal. This is usually where the canonical server-side event should fire for connected mobile apps.
Prepare before we meet
Identify owners for those handlers and gather sanitised sample payloads. Access delays are the most common reason reviews pause.
How the event is consumed
Board metrics, support macros, experiment readouts. We do not remodel your entire warehouse; we make sure the event map feeds the questions you already ask.
Prepare before we meet
Bring one screenshot or query per journey that leadership trusts — or wishes they could trust.
What a finished map looks like
Each event line includes a stable name, required properties, optional properties, firing condition, owner, and a link to the decision log entry. Client-only diagnostics stay in a separate appendix so they are not confused with server-confirmed counts.
During engagements we often sketch these layers on paper first. The custom page you are reading is the same structure we use on day one of a taxonomy workshop.