Що збирає Mixpanel

Mixpanel SDK (завантажений з cdn.mxpnl.com або самостійно розміщений) ініціалізує глобальний об'єкт mixpanel та ідентифікує користувачів за допомогою файлу cookie, що належить Mixpanel і містить згенерований унікальний ID. З цього моменту кожен виклик mixpanel.track() надсилає корисне навантаження події — ім'я події, властивості, унікальний ID та набір автоматично захоплених властивостей (user agent, OS, referrer, UTM-параметри, роздільна здатність екрана, часовий пояс) — на кінцеву точку прийому Mixpanel. SDK також підтримує режим Autocapture, що відстежує DOM та генерує події кліків, перегляду сторінок і відправки форм без явного інструментування, різко розширюючи поверхню того, що збирається.

Коли користувач автентифікується і застосунок викликає mixpanel.identify(user_id), всі наступні події — і, залежно від конфігурації, всі попередні анонімні події — асоціюються з автентифікованою ідентичністю. Ретроактивна асоціація є однією з найбільш корисних функцій Mixpanel і однією з найбільш відкритих з точки зору конфіденційності: анонімна поведінка в мережі, зібрана до отримання згоди, ретроактивно прив'язується до ідентифікованого профілю в момент входу користувача.

Чому фреймінг "Аналітика продукту" не звільняє вас від вимоги згоди

Поширений аргумент від продуктових та інженерних команд полягає в тому, що дані Mixpanel призначені для внутрішніх рішень щодо продукту, а не для маркетингу чи реклами, і що такий фреймінг внутрішнього використання має бути достатнім обґрунтуванням на підставі законного інтересу GDPR. Аргумент значною мірою є хибним з трьох причин, які регулятори чітко висловили.

Обробка все ще є обробкою персональних даних

Незалежно від того, чому збираються дані, файли cookie є необов'язковими згідно з ePrivacy Article 5(3), а події несуть постійні ідентифікатори згідно з визначенням персональних даних GDPR. Аналіз правової підстави є таким самим, як і для будь-якого іншого скрипта відстеження.

Законний інтерес вимагає тесту балансування

CNIL, ICO та EDPB всі написали рекомендації, що чітко вказують: законний інтерес для поведінкової аналітики вимагає задокументованої оцінки, що демонструє необхідність, пропорційність обробки та відсутність порушення обґрунтованих очікувань користувача. Для стороннього постачальника SaaS, що отримує дані про події на рівні користувача, цей тест балансування рідко проходить без явної згоди.

Транскордонна передача є незалежною

Навіть якщо ви могли б встановити законний інтерес для самого збору, міжнародна передача до американської інфраструктури Mixpanel несе власну вимогу щодо правової підстави, яку згода або договірна гарантія зазвичай задовольняє чистіше, ніж лише законний інтерес.

Власні засоби контролю конфіденційності Mixpanel

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

opt_out_tracking

Виклик mixpanel.opt_out_tracking() зупиняє SDK від надсилання подій та зберігає перевагу відмови між сесіями. Поєднайте з mixpanel.opt_in_tracking(), коли користувач приймає категорію аналітики у вашому CMP. SDK дотримується цього налаштування для всіх наступних викликів без необхідності повторної ініціалізації.

has_opted_out_tracking

Функція запиту, що повертає поточний стан відмови, корисна для синхронізації стану SDK зі станом CMP при завантаженні сторінки або зміні маршруту.

Опція резидентності в EU

Mixpanel пропонує тип проєкту з резидентністю даних EU, що зберігає дані про події в інфраструктурі на базі Frankfurt. Це вирішує значну частину проблеми транскордонної передачі і є правильною конфігурацією для будь-якого проєкту, де резидентність в EU є жорсткою вимогою. Це не усуває вимогу згоди.

set_config({ ip: false })

Вимикає захоплення IP-адреси, зменшуючи відбиток персональних даних кожної події. Корисно як захід захисту в глибину поряд з обмеженням згоди.

Покрокова інтеграція CMP

Схема інтеграції, що надійно працює, — ініціалізувати Mixpanel у стані відмови за замовчуванням, а потім дати згоду користувачу, коли він приймає категорію аналітики в CMP.

1. Ініціалізуйте Mixpanel з замовчуванням відмови

Викличте mixpanel.init(token, { opt_out_tracking_by_default: true }) якомога раніше у завантажувачі застосунку. Це завантажує SDK, але запобігає надсиланню будь-яких подій до виклику opt_in_tracking().

2. Підключіть зворотний виклик згоди

