Zašto Amplitude zahtijeva pristanak

Zadani Amplitude Browser SDK i Amplitude mobilni SDK-ovi rade mnogo više od pukog bilježenja pregleda stranica. Pri inicijalizaciji postavljaju identifikator uređaja u pohrani prve strane, generiraju identifikator sesije, bilježe referer, raščlanjuju UTM i identifikatore klikova iz URL-a te počinju stavljati u red automatski snimljene događaje: preglede stranica, klikove na elemente, interakcije s obrascem, preuzimanje datoteka i — u najnovijim izdanjima — snimke sesija. Oni također obogaćuju te događaje geolokacijom izvedenom iz IP-a, podacima o uređaju izvedenim iz user-agenta i, ako je konfigurirano, obogaćivanjem trećih strana od partnera za podatke.

Svaki od tih koraka uključuje zasebnu pravnu osnovu pristanka. Pohrana identifikatora uređaja operacija je pohrane i pristupa prema članku 5(3) Direktive ePrivacy, koja zahtijeva prethodni, slobodno dani, specifični, informirani i nedvosmisleni pristanak u Europskom gospodarskom prostoru, Ujedinjenom Kraljevstvu i svakoj jurisdikciji koja je uvezla isti standard. Bilježenje bihevioralnih događaja vezanih uz taj identifikator je obrada osobnih podataka prema GDPR-u. Obogaćivanje podacima trećih strana uvodi drugi odnos kontrolora. CCPA i CPRA klasificiraju istu obradu kao prodaju ili dijeljenje osim ako izdavač nema propisno definiran ugovor o pružatelju usluge s Amplitudeom — koji je dostupan, ali samo ako je integracija konfigurirana da onemogući reklamne značajke.

Što Amplitude prikuplja prije pristanka — i što morate suzbiti

Najčešća greška pri implementaciji je tretiranje Amplitudea kao laganog analitičkog alata koji može raditi uz kolačić-banner. Ne može. Na zadani amplitude.init() poziv, SDK će, unutar prvog renderiranja stranice, zapisati barem jedan kolačić ili stavku lokalnog pohraništa, poslati identify poziv i početi bafovati događaje. Ništa od toga nije dopušteno prije nego što je korisnik afirmativno prihvatio relevantnu kategoriju pristanka.

Usklađena integracija stoga mora odgoditi amplitude.init() dok CMP nije signalizirao da je kategorija pristanka za analitiku odobrena. SDK se ne smije učitavati ni iz pristankom ograničene oznake <script> koja ovisi o signalu svrhe 8 (analitika) ili svrhe 1 (pohrana i pristup) CMP-a, ovisno o tome koji okvir CMP izlaže. Ako se SDK mora učitati ranije — na primjer jer je spojen u kod aplikacije i ne može se lijeno dohvatiti — inicijalizacijski poziv trebao bi proslijediti defaultTracking: false i optOut: true kako se ne bi emitirali događaji dok se ne zabilježi pristanak, a zatim bi odgođeni opt-in događaj trebao prebaciti te zastavice.

Kolačići i pohrana koje Amplitude zapisuje

Browser SDK 2.x po zadanom zapisuje jedan kolačić prve strane pod nazivom AMP_{apiKey}, s rokom isteka od jedne godine, koji sadrži identifikator uređaja i metapodatke sesije. Starije verzije zapisivale su i amplitude_id_{apiKey}. Mobilni SDK-ovi pohranjuju isti identifikator unutar sandbox pohrane aplikacije. Snimanje sesije dodaje drugi kolačić, AMP_MKTG_{apiKey}, a Amplitudeovi partneri za obogaćivanje mogu postaviti dodatne kolačiće trećih strana ako su omogućeni moduli za ciljanje eksperimenata ili publike. Sve su ovo nebitne i zahtijevaju pristanak.

Mapiranje Amplitudea na okvire pristanka

Amplitude izvorno ne implementira Google Consent Mode v2, IAB TCF niti IAB Global Privacy Platform. To nije nedostatak — Amplitude je platforma za analitiku prve strane, a ne prodavač ad-tech tehnologije — ali znači da odgovornost za integraciju leži na izdavaču. Obrazac koji funkcionira u praksi jest tretirati svaki Amplitudeov modul kao zasebnu kapiju pristanka i vezati ga uz specifični signal koji CMP već izlaže.

• Temeljni analitički događaji vežu se za svrhu analitike. U terminima TCF-a to je najčešće svrha 8 (mjerenje performansi sadržaja) u kombinaciji sa svrhom 1 (pohrana i/ili pristup informacijama). Za Google Consent Mode ovo se mapira na analytics_storage.
• Snimanje sesije trebalo bi biti iza striktnijeg signala. Snimanje bilježi renderirani DOM, uključujući vrijednosti obrasca osim ako nisu eksplicitno maskirane, pa je prikladan zasebni opt-in za preferences ili functional, a snimanje bi trebalo biti zadano isključeno čak i kada je analitika odobrena.
• Publike, kohorti i obogaćivanje trećih strana vežu se za marketinšku svrhu. U terminima TCF-a to je svrha 7 (mjerenje performansi oglasa) ili svrha 9 (primjena istraživanja tržišta). Za Google Consent Mode ovo se mapira na ad_storage i ad_user_data.
• Eksperimentiranje — Amplitude Experiment može raditi s anonimnom, efemeralnom alokacijom na temelju legitimnog interesa, ali trajna alokacija vezana uz identifikator korisnika zahtijeva isti pristanak kao i osnovna analitika.

Obrazac integracije koji funkcionira

