Ce que Mixpanel collecte

Le SDK Mixpanel (chargé depuis cdn.mxpnl.com ou auto-hébergé) initialise un objet global mixpanel et identifie les utilisateurs avec un cookie propriété de Mixpanel contenant un identifiant distinct généré. À partir de ce moment, chaque appel à mixpanel.track() envoie une charge utile d'événement — nom de l'événement, propriétés, l'identifiant distinct, et un ensemble de propriétés auto-capturées (agent utilisateur, OS, référent, paramètres UTM, résolution d'écran, fuseau horaire) — au point d'ingestion de Mixpanel. Le SDK prend également en charge un mode Autocapture qui surveille le DOM et émet des événements de clic, de page vue et de soumission de formulaire sans instrumentation explicite, élargissant considérablement la surface de ce qui est collecté.

Une fois qu'un utilisateur s'authentifie et que l'application appelle mixpanel.identify(user_id), tous les événements suivants — et, selon la configuration, tous les événements anonymes précédents — sont associés à l'identité authentifiée. L'association rétroactive est l'une des fonctionnalités les plus utiles de Mixpanel et l'une des plus exposantes du point de vue de la confidentialité : le comportement de navigation anonyme collecté avant le consentement est rétroactivement lié à un profil identifié dès que cet utilisateur se connecte.

Pourquoi le cadrage « analyse produit » ne vous dispense pas du consentement

Un argument courant des équipes produit et ingénierie est que les données Mixpanel sont pour les décisions produit internes, pas pour le marketing ou la publicité, et que ce cadrage d'usage interne devrait être une justification suffisante sous la base d'intérêt légitime du GDPR. L'argument est largement incorrect pour trois raisons sur lesquelles les régulateurs ont été explicites.

Le traitement reste un traitement de données personnelles

Quelle que soit la raison pour laquelle les données sont collectées, les cookies sont non essentiels selon l'ePrivacy Article 5(3) et les événements portent des identifiants persistants selon la définition du GDPR des données personnelles. L'analyse de la base juridique est la même que pour tout autre script de suivi.

L'intérêt légitime nécessite un test de mise en balance

La CNIL, l'ICO et l'EDPB ont tous rédigé des lignes directrices précisant clairement que l'intérêt légitime pour l'analyse comportementale nécessite une évaluation documentée montrant que le traitement est nécessaire, proportionné, et ne supplante pas les attentes raisonnables de l'utilisateur. Pour un fournisseur SaaS tiers recevant des données d'événements au niveau utilisateur, ce test de mise en balance réussit rarement sans consentement explicite.

Le transfert transfrontalier est indépendant

Même si vous pouviez établir un intérêt légitime pour la collecte elle-même, le transfert international vers l'infrastructure américaine de Mixpanel porte sa propre exigence de base juridique que le consentement ou une garantie contractuelle satisfait généralement plus proprement que l'intérêt légitime seul.

Contrôles de confidentialité natifs de Mixpanel

Mixpanel expose un ensemble significatif de primitives de confidentialité conçues pour soutenir les déploiements conditionnés au consentement. Comme pour la plupart des plateformes, elles supposent que la décision de consentement existe en amont ; elles ne la collectent pas elles-mêmes.

opt_out_tracking

L'appel mixpanel.opt_out_tracking() empêche le SDK d'envoyer des événements et persiste la préférence d'exclusion entre les sessions. Associez-le avec mixpanel.opt_in_tracking() lorsque l'utilisateur accepte la catégorie analytique dans votre CMP. Le SDK respecte ce paramètre pour tous les appels suivants sans nécessiter de réinitialisation.

has_opted_out_tracking

Une fonction de requête qui retourne l'état d'exclusion actuel, utile pour synchroniser l'état du SDK avec l'état de votre CMP au chargement de la page ou au changement de route.

L'option de résidence EU

Mixpanel propose un type de projet de résidence de données EU qui conserve les données d'événements dans l'infrastructure basée à Frankfurt. Cela répond à une portion significative de la préoccupation de transfert transfrontalier et est la configuration appropriée pour tout projet où la résidence EU est une exigence stricte. Cela n'élimine pas l'exigence de consentement.

set_config({ ip: false })

Désactive la capture d'adresse IP, réduisant l'empreinte de données personnelles de chaque événement. Utile comme mesure de défense en profondeur aux côtés du conditionnement au consentement.

Intégration CMP étape par étape

Le schéma d'intégration qui fonctionne de manière fiable est d'initialiser Mixpanel dans un état d'exclusion par défaut, puis d'inclure l'utilisateur lorsqu'il accepte la catégorie analytique dans le CMP.

1. Initialiser Mixpanel avec l'exclusion par défaut

Appelez mixpanel.init(token, { opt_out_tracking_by_default: true }) aussi tôt que possible dans le démarrage de votre application. Cela charge le SDK mais l'empêche d'envoyer des événements jusqu'à ce que opt_in_tracking() soit appelé.

2. Connecter le callback de consentement

