Чому Amplitude потребує згоди

Типовий Amplitude Browser SDK та мобільні SDK Amplitude роблять набагато більше, ніж просто записують перегляди сторінок. Під час ініціалізації вони встановлюють ідентифікатор пристрою в сховищі першої сторони, генерують ідентифікатор сесії, фіксують реферер, аналізують UTM та ідентифікатори кліків з URL, а також починають ставити в чергу автоматично зафіксовані події: перегляди сторінок, кліки по елементах, взаємодії з формами, завантаження файлів та — у останніх версіях — відтворення сесій. Вони також збагачують ці події геолокацією на основі IP, даними про пристрій на основі user-agent, а якщо налаштовано — збагаченням від третіх сторін від партнерів з даних.

Кожен із цих кроків задіює окрему правову основу згоди. Зберігання ідентифікатора пристрою є операцією зберігання та доступу відповідно до Статті 5(3) Директиви ePrivacy, яка вимагає попередньої, вільно наданої, конкретної, поінформованої та однозначної згоди в Європейському економічному просторі, Великій Британії та будь-якій юрисдикції, яка застосувала той самий стандарт. Фіксування поведінкових подій, пов'язаних із цим ідентифікатором, є обробкою персональних даних відповідно до GDPR. Збагачення даними третіх сторін запроваджує другі відносини контролера. CCPA та CPRA класифікують ту саму обробку як продаж або обмін, якщо видавець не має належним чином обмеженого договору про надання послуг з Amplitude — який доступний, але лише якщо інтеграція налаштована на вимкнення рекламних функцій.

Що Amplitude збирає до отримання згоди — і що потрібно придушити

Найпоширенішою помилкою впровадження є ставлення до Amplitude як до легкого інструменту аналітики, що може працювати поряд із банером файлів cookie. Це неможливо. При типовому виклику amplitude.init() SDK під час першого рендерингу сторінки запише принаймні один файл cookie або запис у локальному сховищі, надішле виклик ідентифікації та почне буферизацію подій. Жодне з цього не є допустимим до того, як користувач підтвердить прийняття відповідної категорії згоди.

Тому сумісна інтеграція повинна відкладати amplitude.init() до тих пір, поки CMP не сигналізує про надання категорії згоди на аналітику. SDK взагалі не слід завантажувати з тегу <script>, захищеного згодою, який залежить від сигналу мети 8 (аналітика) або мети 1 (зберігання та доступ) CMP, залежно від того, який фреймворк надає CMP. Якщо SDK необхідно завантажити раніше — наприклад, тому що він об'єднаний у код додатка і не може бути отриманий відкладено — виклик ініціалізації повинен передавати defaultTracking: false та optOut: true, щоб жодні події не генерувалися до реєстрації згоди, а потім відкладена подія opt-in повинна перевернути ці прапорці.

Файли cookie та сховище, які записує Amplitude

Browser SDK 2.x за замовчуванням записує один файл cookie першої сторони з іменем AMP_{apiKey} з терміном дії один рік, що містить ідентифікатор пристрою та метадані сесії. Старіші версії також записували amplitude_id_{apiKey}. Мобільні SDK зберігають той самий ідентифікатор у захищеному сховищі програми. Відтворення сесії додає другий файл cookie, AMP_MKTG_{apiKey}, а партнери зі збагачення Amplitude можуть встановлювати додаткові файли cookie третіх сторін, якщо увімкнені модулі цільового спрямування експериментів або аудиторій. Усі вони є несуттєвими і потребують згоди.

Зіставлення Amplitude з фреймворками згоди

Amplitude не реалізує нативно Google Consent Mode v2, IAB TCF або IAB Global Privacy Platform. Це не вада — Amplitude є платформою аналітики першої сторони, а не постачальником рекламних технологій — але це означає, що відповідальність за інтеграцію лежить на видавці. Схема, яка працює на практиці, полягає в тому, щоб розглядати кожен модуль Amplitude як окремий шлюз згоди і прив'язувати його до конкретного сигналу, який вже надає CMP.

• Основні події аналітики прив'язані до мети аналітики. У термінах TCF це найчастіше мета 8 (вимірювання ефективності вмісту) у поєднанні з метою 1 (зберігання та/або доступ до інформації). Для Google Consent Mode це відповідає analytics_storage.
• Відтворення сесії повинно знаходитися за більш суворим сигналом. Відтворення фіксує відрендерений DOM, включаючи значення форм, якщо вони явно не замасковані, тому окремий opt-in preferences або functional є доцільним, а відтворення за замовчуванням має бути вимкнено навіть при наданні аналітики.
• Аудиторії, когорти та збагачення третіми сторонами прив'язані до маркетингової мети. У термінах TCF це мета 7 (вимірювання ефективності реклами) або мета 9 (застосування маркетингових досліджень). Для Google Consent Mode це відповідає ad_storage та ad_user_data.
• Експериментування — Amplitude Experiment може працювати з анонімним, ефемерним розподілом на основі законного інтересу, але постійний розподіл, прив'язаний до ідентифікатора користувача, потребує тієї самої згоди, що й основна аналітика.

Схема інтеграції, яка працює

