Rezydencja danych Mixpanel w UE: hosty, utrata zdarzeń, RODO

Rezydencja danych Mixpanel w UE oznacza, że zdarzenia projektu są przetwarzane i przechowywane w centrach danych Mixpanel w UE. Wiąże się z nią jedna twarda reguła: każdy nadawca musi wysyłać dane na punkt końcowy przyjmowania w UE, api-eu.mixpanel.com. Wyślij te same zdarzenia na domyślny api.mixpanel.com, a nie zostaną ani zakolejkowane, ani przekierowane, ani oznaczone. Po prostu nigdy się nie pojawią.

Indie działają tak samo z api-in.mixpanel.com. Rezydencję wybiera się przy tworzeniu projektu, nie da się jej później zmienić, a każde narzędzie zapisujące do projektu (SDK w przeglądarce, backend, CDP, zewnętrzne forwardery) trzeba osobno poinformować o właściwym hoście.

Większość awarii bierze się z tego ostatniego punktu i tego lata zrobiło się gorzej. Mixpanel dawniej przekazywał zdarzenia, które starsze projekty UE odbierały na hoście amerykańskim. Według dokumentacji rezydencji w 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 tym polegały, zamilkły. Jeśli porządkujesz szerszą kwestię rezydencji dla swojego stosu, zacznij od przewodnika o rezydencji danych w UE dla narzędzi marketingu; ten wpis zostaje przy Mixpanel.

Co obejmuje rezydencja Mixpanel w UE

Rezydencja w UE to wybór miejsca przechowywania na poziomie projektu. Zaznaczasz "EU Data Residency" przy tworzeniu projektu i od tej pory Mixpanel przetwarza i przechowuje dane tego projektu w UE zamiast w domyślnych USA. Mixpanel prowadzi równoległy program dla Indii, który wiąże z Digital Personal Data Protection Act.

Z tego, że to ustawienie projektu, wynikają trzy rzeczy. Twoja organizacja może mieć projekty w USA i w UE obok siebie. Token projektu nie zdradza jego regionu. Nic dalej w łańcuchu nie wyczyta go z tokenu. Zmienia się też interfejs: projekty UE mieszkają pod eu.mixpanel.com, indyjskie pod in.mixpanel.com, i dlatego adresy zwrotne SSO dla UE wymagają przedrostka eu..

Nie obejmuje ona drogi przed dotarciem danych do Mixpanel. Mixpanel sam to mówi: jeśli zdarzenia wchodzą przez platformę danych klientów (CDP), "nie może zagwarantować", że przyjmowanie, przetwarzanie i przechowywanie pozostaną w UE. Twój potok to Twój problem.

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

Przyjmowanie nie jest jedynym hostem regionalnym. Każda rodzina API ma swój. Jeśli zmienisz tylko host śledzenia, eksporty i skrypty zapytań nadal będą trafiać na hosty amerykańskie i zawodzić wobec projektu UE.

Kolumna dla Indii pochodzi ze strony Mixpanel o rezydencji w Indiach, która wymienia te same rodziny plus Data Pipelines i Lexicon Schemas pod data-in. i in.. Strona o UE jest lustrzana, z -eu i eu..

Dlaczego zdarzenia wysłane na zły host są odrzucane

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

Bolesne jest to, że zły host nie odrzuca żądania w sposób, który większość narzędzi zauważa. Punkt końcowy /track przyjmuje token na słowo, więc nadawca skierowany na host amerykański może widzieć udane odpowiedzi, podczas gdy projekt UE pozostaje pusty. Dowiadujesz się z płaskiego wykresu, zwykle po tygodniu.

Dlatego debuguj od strony projektu. Nigdy nie ufaj tu logom nadawcy. Otwórz widok Events w projekcie UE, wyślij jedno zdarzenie i obserwuj. Brak go po minucie lub dwóch oznacza, że host jest zły albo token należy do innego projektu.

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

Sprawdzenie jest szybkie. Ustawienia projektu pokazują wartość Data Residency; albo spójrz na pasek adresu, gdzie eu. lub in. przed mixpanel.com zdradza wszystko. Zapisałbym tę wartość w dokumencie, który wylicza Twoje integracje, bo będzie potrzebna każdemu narzędziu podłączanemu później.

Przeniesienie to trudna część. Dokumentacja Mixpanel stwierdza, że jeśli wybrano złą lokalizację rezydencji, "trzeba utworzyć nowy projekt z odpowiednią opcją przechowywania danych i zmigrować wszystkie istniejące dane", a Mixpanel nie pomoże w migracji. W praktyce oznacza to:

1. Utwórz nowy projekt z rezydencją w UE (lub Indiach) i skieruj wszystkich nadawców na nowy host i token.
2. Zaimportuj ponownie potrzebną historię, a stary projekt wycofaj, gdy raporty i dashboardy zostaną odbudowane w nowym.

Nic na tych stronach nie mówi, czy przeniesiona historia zachowuje oryginalne identyfikatory lub dashboardy. Nie znalazłem udokumentowanego skrótu i zakładałbym, że go nie ma.

Rezydencja danych Mixpanel a RODO: adresy IP i transfery

