Residencia UE en Mixpanel: hosts, eventos perdidos, GDPR

La residencia de datos UE de Mixpanel significa que los eventos de tu proyecto se procesan y almacenan en los centros de datos de Mixpanel en la UE. Viene con una regla estricta: todo emisor debe enviar al endpoint de ingesta UE, api-eu.mixpanel.com. Si envías los mismos eventos al api.mixpanel.com predeterminado, no se ponen en cola, ni se redirigen ni se marcan. Simplemente nunca aparecen.

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 escribe en el proyecto (SDK de navegador, backend, CDP, forwarders de terceros) tiene que recibir el host correcto por separado.

La mayoría de las averías vienen de esa última parte, y este verano empeoró. Mixpanel solía reenviar los eventos que los proyectos UE antiguos recibían en el host de EE. UU. Según su documentación de residencia UE, ese reenvío de EE. UU. a la UE terminó en julio de 2026 para la mayoría de los proyectos UE creados antes del 18 de agosto de 2025. Las configuraciones que dependían de él sin saberlo se quedaron en silencio. Si estás repasando la cuestión más amplia de la residencia para tu stack, la lista de residencia de datos en la UE para marketing es el punto de partida; este artículo se queda en Mixpanel.

Qué cubre la residencia UE de Mixpanel

La residencia UE es una elección de almacenamiento a nivel de proyecto. Marcas "EU Data Residency" al crear el proyecto y, desde entonces, Mixpanel procesa y almacena los datos de ese proyecto en la UE en lugar de en su opción predeterminada de EE. UU. Mixpanel ejecuta un programa paralelo para India que vincula a la Digital Personal Data Protection Act.

De que sea a nivel de proyecto se siguen tres cosas. Tu organización puede tener proyectos de EE. UU. y de la UE a la vez. El token del proyecto no revela su región. Nada aguas abajo puede deducirla del token. Y la interfaz también se mueve: los proyectos UE viven en eu.mixpanel.com, los de India en in.mixpanel.com, que es también la razón por la que las URL de postback de SSO para la UE necesitan el prefijo eu..

Lo que no cubre es el camino previo a que los datos lleguen a Mixpanel. Mixpanel lo dice él mismo: si los eventos entran a través de una plataforma de datos de clientes, "cannot guarantee" que la ingesta, el procesamiento y el almacenamiento se mantengan en la UE. Tu pipeline es cosa tuya.

Hosts de ingesta para proyectos de EE. UU., la UE e India

La ingesta no es el único host regional. Cada familia de API tiene uno. Si solo cambias el host de seguimiento, tus exportaciones y scripts de consulta seguirán llegando a los hosts de EE. UU. y fallarán contra un proyecto UE.

La columna de India procede de la página de residencia en India de Mixpanel, que lista las mismas familias más Data Pipelines y Lexicon Schemas bajo data-in. e in.. La página de la UE la refleja con -eu y eu..

Por qué se descartan los eventos enviados al host equivocado

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

Lo doloroso es que el host equivocado no rechaza la petición de un modo que la mayoría de las herramientas noten. El endpoint /track acepta el token tal cual, así que un emisor apuntado al host de EE. UU. puede ver respuestas correctas mientras el proyecto UE sigue vacío. Te enteras por una gráfica plana, normalmente una semana después.

Así que depura desde el proyecto. No te fíes nunca de los logs del emisor. Abre la vista de eventos en el proyecto UE, dispara un evento y vigila que llegue. Si no aparece nada 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. Los ajustes del proyecto muestran un valor de Data Residency; o mira la barra de direcciones, donde eu. o in. delante de mixpanel.com lo delata. Yo apuntaría el valor en el documento donde listes tus integraciones, porque cada herramienta que conectes después lo necesita.

Mover es la parte difícil. La documentación de Mixpanel afirma que, si se eligió la ubicación de residencia equivocada, "you will need to create a new project with the applicable data storage option and migrate all your existing data", y que Mixpanel no puede ayudar con la migración. En la práctica significa:

1. Crear un proyecto nuevo con residencia UE (o India) y apuntar cada emisor al nuevo host y token.
2. Reimportar el historial que necesites y retirar el proyecto antiguo cuando los informes y paneles estén reconstruidos en el nuevo.

Nada en esas páginas dice si un historial migrado conserva sus IDs originales o sus paneles. No encontré ningún atajo documentado, y supondría que no existe.

Residencia de datos de Mixpanel y GDPR: IP y transferencias