Еталонна реалізація, яка витримує перевірку регулятора, має чотири рухомі частини: CMP, яка генерує подію в реальному часі, коли користувач змінює згоду; відкладений завантажувач SDK, який отримує Amplitude лише після того, як ця подія спрацьовує для відповідної категорії; захист на рівні сесії, який поважає відмову без втрати попереднього анонімного ідентифікатора пристрою користувача там, де це дозволяє закон; та серверний міст для подій, які дійсно потребують збору незалежно від згоди — наприклад, телеметрії безпеки або виявлення шахрайства — направлених через окрему кінцеву точку зі своєю власною правовою основою.

Веб-реалізація

У вебі найчистіша схема полягає в тому, щоб надати стан згоди CMP через об'єкт window.__cmp_consent або стандартний зворотний виклик __tcfapi, а потім мати невеликий bootstrap-скрипт, що підписується на зміни згоди. Коли аналітична згода перемикається з false на true, bootstrap отримує Amplitude SDK із CDN під управлінням CMP, викликає amplitude.init(apiKey, undefined, { defaultTracking: true }) та відтворює всі події, що стояли в черзі в пам'яті під час очікування згоди. Коли згода перемикається назад на false, bootstrap викликає amplitude.setOptOut(true), очищає файл cookie AMP_ через закінчення терміну дії document.cookie та видаляє будь-який стан у пам'яті. Критично важливо, що bootstrap ніколи не повинен ліниво ініціалізувати Amplitude в тому ж потоці запиту, що й рендеринг банера — SDK повинен чекати явного дозволу.

Мобільна реалізація

На iOS аналогом є збереження імпортованого фреймворку Amplitude, але відкладення Amplitude.instance().initialize(apiKey: apiKey) до тих пір, поки потік згоди у додатку не поверне позитивний аналітичний сигнал. Запит ATT є окремим питанням: ATT регулює IDFA, тоді як ідентифікатор Amplitude є власним UUID SDK, що зберігається в пісочниці програми. Обидва вимагають згоди в EEA, але правові основи та запити різні. На Android та сама логіка застосовується з Amplitude.getInstance().initializeApolloClient() або еквівалентом, залежно від версії SDK.

Серверний режим

Amplitude підтримує прийом даних на стороні сервера через HTTP V2 API. Серверні події не звільнені від згоди — правова основа слідує за даними, а не за транспортом — але серверний прийом дає видавцю повний контроль над тим, які поля надсилаються, що полегшує виконання часткової згоди. Поширена схема полягає в тому, щоб фіксувати мінімальний набір лише суттєвих подій на стороні сервера на основі законного інтересу, і лише збагачувати ці події поведінковими деталями після того, як користувач надав аналітичну згоду на клієнті.

Перевірка інтеграції

Крок перевірки — той, який видавці найчастіше пропускають, а регулятори найчастіше перевіряють. Правильно інтегроване розгортання Amplitude повинно пройти чотири перевірки. По-перше, браузер із відображеним банером згоди, але без зробленого вибору, повинен видавати нуль запитів до api.amplitude.com або api.eu.amplitude.com та нуль файлів cookie AMP_ у document.cookie. По-друге, відхилення категорії аналітики повинно зберігати цей стан — жодних подій, файлів cookie, записів у локальному сховищі з префіксом AMP_. По-третє, прийняття аналітики повинно видати один identify, за яким іде трафік подій, а файл cookie AMP_ повинен з'явитися з атрибутом SameSite, що відповідає політиці CMP видавця. По-четверте, відкликання згоди після факту повинно негайно припинити подальші події та очистити збережені ідентифікатори — затримане очищення є знахідкою.

Журнал аудиту важливий окремо. Відповідно до настанов EDPB 2023 щодо банерів файлів cookie та оновлених пріоритетів цільової групи на 2026 рік, регулятори очікують, що видавець зможе довести для будь-якої події в проекті Amplitude, що користувач, який її сформував, надав дійсну згоду на момент збору. Для цього необхідно, щоб журнал згоди CMP можна було запитати за ідентифікатором пристрою або ідентифікатором сесії, а корисне навантаження події Amplitude містило поле версії згоди, що пов'язується з цим журналом. Зберігання рядка згоди як власного властивості користувача в кожній події є найпростішим способом зробити це посилання перевіреним.

Вибір правильного регіону та місця зберігання даних

Amplitude підтримує два виробничих регіони: США (api.amplitude.com) та ЄС (api.eu.amplitude.com). Для трафіку EEA та Великої Британії регіон ЄС є правильним значенням за замовчуванням — він зберігає дані всередині EEA та зменшує поверхню ризику передачі, яку рішення Schrems II та Рамка захисту конфіденційності ЄС-США зробили центральною в будь-якому аналітичному огляді. Зміна регіонів не є зворотною: існуючі дані залишаються там, де були вперше прийняті. Для видавців, які планують впровадження CMP, тому варто підтвердити регіон перед масштабуванням і задокументувати вибір у повідомленні про конфіденційність, щоб ланцюг правових підстав був чистим від збору до зберігання. Правильно обраний регіон у поєднанні з правильно захищеним SDK та журналом згоди, що підлягає запиту, — це те, що перетворює розгортання Amplitude з регуляторного ризику на захищену частину аналітичного стеку.