Rezydencja dobrze odpowiada na jedno pytanie z RODO: gdzie leżą przechowywane dane. Przy projekcie UE historia zdarzeń nie leży w USA, co wyjmuje transfer z rozdziału V z obrazu przechowywania. Pozostałe obowiązki na poziomie artykułów opisuje przewodnik RODO dla skracaczy URL.

Szczegół, który ludzie pomijają, to adres IP. Nadawcy server-side zwykle dołączają IP odwiedzającego jako właściwość ip, aby Mixpanel mógł określić lokalizację zdarzenia zamiast umieszczać wszystkich w miejscu serwera nadawcy. Według dokumentacji geolokalizacji Mixpanel IP służy do wyznaczenia kraju, regionu i miasta, a potem jest odrzucane przed zapisem zdarzenia. Dobrze. Ale IP nadal podróżuje w żądaniu, a żądanie do api.mixpanel.com to żądanie do amerykańskiego punktu końcowego. Zły host to więc nie tylko błąd utraty danych. To także dane osobowe opuszczające UE w stronę punktu końcowego, którego według rejestru 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 do obsłużenia po Twojej stronie: podstawa prawna, zgoda na ciasteczka ustawiane przez SDK w przeglądarce, umowa powierzenia i to, co każde narzędzie przekazujące zachowuje u siebie. Jak debata o transferach wygląda dla tagów po stronie przeglądarki, opisuje wpis Schrems II i piksele śledzące.

Wysyłanie zdarzeń na punkt końcowy UE z dowolnego narzędzia

Każdy nadawca ma własne ustawienie. Nie ma przełącznika na całe konto, więc wypisz nadawców i popraw każdego:

• SDK w przeglądarce. 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: wskaż host api-eu.mixpanel.com (każde SDK ma własną opcję konfiguracji) albo wysyłaj POST bezpośrednio na https://api-eu.mixpanel.com/track.
• CDP, zadania reverse-ETL i konektory no-code: znajdź ich pole regionu lub punktu końcowego, a jeśli go nie ma, zapytaj dostawcę na piśmie.
• Zewnętrzne forwardery wysyłające w Twoim imieniu, jak skracacz linków wysyłający kliknięcia. Im też token nie zdradza Twojej rezydencji.

Potem zweryfikuj każdego w projekcie UE. Jedno zdarzenie testowe na nadawcę wystarczy.

Przykład: forwarder 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, adres docelowy, znacznik czasu i ip odwiedzającego. Od 22 września 2026 okno połączenia ma pole Data residency z trzema opcjami, a każda odpowiada stałemu hostowi:

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

Wartość jest walidowana przy zapisie; wszystko poza tymi trzema jest odrzucane, więc literówka nie zamieni się w ciche przejście na host amerykański. Połączenia zapisane przed pojawieniem się pola nie mają wartości i nadal idą na host amerykański, więc jeśli Twój projekt ma rezydencję w UE, otwórz połączenie Mixpanel przez Update key, wklej ponownie token projektu (okno nigdy nie pokazuje zapisanego), wybierz UE i zapisz.

Oto ograniczenie, które chciałbym mieć wyraźnie opisane, gdybym to recenzował. Przycisk Test connection nie potrafi udowodnić regionu. Wysyła jedno zdarzenie link_click oznaczone elido_test: true i pokazuje odpowiedź Mixpanel, ale /track akceptuje dowolny token i nie sprawdza rezydencji, więc zielony wynik na złym hoście wygląda identycznie jak zielony na właściwym. Panel mówi to w swojej notatce. Dowodem jest dotarcie tego zdarzenia testowego do widoku Events w Twoim projekcie UE.

Po stronie Elido trzeba jasno powiedzieć, co rezydencja w Mixpanel daje, a czego nie. Elido przechowuje też własne wiersze kliknięć, z pełnym IP odwiedzającego (dziś bez obcinania), i nie oferuje przypinania regionu per workspace, więc nie wybierzesz regionu przechowywania tych wierszy tak, jak wybierasz go w Mixpanel. Nasza lista podprzetwarzających wymienia, kto ma kontakt z danymi. Wpisz oba magazyny do rejestru czynności przetwarzania. Jeśli chcesz mieć kliknięcia linków w projekcie Mixpanel w UE bez pisania własnego forwardera, załóż workspace i połącz go z integracji Mixpanel.

Dwie luki, o których warto wiedzieć: forwarder zawsze wysyła ip (dziś nie ma przełącznika dla ip: 0) i nie ustawia $insert_id, o czym mówi przewodnik po śledzeniu linków w Mixpanel razem z distinct_id per link. O szerszym wyborze, gdzie powinny leżeć dane o kliknięciach, przeczytasz w Mixpanel vs GA4 dla analityki 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 forwardera.
• Rezydencja danych w UE dla narzędzi marketingu: lista IOD - o co pyta Twój IOD poza lokalizacją przechowywania.
• Czy Google Analytics jest zgodny z RODO? Odpowiedź dla UE - to samo pytanie dla narzędzia bez opcji rezydencji.
• Śledzenie konwersji server-side z krótkimi linkami: poradnik - dlaczego zdarzenia opuszczają przeglądarkę i co to zmienia.