Residencia de datos de Mixpanel en la UE: hosts, eventos descartados y RGPD

La residencia de datos de Mixpanel en la UE significa que los eventos de tu proyecto se procesan y almacenan en los centros de datos europeos de Mixpanel, y tiene una regla estricta: los eventos deben enviarse al endpoint de ingestión de la UE, api-eu.mixpanel.com. Si los envías al endpoint predeterminado, api.mixpanel.com, ni se ponen en cola, ni se redirigen, ni se marcan. Simplemente nunca aparecen en el proyecto.

India funciona igual con api-in.mixpanel.com. La residencia se elige al crear el proyecto, no se puede cambiar después, y cada herramienta que escriba en el proyecto (SDK de navegador, backend, CDP y reenviadores de terceros) debe configurarse por separado con el host correcto.

Esa última parte es donde surgen la mayoría de los fallos, y empeoró este verano. Mixpanel solía reenviar los eventos que proyectos antiguos de la UE recibían en el host de EE. UU. Según su documentación sobre residencia en la UE, ese reenvío de EE. UU. a la UE finalizó en julio de 2026 para la mayoría de los proyectos de la UE creados antes del 18 de agosto de 2025. Las configuraciones que dependían de él sin saberlo dejaron de recibir eventos. Si estás analizando la cuestión más amplia de la residencia para tu stack, la guía de residencia de datos en la UE para herramientas de marketing es el punto de partida; esta publicación se centra en Mixpanel.

Qué cubre la residencia de Mixpanel en la UE

La residencia en la UE es una elección de almacenamiento a nivel de proyecto. Seleccionas "Residencia de datos en la UE" al crear el proyecto y, a partir de entonces, Mixpanel procesa y almacena los datos de ese proyecto en la UE en lugar de en su ubicación predeterminada de EE. UU. Mixpanel ofrece un programa paralelo para India que vincula a la Ley de Protección de Datos Personales Digitales.

El hecho de que sea a nivel de proyecto tiene tres consecuencias. Tu organización puede tener proyectos de EE. UU. y de la UE al mismo tiempo. El token del proyecto no revela su región. Nada posterior puede deducirla a partir del token. Y la interfaz también cambia: los proyectos de la UE están en eu.mixpanel.com, los de India en in.mixpanel.com, motivo por el que las URL de postback de SSO para la UE necesitan el prefijo eu..

Lo que no cubre es el recorrido anterior a que los datos lleguen a Mixpanel. Mixpanel lo dice claramente: si los eventos entran mediante una plataforma de datos de clientes, "no puede garantizar" que la ingestión, el procesamiento y el almacenamiento permanezcan en la UE. Tu canalización es tu responsabilidad.

Hosts de ingestión para proyectos de EE. UU., la UE e India

La ingestión no es el único host regional. Cada familia de API tiene uno. Si solo cambias el host de seguimiento, tus scripts de exportación y consulta seguirán accediendo a los hosts de EE. UU. y fallarán con un proyecto de la UE.

La columna de India procede de la página de residencia en India de Mixpanel, que enumera las mismas familias, además de Data Pipelines y Lexicon Schemas bajo data-in. e in.. La página de la UE reproduce el mismo patrón con -eu y eu..

Por qué se descartan los eventos enviados al host equivocado

La formulación de Mixpanel es tajante: no se ingiere ningún dato en un proyecto con residencia en la UE a menos que tu implementación lo envíe a la URL de ingestión de la UE. La página de India afirma lo mismo sobre api-in.mixpanel.com.

La parte dolorosa es que el host equivocado no rechaza la solicitud de una forma que la mayoría de herramientas detecten. El endpoint /track acepta el token sin cuestionarlo, de modo que un emisor dirigido al host de EE. UU. puede ver respuestas correctas mientras el proyecto de la UE permanece vacío. Lo descubres al ver una gráfica plana, normalmente una semana después.

Por eso, depura desde el proyecto. Aquí nunca confíes en los registros del emisor. Abre la vista de eventos del proyecto de la UE, envía un evento y comprueba si aparece. Si no aparece en uno o dos minutos, el host es incorrecto o el token pertenece a otro proyecto.

Cómo comprobar tu residencia y mover un proyecto existente

Comprobarlo es rápido. La configuración del proyecto muestra un valor de residencia de datos; también puedes mirar la barra de direcciones, donde eu. o in. delante de mixpanel.com lo revela. Yo anotaría ese valor en el documento donde enumeras tus integraciones, porque cada herramienta que conectes después lo necesita.

Moverlo es la parte difícil. La documentación de Mixpanel indica que, si se eligió una ubicación de residencia incorrecta, "deberás crear un nuevo proyecto con la opción de almacenamiento de datos aplicable y migrar todos tus datos existentes", y que Mixpanel no puede ayudar con la migración. En la práctica, eso significa:

1. Crea un proyecto nuevo con residencia en la UE (o India) y dirige cada emisor al nuevo host y token.
2. Vuelve a importar el historial que necesites y retira el proyecto anterior cuando los informes y paneles se hayan reconstruido en el nuevo.

Nada en esas páginas indica si un historial migrado conserva sus ID o sus paneles. No encontré un atajo documentado y asumiría que no existe.

Residencia de datos de Mixpanel y RGPD: IP y transferencias

