Резидентність даних Mixpanel в ЄС

Резидентність даних Mixpanel в ЄС означає, що події вашого проєкту обробляються й зберігаються в центрах обробки даних Mixpanel в ЄС. Вона має одне жорстке правило: кожен відправник мусить слати на кінцеву точку прийому для ЄС, api-eu.mixpanel.com. Надішліть ті самі події на типовий api.mixpanel.com, і їх не буде поставлено в чергу, перенаправлено чи позначено. Вони просто ніколи не з'являться.

Індія працює так само з api-in.mixpanel.com. Резидентність обирають під час створення проєкту, потім її не можна змінити, і кожному інструменту, що пише в проєкт (браузерний SDK, бекенд, CDP, сторонні форвардери), правильний хост треба вказати окремо.

Більшість збоїв походить саме з цієї останньої частини, і цього літа стало гірше. Раніше Mixpanel пересилав події, які старіші проєкти ЄС отримували на хості США. Згідно з документацією Mixpanel щодо резидентності в ЄС, це перенаправлення з US на EU припинилося в липні 2026 року для більшості проєктів ЄС, створених до 18 серпня 2025 року. Конфігурації, які тихо на нього покладалися, замовкли. Якщо ви розбираєтеся з ширшим питанням резидентності для свого стеку, почніть із посібника з резидентності даних в ЄС для маркетингових інструментів. Цей допис лишається в межах Mixpanel.

Що охоплює резидентність Mixpanel в ЄС

Резидентність ЄС - це вибір місця зберігання на рівні проєкту. Ви ставите позначку «EU Data Residency» під час створення проєкту, і відтоді Mixpanel обробляє й зберігає дані цього проєкту в ЄС замість типових США. Для Індії Mixpanel має паралельну програму, яку пов'язує з Digital Personal Data Protection Act.

З того, що це рівень проєкту, випливає три речі. Ваша організація може тримати проєкти США й ЄС поруч. Токен проєкту не розкриває його регіон, тож нічого нижче за течією не може визначити регіон за токеном. А інтерфейс теж переїжджає: проєкти ЄС живуть на eu.mixpanel.com, індійські на in.mixpanel.com, тому URL зворотного виклику SSO для ЄС потребують префікса eu..

Чого вона не охоплює - це шлях до того, як дані дійдуть до Mixpanel. Mixpanel каже про це сама: якщо події надходять через платформу клієнтських даних, вона «не може гарантувати», що прийом, обробка й зберігання лишаються в ЄС. Ваш конвеєр - ваша проблема.

Хости прийому для проєктів США, ЄС та Індії

Прийом - не єдиний регіональний хост. Кожне сімейство API має свій. Якщо змінити лише хост відстеження, ваші експорти й скрипти запитів і далі стукатимуть у хости США та падатимуть проти проєкту ЄС.

Стовпець Індії взято зі сторінки Mixpanel про резидентність в Індії, де перелічено ті самі сімейства плюс Data Pipelines і Lexicon Schemas під data-in. та in.. Сторінка для ЄС віддзеркалює її з -eu та eu..

Чому події, надіслані не на той хост, відкидаються

Формулювання Mixpanel пряме: у проєкт із резидентністю ЄС дані не потрапляють, якщо ваша реалізація не надсилає їх на URL прийому для ЄС. Сторінка про Індію каже те саме про api-in.mixpanel.com.

Болюче те, що неправильний хост не відхиляє запит так, щоб більшість інструментів це помітили. Кінцева точка /track бере токен на віру, тож відправник, спрямований на хост США, може бачити успішні відповіді, поки проєкт ЄС лишається порожнім. Ви дізнаєтеся з плоского графіка, зазвичай через тиждень.

Тому налагоджуйте з боку проєкту. Ніколи не довіряйте тут логам відправника. Відкрийте вигляд Events у проєкті ЄС, надішліть одну подію й чекайте на неї. Якщо за хвилину-дві нічого немає, або хост неправильний, або токен належить іншому проєкту.

Як перевірити резидентність і перенести наявний проєкт

Перевірка швидка. Project Settings показує значення Data Residency, або дивіться на адресний рядок, де eu. чи in. перед mixpanel.com видає відповідь. Я б записав це значення в той документ, де перелічено ваші інтеграції, бо воно потрібне кожному інструменту, який ви підключите згодом.

Перенесення - складна частина. Документація Mixpanel стверджує, що якщо вибрано неправильне місце резидентності, «вам потрібно буде створити новий проєкт із відповідним варіантом зберігання даних і перенести всі наявні дані», а Mixpanel із міграцією допомогти не може. На практиці це означає:

1. Створіть новий проєкт із резидентністю ЄС (або Індії) і спрямуйте всіх відправників на новий хост і токен.
2. Повторно імпортуйте потрібну історію, а потім виведіть старий проєкт з експлуатації, коли звіти й дашборди перебудовано на новому.

Жодна з цих сторінок не каже, чи зберігає перенесена історія початкові ідентифікатори або дашборди. Задокументованого короткого шляху я не знайшов і вважав би, що його немає.

Резидентність даних Mixpanel і GDPR: IP-адреси та передачі

Резидентність добре відповідає на одне питання GDPR: де лежать збережені дані. З проєктом ЄС ваша історія подій не лежить у США, що прибирає передачу за Розділом V із картини зберігання. Обов'язки на рівні статей, що лишаються, описує посібник з GDPR для скорочувачів URL.

