Kāpēc Amplitude pieprasa piekrišanu

Noklusējuma Amplitude Browser SDK un Amplitude mobilie SDK dara daudz vairāk nekā reģistrē lapas skatījumus. Inicializācijas laikā tie iestatīs ierīces identifikatoru pirmās puses krātuvē, ģenerēs sesijas identifikatoru, fiksēs atsauci, parsēs UTM un klikšķu identifikatorus no URL, un sāks ierindot automātiski uztvertus notikumus: lapas skatījumus, elementu klikšķus, veidlapu mijiedarbības, failu lejupielādes un — jaunākajos izlaidumos — sesiju atskaņojumus. Tie arī papildinās šos notikumus ar IP iegūtu ģeolokāciju, lietotāja aģenta iegūtiem ierīces datiem un, ja konfigurēts, trešās puses papildināšanu no datu partneriem.

Katrs no šiem soļiem iesaista atsevišķu piekrišanas juridisko pamatu. Ierīces identifikatora glabāšana ir krātuves un piekļuves darbība saskaņā ar ePrivacy direktīvas 5. panta 3. punktu, kas Eiropas Ekonomikas zonā, Apvienotajā Karalistē un jebkurā jurisdikcijā, kas ir importējusi to pašu standartu, prasa iepriekšēju, brīvi sniegtu, specifisku, informētu un nepārprotamu piekrišanu. Uzvedības notikumu fiksēšana, kas saistīta ar šo identifikatoru, ir personas datu apstrāde saskaņā ar GDPR. Papildināšana ar trešās puses datiem ievieš otru pārzinis attiecības. CCPA un CPRA klasificē to pašu apstrādi kā pārdošanu vai koplietošanu, ja vien izdevējam nav pienācīgi izveidots pakalpojumu sniedzēja līgums ar Amplitude — kas ir pieejams, bet tikai tad, ja integrācija ir konfigurēta, lai atspējotu reklāmas funkcijas.

Ko Amplitude vāc pirms piekrišanas — un kas jāapspiež

Visbiežākā ieviešanas kļūda ir uzskatīt Amplitude par vieglu analītikas rīku, kas var darboties paralēli sīkfailu banerim. Tas nevar. Ar noklusējuma amplitude.init() izsaukumu SDK, lapas pirmajā renderēšanā, ierakstīs vismaz vienu sīkfailu vai vietējās krātuves ierakstu, nosūtīs identify izsaukumu un sāks notikumu buferēšanu. Nekas no tā nav atļauts pirms lietotājs nav noteikti akceptējis attiecīgo piekrišanas kategoriju.

Tādēļ atbilstīga integrācija ir jāatliek amplitude.init(), līdz CMP ir signalizējis, ka analītikas piekrišanas kategorija ir piešķirta. SDK nevajadzētu ielādēt vispār no piekrišanas atkarīga <script> taga, kas ir atkarīgs no CMP 8. mērķa (analītika) vai 1. mērķa (krātuves un piekļuves) signāla, atkarībā no tā, kuru sistēmu CMP atklāj. Ja SDK ir jāielādē agrāk — piemēram, tāpēc, ka tas ir iekļauts lietojumprogrammas kodā un nevar tikt ielādēts slinki — inicializācijas izsaukumam jānodod defaultTracking: false un optOut: true, lai neviens notikums netiktu emitēts, līdz piekrišana ir reģistrēta, un pēc tam atlikts opt-in notikums mainīs šos karodziņus.

Sīkfaili un krātuve, ko raksta Amplitude

Browser SDK 2.x raksta vienu pirmās puses sīkfailu ar nosaukumu AMP_{apiKey} pēc noklusējuma, ar viena gada derīguma termiņu, kas satur ierīces identifikatoru un sesijas metadatus. Vecākas versijas arī rakstīja amplitude_id_{apiKey}. Mobilās SDK saglabā to pašu identifikatoru lietojumprogrammas smilšu kastē. Sesiju atskaņojums pievieno otro sīkfailu, AMP_MKTG_{apiKey}, un Amplitude papildināšanas partneri var iestatīt papildu trešās puses sīkfailus, ja eksperimenta mērķēšanas vai auditorijas moduļi ir iespējoti. Visi tie ir nebūtiski un prasa piekrišanu.

