Residenza dati Mixpanel UE: host, eventi persi, GDPR

La residenza dei dati Mixpanel UE significa che gli eventi del tuo progetto vengono elaborati e archiviati nei data center UE di Mixpanel. Comporta una regola ferrea: ogni mittente deve inviare all'endpoint di ingestione UE, api-eu.mixpanel.com. Invia gli stessi eventi all'api.mixpanel.com predefinito e non vengono messi in coda, reindirizzati o segnalati. Semplicemente non compaiono mai.

L'India funziona allo stesso modo con api-in.mixpanel.com. La residenza si sceglie alla creazione del progetto, non può essere cambiata dopo, e ogni strumento che scrive nel progetto (SDK browser, backend, CDP, forwarder di terze parti) va istruito separatamente sull'host giusto.

La maggior parte dei guasti nasce da quest'ultimo punto, ed è peggiorato quest'estate. Mixpanel inoltrava gli eventi che i vecchi progetti UE ricevevano sull'host statunitense. Secondo la sua documentazione sulla residenza UE, quell'inoltro da US a UE è terminato a luglio 2026 per la maggior parte dei progetti UE creati prima del 18 agosto 2025. Le configurazioni che vi facevano silenziosamente affidamento sono diventate mute. Se stai affrontando la questione più ampia della residenza per il tuo stack, la guida alla residenza dei dati UE per gli strumenti di marketing è il punto di partenza; questo articolo resta su Mixpanel.

Cosa copre la residenza UE di Mixpanel

La residenza UE è una scelta di archiviazione a livello di progetto. Spunti «EU Data Residency» alla creazione del progetto e da allora Mixpanel elabora e archivia i dati di quel progetto nell'UE invece che nell'impostazione predefinita statunitense. Mixpanel gestisce un programma parallelo per l'India, che collega al Digital Personal Data Protection Act.

Dal fatto che sia a livello di progetto derivano tre cose. La tua organizzazione può avere progetti US e UE affiancati. Il token del progetto non rivela la sua regione. Nulla a valle può ricavarla dal token. E si sposta anche l'interfaccia: i progetti UE vivono su eu.mixpanel.com, quelli indiani su in.mixpanel.com, motivo per cui anche gli URL di postback SSO per l'UE richiedono il prefisso eu..

Ciò che non copre è il percorso prima che i dati raggiungano Mixpanel. Lo dice Mixpanel stessa: se gli eventi arrivano tramite una customer data platform, «non può garantire» che ingestione, elaborazione e archiviazione restino nell'UE. La tua pipeline è un problema tuo.

Host di ingestione per i progetti US, UE e India

L'ingestione non è l'unico host regionale. Ogni famiglia di API ne ha uno. Se cambi solo l'host di tracciamento, i tuoi export e gli script di query continueranno a colpire gli host statunitensi e falliranno contro un progetto UE.

La colonna India viene dalla pagina di Mixpanel sulla residenza in India, che elenca le stesse famiglie più Data Pipelines e Lexicon Schemas sotto data-in. e in.. La pagina UE la rispecchia con -eu e eu..

Perché gli eventi inviati all'host sbagliato vengono scartati

La formulazione di Mixpanel è netta: nessun dato viene ingerito in un progetto con residenza UE se la tua implementazione non lo invia all'URL di ingestione UE. La pagina sull'India dice lo stesso di api-in.mixpanel.com.

La parte dolorosa è che l'host sbagliato non rifiuta la richiesta in un modo che la maggior parte degli strumenti nota. L'endpoint /track prende il token per buono: un mittente puntato sull'host statunitense può quindi vedere risposte di successo mentre il progetto UE resta vuoto. Lo scopri da un grafico piatto, di solito una settimana dopo.

Quindi fai il debug dal progetto. Qui non fidarti mai dei log del mittente. Apri la vista Events nel progetto UE, invia un evento e aspettalo. Niente entro un paio di minuti significa che l'host è sbagliato o che il token appartiene a un altro progetto.

Come verificare la tua residenza e spostare un progetto esistente

Verificare è rapido. Le impostazioni del progetto mostrano un valore Data Residency; oppure guarda la barra degli indirizzi, dove eu. o in. davanti a mixpanel.com la rivela. Scriverei il valore nel documento che elenca le tue integrazioni, perché ogni strumento che collegherai in seguito ne ha bisogno.

Spostare è la parte difficile. La documentazione di Mixpanel afferma che se è stata scelta la posizione di residenza sbagliata «dovrai creare un nuovo progetto con l'opzione di archiviazione applicabile e migrare tutti i dati esistenti», e che Mixpanel non può aiutare con la migrazione. In pratica significa:

1. Creare un nuovo progetto con residenza UE (o India) e puntare ogni mittente al nuovo host e al nuovo token.
2. Reimportare la cronologia che ti serve, poi ritirare il vecchio progetto una volta ricostruiti report e dashboard su quello nuovo.

Nulla in quelle pagine dice se una cronologia migrata conserva gli ID o le dashboard originali. Non ho trovato scorciatoie documentate e presumo che non ce ne siano.

Residenza dei dati Mixpanel e GDPR: IP e trasferimenti

La residenza risponde bene a una domanda del GDPR: dove si trovano i dati archiviati. Con un progetto UE la cronologia dei tuoi eventi non è negli Stati Uniti, il che toglie un trasferimento del Capo V dal quadro dell'archiviazione. La guida al GDPR per gli URL shortener copre gli obblighi a livello di articolo che restano.

