Event Taxonomy and Tracking Plan Enforced in CI

You get two artifacts, not a document. A tracking plan that lives only in a spreadsheet is stale within a quarter, and the moment engineers notice it is stale they stop reading it, which is the same month it stops being a plan. So alongside the written plan you get a JSON Schema checked into your application repository and wired to a test that fails the pull request when an event is emitted with a property not in the spec, or with a value in a field marked as never-PII. The enforcement is the part that is still working in month nine, and it is the reason this engagement is worth more than a template. Decisions I make and do not reopen: Event names are object then action, snake_case, past tense: application_submitted, deposit_funded, lesson_completed. Property values stay in English even where the interface is in Spanish, so that a locale switch does not quietly create a second name for the same event and split a year of history in two. There is one reserved namespace for platform-set properties that product code may not write to. These are not matters of taste worth a week of debate, and I will spend that week on the things that are. The anti-plan: A list of events deliberately not tracked, each with the reason. It is the shortest section and the most read one, because it is what stops the plan growing by accretion every time somebody wants a new dashboard tile. An event that exists only because it was easy to add costs a review every quarter and answers nothing. Ownership and lifecycle: Every event carries a named owner, not a team, and a review date. Versioning happens by addition: an event's meaning is never redefined in place, because redefinition invalidates every historical comparison silently and there is no way to detect it afterwards from the data alone. Retirement is a step with a date, not a decision to stop looking at something. Privacy rules the validator enforces rather than requests: Email, phone, RFC and CURP are denied as property values in the schema, which turns a policy nobody remembers into a failing build. A wallet address must not sit in the same store as an email; the pair deanonymises an entire on-chain history permanently, and that cannot be walked back with a deletion request. Identifiers belonging to users under 18 do not leave the product, which in education means the taxonomy separates the learner from the paying adult at the schema level rather than in a downstream filter someone can disable. How it gets built: Two working sessions with product and engineering together, in Spanish or English. I read your current event stream first, because what is actually being emitted rarely matches what anyone believes is being emitted, and that gap sets the agenda. You also receive a migration list mapping current names to the new ones, marked by whether each can be renamed at the source or has to be aliased. Not included: Implementation, which is separate work and should not be bundled into the document that judges it. Dashboards. Renaming events in your warehouse history. A vendor or CDP recommendation. Consent platform configuration. What I refuse: Writing a plan for a team with no intention of enforcing it, which produces a well-formatted artifact that changes nothing. Any event without a named human owner. Wallet addresses used as the primary user identifier. Who this is not for: Products with a dozen events and one surface. A single page written by your own engineering lead will serve you better, and I will say so on the first call rather than take the engagement.