La residencia responde bien una pregunta del GDPR: dónde están los datos almacenados. Con un proyecto UE, tu historial de eventos no está en EE. UU., lo que saca una transferencia del Capítulo V del cuadro del almacenamiento. La guía de GDPR para acortadores de URL cubre 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 servidor suelen adjuntar 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 derivar país, región y ciudad y luego se descarta antes de almacenar el evento. Bien. Pero la IP sigue viajando en la petición, y una petición a api.mixpanel.com es una petición a un endpoint de EE. UU. Así que un host equivocado no es solo un error de pérdida de datos. También son datos personales que salen de la UE hacia un endpoint que tu registro de actividades de tratamiento dice que no usas.

Si no necesitas ubicación a nivel de ciudad, puedes enviar ip como 0 y Mixpanel se salta la geolocalización por completo. Todo lo demás sigue siendo cosa tuya: base jurídica, consentimiento para cualquier cookie que establezca el SDK del navegador, el DPA y lo que cada herramienta de reenvío conserve de su lado. El artículo Schrems II y píxeles de seguimiento: dónde te deja el DPF en 2026 repasa cómo se desarrolla el debate sobre transferencias para las etiquetas del navegador.

Enviar eventos al endpoint de ingesta UE desde cualquier herramienta

Cada emisor necesita su propio ajuste. No hay un interruptor para toda la cuenta, así que haz una lista y corrige cada uno:

• SDK de navegador. Define api_host en 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 directas: apunta el host a api-eu.mixpanel.com (cada SDK tiene su propia opción de configuración para ello) o haz POST directamente a https://api-eu.mixpanel.com/track.
• CDP, trabajos de reverse-ETL y conectores no-code: busca su campo de región o endpoint y pregunta por escrito al proveedor si no lo encuentras.
• Forwarders de terceros que publican en tu nombre, como un acortador de enlaces que envía clics. Tampoco pueden ver tu residencia por el token.

Luego verifica cada uno en el proyecto UE. Un evento de prueba por emisor basta.

Ejemplo práctico: el forwarder de Mixpanel de Elido

Elido reenvía cada clic de enlace corto a Mixpanel como un evento link_click del lado servidor con el slug, el ID del enlace, el país, el dispositivo, el destino, la marca de tiempo y la ip del visitante, truncada a /24 (IPv4) o /48 (IPv6). Desde el 22 de septiembre de 2026 el diálogo de conexión tiene un campo Data residency con tres opciones, y cada una corresponde a un host fijo:

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

El valor se valida al guardar; cualquier cosa distinta de esas tres se rechaza, así que un error tipográfico no puede convertirse en un retorno silencioso al host de EE. UU. Las conexiones guardadas antes de que existiera el campo no tienen valor y siguen yendo al host de EE. UU., así que si tu proyecto reside en la UE, vuelve a abrir la conexión de Mixpanel con Update key, pega de nuevo el token del proyecto (el diálogo nunca muestra el guardado), elige UE y guarda.

Este es el límite que querría ver explicado si estuviera revisándolo. El botón Test connection no puede demostrar la región. Envía un link_click marcado elido_test: true y muestra la respuesta de Mixpanel, pero /track acepta cualquier token y no comprueba la residencia, así que un resultado verde en el host equivocado es idéntico a uno verde en el correcto. El panel lo dice en su nota. La prueba es que ese evento de prueba llegue a la vista de eventos de tu proyecto UE.

Por parte de Elido, ten claro qué te da y qué no te da la residencia en Mixpanel. Elido también guarda sus propias filas de clics, con la IP del visitante truncada en el edge (IPv4 /24, IPv6 /48), más la ciudad y el user agent completo, y no ofrece fijar región por espacio de trabajo, así que no puedes elegir una región de almacenamiento para esas filas como la eliges en Mixpanel. Nuestra lista de subencargados nombra quién toca los datos. Pon ambos almacenes en tu registro de actividades de tratamiento. Si quieres clics de enlaces en un proyecto UE de Mixpanel sin escribir tú un forwarder, empieza un espacio de trabajo y conéctalo desde la integración de Mixpanel.

Dos carencias que conviene conocer: el forwarder siempre envía la ip truncada (hoy no hay interruptor para ip: 0, salvo el modo sin datos personales solo por API, que la elimina) y no establece $insert_id, algo que la guía de seguimiento de Mixpanel cubre junto con el distinct_id por enlace. Para la elección más amplia de dónde deben residir los datos de clics, consulta Mixpanel vs GA4 para analítica de enlaces: cuál elegir.

Relacionado en el blog

• Seguimiento de enlaces en Mixpanel: clics de enlaces cortos como eventos - configuración, propiedades y verificación del forwarder.
• Residencia de datos en la UE para marketing: lista para el DPO - lo que tu DPO pregunta más allá de la ubicación del almacenamiento.
• ¿Cumple Google Analytics con el GDPR? La respuesta para la UE - la misma pregunta para una herramienta sin opción de residencia.
• Seguimiento de conversiones server-side con enlaces cortos - por qué los eventos salen del navegador y qué cambia.