Résidence des données Mixpanel UE : hôtes, événements, RGPD

La résidence des données Mixpanel UE signifie que les événements de votre projet sont traités et stockés dans les centres de données UE de Mixpanel. Elle s'accompagne d'une règle stricte : chaque émetteur doit publier sur le point d'accès d'ingestion UE, api-eu.mixpanel.com. Envoyez les mêmes événements au api.mixpanel.com par défaut et ils ne sont ni mis en file, ni redirigés, ni signalés. Ils n'apparaissent tout simplement jamais.

L'Inde fonctionne de la même manière avec api-in.mixpanel.com. La résidence est choisie à la création du projet, elle ne peut pas être inversée plus tard, et chaque outil qui écrit dans le projet (SDK navigateur, backend, CDP, forwarders tiers) doit recevoir séparément le bon hôte.

La plupart des pannes viennent de ce dernier point, et cela s'est aggravé cet été. Mixpanel transmettait auparavant les événements que d'anciens projets UE recevaient sur l'hôte américain. Selon sa documentation sur la résidence UE, ce transfert des États-Unis vers l'UE a pris fin en juillet 2026 pour la plupart des projets UE créés avant le 18 août 2025. Les configurations qui s'y fiaient discrètement sont devenues muettes. Si vous examinez la question plus large de la résidence pour votre stack, le guide de la résidence des données UE pour les outils marketing est le point de départ ; cet article reste sur Mixpanel.

Ce que couvre la résidence UE de Mixpanel

La résidence UE est un choix de stockage au niveau du projet. Vous cochez « EU Data Residency » à la création du projet, et dès lors Mixpanel traite et stocke les données de ce projet dans l'UE au lieu de son défaut américain. Mixpanel gère un programme parallèle pour l'Inde, qu'il rattache à la Digital Personal Data Protection Act.

Trois choses en découlent, puisque c'est un réglage de projet. Votre organisation peut détenir côte à côte des projets américains et UE. Le jeton du projet ne révèle pas sa région. Rien en aval ne peut la déduire du jeton. Et l'interface se déplace aussi : les projets UE vivent sur eu.mixpanel.com, les projets indiens sur in.mixpanel.com, ce qui explique aussi pourquoi les URL de postback SSO pour l'UE ont besoin du préfixe eu..

Ce qu'elle ne couvre pas, c'est le chemin avant que les données n'atteignent Mixpanel. Mixpanel le dit lui-même : si les événements arrivent par une plateforme de données client, il « ne peut pas garantir » que l'ingestion, le traitement et le stockage restent dans l'UE. Votre pipeline est votre problème.

Hôtes d'ingestion pour les projets US, UE et Inde

L'ingestion n'est pas le seul hôte régional. Chaque famille d'API en a un. Si vous ne changez que l'hôte de suivi, vos exports et vos scripts de requête continueront de viser les hôtes américains et échoueront face à un projet UE.

La colonne Inde provient de la page Mixpanel sur la résidence en Inde, qui énumère les mêmes familles plus Data Pipelines et Lexicon Schemas sous data-in. et in.. La page UE la reflète avec -eu et eu..

Pourquoi les événements envoyés au mauvais hôte sont perdus

La formulation de Mixpanel est franche : aucune donnée n'est ingérée dans un projet à résidence UE si votre implémentation ne l'envoie pas à l'URL d'ingestion UE. La page Inde dit la même chose de api-in.mixpanel.com.

Le plus pénible, c'est que le mauvais hôte ne rejette pas la requête d'une façon que la plupart des outils remarquent. Le point d'accès /track prend le jeton au pied de la lettre : un émetteur pointé vers l'hôte américain peut donc voir des réponses réussies pendant que le projet UE reste vide. Vous l'apprenez par un graphique plat, en général une semaine plus tard.

Déboguez donc depuis le projet. Ne vous fiez jamais aux logs de l'émetteur ici. Ouvrez la vue Events du projet UE, envoyez un événement et guettez-le. Rien en une minute ou deux signifie que l'hôte est faux ou que le jeton appartient à un autre projet.

Comment vérifier votre résidence et déplacer un projet existant

La vérification est rapide. Les paramètres du projet affichent une valeur Data Residency ; ou regardez la barre d'adresse, où eu. ou in. devant mixpanel.com le trahit. Je noterais la valeur dans le document qui liste vos intégrations, car chaque outil que vous connecterez plus tard en a besoin.

Le déplacement est la partie difficile. La documentation de Mixpanel indique que si le mauvais lieu de résidence a été choisi, « vous devrez créer un nouveau projet avec l'option de stockage applicable et migrer toutes vos données existantes », et que Mixpanel ne peut pas aider à la migration. En pratique, cela signifie :

1. Créer un nouveau projet avec la résidence UE (ou Inde) et pointer chaque émetteur vers le nouvel hôte et le nouveau jeton.
2. Réimporter l'historique dont vous avez besoin, puis retirer l'ancien projet une fois les rapports et tableaux de bord reconstruits sur le nouveau.

Rien sur ces pages ne dit si un historique migré conserve ses identifiants ou tableaux de bord d'origine. Je n'ai trouvé aucun raccourci documenté, et je suppose qu'il n'y en a pas.

Résidence des données Mixpanel et RGPD : IP et transferts

La résidence répond bien à une question du RGPD : où se trouvent les données stockées. Avec un projet UE, l'historique de vos événements ne se trouve pas aux États-Unis, ce qui retire un transfert du chapitre V du tableau du stockage. Le guide du RGPD pour les raccourcisseurs d'URL couvre les obligations restantes au niveau des articles.