IP-адреса - деталь, яку люди пропускають. Серверні відправники зазвичай додають IP відвідувача як властивість ip, щоб Mixpanel міг геолокувати подію, а не розміщувати всіх на сервері відправника. Згідно з документацією Mixpanel щодо геолокації, IP використовується, щоб визначити країну, регіон і місто, а потім відкидається, перш ніж подію буде збережено. Добре. Але IP усе одно подорожує в запиті, а запит на api.mixpanel.com - це запит до кінцевої точки США. Тож неправильний хост - не лише помилка втрати даних. Це ще й персональні дані, що залишають ЄС для кінцевої точки, якою, за вашими записами про обробку, ви не користуєтеся.

Якщо вам не потрібне місцезнаходження на рівні міста, можна надсилати ip як 0, і Mixpanel зовсім пропустить геолокацію. Усе інше лишається вашою справою: правова підстава, згода на будь-які cookie, які встановлює браузерний SDK, угода DPA і те, що кожен інструмент пересилання зберігає зі свого боку. Як дискусія про передачі розгортається для браузерних тегів, розбирає допис Schrems II і піксели відстеження.

Надсилання подій на кінцеву точку прийому ЄС з будь-якого інструмента

Кожному відправнику потрібне своє налаштування. Перемикача на рівні акаунта немає, тож складіть їхній список і виправте кожного:

• Браузерний SDK. Задайте api_host під час ініціалізації, наприклад mixpanel.init(TOKEN, { api_host: "https://api-eu.mixpanel.com" }), або хост api-in для Індії.
• Серверні SDK і прямі HTTP-виклики: спрямуйте хост на api-eu.mixpanel.com (у кожного SDK для цього своя опція конфігурації) або надсилайте POST прямо на https://api-eu.mixpanel.com/track.
• CDP, завдання reverse-ETL і no-code конектори: знайдіть їхнє поле регіону чи кінцевої точки, а якщо не знаходите, запитайте вендора письмово.
• Сторонні форвардери, що надсилають від вашого імені, як-от скорочувач посилань, який шле кліки. Вони теж не бачать вашої резидентності за токеном.

Потім перевірте кожного в проєкті ЄС. Достатньо однієї тестової події на відправника.

Робочий приклад: форвардер Mixpanel в Elido

Elido пересилає кожен клік по короткому посиланню в Mixpanel як серверну подію link_click зі слагом, ID посилання, країною, пристроєм, призначенням, часовою міткою та ip відвідувача, усіченим до /24 (IPv4) або /48 (IPv6). З 22 вересня 2026 року в діалозі підключення є поле Data residency з трьома варіантами, і кожен відповідає фіксованому хосту:

• Сполучені Штати: api.mixpanel.com (також використовується, коли поле порожнє)
• ЄС: api-eu.mixpanel.com
• Індія: api-in.mixpanel.com

Значення перевіряється під час збереження, будь-що, крім цих трьох, відхиляється, тож одруківка не перетвориться на тихий перехід до хоста США. Підключення, збережені до появи поля, не мають значення й далі ходять на хост США, тому якщо ваш проєкт має резидентність ЄС, знову відкрийте підключення Mixpanel через Update key, вставте токен проєкту ще раз (діалог ніколи не показує збережений), оберіть EU і збережіть.

Ось обмеження, яке я б хотів бачити прописаним, якби сам це рецензував. Кнопка Test connection не може довести регіон. Вона надсилає одну подію link_click, позначену elido_test: true, і показує відповідь Mixpanel, але /track приймає будь-який токен і не перевіряє резидентність, тож зелений результат на неправильному хості виглядає так само, як зелений результат на правильному. Панель каже про це у своїй примітці. Доказ - це тестова подія, що з'явилася у вигляді Events вашого проєкту ЄС.

З боку Elido чітко розрізняйте, що резидентність у Mixpanel дає, а що ні. Elido також зберігає власні рядки кліків, з IP відвідувача, усіченим на edge (IPv4 /24, IPv6 /48), плюс місто та повний user agent, і не пропонує закріплення регіону для робочого простору, тож обрати регіон зберігання для цих рядків так, як ви обираєте його в Mixpanel, не вийде. Наш список субпроцесорів називає, хто торкається даних. Занесіть обидва сховища у свої записи про обробку. Якщо хочете мати кліки по посиланнях у проєкті Mixpanel в ЄС без власного форвардера, запустіть робочий простір і підключіть його через інтеграцію Mixpanel.

Дві прогалини, які варто знати: форвардер завжди надсилає усічений ip (перемикача для ip: 0 наразі немає, окрім режиму без персональних даних лише через API, який його відкидає) і не встановлює $insert_id, про що йдеться в посібнику з відстеження посилань Mixpanel разом із distinct_id для кожного посилання. Про ширший вибір того, де мають жити дані кліків, дивіться Mixpanel чи GA4 для аналітики посилань.

Схожі матеріали в блозі

• Відстеження посилань Mixpanel: кліки коротких посилань як події - налаштування, властивості та перевірка форвардера.
• Резидентність даних в ЄС для маркетингу: чеклист для DPO - про що ваш DPO питає крім місця зберігання.
• Чи відповідає Google Analytics вимогам GDPR? Відповідь для ЄС - те саме питання для інструмента без опції резидентності.
• Серверне відстеження конверсій з короткими посиланнями - чому події йдуть із браузера і що це змінює.