Residência de dados da Mixpanel na UE: hosts, eventos descartados, GDPR

Residência de dados da Mixpanel na UE significa que os eventos do seu projeto são processados e armazenados nos centros de dados da Mixpanel na UE, e isso vem com uma regra rígida: os eventos precisam ser enviados ao endpoint de ingestão da UE, api-eu.mixpanel.com. Envie para o padrão api.mixpanel.com e eles não entram em fila, não são redirecionados nem sinalizados. Eles simplesmente nunca aparecem no projeto.

A Índia funciona do mesmo jeito com api-in.mixpanel.com. A residência é escolhida quando o projeto é criado, não pode ser alterada depois, e cada ferramenta que escreve no projeto (SDK do navegador, backend, CDP, encaminhadores de terceiros) precisa receber o host correto separadamente.

Essa última parte é onde acontece a maior parte das quebras, e isso piorou neste verão. A Mixpanel costumava encaminhar eventos que projetos antigos da UE recebiam no host dos EUA. Segundo a documentação de residência na UE, esse encaminhamento dos EUA para a UE terminou em julho de 2026 para a maioria dos projetos da UE criados antes de 18 de agosto de 2025. Configurações que dependiam dele em silêncio pararam de funcionar. Se você está analisando a questão mais ampla de residência para sua pilha, o guia de residência de dados na UE para ferramentas de marketing é o ponto de partida; este post fica na Mixpanel.

O Que a Residência da Mixpanel na UE Cobre

Residência na UE é uma escolha de armazenamento no nível do projeto. Você marca "EU Data Residency" ao criar o projeto e, a partir daí, a Mixpanel processa e armazena os dados desse projeto na UE, em vez do padrão nos EUA. A Mixpanel mantém um programa paralelo para a Índia, que ela vincula ao Digital Personal Data Protection Act.

Três coisas decorrem disso ser no nível do projeto. Sua organização pode manter projetos dos EUA e da UE lado a lado. O token do projeto não revela sua região. Nada a jusante consegue descobrir isso pelo token. E a interface também muda: projetos da UE ficam em eu.mixpanel.com, projetos da Índia em in.mixpanel.com, o que também explica por que URLs de postback de SSO para a UE precisam do prefixo eu..

O que isso não cobre é o caminho antes de os dados chegarem à Mixpanel. A própria Mixpanel diz isso: se os eventos entram por uma plataforma de dados do cliente, ela "não pode garantir" que ingestão, processamento e armazenamento permaneçam na UE. Seu pipeline é problema seu.

Hosts de Ingestão Para Projetos dos EUA, da UE e da Índia

Ingestão não é o único host regional. Cada família de API tem o seu. Se você mudar apenas o host de rastreamento, suas exportações e scripts de consulta ainda vão chamar os hosts dos EUA e falhar contra um projeto da UE.

A coluna da Índia vem da página de residência na Índia da Mixpanel, que lista as mesmas famílias mais Data Pipelines e Lexicon Schemas sob data-in. e in.. A página da UE espelha isso com -eu e eu..

Por Que Eventos Enviados ao Host Errado São Descartados

A redação da Mixpanel é direta: nenhum dado é ingerido em um projeto com residência na UE a menos que sua implementação o envie para a URL de ingestão da UE. A página da Índia diz o mesmo sobre api-in.mixpanel.com.

A parte dolorosa é que o host errado não rejeita a requisição de um jeito que a maioria das ferramentas perceba. O endpoint /track aceita o token como ele vem, então um remetente apontado para o host dos EUA pode ver respostas bem-sucedidas enquanto o projeto da UE continua vazio. Você descobre por um gráfico zerado, geralmente uma semana depois.

Então depure a partir do projeto. Nunca confie nos logs do remetente aqui. Abra a visualização Events no projeto da UE, dispare um evento e observe se ele aparece. Nada em um ou dois minutos significa que o host está errado ou que o token pertence a outro projeto.

Como Verificar Sua Residência e Mover um Projeto Existente

Verificar é rápido. Project Settings mostra um valor de Data Residency; ou olhe para a barra de endereço, onde eu. ou in. antes de mixpanel.com entrega a resposta. Eu anotaria esse valor em qualquer documento que liste suas integrações, porque toda ferramenta que você conectar depois vai precisar dele.

Mover é a parte difícil. A documentação da Mixpanel afirma que, se o local de residência errado foi escolhido, "você precisará criar um novo projeto com a opção de armazenamento de dados aplicável e migrar todos os seus dados existentes", e que a Mixpanel não pode ajudar com a migração. Na prática, isso significa:

1. Crie um novo projeto com residência na UE (ou na Índia) e aponte todo remetente para o novo host e token.
2. Reimporte o histórico de que você precisa e depois aposente o projeto antigo quando relatórios e painéis forem reconstruídos no novo.

Nada nessas páginas diz se um histórico migrado mantém seus IDs ou painéis originais. Não encontrei um atalho documentado, e eu assumiria que ele não existe.

Residência de Dados da Mixpanel e GDPR: IPs e Transferências

