Зашто Amplitude захтева сагласност

Подразумевани Amplitude Browser SDK и Amplitude мобилни SDK-ови раде много више од бележења приказа страница. При иницијализацији постављају идентификатор уређаја у складиштење прве стране, генеришу идентификатор сесије, хватају упућивача, рашчлањују UTM и идентификаторе кликова из URL-а, и почињу да ставе у ред аутоматски снимљене догађаје: прикази страница, кликови на елементе, интеракције са формуларима, преузимања датотека и — у најновијим издањима — снимци сесија. Такође ће обогатити те догађаје геолоцирањем изведеним из IP адресе, подацима о уређају изведеним из корисничког агента, и, ако је конфигурисано, обогаћивањем трећих страна од партнера за податке.

Сваки од тих корака ангажује засебну правну основу за сагласност. Чување идентификатора уређаја је операција складиштења и приступа под чланом 5(3) Директиве ePrivacy, која захтева претходну, слободно дату, специфичну, информисану и недвосмислену сагласност у Европском економском простору, Уједињеном Краљевству и свакој јурисдикцији која је усвојила исти стандард. Снимање бихевиоралних догађаја везаних за тај идентификатор је обрада личних података под GDPR. Обогаћивање подацима трећих страна уводи другу контролорску везу. CCPA и CPRA класификују исту обраду као продају или дељење осим ако издавач нема правилно ограничен уговор са пружаоцем услуга са Amplitude — који је доступан, али само ако је интеграција конфигурисана да онемогући огласне функције.

Шта Amplitude прикупља пре сагласности — и шта морате да сузбијете

Најчешћа грешка у имплементацији је третирање Amplitude-а као лагани алат за аналитику који може да ради упоредо са банером за колачиће. Не може. При подразумеваном позиву amplitude.init() SDK ће, у оквиру првог приказа странице, написати барем један колачић или унос у локално складиштење, послати позив за идентификацију, и почети да пуферује догађаје. Ништа од тога није дозвољено пре него што корисник потврдно прихвати одговарајућу категорију сагласности.

Стога комплијантна интеграција мора одложити amplitude.init() све до тренутка када CMP сигнализира да је категорија сагласности за аналитику одобрена. SDK се уопште не сме учитати из тага <script> контролисаног сагласношћу који зависи од сигнала сврхе 8 (аналитика) или сврхе 1 (складиштење и приступ) CMP-а, зависно од тога који оквир CMP излаже. Ако SDK мора бити учитан раније — на пример јер је уграђен у код апликације и не може бити лениво преузет — позив за иницијализацију треба да прослеђује defaultTracking: false и optOut: true тако да се ниједан догађај не емитује све до записивања сагласности, а затим одложени догађај пријаве треба да преврне те заставице.

Колачићи и складиштење које Amplitude записује

Browser SDK 2.x по подразумеваним поставкама записује један колачић прве стране под именом AMP_{apiKey}, са годишњим истеком, који садржи идентификатор уређаја и метаподатке сесије. Старије верзије су такође записивале amplitude_id_{apiKey}. Мобилни SDK-ови чувају исти идентификатор унутар заштићеног складиштења апликације. Снимање сесија додаје други колачић, AMP_MKTG_{apiKey}, а партнери за обогаћивање Amplitude-а могу поставити додатне колачиће трећих страна ако су омогућени модули за циљање експеримената или публике. Сви они нису суштински и захтевају сагласност.

Мапирање Amplitude-а на оквире за сагласност

Amplitude нативно не имплементира 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 повратног позива, а затим имати мали бутстреп скрипт претплаћен на промене сагласности. Када сагласност за аналитику пређе из false у true, бутстреп преузима Amplitude SDK са CDN-а управљаног CMP-ом, позива amplitude.init(apiKey, undefined, { defaultTracking: true }), и поново репродукује све догађаје стављене у ред у меморији током чекања на сагласност. Када сагласност поново пређе у false, бутстреп позива amplitude.setOptOut(true), брише AMP_ колачић преко истека document.cookie, и уклања сво стање из меморије. Пресудно је да бутстреп никада не сме лениво да иницијализује Amplitude у истом захтеву потока као приказивање банера — SDK мора чекати на експлицитно одобрење.

Мобилна имплементација

На iOS-у еквивалент је задржавање увезеног Amplitude оквира али одлагање Amplitude.instance().initialize(apiKey: apiKey) све до тренутка када ток сагласности у апликацији врати позитиван сигнал за аналитику. ATT захтев је засебна брига: ATT управља IDFA, док је Amplitude-ов идентификатор UUID самог SDK-а сачуван у заштићеном складишту апликације. Обоје захтевају сагласност у EEA, али правне основе и упити су различити. На Androidu иста логика важи са 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). За EEA и УК саобраћај, ЕУ регион је прави подразумевани — задржава податке унутар EEA и смањује површину ризика преноса коју је одлука Schrems II и Оквир за заштиту података ЕУ-САД учинили централном у свакој аналитичкој ревизији. Промена региона није ретроактивна: постојећи подаци остају тамо где су први пут уноси. За издаваче који планирају увођење CMP-а, вреди стога потврдити регион пре скалирања и документовати избор у обавештењу о приватности тако да ланац правне основе буде чист од прикупљања до складиштења. Правилно одабран регион, упарен са правилно контролисаним SDK-ом и упитивим евиденцијским дневником сагласности, јесте оно што претвара Amplitude постављање из регулаторног ризика у применљив део аналитичког скупа.