De ce Amplitude necesită consimțământ

SDK-ul implicit Amplitude Browser și SDK-urile mobile Amplitude fac mult mai mult decât înregistrarea vizualizărilor de pagini. La inițializare, aceștia setează un identificator de dispozitiv în stocarea primei părți, generează un identificator de sesiune, capturează referrer-ul, analizează identificatorii UTM și de clic din URL și încep să pună în coadă evenimentele capturate automat: vizualizări de pagini, clicuri pe elemente, interacțiuni cu formulare, descărcări de fișiere și — în cele mai recente versiuni — reluări de sesiune. De asemenea, îmbogățesc aceste evenimente cu geolocalizare derivată din IP, date despre dispozitiv derivate din agentul utilizatorului și, dacă este configurat, îmbogățire de la terți de la parteneri de date.

Fiecare dintre acești pași angajează o bază legală separată pentru consimțământ. Stocarea unui identificator de dispozitiv este o operațiune de stocare și acces în temeiul articolului 5 alineatul (3) din Directiva ePrivacy, care necesită consimțământul prealabil, liber exprimat, specific, informat și neechivoc în Spațiul Economic European, Regatul Unit și orice jurisdicție care a importat același standard. Captarea evenimentelor comportamentale legate de acel identificator reprezintă prelucrarea datelor cu caracter personal în temeiul GDPR. Îmbogățirea cu date de la terți introduce o a doua relație de operator. CCPA și CPRA clasifică aceeași prelucrare ca o vânzare sau partajare dacă editorul nu are un contract cu furnizorul de servicii delimitat corect cu Amplitude — care este disponibil, dar numai dacă integrarea este configurată pentru a dezactiva funcțiile de publicitate.

Ce colectează Amplitude înainte de consimțământ — și ce trebuie să suprimați

Cea mai frecventă greșeală de implementare este tratarea Amplitude ca pe un instrument de analiză ușor care poate rula alături de bannerul de cookie-uri. Nu poate. La un apel implicit amplitude.init(), SDK-ul va scrie, în prima randare a paginii, cel puțin o intrare de cookie sau stocare locală, va trimite un apel identify și va începe să buffere evenimente. Nimic din toate acestea nu este permis înainte ca un utilizator să fi acceptat în mod afirmativ categoria de consimțământ relevantă.

O integrare conformă trebuie, prin urmare, să amâne amplitude.init() până când CMP a semnalat că a fost acordată categoria de consimțământ pentru analiză. SDK-ul nu ar trebui să fie încărcat deloc dintr-o etichetă <script> controlată de consimțământ care depinde de semnalul de scop 8 (analiză) sau de scop 1 (stocare și acces) al CMP, în funcție de cadrul pe care CMP îl expune. Dacă SDK-ul trebuie încărcat mai devreme — de exemplu, deoarece este inclus în codul aplicației și nu poate fi preluat în mod leneș — apelul de inițializare ar trebui să treacă defaultTracking: false și optOut: true astfel încât niciun eveniment să nu fie emis până când consimțământul este înregistrat, iar apoi un eveniment de opt-in amânat ar trebui să schimbe acele indicatoare.

Cookie-urile și stocarea pe care le scrie Amplitude

Browser SDK 2.x scrie implicit un singur cookie de prima parte numit AMP_{apiKey}, cu o expirare de un an, care conține identificatorul dispozitivului și metadatele sesiunii. Versiunile mai vechi au scris, de asemenea, amplitude_id_{apiKey}. SDK-urile mobile persistă același identificator în stocarea sandbox a aplicației. Reluarea sesiunii adaugă un al doilea cookie, AMP_MKTG_{apiKey}, și partenerii de îmbogățire ai Amplitude pot seta cookie-uri suplimentare de la terți dacă modulele de direcționare a experimentelor sau audiențe sunt activate. Toate acestea sunt neesențiale și necesită consimțământ.

Maparea Amplitude la cadrele de consimțământ

Amplitude nu implementează nativ Google Consent Mode v2, IAB TCF sau IAB Global Privacy Platform. Aceasta nu este un defect — Amplitude este o platformă de analiză a primei părți, nu un furnizor de tehnologie publicitară — dar înseamnă că responsabilitatea integrării revine editorului. Tiparul care funcționează în practică este să tratați fiecare modul Amplitude ca o poartă de consimțământ separată și să-l legați de un semnal specific pe care CMP îl expune deja.

• Evenimentele de analiză de bază se leagă de scopul analizei. În termenii TCF, acesta este cel mai frecvent scopul 8 (măsurarea performanței conținutului) combinat cu scopul 1 (stocarea și/sau accesarea informațiilor). Pentru Google Consent Mode, acesta se mapează la analytics_storage.
• Reluarea sesiunii ar trebui să se afle în spatele unui semnal mai strict. Reluarea captează DOM-ul randat, inclusiv valorile formularelor cu excepția cazului în care sunt mascate explicit, deci un opt-in separat pentru preferences sau functional este adecvat, iar reluarea ar trebui să fie implicit dezactivată chiar și atunci când analiza este acordată.
• Audiențele, cohortele și îmbogățirea de la terți se leagă de scopul de marketing. În termenii TCF, acesta este scopul 7 (măsurarea performanței anunțurilor) sau scopul 9 (aplicarea cercetării de piață). Pentru Google Consent Mode, acesta se mapează la ad_storage și ad_user_data.
• Experimentarea — Amplitude Experiment poate rula cu alocarea anonimă, efemeră sub o bază de interes legitim, dar alocarea persistentă legată de un identificator de utilizator necesită același consimțământ ca analiza de bază.

Tiparul de integrare care funcționează

