Plan your taxonomy

Using Amplitude effectively requires you to first identify the events and properties you want to track. Designing a solid, scalable taxonomy can make your analyses easier, avoid data gaps, and prevent future data issues.

This playbook reviews the strategy and considerations for creating your tracking plan.

What is a taxonomy

A taxonomy is a set of hierarchical classifications and naming conventions for your data. A taxonomy identifies and categorizes your event and user data so that Amplitude can generate relevant and valuable insights. The process of setting up a taxonomy in Amplitude differs from organization to organization, but the core steps are selecting the events you want to track, identifying event properties and user properties to track, and naming them.

Users, events, and properties

Amplitude's analyses use a combination of events and properties attached to your users.

Users

A user represents a unique individual taking an action or engaging in an activity related to your application. Amplitude uses multiple methods to identify and reconcile your users across various devices.

You can learn how Amplitude tracks unique users, including how to reconcile anonymous users before login.

Events

An event is a distinct action or activity a user takes within your product. Events can be active when a user interacts with your app (for example, starting a game or adding to their cart), or inactive (the user receives a push notification).

When naming events, Amplitude recommends establishing a consistent naming convention that uses:

• Consistent capitalization: Amplitude captures Song Played and song played as two separate events, so this naming convention helps prevent messy data, especially when multiple teams send the same event.
• A consistent syntax: Song Played and Played Song are also separate events. For example, a standard of [Noun] + [Past-Tense Verb] ensures all your events stay consistent.
• A consistent actor: Does Message Sent mean that the user sent a message, or that you sent a message to the user? If all your events use the user's perspective, the meaning is clear immediately.

Default events use Title Case from the user's perspective, with [Noun] + [Past Tense Verb]. You can also establish your own convention as long as you stay consistent.

Properties

Properties are attributes that help define details around your events and users:

• Event properties are attributes that describe details specific to a particular instance of an event. For example, if you have a Purchase Completed event, you can specify what the user purchased, the total value of the order, and the payment method used.
• User properties are traits that describe the user and apply across all the user's future events until the properties are modified. Amplitude's SDK captures several user properties by default, and you can also set up your own properties to track.

Learn more about the differences between events and user properties. As with events, establish a naming convention with consistent casing.

Step 1: Define your business objectives

Starting with your goals and metrics helps ensure you've prioritized the most important ones for your implementation. For example:

• What are you and your team working toward?
• What metric are you trying to optimize?
• What questions do you want to answer with data?

Some typical goals Amplitude customers pursue include:

• Improving acquisition ROI.
• Finding the "aha" moment in the product.
• Optimizing conversion.
• Increasing user retention and LTV.

After you identify your organization's overarching goals, it's easier to break them down into individual metrics and ensure your tracking plan measures the outcome you want.

For example, suppose you have an e-commerce app and want to increase purchases. You can do this by:

• Increasing the conversion rate of users through your purchase flow.
• Increasing the number of users who make multiple purchases.
• Increasing the number of users coming to your app.

Each of these can be an input metric to achieve your goal. Prioritize these input metrics so you can answer the most important question first. Consider an iterative approach, where you plan and instrument your most important metrics, then iterate later to add more.

Step 2: Break down your key metrics

After you know your ultimate goal and have hypotheses about how to accomplish that goal, break down those input metrics further. What critical paths do your users take, and how do they involve each of those metrics? What actions are essential to each of those paths?

Suppose you start with increasing the conversion rate of users through your purchase flow. What are users' critical interactions with your application through the purchase flow? They could be:

• Search completed: The user searched for an item to purchase.
• Product details viewed: The user viewed the details of an item.
• Product added: The user added an item to their order to purchase.
• Order reviewed: The user viewed the items in their order before purchase.
• Order completed: The user made a purchase and completed their order.

For each of these, think about the various factors involved in each step. For example:

• When using search, what term did the user search for?
• When the user viewed an item, what was the Product ID for the item purchased?

One helpful technique is to think about the objects involved with each action and include attributes of those actions in each event. For example, an item in your system likely has an ID, a category, and a price, all properties you can add to events related to your items.

Step 3: Optimize your events and properties

It's time for final optimizations on your plan. Ask yourself these questions.

Do you have multiple events for similar actions

Suppose you have two user actions you can capture as two separate events, or as a single event with a property distinguishing the two distinct cases.

For example, suppose you believe payment method is a critical factor. Should you instrument:

• Order Completed as a single event with a Payment Method property that captures Credit Card or Apple Pay, or
• Separate events for Credit Card Order Completed and Apple Pay Order Completed?

Consider these factors:

• Start with your key metrics. In this case, while the purchase method is important, the key metric is the purchase flow conversion. A single Order Completed event is easier to include in a funnel to view the overall purchase flow conversion.
• Is the event scalable? In this example, what happens when you introduce PayPal as a new payment method? Any chart measuring overall conversion would need an update. You'd also be using three events for an interaction where one is enough.
• Do you want to identify these separately in Journeys? If so, a single Order Completed event is probably fine. If you made all your events Page Clicked instead, a series of these generic events is unlikely to help when looking at a user flow.

Are your property definitions consistent across your events

Even though event properties are specific to each event, define them consistently across your taxonomy. For example, instead of having a property called Type that could represent the type of an item in one event and a type of payment in another, consider separate properties: Item Type and Payment Type.

Are your properties captured across all applicable events

One typical use case for event properties is tracking values that must hold constant to count toward funnel conversion. For example, suppose you want to know how often users add to cart after viewing details:

• Step 1: Product Details Viewed
• Step 2: Product Added

Here, users should count as having converted through the funnel only if they triggered the event on the same product. To ensure this, instrument the event property Product ID and require the funnel to hold this value constant. Every event in the funnel must have that property for the holding constant feature to work.

• Step 1: Product Details Viewed
  • Product ID = 3345
• Step 2: Product Added
  • Product ID = 3345
  • quantity = 1

In this example, you can understand how often a user adds to their cart after viewing an item. Without the Product ID, you'd be analyzing how often a user adds any item to their cart after viewing any item.

AI-assisted taxonomy planning

Amplitude's MCP plugin includes skills that automate the most time-consuming parts of taxonomy design and event instrumentation. Install the plugin from the Amplitude MCP Marketplace to unlock all six skills in Claude Code, Cursor, or any MCP-compatible editor.

Taxonomy and governance skills

Automated instrumentation pipeline

Use amplitude:add-analytics-instrumentation as a single entry point. It runs the full pipeline end-to-end for a given PR, branch, file, or feature description, and outputs a concrete instrumentation plan you can hand to engineering.

Internally, three sub-skills run sequentially:

1. amplitude:diff-intake: Reads a PR or branch diff and produces a structured summary of which files changed, which user-facing surfaces the changes affect, and the overall analytics scope.
2. amplitude:discover-event-surfaces: Given that summary, generates a prioritized list of candidate events organized by business outcome, user journey, feature success, and friction.
3. amplitude:instrument-events: Given the candidate events, outputs exact insertion points in your code, recommended event names, descriptions, categories, and properties that meet Amplitude's AI-readiness guidelines.

The skills are open source: Amplitude MCP Marketplace on GitHub.

Next steps

Refer to the steps in this playbook as you add new features or iterate on your product analytics. Amplitude Data provides ways to create and iterate on your plan directly in the product, or by importing a CSV file.

For more specific examples, go to the following industry-specific best practices guides for sample use cases, business questions, taxonomy recommendations, and complementary dashboards. Each guide addresses the specific needs of these sectors:

• E-commerce.
• Fintech.
• Publications.
• Streaming Media.
• B2B.
• Healthcare.