Почему Amplitude требует согласия

Браузерный SDK Amplitude по умолчанию и мобильные SDK Amplitude делают гораздо больше, чем запись просмотров страниц. При инициализации они устанавливают идентификатор устройства в первичном хранилище, генерируют идентификатор сессии, захватывают реферер, парсят параметры UTM и идентификаторы кликов из URL и начинают ставить в очередь автоматически захваченные события: просмотры страниц, клики по элементам, взаимодействия с формами, загрузки файлов и — в последних релизах — записи сессий. Они также обогащают эти события геолокацией на основе IP, данными устройства на основе user-agent и, если настроено, обогащением третьих сторон от партнёров по данным.

Каждый из этих шагов задействует отдельную правовую основу согласия. Хранение идентификатора устройства — это операция хранения и доступа по статье 5(3) Директивы ePrivacy, которая требует предварительного, свободно данного, конкретного, информированного и недвусмысленного согласия в Европейской экономической зоне, Великобритании и любой юрисдикции, которая импортировала тот же стандарт. Захват поведенческих событий, привязанных к этому идентификатору, является обработкой персональных данных по GDPR. Обогащение данными третьих сторон вводит вторые отношения контролёра. CCPA и CPRA классифицируют ту же обработку как продажу или передачу, если издатель не имеет должным образом ограниченного договора поставщика услуг с Amplitude — который доступен, но только если интеграция настроена на отключение рекламных функций.

Что Amplitude собирает до согласия — и что вы должны подавить

Самая распространённая ошибка внедрения — рассматривать Amplitude как лёгкий инструмент аналитики, который может работать рядом с баннером cookie. Это невозможно. При вызове amplitude.init() по умолчанию SDK в течение первой отрисовки страницы запишет как минимум один cookie или запись локального хранилища, отправит вызов identify и начнёт буферизацию событий. Ничто из этого не допустимо до того, как пользователь утвердительно принял соответствующую категорию согласия.

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

Cookie и хранилище, которые записывает Amplitude

Браузерный 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 является первичной аналитической платформой, а не ad-tech-поставщиком — но это означает, что ответственность за интеграцию ложится на издателя. Шаблон, который работает на практике, — рассматривать каждый модуль 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 только после срабатывания этого события для соответствующей категории, защиту на уровне сессии, которая уважает opt-out, не теряя предыдущий анонимный идентификатор устройства пользователя там, где это разрешает закон, и серверный мост для событий, которые действительно требуют сбора независимо от согласия — таких как телеметрия безопасности или обнаружение мошенничества — маршрутизируемых через отдельную конечную точку с собственной правовой основой.

Веб-внедрение

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

Мобильное внедрение

На iOS эквивалент — держать фреймворк Amplitude импортированным, но отложить Amplitude.instance().initialize(apiKey: apiKey) до тех пор, пока внутриприложенный поток согласия не вернёт положительный сигнал аналитики. Запрос ATT — это отдельная проблема: ATT управляет IDFA, тогда как идентификатор Amplitude — это собственный UUID SDK, хранящийся в песочнице приложения. Оба требуют согласия в ЕЭЗ, но правовые основы и запросы различны. На 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 по баннерам cookie 2023 года и обновлённым приоритетам рабочей группы 2026 года регуляторы ожидают, что издатель сможет доказать для любого данного события в проекте Amplitude, что пользователь, который его сгенерировал, дал действительное согласие в момент захвата. Это требует, чтобы журнал согласия CMP можно было запросить по идентификатору устройства или идентификатору сессии, а полезная нагрузка события Amplitude несла поле версии согласия, которое связывается обратно с этим журналом. Хранение строки согласия как пользовательского свойства на каждом событии — самый простой способ сделать эту связь проверяемой.

Выбор правильного региона и резидентности данных

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