Event taxonomy
The naming rules for your analytics events, so 'signup', 'sign_up', and 'Signed Up' never become three different metrics.
See it
What it is
An event taxonomy is the house style for your analytics data: which actions become events, how those events are named, and which properties ride along with each one. Without it, three engineers ship 'signup', 'sign_up', and 'Signed Up' in the same quarter and your conversion rate is now split across three charts that each look broken.
The part everyone agrees on is object plus action in past tense: the thing, then what happened to it, already done. Casing is where houses differ. The default worth picking is snake_case ('project_created', 'invite_sent', 'card_added') because it survives SQL, warehouse column names, and URL parameters without quoting. Override it when your tool's own documentation and UI assume something else: Segment's spec and Amplitude's examples use Title Case with a space ('Project Created'), and matching the tool your team reads all day beats matching a style guide. Either is fine. Mixing the two is not, so write the choice down once and never mix. Keep the event name generic and push the specifics into properties, so you log 'Button Clicked' with a button_name property instead of minting 'Nav CTA Clicked' and forty siblings. Fix property names and types once (plan_tier is always a lowercase string, never sometimes a number) and write the whole thing down as a tracking plan that code review checks against.
Gotcha: event names are close to permanent. Analytics tools do not rewrite history, so renaming an event in month nine leaves you with two half-series and a funnel that dies at the seam. The other trap is the opposite of chaos: over-instrumenting. Tracking every hover produces high-cardinality noise, a bigger bill, and nobody who can find the ten events that actually matter.
Ask AI for it
Design an event taxonomy for my product (describe it below). Name events as object plus action in past tense, in snake_case ('project_created'), unless the analytics tool already in this project documents a different house casing, in which case use that one and say which tool and which doc drove the choice. Give me a table of 12 to 20 core events covering signup, activation, core usage, and monetization, and for each one list its properties with types and example values. Keep event names generic and push variants into properties. Add a shared set of user properties and global event properties that every event carries, plus 5 explicit naming rules (casing, tense, forbidden patterns, when to add a property instead of a new event, how to deprecate). Flag anything I listed that should NOT be its own event.