> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/mixpanel/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Building a Tracking Strategy

> Learn how to create a tracking plan that captures the right events and properties for meaningful analysis

# Building a Tracking Strategy

A well-defined tracking strategy ensures your product data stays consistent and reliable, enabling teams to make data-informed decisions without wasting time on data cleanup.

This guide details how to create a tracking strategy that enables your team to capture the right events and properties, keep them consistent, and set them up for meaningful analysis.

## What is a Tracking Strategy?

A tracking strategy is a plan for deciding **which events and properties to capture, how to name them, and how to manage them over time**.

In Mixpanel, this means using the [data model](/docs/data-structure/concepts) (events, users, and properties) intentionally, so your data is structured for the KPIs that matter most to your business.

A tracking strategy is not just about what you log; it is about creating a shared framework so product, engineering, and analytics teams can trust the data and use it to answer business questions.

## Building a Tracking Strategy

A good strategy is built step by step, not all at once. The practices below will help you move from a vague idea of "we should track more" to a clear, scalable framework your whole team can rely on.

## Define the Events that Matter

Events are the backbone of Mixpanel. Start by mapping out the key user actions tied to your KPIs (e.g. sign-up started, checkout completed, feature used).

* Only track events that represent meaningful behaviors connected to business goals
* Don't track every click or interaction simply because it is possible, since doing so can clutter your analysis

<Tip>
  Focus on events that directly answer questions your team needs to solve. Every event should have a clear purpose.
</Tip>

Learn more about [Events](/docs/data-structure/events-and-properties).

## Use Event Properties to Add Context

Events tell you *what* happened, properties tell you *how* it happened. Properties give you the flexibility to keep your event list small while still allowing rich analysis.