Residência responde bem a uma pergunta do GDPR: onde os dados armazenados ficam. Com um projeto da UE, seu histórico de eventos não fica nos EUA, o que tira uma transferência do Capítulo V do cenário de armazenamento. O guia de GDPR para encurtadores de URL cobre as obrigações em nível de artigo que permanecem.

O endereço IP é o detalhe que as pessoas deixam passar. Remetentes server-side geralmente anexam o IP do visitante como a propriedade ip para que a Mixpanel possa geolocalizar o evento em vez de colocar todo mundo no servidor do remetente. Segundo a documentação de geolocalização da Mixpanel, o IP é usado para derivar país, região e cidade e depois descartado antes de o evento ser armazenado. Ótimo. Mas o IP ainda viaja na requisição, e uma requisição para api.mixpanel.com é uma requisição para um endpoint dos EUA. Então um host errado não é só um bug de perda de dados. Também é dado pessoal saindo da UE para um endpoint que seus registros de processamento dizem que você não usa.

Se você não precisa de localização em nível de cidade, pode enviar ip como 0 e a Mixpanel ignora a geolocalização completamente. Todo o resto continua sob sua responsabilidade: base legal, consentimento para qualquer cookie que o SDK do navegador defina, o DPA e o que cada ferramenta de encaminhamento mantém do lado dela. O post sobre Schrems II e pixels de rastreamento mostra como o debate sobre transferências se desenrola para tags no navegador.

Enviando Eventos ao Endpoint de Ingestão da UE a Partir de Qualquer Ferramenta

Cada remetente precisa da sua própria configuração. Não existe uma opção que valha para a conta inteira, então liste todos e corrija um por um:

• SDK do navegador. Defina api_host na inicialização, por exemplo mixpanel.init(TOKEN, { api_host: "https://api-eu.mixpanel.com" }), ou o host api-in para a Índia.
• SDKs de servidor e chamadas HTTP brutas: aponte o host para api-eu.mixpanel.com (cada SDK tem sua própria opção de configuração para isso) ou faça POST diretamente para https://api-eu.mixpanel.com/track.
• CDPs, tarefas de reverse-ETL e conectores no-code: encontre o campo de região ou endpoint e pergunte ao fornecedor por escrito se não conseguir.
• Encaminhadores de terceiros que publicam em seu nome, como um encurtador de links que envia cliques. Eles também não conseguem ver sua residência pelo token.

Depois verifique cada um no projeto da UE. Um evento de teste por remetente é suficiente.

Exemplo Prático: Encaminhador da Mixpanel da Elido

A Elido encaminha cada clique em link curto para a Mixpanel como um evento server-side link_click que carrega o slug, ID do link, país, dispositivo, destino, timestamp e o ip do visitante. Desde 22 de setembro de 2026, o diálogo de conexão tem um campo Data residency com três opções, e cada uma mapeia para um host fixo:

• United States: api.mixpanel.com (também usado quando o campo está vazio)
• EU: api-eu.mixpanel.com
• India: api-in.mixpanel.com

O valor é validado ao salvar; qualquer coisa diferente dessas três opções é rejeitada, então um erro de digitação não vira um retorno silencioso para o host dos EUA. Conexões salvas antes de o campo existir não têm valor e continuam indo para o host dos EUA, então, se seu projeto tem residência na UE, reabra a conexão da Mixpanel com Update key, cole o token do projeto de novo (o diálogo nunca mostra o token armazenado), escolha EU e salve.

Aqui está o limite que eu gostaria de ver explicado se estivesse revisando isso. O botão Test connection não consegue provar a região. Ele envia um link_click marcado como elido_test: true e mostra a resposta da Mixpanel, mas /track aceita qualquer token e não verifica residência, então um resultado verde no host errado parece idêntico a um resultado verde no host certo. O painel diz isso na observação. A prova é esse evento de teste chegando à visualização Events do seu projeto da UE.

Os cliques em si são registrados em uma região da UE no lado da Elido, e nossa lista de subprocessadores informa quem tem acesso a eles. Se você quer que cliques em links cheguem a um projeto da Mixpanel na UE sem escrever o encaminhador por conta própria, crie um espaço de trabalho e conecte-o pela integração da Mixpanel.

Duas lacunas valem saber: o encaminhador sempre envia ip (hoje não há opção para ip: 0) e ele não define $insert_id, algo que o guia de rastreamento de links com Mixpanel cobre junto com o distinct_id por link. Para a escolha mais ampla de onde os dados de clique devem ficar, veja Mixpanel vs GA4 para análise de links.

Relacionados no Blog

• Rastreamento de links com Mixpanel: cliques em links curtos como eventos - configuração, propriedades e verificação do encaminhador.
• Residência de dados na UE para ferramentas de marketing - o que seu DPO pergunta além do local de armazenamento.
• O Google Analytics é compatível com GDPR? - a mesma pergunta para uma ferramenta sem opção de residência.
• Rastreamento de conversões server-side - por que eventos saem do navegador e o que isso muda.