Is Mixpanel GDPR-compliant?

At a glance

Mixpanel is not GDPR compliant by default. It collects personal data (cookie identifiers, IP addresses, device information), fires without consent, stores data in the US by default, and doesn’t clean PII from event properties automatically. Like all major analytics tools, it needs to be configured for GDPR compliance.

But Mixpanel offers more compliance tools than most comparable products – including EU data residency and a deletion API. The biggest risk is PII passed into custom event properties. Audit your data model carefully before doing anything else.

Mixpanel has become a go-to tool for product analytics – tracking user behaviour within apps and SaaS products rather than just website page views. Its event-based model is powerful, but that same flexibility creates significant GDPR risks if not implemented carefully.

The most common compliance problem with Mixpanel isn’t the cookies or the data transfers – it’s what gets sent as event properties. If someone’s email address, name, or other personal data ends up in a Mixpanel event property, you have a more complex problem to solve.

What does Mixpanel collect?

• The distinct_id: Mixpanel’s primary user identifier, typically stored in a cookie or local storage. This is a pseudonymous identifier, but can become personal data if linked to a profile with identifying information.
• IP address: collected by default for geolocation; Mixpanel claims not to store the full IP in processed data, but it’s processed during ingestion.
• Device and browser information: user agent, operating system, screen resolution.
• Event data: whatever events and properties your implementation sends. This is the variable that can contain PII if not carefully managed.
• UTM parameters and referrer data.
• Geolocation derived from IP address.

The PII-in-events problem

This is the most serious and most common GDPR risk in Mixpanel implementations. By design, Mixpanel’s event model allows you to attach any property to any event. This flexibility is what makes it powerful – but it also means that personal data can end up in event properties by accident or through imprecise engineering.

Common examples:

• Sending user.email as an event property when tracking a login event
• Passing a user profile object that includes first name, last name, or contact details to Mixpanel’s People feature
• Including search query text that might contain someone’s name or personal health information
• Attaching a CRM ID that can be joined back to a system containing identifying information

Once PII is in a Mixpanel event property, it’s much harder to manage than if it had never been there. Deletion requests become complex; data audits become difficult. Audit your event schema before you get any further into compliance work.

Compliance steps: what you need to do

1. Audit your event data model: Before touching consent or retention settings, review every event your Mixpanel implementation sends. For each event type, list all properties being sent. Identify any that contain or could contain personal data. Work with your engineering team to replace direct identifiers with pseudonymous IDs or remove PII from properties entirely.
2. Integrate with your consent banner: Mixpanel’s script should not load until the user consents via your cookie banner. Gate the Mixpanel initialisation call behind consent. For logged-in users in a product context, handle the consent check during the product’s authentication flow rather than relying solely on the cookie banner.
3. Enable EU data residency: Mixpanel offers an EU data residency option that stores and processes data in European data centres. This is configured at the project level. Enable EU residency for any project collecting data from EU users. This removes the US data transfer concern as your primary issue – though your DPA and sub-processor list should still be reviewed.
4. Enable IP anonymisation: Mixpanel provides an option to drop the IP address from data after geolocation has been resolved. Enable this setting in your project settings. Without it, the full IP address is retained in event data.
5. Configure data retention: Mixpanel allows you to set data retention periods at the project level. Event data and user profile data can have different retention settings. Set periods that align with your documented retention policy – for most organisations, 12–24 months for event data is sufficient; adjust based on your specific analytics needs.
6. Implement DSAR deletion workflows: Mixpanel provides a Deletion API that allows you to delete all data associated with a specific distinct_id. Integrate this into your DSAR process: when you receive a verified erasure request, submit a deletion job to Mixpanel via the API for all distinct_ids associated with the individual. Be aware that if an email address appears in event properties, you’ll also need to search and delete by that property value.
7. Sign the DPA: Mixpanel provides a DPA through their terms of service. Sign the DPA and retain a copy. If you’re using EU data residency, confirm that the DPA covers EU-region processing specifically. Review the sub-processor list for any concerning third-party data sharing.

Mixpanel opt-out for logged-in users

For product analytics (tracking behaviour within a logged-in application), consent management is more complex than a standard website cookie banner. Just because a user is logged in to your service, it doesn’t mean they’ve consented to specific cookie categories. Mixpanel provides an opt-out mechanism at the SDK level:

• mixpanel.opt_out_tracking() – disables all Mixpanel tracking for the current user
• mixpanel.opt_in_tracking() – re-enables tracking with consent
• mixpanel.has_opted_out_tracking() – checks current opt-out status

This needs to be wired into your consent management flow – whether that’s through your cookie banner for unauthenticated sessions, or through an in-product privacy preference setting for authenticated users.