L'indirizzo IP è il dettaglio che molti trascurano. I mittenti lato server di solito allegano l'IP del visitatore come proprietà ip così Mixpanel può geolocalizzare l'evento invece di collocare tutti sul server del mittente. Secondo la documentazione sulla geolocalizzazione di Mixpanel, l'IP serve a ricavare paese, regione e città e poi viene scartato prima che l'evento sia archiviato. Bene. Ma l'IP viaggia comunque nella richiesta, e una richiesta a api.mixpanel.com è una richiesta a un endpoint statunitense. Quindi un host sbagliato non è solo un bug di perdita dati. È anche un dato personale che lascia l'UE verso un endpoint che il tuo registro dei trattamenti dice di non usare.

Se non ti serve la posizione a livello di città, puoi inviare ip come 0 e Mixpanel salta del tutto la geolocalizzazione. Tutto il resto resta a tuo carico: base giuridica, consenso per ogni cookie impostato dall'SDK del browser, DPA e ciò che ogni strumento di inoltro conserva dal proprio lato. L'articolo Schrems II e pixel di tracciamento spiega come si svolge il dibattito sui trasferimenti per i tag lato browser.

Inviare eventi all'endpoint di ingestione UE da qualsiasi strumento

Ogni mittente ha bisogno della propria impostazione. Non esiste un interruttore a livello di account, quindi elencali e correggili uno per uno:

• SDK browser. Imposta api_host all'inizializzazione, per esempio mixpanel.init(TOKEN, { api_host: "https://api-eu.mixpanel.com" }), oppure l'host api-in per l'India.
• SDK server e chiamate HTTP dirette: punta l'host a api-eu.mixpanel.com (ogni SDK ha una propria opzione di configurazione) oppure fai POST direttamente a https://api-eu.mixpanel.com/track.
• CDP, job di reverse ETL e connettori no-code: trova il loro campo di regione o endpoint e, se non lo trovi, chiedilo al fornitore per iscritto.
• Forwarder di terze parti che inviano per tuo conto, come un link shortener che invia i click. Neanche loro vedono la tua residenza dal token.

Poi verifica ciascuno nel progetto UE. Basta un evento di test per mittente.

Esempio pratico: il forwarder Mixpanel di Elido

Elido inoltra a Mixpanel ogni click su un link breve come evento link_click lato server con slug, ID del link, paese, dispositivo, destinazione, timestamp e l'ip del visitatore. Dal 22 settembre 2026 la finestra di connessione ha un campo Data residency con tre opzioni, ciascuna associata a un host fisso:

• Stati Uniti: api.mixpanel.com (usato anche quando il campo è vuoto)
• UE: api-eu.mixpanel.com
• India: api-in.mixpanel.com

Il valore viene convalidato al salvataggio; qualsiasi cosa diversa da quei tre viene rifiutata, quindi un refuso non può trasformarsi in un ripiego silenzioso sull'host statunitense. Le connessioni salvate prima dell'esistenza del campo non hanno valore e continuano ad andare all'host statunitense: se il tuo progetto è a residenza UE, riapri la connessione Mixpanel con Update key, incolla di nuovo il token del progetto (la finestra non mostra mai quello memorizzato), scegli EU e salva.

Ecco il limite che vorrei vedere spiegato se rivedessi questo testo. Il pulsante Test connection non può provare la regione. Invia un link_click contrassegnato elido_test: true e mostra la risposta di Mixpanel, ma /track accetta qualsiasi token e non controlla la residenza, quindi un risultato verde sull'host sbagliato è identico a uno verde su quello giusto. Il pannello lo dice nella sua nota. La prova è quell'evento di test che arriva nella vista Events del tuo progetto UE.

Dal lato di Elido, sii chiaro su cosa la residenza in Mixpanel ti dà e cosa no. Elido conserva anche le proprie righe di click, con l'IP completo del visitatore (senza troncamento oggi), e non offre il blocco della regione per workspace, quindi non puoi scegliere una regione di archiviazione per quelle righe come lo fai in Mixpanel. La nostra lista dei sub-responsabili indica chi tocca i dati. Metti entrambi gli archivi nel tuo registro dei trattamenti. Se vuoi i click dei link in un progetto Mixpanel UE senza scrivere un forwarder, avvia un workspace e collegalo dall'integrazione Mixpanel.

Due lacune da conoscere: il forwarder invia sempre ip (oggi non c'è un interruttore per ip: 0) e non imposta $insert_id, di cui parla la guida al tracciamento dei link con Mixpanel insieme al distinct_id per link. Per la scelta più ampia di dove dovrebbero vivere i dati dei click, vedi Mixpanel vs GA4 per le analytics dei link.

Correlati sul blog

• Mixpanel Link Tracking: i clic sui link brevi come eventi - configurazione, proprietà e verifica del forwarder.
• Data residency UE per i tool di marketing: checklist DPO - cosa chiede il tuo DPO oltre alla posizione di archiviazione.
• Google Analytics è Conforme al GDPR? La Risposta per l'UE - la stessa domanda per uno strumento senza opzione di residenza.
• Tracciamento conversioni server-side con i link brevi: guida - perché gli eventi lasciano il browser e cosa cambia.