Amplitude kartēšana uz piekrišanas ietvariem

Amplitude nativitāti neievieš Google Consent Mode v2, IAB TCF vai IAB Global Privacy Platform. Tas nav defekts — Amplitude ir pirmās puses analītikas platforma, nevis reklāmas tehnoloģijas pārdevējs — bet tas nozīmē, ka integrācijas atbildība gulstas uz izdevēju. Modelis, kas praksē darbojas, ir aplūkot katru Amplitude moduli kā atsevišķu piekrišanas vārtu un saistīt to ar konkrētu signālu, ko CMP jau atklāj.

• Galvenie analītikas notikumi ir saistīti ar analītikas mērķi. TCF izteiksmē tas visbiežāk ir 8. mērķis (mērīt satura veiktspēju) kopā ar 1. mērķi (saglabāt un/vai piekļūt informācijai). Google Consent Mode tas atbilst analytics_storage.
• Sesiju atskaņojumam jābūt aiz stingrāka signāla. Atskaņojums fiksē renderēto DOM, tostarp veidlapu vērtības, ja vien nav skaidri maskētas, tāpēc ir atbilstoša atsevišķa preferences vai functional opt-in, un atskaņojumam pēc noklusējuma jābūt izslēgtam pat tad, kad analītika ir piešķirta.
• Auditorijas, kohortas un trešās puses papildināšana ir saistītas ar mārketinga mērķi. TCF izteiksmē tas ir 7. mērķis (mērīt reklāmas veiktspēju) vai 9. mērķis (piemērot tirgus izpēti). Google Consent Mode tas atbilst ad_storage un ad_user_data.
• Eksperimentēšana — Amplitude Experiment var darboties ar anonīmu, īslaicīgu piešķiršanu uz leģitīmo interešu pamata, bet pastāvīga piešķiršana, kas saistīta ar lietotāja identifikatoru, prasa to pašu piekrišanu kā galvenā analītika.

Integrācijas modelis, kas darbojas

Atsauces ieviešanai, kas iztur regulatora pārbaudi, ir četras mainīgas daļas: CMP, kas atklāj reāllaika notikumu, kad lietotājs maina piekrišanu, atlikts SDK ielādētājs, kas ielādē Amplitude tikai pēc šī notikuma aktivizēšanas attiecīgajai kategorijai, sesijas līmeņa aizsargs, kas ievēro opt-out, nezaudējot lietotāja iepriekšējo anonīmo ierīces identifikatoru, kur to atļauj likums, un servera puses tilts notikumiem, kuriem tiešām nepieciešama vākšana neatkarīgi no piekrišanas — piemēram, drošības telemetrija vai krāpšanas atklāšana — maršrutēti caur atsevišķu galapunktu ar savu juridisko pamatu.

Tīmekļa ieviešana

Tīmeklī tīrākais modelis ir atklāt CMP piekrišanas stāvokli caur window.__cmp_consent objektu vai standarta __tcfapi atzvanu, tad likt mazam bootstrap skriptam abonēt piekrišanas izmaiņas. Kad analītikas piekrišana mainās no false uz true, bootstrap ielādē Amplitude SDK no CMP pārvaldīta CDN, izsauc amplitude.init(apiKey, undefined, { defaultTracking: true }) un atkārtoti atskaņo visus notikumus, kas tika ierindoti atmiņā, kamēr piekrišana bija gaida. Kad piekrišana mainās atpakaļ uz false, bootstrap izsauc amplitude.setOptOut(true), notīra AMP_ sīkfailu caur document.cookie derīguma termiņu un noņem jebkādu atmiņas stāvokli. Būtiski, bootstrap nekad nedrīkst slinki inicializēt Amplitude tajā pašā pieprasījumu plūsmā kā banera renderēšana — SDK ir jāgaida uz skaidru atļauju.

Mobilā ieviešana

