Mixpanel EU Data Residency: hosty, utracone zdarzenia, RODO

Rezydencja danych Mixpanel w UE oznacza, że zdarzenia Twojego projektu są przetwarzane i przechowywane w centrach danych Mixpanel w UE, a wraz z tym obowiązuje jedna twarda reguła: zdarzenia muszą być wysyłane do punktu przyjmowania danych w UE, api-eu.mixpanel.com. Wyślij je do domyślnego api.mixpanel.com, a nie zostaną zakolejkowane, przekierowane ani oznaczone. Po prostu nigdy nie pojawią się w projekcie.

Indie działają tak samo z api-in.mixpanel.com. Rezydencję wybiera się podczas tworzenia projektu, nie można jej później przełączyć, a każde narzędzie zapisujące dane do projektu (SDK przeglądarkowe, backend, CDP, zewnętrzne narzędzia przekazujące) trzeba osobno skierować na właściwy host.

Ten ostatni fragment jest źródłem większości awarii, a tego lata problem się pogłębił. Mixpanel wcześniej przekazywał zdarzenia, które starsze projekty UE otrzymywały na hoście USA. Zgodnie z dokumentacją rezydencji UE, to przekazywanie z USA do UE zakończyło się w lipcu 2026 dla większości projektów UE utworzonych przed 18 sierpnia 2025. Konfiguracje, które po cichu na nim polegały, ucichły. Jeśli analizujesz szersze pytanie o rezydencję danych w swoim stosie, zacznij od przewodnika po rezydencji danych w UE dla narzędzi marketingowych; ten wpis zostaje przy Mixpanel.

Co obejmuje rezydencja UE w Mixpanel

Rezydencja UE to wybór miejsca przechowywania na poziomie projektu. Zaznaczasz "EU Data Residency" podczas tworzenia projektu i od tej chwili Mixpanel przetwarza oraz przechowuje dane tego projektu w UE zamiast w domyślnej lokalizacji w USA. Mixpanel prowadzi równoległy program dla Indii, który łączy z Digital Personal Data Protection Act.

Z tego, że ustawienie działa na poziomie projektu, wynikają trzy rzeczy. Twoja organizacja może mieć obok siebie projekty USA i UE. Token projektu nie ujawnia regionu. Nic niżej w przepływie nie odczyta go z tokena. Zmienia się też interfejs: projekty UE działają pod eu.mixpanel.com, projekty indyjskie pod in.mixpanel.com, dlatego adresy SSO postback dla UE także potrzebują prefiksu eu..

Nie obejmuje natomiast drogi, którą dane pokonują, zanim dotrą do Mixpanel. Mixpanel mówi to wprost: jeśli zdarzenia przychodzą przez platformę danych klientów, "nie może zagwarantować", że ich przyjęcie, przetwarzanie i przechowywanie pozostaną w UE. Twój przepływ danych to Twój problem.

Hosty przyjmowania danych dla projektów USA, UE i Indii

Przyjmowanie danych nie jest jedynym regionalnym hostem. Każda rodzina API ma własny. Jeśli zmienisz tylko host śledzenia, eksporty i skrypty zapytań nadal będą trafiały do hostów USA i nie zadziałają z projektem UE.

Kolumna Indii pochodzi ze strony Mixpanel o rezydencji w Indiach, która wymienia te same rodziny oraz Data Pipelines i Lexicon Schemas pod data-in. oraz in.. Strona UE odzwierciedla to przez -eu i eu..

Dlaczego zdarzenia wysłane do niewłaściwego hosta przepadają

Sformułowanie Mixpanel jest bezpośrednie: żadne dane nie są przyjmowane do projektu z rezydencją UE, jeśli implementacja nie wysyła ich na adres przyjmowania danych w UE. Strona Indii mówi to samo o api-in.mixpanel.com.

