The complete guide to event & property taxonomy

How to name events, event properties and user properties consistently — and the mistakes to avoid so your data stays reliable.

Before we start, if you need help with your product taxonomy, write to me at guido@bildungdata.com

General recommendations

• Consistent taxonomy: pick a taxonomy for your events and properties, and stick to it. This matters far more than which taxonomy you actually pick (camelCase, snakecase, etc).
• Use the same taxonomy across platforms: use the same taxonomy across all your platforms — Android, iOS, Web, Server-Side, etc.
• Use the same taxonomy across every tool where you track events: if you send an event to multiple MarTech tools (Mixpanel, OneSignal, Appsflyer, etc), use the same taxonomy in all of them.
• Don't track users' private data: never send personal data to any tool. E.g.: credit card, balances, etc.

→ TLDR: be consistent and use the same taxonomy everywhere.

Taxonomy — EVENTS

• Events: events are (1) actions performed by users (e.g. completing a purchase), or (2) actions that happen to users (e.g. a balance being updated through a backend process).
• Recommended taxonomy: we want a taxonomy that's easy for a human eye to parse. So the taxonomy we recommend is "object + verb in past tense". E.g.: Item Viewed, Item Purchased, Video Played.
• Use spaces to separate words. This makes it easier to read for anyone.
• Use upper and lower case properly (e.g.: Video Played).
• Avoid using taxonomies like camelCase or snakecase, simply because they're harder to read and therefore less human-readable (if you prefer one of these, use it — but be consistent).
• Use tags to identify which flow each event belongs to: if your platform has many flows (onboarding, checkout, etc), it's useful to identify which flow each event belongs to so they're easier to find when building a report. You can use Tags in Mixpanel for this.
• Don't use very specific names: for example, don't use "User Signed Up With Facebook". Use "User Signed Up", and use an event property to record the method (signupmethod = Facebook).
• Language: pick a language everyone understands. All things equal, we recommend English.

→ TLDR: use a taxonomy that's easy to read: Object + Verb in past tense. Separate words with spaces. Use upper and lower case. E.g.: Item Viewed, Video Watched.

Taxonomy — EVENT PROPERTIES

• Event properties: event properties enrich the data of an event. For example, for the "Item Purchased" event, we can send the type of product purchased (type = 'Coffee'), or the item price (price = 3.14).
• Taxonomy: we recommend a different taxonomy than the one used for events, simply so it's easy to tell a property apart from an event.
• We recommend snakecase with all words in lowercase.
• Examples: signupmethod, errortype, amountpurchased, itemprice, itemcategory.
• There are different types of event properties: (1) String — alphanumeric value (e.g. userid = "abc123"); (2) Numeric — integers or decimals (e.g. price = 3.14); (3) Boolean — true or false (e.g. completedonboarding = true); (4) Timestamp — dates in ISO 8601 format (e.g. lastlogin = "2025-06-12T14:23:00Z"); (5) List — list of values (e.g. favoriteditems = ["milk", "bread"]).
• Consistent taxonomy across events: if you track the same property across different events, it's very important to use the same name in every case.
• E.g.: when a user views a product (Item Viewed), and when a user purchases a product (Item Purchased), we want to store its category (property: itemcategory). Send itemcategory in both events with zero variation (spaces, casing, etc).
• Specific event vs Event + Property: the same piece of data can be stored as part of the event or as a property. For example, there are actions you can perform from multiple screens — you can add an item to the cart from Categories or from Search results:
• Option 1 — create two specific events: Item Added From Category, Item Added From Search.
• Option 2 — create a single event with a property: Item Added (property: from; values: Category, Search).

→ To pick the best option, think about how and how often you'll use it; building a report filtered by a property takes more time. If you'll build that report often, Option 1 might be better.

• Auto-tracked properties: Mixpanel's client-side SDK automatically tracks certain properties on every event. They follow this taxonomy: $browser, $device, $screenwidth.

→ TLDR: properties enrich events. There are 5 types of properties. Use a different taxonomy than Events so they're easy to tell apart.

Taxonomy — USER PROPERTIES

• Users: specific individuals who complete actions inside your product.
• User properties: user properties enrich the user's profile. For example: name, city, currentplan, numberoftransactions.
• There are different types of user properties: in general, the types are the same as event properties: (1) String, (2) Numeric, (3) Boolean, (4) Timestamp, (5) List.
• Taxonomy: we recommend the same taxonomy as for event properties, to keep properties easy to tell apart from events.
• Use snakecase with all words in lowercase.
• Examples: firstname, plantype, city, signupmethod.
• They are mutable — they can change over time: user properties can change over time (mutable), but not all of them will. For example, name or userid won't change; while plantype or totalpurchases will keep updating to always show the latest state.
• Incremental properties: incremental properties help track the historical value of key properties. For example, if you care about each user's all-time purchase count, you can track the incremental property totalpurchases, which adds +1 on each new purchase.
• Auto-tracked properties: Mixpanel's client-side SDK automatically tracks certain properties on every user. They follow this taxonomy: $city, $region, $countrycode.

→ TLDR: user properties enrich users' profiles. They are mutable — they can change over time.