Résidence des données de Mixpanel dans l'UE : hôtes, événements ignorés, RGPD

La résidence des données de Mixpanel dans l'UE signifie que les événements de votre projet sont traités et stockés dans les centres de données européens de Mixpanel. Elle s'accompagne d'une règle stricte : les événements doivent être envoyés au point d'ingestion de l'UE, api-eu.mixpanel.com. Si vous les envoyez à l'hôte par défaut api.mixpanel.com, ils ne sont ni mis en file d'attente, ni redirigés, ni signalés. Ils n'apparaissent tout simplement jamais dans le projet.

Le fonctionnement est identique pour l'Inde avec api-in.mixpanel.com. La résidence est choisie lors de la création du projet, elle ne peut pas être modifiée par la suite, et chaque outil qui écrit dans le projet (SDK navigateur, backend, CDP, outils de transfert tiers) doit recevoir séparément le bon hôte.

C'est cette dernière étape qui provoque la plupart des pannes, et la situation s'est aggravée cet été. Mixpanel transférait auparavant vers l'UE les événements reçus sur l'hôte américain par les anciens projets de l'UE. D'après sa documentation sur la résidence dans l'UE, ce transfert des États-Unis vers l'UE a pris fin en juillet 2026 pour la plupart des projets de l'UE créés avant le 18 août 2025. Les configurations qui en dépendaient discrètement sont devenues silencieuses. Si vous examinez la question plus large de la résidence pour votre stack, commencez par le guide sur la résidence des données dans l'UE pour les outils marketing ; cet article reste consacré à Mixpanel.

Ce que couvre la résidence des données de Mixpanel dans l'UE

La résidence dans l'UE est un choix de stockage au niveau du projet. Vous cochez "EU Data Residency" lors de la création du projet, puis Mixpanel traite et stocke dès lors les données de ce projet dans l'UE au lieu de son emplacement par défaut aux États-Unis. Mixpanel propose un programme parallèle pour l'Inde, qu'il rattache au Digital Personal Data Protection Act.

Trois conséquences découlent de ce fonctionnement au niveau du projet. Votre organisation peut détenir côte à côte des projets aux États-Unis et dans l'UE. Le jeton du projet ne révèle pas sa région. Aucun système en aval ne peut la déduire du jeton. L'interface change également : les projets de l'UE se trouvent sur eu.mixpanel.com, les projets de l'Inde sur in.mixpanel.com, ce qui explique aussi pourquoi les URL de retour SSO pour l'UE doivent utiliser le préfixe eu..

Ce que cette résidence ne couvre pas, c'est le parcours des données avant leur arrivée dans Mixpanel. Mixpanel le précise lui-même : si les événements arrivent via 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 relève de votre responsabilité.

Hôtes d'ingestion pour les projets aux États-Unis, dans l'UE et en Inde

L'ingestion n'est pas le seul hôte régional. Chaque famille d'API en possède un. Si vous ne modifiez que l'hôte de suivi, vos scripts d'export et de requête continueront d'appeler les hôtes américains et échoueront avec un projet de l'UE.

La colonne Inde provient de la page de Mixpanel sur la résidence en Inde, qui répertorie les mêmes familles ainsi que Data Pipelines et Lexicon Schemas sous data-in. et in.. La page consacrée à l'UE suit le même principe avec -eu et eu..

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

La formulation de Mixpanel est catégorique : aucune donnée n'est ingérée dans un projet avec résidence dans l'UE, sauf si votre implémentation l'envoie à l'URL d'ingestion de l'UE. La page sur l'Inde indique la même chose pour api-in.mixpanel.com.

Le problème est que le mauvais hôte ne rejette pas la requête d'une manière détectée par la plupart des outils. Le point /track accepte le jeton tel quel, de sorte qu'un émetteur configuré sur l'hôte américain peut recevoir des réponses positives alors que le projet de l'UE reste vide. Vous le découvrez en constatant un graphique plat, généralement une semaine plus tard.

Déboguez donc à partir du projet. Ne faites jamais confiance ici aux journaux de l'émetteur. Ouvrez la vue Events dans le projet de l'UE, déclenchez un événement et surveillez son arrivée. Si rien n'apparaît au bout d'une ou deux minutes, l'hôte est incorrect ou 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 ; vous pouvez aussi consulter la barre d'adresse, où la présence de eu. ou in. devant mixpanel.com donne la réponse. Je vous conseille de noter cette valeur dans le document qui répertorie vos intégrations, car chaque outil connecté ultérieurement en aura besoin.

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

1. Créez un nouveau projet avec la résidence dans l'UE (ou en Inde), puis dirigez chaque émetteur vers le nouvel hôte et le nouveau jeton.
2. Réimportez l'historique dont vous avez besoin, puis retirez l'ancien projet une fois les rapports et tableaux de bord recréés dans le nouveau.