Bolesne jest to, że niewłaściwy host nie odrzuca żądania w sposób zauważalny dla większości narzędzi. Punkt końcowy /track przyjmuje token bez sprawdzania, więc nadawca skierowany na host USA może widzieć udane odpowiedzi, podczas gdy projekt UE pozostaje pusty. Dowiadujesz się o tym z płaskiego wykresu, zwykle tydzień później.

Dlatego debuguj od strony projektu. Nie ufaj tutaj logom nadawcy. Otwórz widok Events w projekcie UE, wyślij jedno zdarzenie i sprawdź, czy się pojawi. Brak czegokolwiek w ciągu minuty lub dwóch oznacza, że host jest niewłaściwy albo token należy do innego projektu.

Jak sprawdzić rezydencję i przenieść istniejący projekt

Sprawdzenie jest szybkie. Project Settings pokazuje wartość Data Residency; możesz też spojrzeć na pasek adresu, gdzie eu. albo in. przed mixpanel.com zdradza region. Zapisałbym tę wartość w dokumencie z listą integracji, bo będzie jej potrzebowało każde narzędzie podłączane później.

Przeniesienie to trudniejsza część. Dokumentacja Mixpanel stwierdza, że jeśli wybrano niewłaściwą lokalizację rezydencji, "trzeba utworzyć nowy projekt z odpowiednią opcją przechowywania danych i przenieść wszystkie istniejące dane", a Mixpanel nie może pomóc w migracji. W praktyce oznacza to:

1. Utwórz nowy projekt z rezydencją UE (albo Indii) i skieruj każdego nadawcę na nowy host oraz token.
2. Ponownie zaimportuj potrzebną historię, a potem wycofaj stary projekt, gdy raporty i pulpity zostaną odbudowane na nowym.

Na tych stronach nie ma informacji, czy przeniesiona historia zachowuje pierwotne ID albo pulpity. Nie znalazłem udokumentowanego skrótu i zakładałbym, że go nie ma.

Rezydencja danych Mixpanel i RODO: adresy IP oraz transfery

Rezydencja dobrze odpowiada na jedno pytanie z zakresu RODO: gdzie znajdują się przechowywane dane. W projekcie UE historia zdarzeń nie leży w USA, więc w zakresie przechowywania transfer z rozdziału V w ogóle nie występuje. Przewodnik po RODO dla skracaczy URL omawia obowiązki na poziomie artykułów, które nadal zostają.

Adres IP to szczegół, który wiele osób pomija. Nadawcy server-side zwykle dołączają IP odwiedzającego jako właściwość ip, aby Mixpanel mógł geolokalizować zdarzenie zamiast umieszczać wszystkich przy serwerze nadawcy. Według dokumentacji geolokalizacji Mixpanel, IP służy do wyprowadzenia kraju, regionu i miasta, a potem jest usuwany przed zapisaniem zdarzenia. Dobrze. Ale IP nadal podróżuje w żądaniu, a żądanie do api.mixpanel.com jest żądaniem do punktu końcowego w USA. Niewłaściwy host nie jest więc tylko błędem powodującym utratę danych. To także wyprowadzenie danych osobowych z UE do punktu końcowego, którego według rejestrów czynności przetwarzania nie używasz.

Jeśli nie potrzebujesz lokalizacji na poziomie miasta, możesz wysłać ip jako 0, a Mixpanel całkowicie pominie geolokalizację. Cała reszta pozostaje po Twojej stronie: podstawa prawna, zgoda na każdy plik cookie ustawiany przez SDK przeglądarkowe, DPA oraz to, co każde narzędzie przekazujące przechowuje u siebie. Wpis Schrems II i piksele śledzące pokazuje, jak debata o transferach wygląda dla tagów po stronie przeglądarki.

Wysyłanie zdarzeń do punktu przyjmowania danych w UE z dowolnego narzędzia

Każdy nadawca potrzebuje własnego ustawienia. Nie ma przełącznika dla całego konta, więc wypisz je i popraw po kolei:

