Защо Amplitude изисква съгласие

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

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

Какво събира Amplitude преди съгласие — и какво трябва да потиснете

Най-честата грешка при внедряване е третирането на Amplitude като лек инструмент за аналитика, който може да работи наред с банера за бисквитки. Не може. При стандартно повикване на amplitude.init() SDK ще напише поне един запис на бисквитка или локално хранилище в рамките на първото рисуване на страницата, ще изпрати повикване за идентификация и ще започне буферирането на събития. Нищо от това не е допустимо, преди потребителят да е приел утвърдително съответната категория съгласие.

Следователно съответстващата интеграция трябва да забави amplitude.init(), докато CMP сигнализира, че категорията за аналитично съгласие е предоставена. SDK изобщо не трябва да се зарежда от таг <script>, ограден от съгласие, който зависи от сигнала за цел 8 (аналитика) или цел 1 (съхранение и достъп) на CMP, в зависимост от това кой framework излага CMP. Ако SDK трябва да се зареди по-рано — например защото е включен в кода на приложението и не може да бъде изтеглен мързеливо — повикването за инициализация трябва да предаде defaultTracking: false и optOut: true, така че никакви събития да не се изпращат, докато не бъде записано съгласие, и след това отложено събитие за включване трябва да обърне тези флагове.

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

Browser SDK 2.x записва по подразбиране единична бисквитка от първа страна с име AMP_{apiKey}, с едногодишен срок на изтичане, съдържаща идентификатора на устройството и метаданните на сесията. По-старите версии са записвали и amplitude_id_{apiKey}. Мобилните SDK-та запазват същия идентификатор в изолираното хранилище на приложението. Записът на сесия добавя втора бисквитка, AMP_MKTG_{apiKey}, а партньорите за обогатяване на Amplitude могат да задават допълнителни бисквитки от трети страни, ако са активирани модулите за целево насочване при експерименти или аудитории. Всички те не са основни и изискват съгласие.

Картографиране на Amplitude към frameworks за съгласие

Amplitude не прилага native Google Consent Mode v2, IAB TCF или IAB Global Privacy Platform. Това не е дефект — Amplitude е платформа за аналитика от първа страна, а не доставчик на рекламни технологии — но означава, че отговорността за интеграция се пада на издателя. Шаблонът, който работи на практика, е третирането на всеки модул на Amplitude като отделна порта за съгласие и обвързването му с конкретен сигнал, вече излаган от CMP.

• Основните аналитични събития се обвързват с аналитичната цел. В термините на TCF това най-често е цел 8 (измерване на ефективността на съдържанието) в комбинация с цел 1 (съхранение и/или достъп до информация). За Google Consent Mode това съответства на analytics_storage.
• Записът на сесия трябва да се намира зад по-строг сигнал. Записът улавя рендирания DOM, включително стойностите на формуляри, освен ако изрично не са маскирани, така че отделното включване за 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), изчиства бисквитката AMP_ чрез изтичане на document.cookie и премахва всяко вътрешно-паметово състояние. Критично е, че bootstrap-ът никога не трябва да инициализира мързеливо Amplitude в същия поток на заявката като рендирането на банера — SDK трябва да изчака изрично предоставяне.

Мобилно внедряване

На iOS еквивалентното е да се запази импортираният Amplitude framework, но да се отложи 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 и нула бисквитки AMP_ в document.cookie. Второ, отхвърлянето на категорията за аналитика трябва да запази това състояние — никакви събития, никакви бисквитки, никакви записи в локалното хранилище с префикс AMP_. Трето, приемането на аналитика трябва да произведе единичен identify последван от трафик на събития, а бисквитката AMP_ трябва да се появи с атрибут SameSite, съответстващ на политиката на CMP на издателя. Четвърто, оттеглянето на съгласие след факта трябва незабавно да спре по-нататъшните събития и да изчисти съхранените идентификатори — забавеното почистване е констатация.

Одитната следа е от значение отделно. Съгласно насоките за банери за бисквитки на EDPB от 2023 г. и обновените приоритети на работната група за 2026 г., регулаторите очакват издателят да може да докаже за всяко дадено събитие в проекта Amplitude, че потребителят, генерирал го, е дал валидно съгласие в момента на улавяне. Това изисква журналът за съгласие на CMP да може да се заявява по идентификатор на устройство или идентификатор на сесия, а полезният товар на събитието на Amplitude да носи поле за версия на съгласие, което се свързва обратно с този журнал. Съхраняването на низа за съгласие като персонализирано потребителско свойство при всяко събитие е най-простият начин да се направи тази връзка одитируема.

Избиране на правилния регион и резидентност на данните

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