Implementarea de referință care supraviețuiește examinării unui organism de reglementare are patru părți mobile: un CMP care expune un eveniment în timp real când utilizatorul schimbă consimțământul, un încărcător de SDK amânat care preia Amplitude numai după ce acel eveniment se declanșează pentru categoria relevantă, o gardă la nivel de sesiune care respectă opt-out-ul fără a pierde identificatorul anonim anterior al dispozitivului utilizatorului acolo unde legea permite și o punte pe server-side pentru evenimentele care necesită în mod real colectare indiferent de consimțământ — cum ar fi telemetria de securitate sau detectarea fraudei — dirijate printr-un endpoint separat cu propria bază legală.

Implementare web

Pe web, cel mai curat tipar este să expuneți starea de consimțământ a CMP printr-un obiect window.__cmp_consent sau callback-ul standard __tcfapi, apoi să aveți un mic script de bootstrap care să se aboneze la modificările de consimțământ. Când consimțământul pentru analiză trece de la false la true, bootstrap-ul preia SDK-ul Amplitude din CDN-ul gestionat de CMP, apelează amplitude.init(apiKey, undefined, { defaultTracking: true }) și redă orice evenimente care au fost puse în coadă în memorie în timp ce consimțământul era în așteptare. Când consimțământul revine la false, bootstrap-ul apelează amplitude.setOptOut(true), șterge cookie-ul AMP_ prin expirarea document.cookie și elimină orice stare din memorie. În mod critic, bootstrap-ul nu trebuie niciodată să inițializeze Amplitude în mod leneș în același flux de cerere ca randarea bannerului — SDK-ul trebuie să aștepte o acordare explicită.

Implementare mobilă

Pe iOS, echivalentul este să mențineți framework-ul Amplitude importat, dar să amânați Amplitude.instance().initialize(apiKey: apiKey) până când fluxul de consimțământ din aplicație a returnat un semnal de analiză pozitiv. Promptul ATT este o preocupare separată: ATT guvernează IDFA, în timp ce identificatorul Amplitude este UUID-ul propriu al SDK-ului stocat în sandbox-ul aplicației. Ambele necesită consimțământ în SEE, dar bazele legale și prompturile sunt distincte. Pe Android aceeași logică se aplică cu Amplitude.getInstance().initializeApolloClient() sau echivalentul în funcție de versiunea SDK.

Mod server-side

Amplitude suportă ingestia pe server-side prin HTTP V2 API. Evenimentele server-side nu sunt scutite de consimțământ — baza legală urmează datele, nu transportul — dar ingestia pe server-side oferă editorului control total asupra câmpurilor care sunt trimise, ceea ce facilitează respectarea consimțământului parțial. Un tipar comun este captarea unui set minim, doar de evenimente esențiale, pe server-side sub interes legitim și îmbogățirea acelor evenimente cu detalii comportamentale numai după ce utilizatorul a acordat consimțământul pentru analiză pe client.

Validarea integrării

Etapa de validare este cea pe care editorii o sar cel mai adesea și pe care organismele de reglementare o verifică cel mai adesea. O implementare Amplitude corect integrată ar trebui să treacă patru verificări. În primul rând, un browser cu bannerul de consimțământ afișat, dar fără alegere făcută, ar trebui să producă zero solicitări către api.amplitude.com sau api.eu.amplitude.com și zero cookie-uri AMP_ în document.cookie. În al doilea rând, refuzarea categoriei de analiză ar trebui să mențină acea stare — niciun eveniment, niciun cookie, nicio intrare de stocare locală cu prefix AMP_. În al treilea rând, acceptarea analizei ar trebui să producă un singur identify urmat de trafic de evenimente, iar cookie-ul AMP_ ar trebui să apară cu un atribut SameSite consistent cu politica CMP a editorului. În al patrulea rând, retragerea consimțământului după fapt ar trebui să oprească imediat alte evenimente și să șteargă identificatorii stocați — o curățare întârziată este o constatare.

Traseul de audit contează separat. Conform ghidurilor privind bannerul de cookie-uri ale EDPB din 2023 și prioritățile reînnoite ale grupului de lucru din 2026, organismele de reglementare se așteaptă ca editorul să poată dovedi, pentru orice eveniment dat în proiectul Amplitude, că utilizatorul care l-a generat a dat consimțământ valid în momentul capturii. Aceasta necesită ca jurnalul de consimțământ al CMP să fie interogabil prin identificatorul dispozitivului sau identificatorul sesiunii și ca sarcina utilă a evenimentului Amplitude să conțină un câmp de versiune a consimțământului care leagă înapoi la acel jurnal. Stocarea șirului de consimțământ ca proprietate personalizată a utilizatorului la fiecare eveniment este cel mai simplu mod de a face acea legătură auditabilă.

Alegerea regiunii potrivite și a rezidențialității datelor

Amplitude operează două regiuni de producție: SUA (api.amplitude.com) și UE (api.eu.amplitude.com). Pentru traficul SEE și Regatul Unit, regiunea UE este valoarea implicită corectă — păstrează datele în interiorul SEE și reduce suprafața de risc a transferului pe care decizia Schrems II și Cadrul de confidențialitate a datelor UE-SUA le-au plasat central pentru orice examinare a analizei. Schimbarea regiunilor nu este retroactivă: datele existente rămân acolo unde au fost ingerate pentru prima dată. Pentru editorii care planifică un lansare CMP, merită astfel confirmat regiunea înainte de scalare și merită documentată alegerea în notificarea de confidențialitate, astfel încât lanțul bazei legale să fie clar de la colectare la stocare. O regiune aleasă corect, combinată cu un SDK controlat corect și un jurnal de consimțământ interogabil, este ceea ce transformă o implementare Amplitude dintr-un risc de reglementare într-o parte justificabilă a stivei de analiză.