Резидентність даних Mixpanel в ЄС: хости, втрачені події, GDPR

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

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

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

Що покриває резидентність Mixpanel в ЄС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На цих сторінках нічого не сказано про те, чи зберігає мігрована історія свої початкові ID або дашборди. Я не знайшов задокументованого короткого шляху й припускав би, що його немає.

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

Резидентність добре відповідає на одне питання GDPR: де лежать збережені дані. З проєктом ЄС ваша історія подій не зберігається у США, тож щодо зберігання питання передачі за главою V GDPR просто не виникає. Гайд з 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 і конектори без коду: знайдіть у них поле регіону або кінцевої точки і письмово запитайте постачальника, якщо не можете його знайти.
• Сторонні інструменти пересилання, які надсилають дані від вашого імені, наприклад скорочувач посилань, що надсилає кліки. Вони також не бачать вашу резидентність за токеном.

Потім перевірте кожен із них у проєкті ЄС. Однієї тестової події на відправника достатньо.

Приклад з практики: пересилач Mixpanel від Elido

Elido пересилає кожен клік за коротким посиланням до Mixpanel як серверну подію link_click, що містить slug, ID посилання, країну, пристрій, цільову адресу, час і ip відвідувача. З 22 вересня 2026 року діалог підключення має поле резидентності даних з трьома варіантами, і кожен з них відповідає фіксованому хосту:

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

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

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

Самі кліки записуються в регіоні ЄС на боці Elido, а наш список субпроцесорів називає, хто їх обробляє. Якщо ви хочете, щоб кліки за посиланнями потрапляли в проєкт Mixpanel у ЄС без написання власного пересилача, створіть робочий простір і під'єднайте його з інтеграції Mixpanel.

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

Пов'язане в блозі

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