La residencia responde bien a una pregunta del RGPD: dónde se encuentran los datos almacenados. Con un proyecto de la UE, tu historial de eventos no se almacena en EE. UU., lo que elimina del almacenamiento una transferencia del Capítulo V. La guía del RGPD para acortadores de URL trata las obligaciones a nivel de artículo que permanecen.

La dirección IP es el detalle que la gente pasa por alto. Los emisores del lado del servidor normalmente adjuntan la IP del visitante como propiedad ip para que Mixpanel pueda geolocalizar el evento en lugar de situar a todos en el servidor del emisor. Según la documentación de geolocalización de Mixpanel, la IP se usa para obtener el país, la región y la ciudad, y luego se descarta antes de almacenar el evento. Bien. Pero la IP sigue viajando en la solicitud, y una solicitud a api.mixpanel.com es una solicitud a un endpoint de EE. UU. Por tanto, un host incorrecto no es solo un error de pérdida de datos. También supone que datos personales salen de la UE hacia un endpoint que tus registros de actividades de tratamiento indican que no utilizas.

Si no necesitas una ubicación a nivel de ciudad, puedes enviar ip como 0 y Mixpanel omitirá la geolocalización por completo. Todo lo demás sigue siendo tu responsabilidad: la base jurídica, el consentimiento para cualquier cookie que establezca el SDK de navegador, el DPA y lo que conserve cada herramienta de reenvío por su parte. La publicación sobre Schrems II y píxeles de seguimiento explica cómo se desarrolla el debate sobre transferencias para etiquetas del lado del navegador.

Enviar eventos al endpoint de ingestión de la UE desde cualquier herramienta

Cada emisor necesita su propia configuración. No existe un interruptor para toda la cuenta, así que enuméralos y corrige cada uno:

• SDK de navegador. Configura api_host durante la inicialización, por ejemplo mixpanel.init(TOKEN, { api_host: "https://api-eu.mixpanel.com" }), o el host api-in para India.
• SDK de servidor y llamadas HTTP sin procesar: dirige el host a api-eu.mixpanel.com (cada SDK tiene su propia opción de configuración) o haz POST directamente a https://api-eu.mixpanel.com/track.
• CDP, trabajos de ETL inverso y conectores sin código: busca su campo de región o endpoint, y pide confirmación por escrito al proveedor si no lo encuentras.
• Reenviadores de terceros que envían datos en tu nombre, como un acortador de enlaces que envía clics. Tampoco pueden saber tu residencia a partir del token.

Después, verifica cada uno en el proyecto de la UE. Basta un evento de prueba por emisor.

Ejemplo práctico: el reenviador de Mixpanel de Elido

Elido reenvía cada clic en un enlace corto a Mixpanel como un evento de servidor link_click que incluye el slug, el ID del enlace, el país, el dispositivo, el destino, la marca de tiempo y la ip del visitante. Desde el 22 de septiembre de 2026, el diálogo de conexión tiene un campo de residencia de datos con tres opciones, y cada una se asigna a un host fijo:

• Estados Unidos: api.mixpanel.com (también se usa cuando el campo está vacío)
• UE: api-eu.mixpanel.com
• India: api-in.mixpanel.com

El valor se valida al guardar; se rechaza cualquier valor distinto de esos tres, de modo que un error tipográfico no puede convertirse en una alternativa silenciosa al host de EE. UU. Las conexiones guardadas antes de que existiera el campo no tienen valor y siguen accediendo al host de EE. UU.; por tanto, si tu proyecto tiene residencia en la UE, vuelve a abrir la conexión de Mixpanel con Actualizar clave, pega de nuevo el token del proyecto (el diálogo nunca muestra el almacenado), selecciona UE y guarda.

Este es el límite que querría ver claramente explicado al revisarlo. El botón Probar conexión no puede demostrar la región. Envía un link_click marcado como elido_test: true y muestra la respuesta de Mixpanel, pero /track acepta cualquier token y no comprueba la residencia, por lo que un resultado correcto en el host equivocado parece idéntico a uno en el host correcto. El panel lo indica en su nota. La prueba es que ese evento de prueba llegue a la vista de eventos de tu proyecto de la UE.

Los clics se registran en una región de la UE del lado de Elido, y nuestra lista de subencargados indica quién los procesa. Si quieres que los clics en enlaces lleguen a un proyecto de Mixpanel en la UE sin programar tú mismo el reenviador, crea un espacio de trabajo y conéctalo desde la integración de Mixpanel.

Conviene conocer dos limitaciones: el reenviador siempre envía ip (hoy no hay un interruptor para ip: 0) y no configura $insert_id, cuestión que trata la guía de seguimiento de enlaces con Mixpanel junto con el distinct_id de cada enlace. Para elegir de forma más amplia dónde deben residir los datos de clics, consulta Mixpanel frente a GA4 para analítica de enlaces.

Relacionado en el blog

• Seguimiento de enlaces con Mixpanel: clics en enlaces cortos como eventos - configuración, propiedades y verificación del reenviador.
• Residencia de datos en la UE para herramientas de marketing - lo que tu DPO pregunta además de la ubicación de almacenamiento.
• ¿Google Analytics cumple el RGPD? - la misma pregunta para una herramienta sin opción de residencia.
• Seguimiento de conversiones del lado del servidor - por qué los eventos salen del navegador y qué cambia con ello.