Here’s a conversation I’ve had more times than I can count. A data analyst pulls up the Mixpanel event list to build a funnel and finds all three of these:
add_to_cartAddToCartadd_to_cart_clicked
Three events. Three different engineers. Three different naming conventions. All firing in production. None of them documented. Nobody sure if they’re the same event or three different ones.
They’re the same event. Three teams, three sprints, no agreed standard.
This is the problem Data Standards solves — not after the fact, but as a live compliance layer baked directly into Lexicon. You define the rules once. Mixpanel evaluates every event against them and shows you exactly what’s in violation. No manual auditing, no spreadsheet-based naming convention documents that nobody reads.
What Is Data Standards?
Data Standards is a data governance feature that lets you define rules for how events should be structured in your Mixpanel project, then automatically evaluates every event against those rules and assigns a compliancy status to each one.
The compliancy status is visible directly in Lexicon. At any moment, any admin or analyst can open Lexicon, see which events are compliant and which aren’t, filter by compliancy status, and take corrective action from the same screen.
It’s available on Enterprise plans only. Only Project Admins or Owners can define the standards themselves, though all Lexicon users can see the compliancy status once standards are in place.
Step 1: Define Your Data Standards
To set up your standards, open Lexicon and navigate to the Data Standards tab. This is where you configure the rules that every event in your project will be evaluated against.
There are four types of rules you can configure:
Naming conventions. This is usually the most impactful rule for teams coming out of a chaotic implementation. You can require that all event names follow a specific syntax — snake_case, camelCase, or whatever convention your team has agreed on. Once set, any event that doesn’t match the required format will immediately show as non-compliant. This makes naming drift visible and actionable instead of something that accumulates silently.
Descriptions. You can require that all events have a description in Lexicon. This pairs naturally with a documentation culture — if analysts can see at a glance which events have descriptions and which don’t, there’s both visibility and mild accountability built in. For new events coming through the Event Approval workflow, the review step becomes the natural moment to add the description before marking the event visible.
Ownership. You can require that every event has an assigned owner — a named point of contact for that event. This is particularly useful in larger organizations where different teams own different parts of the product. When something goes wrong with an event or someone has a question about it, ownership removes the guesswork about who to ask.
Rich media uploads. You can require that events have relevant media assets attached — things like Figma mockups of the feature the event tracks, or app screenshots showing where in the product the event fires. This is less commonly mandated as a hard rule, but it’s worth knowing it’s an option, especially for teams that maintain close alignment between design and analytics.
Define the standards that are realistic for your organization right now. If your project is already a mess, starting with naming conventions and descriptions is usually enough. You can tighten the rules over time as your team builds the discipline around them.
Step 2: Understand What Gets Evaluated
There’s one important nuance to know about how Mixpanel applies your naming convention rule.
If an event has a Display Name set in Lexicon, the standard will be checked against the Display Name, not the underlying tracked event name. If no Display Name is set, it checks against the raw event name that was sent to Mixpanel.
This matters because a lot of teams have legacy event names they can’t change — the raw database name is baked into their codebase and renaming it would require an engineering sprint. In those cases, setting a clean Display Name that follows the naming convention is a valid way to bring an event into compliance without touching the implementation. The raw name stays as it is; the display name follows the rules.
If your team is starting fresh or has the ability to rename events at the source, enforce the convention at the tracked name level and don’t rely on Display Names as a workaround. Cleaner in the long run.
Step 3: Read the Compliancy Status in Lexicon
Once your standards are defined, Mixpanel evaluates every event in the project automatically and surfaces the compliancy status in Lexicon. You don’t run a scan manually — it’s always on.
In the Lexicon events view, you’ll see the compliancy status displayed alongside the usual fields like event name, status, volume, and query count. From there you can do three things:
Scan at a glance. Compliant and non-compliant events are visually distinct. A quick scroll through the event list tells you the overall health of your implementation without needing to click into anything.
Filter and sort by compliancy status. This is where it becomes genuinely useful as a governance tool. Filter to show only non-compliant events, and you have an instant remediation queue. Sort by compliancy alongside volume, and you can prioritize fixing the non-compliant events that are actually being used over ones that are stale or low-traffic.
Fix directly from Lexicon. You don’t need to go anywhere else to remediate. Click into a non-compliant event, update the description, assign an owner, set a Display Name that follows the naming convention — whatever the violation is, you can address it from the same screen. Once the event meets the standards, the compliancy status updates automatically.
How to Use This in Practice
The compliancy status is most powerful when it becomes part of your regular governance rhythm rather than something you check once and forget.
Use it in Lexicon audits. When you’re doing a periodic Mixpanel audit — quarterly is a reasonable cadence for most teams — filter to non-compliant events first. Work through that list before doing anything else. Non-compliant events are either undocumented, wrongly named, or unowned, and any of those conditions makes them less trustworthy for analysis.
Pair it with Event Approval. When a new event comes through the approval queue, part of your review before marking it visible should be checking whether it will be compliant under your defined standards. If you’re approving an event with a non-compliant name, you’re making a decision to approve something that will immediately show up as a violation. Sometimes that’s acceptable — there are legitimate reasons to approve an event you’ll fix later — but it should be a conscious decision, not an oversight.
Use it to create accountability with engineering teams. If your organization has engineering teams who implement tracking independently, the compliancy dashboard gives you a concrete, objective view of compliance by event. This moves conversations about naming standards from “we should probably be consistent” to “here are the 23 events your team shipped in the last quarter that don’t follow the convention.” Specific is more actionable than general.
Document your standards somewhere engineering teams will see them. Data Standards enforces the rules at the Mixpanel level, but engineers implementing tracking need to know the rules before they write the code. Keep a tracking guide in your engineering handbook or internal wiki that mirrors your Data Standards configuration. The governance tool catches violations; the documentation prevents them.
What’s Coming
Mixpanel has indicated that automated actions triggered by Data Standards violations are in development — meaning the system will eventually be able to take predefined actions automatically when an event comes in that violates your standards, rather than just flagging it for manual review. If that kind of automated enforcement would be valuable for your organization, it’s worth reaching out to your Mixpanel account manager to ask about early access.
The Scenarios Where This Pays Off Most
Post-acquisition data consolidation. When two product teams or two companies merge their Mixpanel implementations, you almost always end up with two different naming conventions running in parallel. Data Standards gives you visibility into exactly how many events are violating the canonical standard and a clear queue for remediation.
Onboarding new engineering teams. When a new team starts contributing to an existing Mixpanel project, Data Standards communicates your conventions automatically through the compliancy status. New events they ship that don’t follow the rules will show up as violations immediately, creating a natural feedback loop without anyone needing to run a manual review.
Scaling past the point where informal norms work. In a three-person startup, one person knows all the events and naming is consistent because one person does all the tracking. In a 50-person company with multiple product teams, that breaks down fast. Data Standards is what replaces the informal norm at scale — it makes the rules explicit and the violations visible.
The Bottom Line
Data Standards is the Mixpanel feature that converts your team’s tracking conventions from a document nobody reads into a live compliance layer that evaluates every single event automatically.
The setup is straightforward — define your naming convention, require descriptions, require ownership, optionally require media. From that point, Lexicon becomes not just a data dictionary but a data quality dashboard. Non-compliant events are visible. Filtering to your remediation queue takes one click. Fixing a violation takes less than a minute from the same screen.
The compliancy status won’t fix the events that were already in your project before you defined the standards. That’s still manual cleanup work. But it will stop the drift from accelerating, and it will make the work of improving your implementation visible in a way that motivates actually doing it.
If you’re on Enterprise and you’ve already set up Lexicon documentation and Event Approval, Data Standards is the third layer that completes the governance picture. Enable it, define your rules, and let Mixpanel tell you exactly where you stand.