In-App Event Taxonomy and Tracking Plan Governance

Two tiers, and the first one is small. Events that feed bidding, the ones Meta, TikTok, Google and your SKAN schema optimize against, should number around six, and each has to be defensible under audit six months from now. Events that feed analysis can run to hundreds and cost almost nothing. Nearly every taxonomy we are asked to repair has this the wrong way round: forty events wired into ad platforms, a third of them firing on screen views, and a bidding surface nobody in the room can explain. The tiering: Tier one is the bidding surface. Fixed names, no free-form string parameters, validated server side wherever money is involved, and changes only through a release with a dual-write period. Tier two is product analytics, named freely within the convention, versioned, cheap to add and cheap to retire. Tier three is diagnostics, which never leave your own store. A parameter that cannot be enumerated does not belong in tier one. Revenue that has not been checked against StoreKit 2 transactions or your RevenueCat webhooks is not a purchase event, it is a client claim, and it belongs in tier three until a server confirms it. The convention: Object then action, snake case, past tense, one meaning per name permanently. Parameters typed in a JSON Schema that lives in your repository rather than in a spreadsheet somebody renames. Currency always an ISO 4217 code, with gross and net carried as separate fields, because networks want gross and your board wants net and one field cannot honestly be both. Subscription lifecycle gets its own vocabulary: trial start, conversion, renewal, refund and clawback are five distinct events, and collapsing them is how a pet app books the same revenue twice and finds out at close. Mappings: Delivery includes the table mapping your tier one events to MMP partner events, Meta app events, TikTok events, Google Ads conversion actions and your SKAN conversion value positions. That table is the artifact that ends the arguments. When the ad platform and the MMP disagree, someone opens one document and sees exactly which fire produced which row, instead of three people guessing in a thread. Consent: The plan states what is collectable under each ATT and consent state, per destination. First-party analysis and network signal are separated in the plan rather than at reporting time, because a crypto product operating across several jurisdictions cannot afford that decision to be made ad hoc by whichever engineer wires the SDK next. Enforcement: A schema check in CI that fails the build on an off-schema tier one event. Without it a taxonomy decays within two releases. We have not seen an exception, and we no longer take taxonomy work without the check attached, because the alternative is being paid to write a document that is wrong by summer. What we do not do: We do not log everything and sort it out later. We do not rename events in place: a rename is a new name, a dual-write window and a stated cutover date. We do not add a bidding event because a network representative asked for one. And we do not write a plan and walk away from the migration, because the migration is the difficult part and it sits inside the scope. Who this is not for: Pre-launch apps with no traffic. Design the taxonomy once you know what users actually do, not from a whiteboard. Teams without engineering capacity across the next two releases, since the dual-write window needs both. And anyone who wants the tracking plan as a spreadsheet only. We do produce the spreadsheet, but the schema in your repository is the deliverable and the spreadsheet is a view of it.