L'adresse IP est le détail que l'on oublie. Les émetteurs côté serveur joignent généralement l'IP du visiteur comme propriété ip pour que Mixpanel géolocalise l'événement au lieu de placer tout le monde sur le serveur de l'émetteur. D'après la documentation de géolocalisation de Mixpanel, l'IP sert à déduire le pays, la région et la ville, puis est supprimée avant le stockage de l'événement. Très bien. Mais l'IP voyage quand même dans la requête, et une requête vers api.mixpanel.com est une requête vers un point d'accès américain. Un mauvais hôte n'est donc pas seulement un bogue de perte de données. C'est aussi une donnée personnelle qui quitte l'UE vers un point d'accès que votre registre des traitements dit ne pas utiliser.

Si vous n'avez pas besoin de la localisation à l'échelle de la ville, vous pouvez envoyer ip à 0 et Mixpanel saute entièrement la géolocalisation. Tout le reste vous incombe toujours : base légale, consentement pour les cookies posés par le SDK navigateur, DPA, et ce que chaque outil de transfert conserve de son côté. L'article Schrems II et pixels de suivi détaille comment le débat sur les transferts se joue pour les balises côté navigateur.

Envoyer des événements au point d'accès d'ingestion UE depuis n'importe quel outil

Chaque émetteur a besoin de son propre réglage. Il n'existe pas d'interrupteur au niveau du compte : listez-les donc et corrigez-les un par un :

• SDK navigateur. Définissez api_host à l'initialisation, par exemple mixpanel.init(TOKEN, { api_host: "https://api-eu.mixpanel.com" }), ou l'hôte api-in pour l'Inde.
• SDK serveur et appels HTTP bruts : pointez l'hôte vers api-eu.mixpanel.com (chaque SDK a sa propre option de configuration) ou envoyez directement en POST à https://api-eu.mixpanel.com/track.
• CDP, tâches de reverse-ETL et connecteurs no-code : trouvez leur champ de région ou de point d'accès, et demandez par écrit au fournisseur si vous ne le trouvez pas.
• Forwarders tiers qui publient en votre nom, comme un raccourcisseur de liens qui envoie des clics. Eux non plus ne voient pas votre résidence depuis le jeton.

Vérifiez ensuite chacun dans le projet UE. Un événement de test par émetteur suffit.

Exemple concret : le forwarder Mixpanel d'Elido

Elido transmet chaque clic de lien court à Mixpanel sous forme d'événement link_click côté serveur contenant le slug, l'ID du lien, le pays, l'appareil, la destination, l'horodatage et l'ip du visiteur, tronquée à /24 (IPv4) ou /48 (IPv6). Depuis le 22 septembre 2026, la boîte de dialogue de connexion comporte un champ Data residency avec trois options, chacune associée à un hôte fixe :

• États-Unis : api.mixpanel.com (aussi utilisé quand le champ est vide)
• UE : api-eu.mixpanel.com
• Inde : api-in.mixpanel.com

La valeur est validée à l'enregistrement ; tout ce qui n'est pas l'une de ces trois valeurs est rejeté, si bien qu'une faute de frappe ne peut pas se transformer en repli silencieux vers l'hôte américain. Les connexions enregistrées avant l'existence du champ n'ont pas de valeur et continuent d'aller vers l'hôte américain : si votre projet est à résidence UE, rouvrez la connexion Mixpanel avec Update key, collez à nouveau le jeton du projet (la boîte de dialogue n'affiche jamais celui qui est stocké), choisissez EU et enregistrez.

Voici la limite que je voudrais voir énoncée si je relisais ce texte. Le bouton Test connection ne peut pas prouver la région. Il envoie un link_click marqué elido_test: true et affiche la réponse de Mixpanel, mais /track accepte n'importe quel jeton et ne vérifie pas la résidence : un résultat vert sur le mauvais hôte est donc identique à un résultat vert sur le bon. Le panneau le dit d'ailleurs dans sa note. La preuve, c'est cet événement de test qui arrive dans la vue Events de votre projet UE.

Du côté d'Elido, soyez clair sur ce que la résidence chez Mixpanel vous apporte ou non. Elido conserve aussi ses propres lignes de clics, avec l'IP du visiteur tronquée à l'edge (IPv4 /24, IPv6 /48) plus la ville et le user agent complet, et ne propose pas d'épinglage de région par espace de travail : vous ne pouvez donc pas choisir une région de stockage pour ces lignes comme vous en choisissez une chez Mixpanel. Notre liste des sous-traitants nomme qui touche aux données. Mettez les deux stockages dans votre registre des traitements. Si vous voulez des clics de liens dans un projet Mixpanel UE sans écrire vous-même un forwarder, démarrez un espace de travail et connectez-le depuis l'intégration Mixpanel.

Deux lacunes à connaître : le forwarder envoie toujours l'ip tronquée (il n'y a pas d'interrupteur pour ip: 0 aujourd'hui, sauf le mode sans données personnelles réservé à l'API, qui la supprime), et il ne définit pas $insert_id, ce que le guide du suivi de liens Mixpanel traite avec le distinct_id par lien. Pour le choix plus large de l'endroit où doivent vivre les données de clics, voir Mixpanel ou GA4 pour les analytics de liens.

À lire aussi sur le blog

• Suivi de liens Mixpanel : les clics sur liens courts comme événements - configuration, propriétés et vérification du forwarder.
• Résidence des données UE pour le marketing : liste DPO - ce que votre DPO demande au-delà du lieu de stockage.
• Google Analytics est-il conforme au RGPD ? La réponse pour l'UE - la même question pour un outil sans option de résidence.
• Suivi des conversions côté serveur avec liens courts - pourquoi les événements quittent le navigateur et ce que cela change.