Резидентность данных 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, поэтому и URL постбэка SSO для ЕС требуют префикса eu..

Не охватывает она путь до того, как данные дойдут до Mixpanel. Сам Mixpanel говорит об этом: если события поступают через платформу клиентских данных, он «cannot guarantee», что приём, обработка и хранение останутся в ЕС. Ваш конвейер это ваша проблема.

Хосты приёма для проектов США, ЕС и Индии

Хост приёма не единственный региональный. У каждого семейства 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 сказано, что если выбрано неверное место резидентности, «you will need to create a new project with the applicable data storage option and migrate all your existing data», и что Mixpanel не может помочь с миграцией. На практике это означает:

1. Создать новый проект с резидентностью в ЕС (или в Индии) и направить каждого отправителя на новый хост и токен.
2. Заново импортировать нужную историю, а затем вывести старый проект из использования, когда отчёты и дашборды пересобраны на новом.

Ни на одной из этих страниц не сказано, сохраняет ли перенесённая история исходные ID или дашборды. Документированной короткой дороги я не нашёл и предположил бы, что её нет.

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

Резидентность хорошо отвечает на один вопрос GDPR: где лежат сохранённые данные. С проектом ЕС история ваших событий не лежит в США, что убирает передачу по Главе V из картины хранения. Обязанности по статьям, которые остаются, разобраны в руководстве по GDPR для сокращателей ссылок.

IP-адрес это деталь, которую упускают. Серверные отправители обычно прикладывают IP посетителя как свойство ip, чтобы Mixpanel определил геолокацию события, а не поместил всех на сервер отправителя. Согласно документации Mixpanel по геолокации, IP используется для получения страны, региона и города, а затем отбрасывается до сохранения события. Хорошо. Но IP всё равно путешествует в запросе, а запрос на api.mixpanel.com это запрос к конечной точке в США. Так что неверный хост это не только ошибка с потерей данных. Это ещё и персональные данные, уходящие из ЕС на конечную точку, которую, согласно вашим записям об обработке, вы не используете.

Если вам не нужна геолокация на уровне города, можно отправлять ip как 0, и Mixpanel вообще пропустит геолокацию. Всё остальное остаётся за вами: правовое основание, согласие на любые cookie, которые ставит SDK браузера, DPA и то, что хранит у себя каждый пересылающий инструмент. Как дебаты о передаче данных разворачиваются для тегов на стороне браузера, разобрано в статье Schrems II и пиксели отслеживания: где нас оставляет DPF в 2026 году.

Отправка событий на конечную точку приёма ЕС из любого инструмента

Каждому отправителю нужна своя настройка. Общего переключателя для всего аккаунта нет, так что составьте список и исправьте каждый:

• 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-коннекторы: найдите у них поле региона или конечной точки, а если не нашли, спросите вендора письменно.
• Сторонние форвардеры, которые отправляют от вашего имени, например сокращатель ссылок, пересылающий клики. Они тоже не видят вашу резидентность по токену.

Затем проверьте каждого в проекте ЕС. Одного тестового события на отправителя достаточно.

Практический пример: форвардер Elido в Mixpanel

Elido пересылает каждый клик по короткой ссылке в Mixpanel как серверное событие link_click со slug, 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? Ответ для ЕС - тот же вопрос для инструмента без опции резидентности.
• Серверное отслеживание конверсий через короткие ссылки - почему события уходят из браузера и что это меняет.