In-app event taxonomy for bidding partners and the warehouse

Meta will rank eight events for you and no more. Google Ads works properly with one primary conversion action per campaign objective. Your warehouse will happily store four hundred, all named by whoever shipped the feature that week. The work here is choosing the eight, and making sure each one means precisely the same thing in the app, in the MMP, in the bidder and in the model finance uses. When those four disagree, and they usually do by a wide margin on subscription apps, every optimisation decision downstream is being made against a number nobody in the room defined. How the taxonomy gets built: I start from the bidding constraint and work backwards, which is the opposite of how most taxonomies are written. Events earn their place by changing a decision: a bid, a budget, a creative retirement, or a line in the finance model. Everything else is a property on an existing event rather than a new event. That single rule removes most of the sprawl I am usually asked to organise, and it is why I would rather redesign a taxonomy than tidy one. The mapping table: One table, versioned, with a row per event and a column per destination: the app-side name, the MMP token, the Meta standard or custom event, the Google Ads conversion action, the TikTok event, the warehouse table. Where an event goes to some destinations and not others, the reason is written in the row. The most important rows are the ones that go nowhere near a bidder, and I will come back to that. Revenue events: Currency recorded in ISO 4217 as charged, never converted on the client. Gross or net of store commission decided once, in writing, before anyone builds a dashboard against it. Refunds sent as their own event carrying the original transaction identifier rather than as negative revenue on the original, so a refund never silently rewrites a completed cohort. Transaction identifiers used as idempotency keys, because retries happen and a duplicated purchase is a worse error than a missing one. Subscriptions, and what I refuse: Renewals do not go to a bidding partner as purchases. This is the argument I have most often and I do not concede it. A renewal in month seven was not caused by the ad, and feeding it to a bidder teaches the model to buy users who look like your existing base rather than users who convert. Trial starts, trial conversions, renewals and cancellations stay separate events with separate destinations. I also will not forward hashed email addresses into an MMP, and I will not add an event whose only purpose is making a channel look better in a weekly deck. Consent, and what never leaves the device: The event queue holds before consent and flushes only after, with ATT and the TCF string ordered correctly so a rejection is honoured rather than raced. For Spanish and EU traffic that ordering is what an audit will actually examine. Fields that never leave: raw identifiers, free-text input, and anything typed into a search box on a banking or health app. Who this is not for: Pre-product-market-fit teams, where the taxonomy will be obsolete before it is implemented and a handful of events will serve you better. Teams wanting an audit of an existing taxonomy without permission to remove anything, since removal is most of the value. And anyone who needs this delivered in a week, because the mapping argument with the paid team is the work and it does not compress.