Lorsque le CMP déclenche son événement de catégorie analytique acceptée, appelez mixpanel.opt_in_tracking(). Les événements en file d'attente qui ont été capturés pendant la période d'exclusion sont généralement supprimés ; si vous devez les conserver, configurez explicitement le comportement de mise en file d'attente du SDK et acceptez le petit risque que les événements de la période pré-consentement soient envoyés post-consentement.

3. Gérer la révocation

Si l'utilisateur révoque ultérieurement le consentement, appelez mixpanel.opt_out_tracking(). Cela arrête toute ingestion d'événements supplémentaire. Pour la suppression complète des données historiques, l'application doit en outre appeler l'API de suppression de Mixpanel ou déclencher une demande de suppression depuis l'interface du projet Mixpanel.

4. Éviter la fusion d'identité rétroactive sans consentement explicite

Désactivez le comportement de fusion rétroactive de l'appel identify à moins que l'utilisateur n'ait consenti à ce que sa navigation pré-identification soit liée à son profil. Les options du SDK de Mixpanel exposent un indicateur pour cela ; la valeur par défaut conservatrice est « pas de fusion rétroactive ».

5. Utiliser le projet de résidence EU pour le trafic EU

Pour les projets où la résidence EU importe, routez le trafic EU vers un projet Mixpanel de résidence EU et le trafic US/autre vers un projet séparé. Le SDK prend en charge le chargement de différents tokens conditionnellement à la région détectée de l'utilisateur.

Pièges courants

Quatre erreurs d'intégration comptent pour la plupart des constatations d'audit sur les déploiements Mixpanel.

Traiter Mixpanel comme exempt parce qu'il est d'usage interne

C'est l'erreur la plus courante de loin. Les données sont des données personnelles, le cookie est non essentiel, et le transfert tiers est réel quelle que soit la manière dont les données sont utilisées en aval. Conditionnez Mixpanel sous le consentement analytique comme tout autre traceur.

Laisser Autocapture activé par défaut

Autocapture élargit considérablement la surface de ce qui est envoyé — chaque clic, chaque interaction de champ de saisie, chaque page vue. La surface de risque évolue avec. Pour la plupart des déploiements SaaS, l'instrumentation explicite produit des données plus propres et une empreinte d'audit plus petite qu'Autocapture ; désactivez Autocapture sauf si vous avez une raison spécifique de le garder.

Oublier la fusion d'identité rétroactive

Le comportement d'identification par défaut associe les événements anonymes avec l'utilisateur maintenant identifié. Si l'utilisateur a accepté le consentement analytique seulement au moment où il s'est connecté, l'association rétroactive de sa navigation anonyme pré-consentement crée un problème de documentation. Désactivez la fusion rétroactive ou limitez-la explicitement aux événements post-consentement.

Coder en dur l'hypothèse de résidence EU

Un nombre surprenant d'équipes routent tout le trafic vers un projet Mixpanel de résidence US en supposant que le consentement couvre la question de résidence. Ce n'est pas le cas — consentement et résidence sont des questions de conformité indépendantes. Routez par région détectée, pas par défaut global.

Liste de vérification d'audit

Six questions concrètes à répondre pour tout déploiement Mixpanel touchant le trafic EU, UK ou californien.

• Mixpanel démarre-t-il en exclusion ? Confirmez que le SDK s'initialise avec opt_out_tracking_by_default: true et qu'aucun événement ne se déclenche avant le consentement.
• L'opt-in se déclenche-t-il sur le bon événement CMP ? Confirmez que le callback analytique accepté appelle opt_in_tracking(), pas un événement plus permissif.
• Autocapture est-il nécessaire ? S'il est activé, documentez pourquoi. Sinon, désactivez-le.
• La fusion rétroactive est-elle désactivée ? Confirmez que l'appel d'identification n'associe pas le comportement anonyme pré-consentement avec les profils nouvellement identifiés.
• Le trafic EU est-il sur un projet de résidence EU ? Confirmez que la logique de routage envoie les visiteurs EU vers un token de projet EU.
• Les demandes de suppression sont-elles automatisées ? Confirmez que les demandes DSAR déclenchent l'API de suppression de Mixpanel plutôt qu'un ticket manuel.

Où Mixpanel s'intègre dans une pile axée sur le consentement

Les plateformes d'analyse produit occupent une catégorie réglementaire que les équipes produit résistent souvent — elles veulent penser à Mixpanel comme une infrastructure interne, pas comme un traceur tiers. Les régulateurs ne font pas cette distinction, et les actions d'application des deux dernières années ont clairement montré qu'ils ne le feront pas. L'architecture appropriée traite Mixpanel exactement comme toute autre surface d'analyse tierce : conditionnez-le derrière le consentement, utilisez les primitives d'opt-in natives de la plateforme pour faire respecter la barrière, routez le trafic EU vers l'infrastructure de résidence EU, et désactivez les fonctionnalités (Autocapture, fusion d'identification rétroactive) qui élargissent la surface d'audit sans bénéfice analytique proportionné. Fait correctement, les équipes produit conservent les données d'entonnoir et de rétention dont elles ont besoin, et l'équipe juridique conserve la documentation dont elle a besoin pour défendre le déploiement sous audit.