Event Taxonomy and Tracking Plan, Enforced in CI

The tracking plans I am asked to repair usually name more than two hundred events, and fewer than forty of them appear in any query anyone ran in the previous ninety days. What I hand back is normally thirty to sixty events, and each one is attached to a decision somebody makes on a stated cadence: a Monday channel review, a monthly retention call, a quarterly pricing argument. An event that settles nothing does not get collected. What I hold to be true here: Instrumentation is not documentation of the product. A plan built screen by screen produces names that change whenever design ships a new layout, and a warehouse full of columns nobody can defend in a meeting. I work backwards from the numbers people fight about, and I would rather leave a behavior uninstrumented for a quarter than add a name no query will ever reference. How the plan gets built: Interviews first, with whoever owns the number rather than whoever owns the roadmap: paid acquisition, lifecycle, finance, and the analyst who actually writes the SQL. Those sessions produce a list of questions, each with the decision it feeds and the table it would need. Only then the event list. Naming is object_action, past tense, snake_case — checkout_started, deposit_completed, appointment_booked — with variance carried in properties rather than in new event names, so the plan does not sprawl every time a campaign adds a variant. What is handed over: A spreadsheet the marketing side reads and a JSON Schema, draft 2020-12, that engineering compiles against. Typed wrappers generated for the platforms in use, so an event name is an identifier in the editor and not a string literal. A build step that fails a pull request carrying an undeclared event, a missing required property, or an enum value outside the declared list. And a one-page deprecation procedure, because plans rot for a single reason: nobody ever agreed how to remove something. Identity and consent: The identity section is written before the event section, not after. Anonymous-to-known aliasing, which traits are set on identify and which are left to the warehouse, what happens on logout, what happens when two accounts merge. Consent state travels as a required property on every event rather than as a wrapper somebody forgets to check, so any downstream query can tell what was collected under which basis. Regulated categories: In health and wellness, no condition, medication, provider name or appointment reason crosses the first-party boundary. Those fields are named in the plan as blocked destinations rather than left to a developer's judgement at two in the morning. In igaming, deposit amounts, stake size and self-exclusion status stay out of the advertising platforms entirely, and the plan says so in writing, so the next person who adds a pixel has something to be overruled by. Not included: I do not write the instrumentation. Your engineers do, against the schema, and in the top tier I review their pull requests. No dashboards, no BI layer, no CDP migration, and no vendor selection dressed up as a plan. If the outcome you want is a signed recommendation to buy a particular tool, we are the wrong fit. Who this is not for: Teams before launch, with no traffic to argue about; the plan gets rewritten anyway and you would be paying twice. Teams where no single person can approve an event name, which means the real problem is ownership rather than taxonomy. And anyone who wants the two hundred events restored because a leader likes the length of the list.