<Steps>
  ### Utilize properties to avoid creating separate events for each variation

  Properties like `plan_type`, `payment_method`, or `device` can help keep your event list targeted and make analysis easier. Instead of hunting across multiple events, you can filter one event by property values.

  ### Use consistent data types for predictable analysis

  Consistency in [data types](/docs/data-structure/property-reference/data-type) (e.g. string, numeric, or Boolean) ensures your metrics are accurate and comparable over time. For example, if a property is sometimes a string and sometimes a number, queries can break and charts can become unreliable.

  ### Attach session-level context as super properties

  Promoting context like app version, device type, or campaign source to a [super property](/docs/tracking-methods/sdks/javascript#setting-super-properties) auto-attaches it to every event, which saves engineering effort and guarantees important context is always available in your analysis.
</Steps>

<Tip>
  Teams typically see the best results when they limit their schema to a manageable set of core events, enriched with properties for detail.
</Tip>

## Capture User Profiles and Properties

Events capture behavior, while user profiles capture who the user is today (e.g. their email, location, and subscription level). When you pair event properties with user properties, you can compare past behavior with the current state.

For example, a user property for `current_country = Singapore` can be compared with an event geolocation property showing where they logged in previously. A user who travels often may track events in different locations despite their current location being somewhere else.

Learn more about [User Profiles](/docs/data-structure/user-profiles).

## Tips for Choosing Properties

Properties, whether attached to events or stored on user profiles, add the context that makes your analysis meaningful. The right ones make it easy to answer business questions; the wrong ones add noise and confusion.

Use these guidelines to decide which properties to include.

<Steps>
  ### Prioritize analysis needs

  Capture properties that directly support the questions your team needs to answer. For example, if "Which payment methods drive the most revenue?" is a key question for your team, you should prioritize including properties like `payment_processor` and `payment_method`.

  ### Favor stability

  Pick properties that are unlikely to change meaning or format frequently. This keeps your reporting consistent over time.

  ### Balance detail with simplicity

  More properties mean more flexibility, but too many can overwhelm dashboards and confuse stakeholders.

  ### Reuse across events

  Standardize common properties like `plan_type`, `device`, or `region` so you can compare data across events instead of reinventing them each time.
</Steps>

Following these guidelines keeps your schema focused, while still giving you the flexibility to answer the questions that matter most.

## Standardize Naming Conventions

Clear, consistent names make your data easier to use and trust. A naming convention prevents confusion, reduces duplicate events, and keeps your queries simple.

* Pick one convention and use it everywhere
* Don't mix formats like `SignUp`, `signup_started`, and `Signup Started`

As a best practice, use `snake_case` for all event names, properties, and property values (for example: `checkout_completed`, `payment_method = credit_card`). Snake case works well with APIs and avoids ambiguity.

<Tip>
  Write down your naming rules in your tracking plan so engineers and analysts always know what to follow.
</Tip>

## Document and Govern Your Tracking Plan

Your strategy only works if it is shared and enforced. Keep a **living tracking plan** and lean on Mixpanel's governance features.

1. Store your tracking plan in a shared location, such as a Google Sheet or Notion page
2. Keep your tracking plan updated as your product evolves
3. Share your tracking plan widely across product, engineering, and analytics teams

### Tools to Help with Data Governance

* [Tracking Plan Template](/docs/tracking-best-practices/tracking-plan): Organize event names, properties, and owners in one place
* [Lexicon](/docs/data-governance/lexicon): Add descriptions, assign owners, and hide deprecated events right in Mixpanel

Learn more about [Data Governance](/docs/data-governance).

## Example Tracking Plan

Here's what a simple tracking plan might look like for an e-commerce site:

### Core Events

| Event Name           | Description                      | Key Properties                                       |
| -------------------- | -------------------------------- | ---------------------------------------------------- |
| `product_viewed`     | User views a product detail page | `product_id`, `product_name`, `category`, `price`    |
| `add_to_cart`        | User adds item to shopping cart  | `product_id`, `quantity`, `cart_total`               |
| `checkout_started`   | User begins checkout flow        | `cart_value`, `item_count`                           |
| `payment_info_added` | User enters payment details      | `payment_method`                                     |
| `purchase_completed` | User completes purchase          | `order_id`, `total_amount`, `currency`, `item_count` |

### User Properties

| Property Name     | Description               | Type     |
| ----------------- | ------------------------- | -------- |
| `email`           | User's email address      | String   |
| `signup_date`     | Date user created account | DateTime |
| `plan_type`       | Free, Pro, or Enterprise  | String   |
| `total_purchases` | Lifetime purchase count   | Number   |
| `ltv`             | Customer lifetime value   | Number   |

### Naming Conventions

* All events: `snake_case` (e.g., `checkout_started`)
* All properties: `snake_case` (e.g., `payment_method`)
* Property values: `snake_case` (e.g., `credit_card`, not `Credit Card`)
* Boolean properties: Prefix with `is_` (e.g., `is_premium`)

## Common Tracking Mistakes to Avoid

### Tracking Too Many Events

**Problem:** Every click becomes an event, cluttering your schema.

**Solution:** Only track events that tie to business questions. Ask: "Will this help us make a decision?"

### Inconsistent Naming

**Problem:** `SignUp`, `sign_up`, `user_signup`, and `Signup` all exist.

**Solution:** Document your naming convention and enforce it through code reviews and governance.

### Missing Critical Properties

**Problem:** Events exist but lack context (e.g., `purchase_completed` without `amount`).

**Solution:** Define required properties for each event in your tracking plan.

### Not Versioning Your Schema

**Problem:** You change what an event means, breaking historical analysis.

**Solution:** If an event's meaning changes significantly, create a new event (e.g., `checkout_started_v2`) or use a version property.

### No Ownership

**Problem:** Nobody knows who's responsible for maintaining tracking.

**Solution:** Assign owners to events and properties in Lexicon. Make someone accountable for data quality.

## Implementing Your Tracking Plan

Once you've documented your strategy, implement it:

<Steps>
  ### Share the plan

  Distribute your tracking plan to product, engineering, and analytics teams.

  ### Set up your SDKs

  Implement [Mixpanel SDKs](/docs/tracking-methods/sdks) in your application.

  ### Instrument events

  Add tracking calls for your defined events with their required properties.

  ### QA your implementation

  Test in a development environment before pushing to production.

  ### Document in Lexicon

  Add descriptions and owners for all events and properties in [Lexicon](/docs/data-governance/lexicon).
</Steps>

## Maintaining Your Tracking Plan

Your tracking plan is a living document. As your product evolves, so should your tracking:

### Regular Audits

* Quarterly reviews of all events and properties
* Identify deprecated or unused events
* Check for naming inconsistencies
* Verify property data types

### When to Update

* New product features launch
* User flows change significantly
* New business questions emerge
* Teams request additional context

### Communication

* Announce tracking changes in team channels
* Update documentation immediately
* Train new team members on tracking standards

<Tip>
  Treat your tracking plan like production code. Require reviews before changes, document updates, and communicate broadly.
</Tip>

## Key Takeaways

* Only track events that tie directly to KPIs
* Use properties to keep your schema flexible
* Capture user profiles to combine "who" with "what"
* Standardize names using snake\_case
* Document your plan and use governance features to keep data clean
* Treat your tracking plan as a living document
* Assign ownership for data quality

## Next Steps

* Download the [Tracking Plan Template](/docs/tracking-best-practices/tracking-plan)
* Map your key user journeys to events
* Define required properties for each event
* Document your naming convention
* Set up [Lexicon](/docs/data-governance/lexicon) to govern your schema
* Review the [Data Quality guide](/guides/data-quality) to learn how to QA your implementation