Коли CMP викликає подію прийняття категорії аналітики, викличте mixpanel.opt_in_tracking(). Поставлені в чергу події, захоплені під час відмови, зазвичай відкидаються; якщо вам потрібно їх зберегти, явно налаштуйте поведінку черги SDK і прийміть невеликий ризик надсилання подій із до-згодного периоду після згоди.

3. Обробка відкликання

Якщо користувач пізніше відкликає згоду, викличте mixpanel.opt_out_tracking(). Це зупиняє подальший прийом подій. Для повного видалення історичних даних застосунок також повинен викликати API видалення Mixpanel або ініціювати запит на видалення з інтерфейсу проєкту Mixpanel.

4. Уникайте ретроактивного злиття ідентичності без явної згоди

Вимкніть ретроактивну поведінку злиття виклику identify, якщо тільки користувач не надав згоду на прив'язку свого перегляду до ідентифікації до свого профілю. Параметри SDK Mixpanel відкривають прапорець для цього; консервативним замовчуванням є "без ретроактивного злиття".

5. Використовуйте проєкт резидентності EU для трафіку EU

Для проєктів, де резидентність EU важлива, маршрутизуйте трафік EU до проєкту Mixpanel з резидентністю EU, а трафік США/інший — до окремого проєкту. SDK підтримує завантаження різних токенів залежно від виявленого регіону користувача.

Поширені підводні камені

Чотири помилки інтеграції становлять більшість результатів аудиту розгортань Mixpanel.

Трактування Mixpanel як звільненого через внутрішнє використання

Це найпоширеніша помилка. Дані є персональними даними, файл cookie є необов'язковим, а передача третій стороні є реальною незалежно від того, як дані використовуються далі. Розмістіть Mixpanel за згодою на аналітику, як і будь-який інший трекер.

Залишення Autocapture увімкненим за замовчуванням

Autocapture різко розширює поверхню того, що надсилається — кожен клік, кожна взаємодія з полем введення, кожен перегляд сторінки. Поверхня ризику масштабується разом із нею. Для більшості розгортань SaaS явне інструментування дає чистіші дані та менший відбиток аудиту, ніж Autocapture; вимкніть Autocapture, якщо у вас немає конкретної причини залишити його.

Забути про ретроактивне злиття ідентичності

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

Жорстке кодування припущення про резидентність EU

Дивовижна кількість команд маршрутизує весь трафік до проєкту Mixpanel з резидентністю в США, припускаючи, що згода охоплює питання резидентності. Не охоплює — згода та резидентність є незалежними питаннями відповідності. Маршрутизуйте за виявленим регіоном, а не за глобальним замовчуванням.

Контрольний список аудиту

Шість конкретних питань для відповіді для будь-якого розгортання Mixpanel, що торкається трафіку EU, UK або Каліфорнії.

• Чи Mixpanel починає у стані відмови? Підтвердіть, що SDK ініціалізується з opt_out_tracking_by_default: true і жодна подія не запускається до згоди.
• Чи активується прийняття на правильній події CMP? Підтвердіть, що зворотний виклик прийняття аналітики викликає opt_in_tracking(), а не більш дозволяючу подію.
• Чи Autocapture необхідний? Якщо він увімкнений, задокументуйте чому. Якщо ні — вимкніть.
• Чи вимкнено ретроактивне злиття? Підтвердіть, що виклик identify не асоціює анонімну поведінку до згоди з щойно ідентифікованими профілями.
• Чи трафік EU перебуває в проєкті з резидентністю EU? Підтвердіть, що логіка маршрутизації надсилає відвідувачів EU до токена проєкту EU.
• Чи автоматизовані запити на видалення? Підтвердіть, що запити DSAR запускають API видалення Mixpanel, а не ручний тікет.

Де Mixpanel вписується у стек, орієнтований на згоду

Платформи аналітики продукту займають регуляторну категорію, якій продуктові команди часто чинять опір — вони хочуть думати про Mixpanel як про внутрішню інфраструктуру, а не як про сторонній трекер. Регулятори не проводять такого розмежування, і правозастосовні дії останніх двох років чітко дали зрозуміти, що не будуть. Правильна архітектура трактує Mixpanel точно так само, як і будь-яку іншу сторонню аналітичну поверхню: розмістіть його за згодою, використовуйте власні примітиви прийняття платформи для забезпечення воріт, маршрутизуйте трафік EU до інфраструктури резидентності EU та вимкніть функції (Autocapture, ретроактивне злиття ідентичності), що розширюють поверхню аудиту без пропорційної аналітичної користі. Зроблено правильно, продуктові команди зберігають потрібні їм дані воронки та утримання, а юридична команда зберігає документацію, необхідну для захисту розгортання під час аудиту.