Aucune de ces pages n'indique si un historique migré conserve ses identifiants ou ses tableaux de bord d'origine. Je n'ai trouvé aucun raccourci documenté et je partirais du principe qu'il n'en existe pas.

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

La résidence répond bien à une question du RGPD : où les données stockées se trouvent-elles ? Avec un projet de l'UE, l'historique de vos événements ne se trouve pas aux États-Unis, ce qui retire le stockage de la question des transferts relevant du chapitre V. Le guide RGPD pour les raccourcisseurs d'URL détaille, article par article, les obligations qui subsistent.

L'adresse IP est le détail que l'on oublie souvent. Les émetteurs côté serveur joignent généralement l'adresse IP du visiteur en tant que propriété ip, afin que Mixpanel puisse géolocaliser l'événement au lieu de placer tout le monde à l'emplacement du serveur émetteur. Selon la documentation de Mixpanel sur la géolocalisation, l'IP sert à déterminer le pays, la région et la ville, puis est supprimée avant le stockage de l'événement. C'est une bonne chose. Mais l'IP circule tout de même dans la requête, et une requête vers api.mixpanel.com est une requête vers un point de terminaison américain. Un mauvais hôte n'est donc pas seulement un problème de perte de données. C'est aussi une sortie de données personnelles de l'UE vers un point de terminaison que vos registres de traitement indiquent ne pas utiliser.

Si vous n'avez pas besoin d'une localisation au niveau de la ville, vous pouvez envoyer ip à 0 et Mixpanel désactivera complètement la géolocalisation. Tout le reste reste à votre charge : base légale, consentement pour les cookies installés par le SDK navigateur, DPA et données conservées de son côté par chaque outil de transfert. L'article sur Schrems II et les pixels de suivi explique comment se déroule le débat sur les transferts pour les balises côté navigateur.

Envoyer des événements au point d'ingestion de l'UE depuis n'importe quel outil

Chaque émetteur a besoin de son propre paramètre. Il n'existe pas de commutateur pour l'ensemble du compte : répertoriez-les et corrigez chacun d'eux :

• SDK navigateur. Définissez api_host lors de l'initialisation, par exemple mixpanel.init(TOKEN, { api_host: "https://api-eu.mixpanel.com" }), ou utilisez l'hôte api-in pour l'Inde.
• SDK serveur et appels HTTP bruts : configurez l'hôte sur api-eu.mixpanel.com (chaque SDK possède sa propre option de configuration) ou envoyez directement une requête POST à https://api-eu.mixpanel.com/track.
• CDP, tâches de reverse ETL et connecteurs no-code : cherchez leur champ de région ou de point de terminaison et demandez au fournisseur par écrit si nécessaire.
• Outils de transfert tiers qui envoient des données en votre nom, comme un raccourcisseur de liens qui envoie les clics. Eux non plus ne peuvent pas déduire votre résidence à partir du jeton.

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

Exemple pratique : le transfert Mixpanel d'Elido

Elido transmet chaque clic sur un lien court à Mixpanel sous la forme d'un événement serveur link_click contenant le slug, l'identifiant du lien, le pays, l'appareil, la destination, l'horodatage et l'ip du visiteur. Depuis le 22 septembre 2026, la boîte de dialogue de connexion comporte un champ Data residency avec trois options, chacune correspondant à un hôte fixe :

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

La valeur est validée lors de l'enregistrement ; toute valeur autre que ces trois options est rejetée, de sorte qu'une faute de frappe ne peut pas provoquer un basculement silencieux vers l'hôte américain. Les connexions enregistrées avant l'apparition du champ n'ont aucune valeur et continuent d'utiliser l'hôte américain. Si votre projet se trouve dans l'UE, rouvrez donc la connexion Mixpanel avec Update key, saisissez à nouveau le jeton du projet (la boîte de dialogue n'affiche jamais celui qui est enregistré), choisissez UE et enregistrez.

Voici la limite que je voudrais voir explicitement mentionnée lors d'une revue. 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 positif sur le mauvais hôte ressemble donc exactement à un résultat positif sur le bon. Le panneau le précise dans sa note. La preuve est l'arrivée de cet événement de test dans la vue Events de votre projet de l'UE.

Les clics eux-mêmes sont enregistrés dans une région de l'UE du côté d'Elido, et notre liste des sous-traitants indique qui les traite. Si vous voulez que les clics sur vos liens arrivent dans un projet Mixpanel de l'UE sans écrire vous-même l'outil de transfert, créez un espace de travail et connectez-le depuis l'intégration Mixpanel.

Deux limites méritent d'être connues : le transfert envoie toujours ip (il n'existe pas encore de commutateur pour ip: 0) et ne définit pas $insert_id, ce que le guide de suivi des liens Mixpanel explique avec le distinct_id propre à chaque lien. Pour un aperçu plus large du choix de l'emplacement des données de clics, consultez Mixpanel ou GA4 pour l'analyse des liens.

Articles associés

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