Mixpanel Guide to Data Privacy & PII Best Practices
Mixpanel’s recommended approach for managing sensitive data is built on a simple goal: help you collect only what you need, reduce risk, and maintain high-quality analytics.
Privacy in analytics isn’t solved by a single setting—it’s a continuous practice. At Mixpanel, we aim to make responsible data behaviors the default, ensuring you can maintain a safe environment without compromising your team’s velocity.
To achieve this balance, we recommend adhering to four core principles that act as practical habits for your team:
- Data Minimization: Track only what supports your KPIs and product decision-making. If a specific data point or property doesn’t drive insight, do not collect it.
- Pseudonymization by Default: Use stable internal identifiers (like
user_id) rather than emails or phone numbers. If internal IDs are identifying, hash or encrypt them before sending. - Purpose Alignment: Design tracking around meaningful “value moments” rather than exhaustive behavioral capture. Data collected without a specific purpose is almost always a liability.
- Shared Responsibility: While Mixpanel provides governance tools like Data Views, Data Classification, Data Deletion, and privacy features, you determine what enters the system to align with your regulatory requirements.
Below is a simple three-step framework for deciding what data to collect, identifying any sensitive data involved, and ensuring it’s handled safely.
Phase 1: Design & Collection
This phase focuses on the decision-making process before data is collected: defining what data creates value versus what creates risk.
What is PII?
PII (Personally Identifiable Information) refers to any data point that can directly identify a person or can be combined with other data to do so. While often associated with obvious fields like names or emails, PII in Mixpanel also includes technical identifiers—such as IP addresses or device IDs—that require governance.
Understanding how these identifiers surface in events and profiles helps you design tracking that protects users while still giving product teams the insight they need.
PII can appear in several forms:
- Direct identifiers: Names, emails, phone numbers.
- Account identifiers: Internal user IDs, workspace IDs.
- Device/network identifiers: IP address, device ID, ad IDs.
- Highly sensitive data: Government IDs, payment card details, authentication secrets.
Classifying Data Risk
While Mixpanel captures data through events, user profiles, and (optionally) group profiles, the privacy risk lies almost entirely in the properties you attach to them. Use this matrix to classify your data before adding it to your tracking plan.
| Risk Level | Common Examples | Best Practice |
|---|---|---|
| Low Risk | Plan tier, device type, experiment variation, feature metadata. | Safe to Track. These properties drive product insights without identifying specific individuals. |
| Moderate Risk | Email, phone number, IP address, Device ID. | Govern Carefully. Only track if needed for a legitimate business purpose. Must be marked as “Classified” immediately. |
| High Risk | Government IDs (SSN), payment card details, authentication secrets. | Do Not Track. Avoid sending this data entirely. |
Tracking Do’s
- DO use internal IDs: Use non-personally identifiable internal IDs (like
user_idoraccount_id) whenever possible. If an internal ID reveals identity, hash or encrypt it before sending. - DO maintain a tracking plan: Document definitions, data types, business purposes, and PII flags for every event and property you intend to collect.
- DO track value moments: Map events directly to KPIs—such as activation, engagement, monetization, or retention—rather than tracking every possible click.
Tracking Don’ts
- DON’T send high-sensitivity data: Never send government ID numbers, payment data, or credentials.
- DON’T rely on email/phone as IDs: Treat emails and phone numbers as optional properties for communication, not as your primary stable user identifier.
- DON’T send unreviewed free-text: Avoid free-text fields (like form inputs) that may contain unintentional PII.
- DON’T send raw identifiers in Session Replay: Mask or redact input fields where appropriate.
Handling “Must-Have” PII
Mixpanel’s stance is that you should avoid sending highly sensitive data entirely. If you must send PII (like an email for targeting), ensure it has a legitimate business purpose approved by your compliance team, and mark it as “Classified” immediately.
Phase 2: Governance & Access
Once you have defined what data to collect, you must ensure it is accessed safely. Rather than gating analytics behind complex configurations, Mixpanel uses a “governance layer” to control visibility without blocking data ingestion.
Classify Sensitive Properties
Data Classification is your first line of defense. It is a simple toggle that marks a property as “Classified.”
- Action: Review your tracking plan and mark any property containing identifiers (e.g.
$email,$ip) or sensitive business data as classified. - Effect: This does not stop data collection, but it tags the data so you can enforce policies on who views it.
Curate Data Views
Instead of giving every user access to raw data, use Data Views to create governed subsets of data relevant to their specific role. This allows you to “curate” a safe environment rather than just restricting access.
- Create a “Broad-Access” View: Exclude classified PII (like email or Device ID) from the default view used by Product Managers and Analysts. This prevents accidental exposure while maintaining full analytical power.
- Create Regional Views: Filter events by geography (e.g.
cityorregion) to create specific views (like “EU Data Only”) that align with local data residency and compliance requirements.
Define Access & Roles
Privacy and strong governance depend on how you plan your organizational settings around who has access, how projects are structured, and how often those permissions are reviewed.
- Least-Privilege Access: Grant teams access only to the Data Views they need. For example, Customer Support may need a “User History” view (with PII), while the Strategy team only needs “Anonymized Trends.” Start with minimal permissions and add them only when necessary.
- Routine Access Reviews: Conduct regular audits to confirm that only the right people can still see classified data.
- Training: Train your teams on what PII is and how to interpret “Classified” badges inside Mixpanel so they understand the boundaries.
- Separate Environments: Use separate Mixpanel projects for Production and QA. Never populate non-production projects with real user identifiers.
Operationalize Compliance
Mixpanel includes specific features to support compliance with GDPR, CCPA, and other similar frameworks, helping you operationalize privacy requirements without manual workarounds.
- Data Retention: Set up policies to automatically purge older data that is no longer needed for analysis.
- User Deletion API: Integrate the Deletion API to delete all user-related data programmatically upon request (e.g. “Right to be Forgotten”).
- Opt-out Settings: Ensure your SDK implementation respects user consent flags and local requirements.
Document in Lexicon
Use Lexicon as your single source of truth. Document the privacy posture of each field—explicitly stating its business purpose and which Data Views it belongs to—so new team members understand how to handle it safely.
Phase 3: Monitoring & Maintenance
Even well-governed data drifts over time. This phase ensures your privacy posture remains healthy as your product evolves.
Routine Reviews
Schedule quarterly or semi-annual reviews to catch issues early. Your review checklist should cover:
- New Tracking: Audit recently added events and properties to ensure no accidental PII was introduced.
- Drift: Check existing properties to ensure they haven’t started capturing PII (e.g. a “Search Query” field where users have started typing names).
- Clean-up: Identify and deprecate redundant or unused fields to minimize your data footprint.
Remediation Workflow
If you discover unexpected PII, follow a structured remediation flow immediately:
- Stop Ingestion: Drop the event or property at ingestion to stop the leak.
- Restrict Access: Immediately reclassify the property and restrict access using Data Views and Data Classification.
- Notify & Update: Inform relevant stakeholders (including Legal/Compliance) and update your tracking documentation to prevent recurrence.
Governance Toolkit
Leverage Mixpanel’s tools to automate maintenance and cleanup:
- Visibility Control: Hide data in Lexicon that is no longer needed to keep the project clean without permanently deleting it.
- Configuration Updates: Update Data Classification and Data Views as your data evolves to ensure new properties are governed correctly.
- Project Data Deletion: Use Mixpanel’s Data Deletion feature to permanently remove specific events or properties that contain accidental PII or are no longer valid.
- Lexicon Updates: Keep Lexicon descriptions up to date so the “safe” status of every metric is clear to all users.
Summary
Privacy-aware analytics requires intentional data collection, strong governance, and continuous review.
- Design intentionally: Send only the data you truly need to drive decisions, and keep high-risk data out of your tracking plan from the start.
- Govern proactively: Use Data Classification and Data Views to curate safe environments, ensuring teams access only the insights they need without unnecessary exposure to PII.
- Maintain habits: Treat privacy as an organizational practice—using regular access reviews, documentation in Lexicon, and cleanup routines to reinforce safety over time.
Get the Checklist: To ensure your implementation meets all these standards—including naming hygiene, security controls, and QA workflows—download the PII & Data Privacy Best Practice Checklist.
When teams operate within these guardrails, Mixpanel becomes a secure, reliable foundation for confident decision-making.
Was this page useful?