iOS ekvivalents ir saglabāt Amplitude ietvaru importētu, bet atlikt Amplitude.instance().initialize(apiKey: apiKey), līdz lietotnes piekrišanas plūsma ir atgriezusi pozitīvu analītikas signālu. ATT uzvedne ir atsevišķs jautājums: ATT pārvalda IDFA, savukārt Amplitude identifikators ir SDK pats UUID, kas tiek glabāts lietotnes smilšu kastē. Abi prasa piekrišanu EEA, bet juridiskie pamati un uzvednes ir atšķirīgas. Android tā pati loģika attiecas ar Amplitude.getInstance().initializeApolloClient() vai ekvivalentu atkarībā no SDK versijas.

Servera puses režīms

Amplitude atbalsta servera puses uzņemšanu caur HTTP V2 API. Servera puses notikumi nav atbrīvoti no piekrišanas — juridiskais pamats seko datiem, nevis transportam — bet servera puses uzņemšana dod izdevējam pilnu kontroli pār to, kuri lauki tiek sūtīti, kas atvieglo daļējas piekrišanas ievērošanu. Izplatīts modelis ir uztvert minimālu, tikai būtisku notikumu kopu servera pusē uz leģitīmo interešu pamata, un bagātināt šos notikumus ar uzvedības detaļām tikai pēc tam, kad lietotājs ir piešķīris analītikas piekrišanu klientā.

Integrācijas validēšana

Validēšanas solis ir tas, ko izdevēji visbiežāk izlaiž un regulatori visbiežāk pārbauda. Pareizi integrētam Amplitude izvietojumam jāiztur četras pārbaudes. Pirmkārt, pārlūkprogrammai ar rādītu piekrišanas baneri, bet bez izdarītas izvēles, jārada nulle pieprasījumu uz api.amplitude.com vai api.eu.amplitude.com un nulle AMP_ sīkfailu document.cookie. Otrkārt, analītikas kategorijas noraidīšanai jāsaglabā šis stāvoklis — nav notikumu, nav sīkfailu, nav vietējās krātuves ierakstu ar AMP_ prefiksu. Treškārt, analītikas akceptēšanai jārada viens identify, kam seko notikumu datplūsma, un AMP_ sīkfailam jāparādās ar SameSite atribūtu, kas atbilst izdevēja CMP politikai. Ceturtkārt, piekrišanas atsaukšanai pēc fakta nekavējoties jāaptur turpmāki notikumi un jānotīra saglabātie identifikatori — aizkavēta tīrīšana ir atradums.

Revīzijas pieraksts ir svarīgs atsevišķi. Saskaņā ar EDPB 2023. gada sīkfailu baneru vadlīnijām un atjaunotajām 2026. gada darba grupas prioritātēm, regulatori gaida, ka izdevējs varēs pierādīt, jebkuram Amplitude projektā esošam notikumam, ka lietotājs, kurš to ģenerēja, bija devis derīgu piekrišanu uztveršanas brīdī. Tam nepieciešams, lai CMP piekrišanas žurnāls būtu vaicājams pēc ierīces identifikatora vai sesijas identifikatora, un Amplitude notikuma kravai jānēsā piekrišanas versijas lauks, kas saistās ar šo žurnālu. Piekrišanas virknes saglabāšana kā pielāgots lietotāja rekvizīts katrā notikumā ir vienkāršākais veids, kā padarīt šo saiti revidējamu.

Pareizā reģiona un datu rezidences izvēle

Amplitude darbojas divos ražošanas reģionos: ASV (api.amplitude.com) un ES (api.eu.amplitude.com). EEA un Apvienotās Karalistes satiksmei ES reģions ir pareizais noklusējums — tas saglabā datus EEA iekšienē un samazina pārsūtīšanas riska virsmu, ko Schrems II lēmums un ES-ASV Datu privātuma ietvars ir padarījuši centrālu jebkurai analītikas pārskatīšanai. Reģionu maiņa nav retroaktīva: esošie dati paliek tur, kur tika pirmoreiz uzņemti. Izdevējiem, kas plāno CMP ieviešanu, tāpēc ir vērts apstiprināt reģionu pirms mēroga palielināšanas, un dokumentēt izvēli privātuma paziņojumā, lai juridiskās atbildības ķēde būtu tīra no vākšanas līdz glabāšanai. Pareizi izvēlēts reģions, kopā ar pareizi kontrolētu SDK un vaicājamu piekrišanas žurnālu, ir tas, kas pārvērš Amplitude izvietojumu no regulatīvā riska par pamatojamu analītikas steka daļu.