Referentna implementacija koja preživljava regulatorovu provjeru ima četiri pokretna dijela: CMP koji izlaže događaj u stvarnom vremenu kada korisnik mijenja pristanak, odgođeni SDK učitavač koji dohvaća Amplitude samo nakon što se taj događaj aktivira za relevantnu kategoriju, čuvar na razini sesije koji poštuje opt-out bez gubitka prethodnog anonimnog identifikatora uređaja korisnika gdje to zakon dopušta, i most na strani poslužitelja za događaje koji zaista zahtijevaju prikupljanje bez obzira na pristanak — poput sigurnosne telemetrije ili otkrivanja prijevara — preusmjeren kroz zasebnu krajnju točku s vlastitom pravnom osnovom.

Web implementacija

Na webu, najčišći obrazac je izlaganje stanja pristanka CMP-a putem objekta window.__cmp_consent ili standardnog __tcfapi povratnog poziva, a zatim imati mali bootstrap skript koji se pretplaćuje na promjene pristanka. Kada se pristanak za analitiku prebaci s false na true, bootstrap dohvaća Amplitude SDK s CDN-a kojim upravlja CMP, poziva amplitude.init(apiKey, undefined, { defaultTracking: true }) i reproducira sve događaje koji su bili u redu u memoriji dok je pristanak bio na čekanju. Kada se pristanak vrati na false, bootstrap poziva amplitude.setOptOut(true), briše AMP_ kolačić putem isteka document.cookie i uklanja svako stanje u memoriji. Kritično, bootstrap nikada ne smije lijeno inicijalizirati Amplitude u istom tijeku zahtjeva kao i renderiranje bannera — SDK mora čekati eksplicitno odobrenje.

Mobilna implementacija

Na iOS-u ekvivalent je zadržati Amplitude framework uvezenim ali odgoditi Amplitude.instance().initialize(apiKey: apiKey) dok tok pristanka unutar aplikacije nije vratio pozitivan signal analitike. Prompt ATT zasebna je briga: ATT upravlja IDFA-om, dok je identifikator Amplitudea vlastiti UUID SDK-a pohranjen u sandbox aplikacije. Oba zahtijevaju pristanak u EGP-u, ali pravne osnove i promptovi su zasebni. Na Androidu ista logika primjenjuje se s Amplitude.getInstance().initializeApolloClient() ili ekvivalentom ovisno o verziji SDK-a.

Način rada na strani poslužitelja

Amplitude podržava unos na strani poslužitelja putem HTTP V2 API-ja. Događaji na strani poslužitelja nisu izuzeti od pristanka — pravna osnova prati podatke, ne transport — ali unos na strani poslužitelja daje izdavaču potpunu kontrolu nad tim koji se podaci šalju, što olakšava poštivanje djelomičnog pristanka. Uobičajen obrazac je bilježenje minimalnog skupa samo bitnih događaja na strani poslužitelja na temelju legitimnog interesa, i obogaćivanje tih događaja ponašanjem tek nakon što je korisnik dao pristanak za analitiku na strani klijenta.

Provjera valjanosti integracije

Korak provjere valjanosti onaj je koji izdavači najčešće preskakuju i koji regulatori najčešće provjeravaju. Ispravno integrirana Amplitudeova implementacija trebala bi proći četiri provjere. Prvo, preglednik s prikazanim kolačić-bannerom ali bez napravljenog izbora trebao bi producirati nula zahtjeva prema api.amplitude.com ili api.eu.amplitude.com i nula AMP_ kolačića u document.cookie. Drugo, odbijanje kategorije analitike trebalo bi zadržati to stanje — bez događaja, bez kolačića, bez stavki lokalnog pohraništa s prefiksom AMP_. Treće, prihvaćanje analitike trebalo bi producirati jedan identify praćen prometom događaja, a kolačić AMP_ trebao bi se pojaviti s atributom SameSite konzistentnim s CMP pravilnikom izdavača. Četvrto, naknadno povlačenje pristanka trebalo bi odmah zaustaviti daljnje događaje i obrisati pohranjene identifikatore — odgođeno čišćenje je nalaz.

Revizijski trag zasebno je važan. Prema EDPB-ovim smjernicama o kolačić-bannerima iz 2023. i obnovljenim prioritetima radne skupine za 2026., regulatori očekuju da izdavač može dokazati, za bilo koji dani događaj u Amplitudeovom projektu, da je korisnik koji ga je generirao dao valjani pristanak u trenutku bilježenja. To zahtijeva da revizijski zapis pristanka CMP-a bude upitljiv prema identifikatoru uređaja ili identifikatoru sesije, te da korisni teret događaja Amplitudea nosi polje verzije pristanka koje se veže uz taj zapis. Pohrana niza pristanka kao prilagođenog korisničkog svojstva na svakom događaju najjednostavniji je način da se ta veza učini revizijskom.

Odabir pravog regije i pohrane podataka

Amplitude upravlja s dvije produkcijske regije: SAD (api.amplitude.com) i EU (api.eu.amplitude.com). Za promet EGP-a i UK-a EU regija je pravi zadani odabir — čuva podatke unutar EGP-a i smanjuje površinu rizika prijenosa koju su presuda Schrems II i EU-US Data Privacy Framework stavili u središte svake analitičke provjere. Mijenjanje regija nije retroaktivno: postojeći podaci ostaju tamo gdje su prvi put uneseni. Za izdavače koji planiraju uvođenje CMP-a stoga se isplati potvrditi regiju prije skaliranja i dokumentirati odabir u obavijesti o privatnosti kako bi lanac pravne osnove bio čist od prikupljanja do pohrane. Ispravno odabrana regija, u paru s ispravno ograđenim SDK-om i upitljivim revizijskim zapisom pristanka, ono je što Amplitudeov uvod pretvara od regulatornog rizika u obranjivi dio analitičkog skupa.