• SDK przeglądarkowe. Ustaw api_host przy inicjalizacji, na przykład mixpanel.init(TOKEN, { api_host: "https://api-eu.mixpanel.com" }), albo host api-in dla Indii.
• SDK serwerowe i surowe wywołania HTTP: skieruj host na api-eu.mixpanel.com (każde SDK ma do tego własną opcję konfiguracji) albo wyślij POST bezpośrednio do https://api-eu.mixpanel.com/track.
• CDP, zadania reverse-ETL i konektory no-code: znajdź ich pole regionu albo punktu końcowego, a jeśli nie możesz, zapytaj dostawcę na piśmie.
• Zewnętrzne narzędzia przekazujące, które publikują dane w Twoim imieniu, na przykład skracacz linków wysyłający kliknięcia. One też nie widzą rezydencji z tokena.

Następnie zweryfikuj każde z nich w projekcie UE. Wystarczy jedno zdarzenie testowe na nadawcę.

Przykład praktyczny: narzędzie przekazujące Mixpanel w Elido

Elido przekazuje każde kliknięcie krótkiego linku do Mixpanel jako zdarzenie link_click po stronie serwera, niosące slug, ID linku, kraj, urządzenie, cel, znacznik czasu i ip odwiedzającego. Od 22 września 2026 okno połączenia ma pole Data residency z trzema opcjami, a każda z nich mapuje się na stały host:

• Stany Zjednoczone: api.mixpanel.com (używany także wtedy, gdy pole jest puste)
• UE: api-eu.mixpanel.com
• Indie: api-in.mixpanel.com

Wartość jest walidowana przy zapisie; wszystko poza tymi trzema opcjami jest odrzucane, więc literówka nie może zmienić się w cichy powrót do hosta USA. Połączenia zapisane przed pojawieniem się tego pola nie mają wartości i nadal idą do hosta USA, więc jeśli Twój projekt ma rezydencję UE, otwórz ponownie połączenie Mixpanel przez Update key, wklej token projektu jeszcze raz (okno nigdy nie pokazuje zapisanego tokena), wybierz EU i zapisz.

Oto ograniczenie, które sam chciałbym mieć jasno opisane, gdybym to sprawdzał. Przycisk Test connection nie może potwierdzić regionu. Wysyła jedno link_click oznaczone elido_test: true i pokazuje odpowiedź Mixpanel, ale /track przyjmuje dowolny token i nie sprawdza rezydencji, więc zielony wynik na niewłaściwym hoście wygląda identycznie jak zielony wynik na właściwym. Panel mówi o tym w swojej notatce. Dowodem jest dopiero pojawienie się zdarzenia testowego w widoku Events Twojego projektu UE.

Same kliknięcia są zapisywane po stronie Elido w regionie UE, a nasza lista podprocesorów wskazuje, kto ma z nimi kontakt. Jeśli chcesz, aby kliknięcia linków trafiały do projektu Mixpanel w UE bez samodzielnego pisania narzędzia przekazującego, utwórz obszar roboczy i podłącz go z integracji Mixpanel.

Dwie luki warto znać: narzędzie przekazujące zawsze wysyła ip (dziś nie ma przełącznika dla ip: 0) i nie ustawia $insert_id, co przewodnik śledzenia linków w Mixpanel omawia wraz z osobnym dla każdego linku distinct_id. Szerszy wybór miejsca przechowywania danych o kliknięciach opisuje wpis Mixpanel kontra GA4 w analityce linków.

Powiązane na blogu

• Śledzenie linków w Mixpanel: kliknięcia krótkich linków jako zdarzenia - konfiguracja, właściwości i weryfikacja narzędzia przekazującego.
• Rezydencja danych w UE dla narzędzi marketingowych - o co DPO pyta poza lokalizacją przechowywania.
• Czy Google Analytics jest zgodny z RODO? - to samo pytanie dla narzędzia bez opcji rezydencji.
• Śledzenie konwersji po stronie serwera - dlaczego zdarzenia przenoszą się poza przeglądarkę i co to zmienia.