Kodėl Amplitude reikia sutikimo

Numatytasis Amplitude Browser SDK ir Amplitude mobilioji SDK daro kur kas daugiau nei tiesiog fiksuoja puslapių peržiūras. Inicijavimo metu jie nustato įrenginio identifikatorių pirmosios šalies saugykloje, generuoja seanso identifikatorių, fiksuoja nukreipimo šaltinį, analizuoja UTM ir paspaudimų identifikatorius iš URL ir pradeda automatiškai fiksuojamų įvykių eilę: puslapių peržiūras, elementų paspaudimus, formų sąveikas, failų atsisiuntimus ir — naujausių leidimų — sesijų įrašų peržiūras. Jie taip pat praturtins šiuos įvykius IP pagrindu nustatyta geovizualizacija, įrenginio duomenimis pagal vartotojo agentą ir, jei sukonfigūruota, trečiųjų šalių praturtinimu iš duomenų partnerių.

Kiekvienas iš šių žingsnių apima atskirą sutikimo teisinį pagrindą. Įrenginio identifikatoriaus saugojimas yra saugojimo ir prieigos operacija pagal ePrivacy direktyvos 5 straipsnio 3 dalį, kuriai reikalingas išankstinis, laisvas, konkretus, informuotas ir nedviprasmiškas sutikimas Europos ekonominėje erdvėje, Jungtinėje Karalystėje ir bet kurioje jurisdikcijoje, kuri priėmė tą patį standartą. Su šiuo identifikatoriumi susijusių elgsenos įvykių fiksavimas yra asmens duomenų tvarkymas pagal GDPR. Praturtinimas trečiųjų šalių duomenimis sukuria antrą valdytojo santykį. CCPA ir CPRA tą patį tvarkymą klasifikuoja kaip pardavimą arba dalijimąsi, nebent leidėjas turi su Amplitude tinkamai apibrėžtą paslaugų teikėjo sutartį — kuri yra, bet tik jei integracija sukonfigūruota reklamines funkcijas išjungti.

Ką Amplitude renka prieš sutikimą — ir ką reikia slopinti

Dažniausia įgyvendinimo klaida — traktuoti Amplitude kaip lengvą analizės įrankį, galintį veikti šalia slapukų banerio. Tai negalima. Numatytajame amplitude.init() iškvietimo atveju SDK pirmojo puslapio atspalvio metu įrašys bent vieną slapuką arba vietinės saugyklos įrašą, siųs identify iškvietimą ir pradės buferizuoti įvykius. Visa tai negalima, kol vartotojas aiškiai nepriims atitinkamos sutikimo kategorijos.

Todėl atitinkanti integracija turi atidėti amplitude.init(), kol CMP nepranešė, kad analizės sutikimo kategorija buvo suteikta. SDK apskritai neturi būti įkeltas iš sutikimu apribotos <script> žymės, kuri priklauso nuo CMP 8-ojo tikslo (analizė) arba 1-ojo tikslo (saugojimas ir prieiga) signalo, priklausomai nuo to, kurią sistemą CMP atskleidžia. Jei SDK turi būti įkeltas anksčiau — pavyzdžiui, nes jis supakuotas į programos kodą ir negali būti lėtai gautas — inicijavimo iškvietimas turėtų perduoti defaultTracking: false ir optOut: true, kad jokie įvykiai nebūtų išsiunčiami, kol sutikimas nebus užregistruotas, o tada atidėtas opt-in įvykis turėtų perjungti šias vėliavėles.

Slapukai ir saugykla, kurią Amplitude rašo

Browser SDK 2.x numatytaisiais nustatymais rašo vieną pirmosios šalies slapuką pavadinimu AMP_{apiKey} su vienerių metų galiojimo laiku, kuriame yra įrenginio identifikatorius ir seanso metaduomenys. Senesnės versijos taip pat rašė amplitude_id_{apiKey}. Mobiliosios SDK išlaiko tą patį identifikatorių programos smėlio dėžės saugykloje. Seanso peržiūra prideda antrą slapuką AMP_MKTG_{apiKey}, o Amplitude praturtinimo partneriai gali nustatyti papildomus trečiųjų šalių slapukus, jei įjungti eksperimentų nukreipimo arba auditorijų moduliai. Visi jie yra nebūtini ir reikalauja sutikimo.

Amplitude atitikimas sutikimo sistemoms

Amplitude natūraliai neįgyvendina Google Consent Mode v2, IAB TCF ar IAB Global Privacy Platform. Tai nėra trūkumas — Amplitude yra pirmosios šalies analizės platforma, o ne reklamos technologijų tiekėjas — tačiau tai reiškia, kad integravimo atsakomybė tenka leidėjui. Praktikoje veikiantis modelis — kiekvieną Amplitude modulį traktuoti kaip atskirą sutikimo vartus ir susieti su konkrečiu signalu, kurį CMP jau atskleidžia.

• Pagrindiniai analizės įvykiai susiejami su analizės tikslu. TCF požiūriu tai dažniausiai yra 8-asis tikslas (turinio našumo matavimas) kartu su 1-uoju tikslu (informacijos saugojimas ir (arba) prieiga). Google Consent Mode atveju tai atitinka analytics_storage.
• Seanso peržiūra turėtų būti už griežtesnio signalo. Peržiūra fiksuoja atvaizdintą DOM, įskaitant formos reikšmes, nebent jos aiškiai užmaskuotos, todėl tinka atskiras preferences arba functional opt-in, o peržiūra turėtų būti numatytaisiais nustatymais išjungta, net kai suteikta analizės sutikimas.
• Auditorijos, kohortos ir trečiųjų šalių praturtinimas susiejami su rinkodaros tikslu. TCF požiūriu tai yra 7-asis tikslas (reklamos našumo matavimas) arba 9-asis tikslas (rinkos tyrimų taikymas). Google Consent Mode atveju tai atitinka ad_storage ir ad_user_data.
• Eksperimentavimas — Amplitude Experiment gali veikti su anoniminiu, efemerišku paskyrimu teisėto intereso pagrindu, tačiau nuolatinis paskyrimas, susietas su vartotojo identifikatoriumi, reikalauja to paties sutikimo kaip ir pagrindinė analizė.

Veikiantis integravimo modelis

Nuorodos įgyvendinimas, kuris išlaiko reguliuotojo patikrinimą, turi keturias judančias dalis: CMP, kuris atskleidžia realaus laiko įvykį, kai vartotojas keičia sutikimą; atidėtas SDK įkėlimas, kuris gauną Amplitude tik tada, kai tas įvykis aktyvuojamas atitinkamai kategorijai; seanso lygio sargybinis, kuris gerbia atsisakymą neprarandant ankstesnio anonimiško vartotojo įrenginio identifikatoriaus, kur tai leidžia įstatymas; ir serverio pusės tiltas įvykiams, kuriems tikrai reikia rinkti neatsižvelgiant į sutikimą — pvz., saugos telemetriją ar sukčiavimo aptikimą — nukreiptų per atskirą galinį tašką su savo teisiniu pagrindu.

Žiniatinklio įgyvendinimas

Žiniatinklyje švaresnis modelis — CMP sutikimo būseną atskleisti per window.__cmp_consent objektą arba standartinį __tcfapi atgalinį iškvietimą, tada turėti mažą pradinio krovimo scenarijų, kuris prenumeruoja sutikimo pokyčius. Kai analizės sutikimas persijungia iš false į true, pradinis krovimas gauną Amplitude SDK iš CMP valdomos CDN, kviečia amplitude.init(apiKey, undefined, { defaultTracking: true }) ir pakartoja visus įvykius, kurie buvo eilėje atmintyje laukiant sutikimo. Kai sutikimas grįžta į false, pradinis krovimas kviečia amplitude.setOptOut(true), per document.cookie galiojimo pabaigą valo AMP_ slapuką ir pašalina visą atminties būseną. Svarbu, kad pradinis krovimas niekada neturėtų tingiai inicijuoti Amplitude tame pačiame užklausos sraute kaip banerio atvaizdavimas — SDK turi laukti aiškaus leidimo.

Mobilusis įgyvendinimas

iOS atitikmenys yra Amplitude sistemos importo išlaikymas, tačiau Amplitude.instance().initialize(apiKey: apiKey) atidėjimas, kol programos sutikimo srautas negrąžins teigiamo analizės signalo. ATT raginimas yra atskiras klausimas: ATT reglamentuoja IDFA, o Amplitude identifikatorius yra paties SDK UUID, saugomas programos smėlio dėžėje. Abu reikalauja sutikimo EEA, tačiau teisiniai pagrindai ir raginimai skiriasi. Android ta pati logika galioja su Amplitude.getInstance().initializeApolloClient() arba atitinkamu, priklausomai nuo SDK versijos.

Serverio pusės režimas

Amplitude palaiko serverio pusės duomenų gavybą per HTTP V2 API. Serverio pusės įvykiai nėra neįpareigojami sutikimo atžvilgiu — teisinis pagrindas seka duomenis, o ne transportą — tačiau serverio pusės gavyba suteikia leidėjui visišką kontrolę, kurie laukai siunčiami, todėl lengviau gerbti dalinį sutikimą. Įprastas modelis — serverio pusėje pagal teisėtą interesą fiksuoti minimalų tik esminių įvykių rinkinį ir praturtinti šiuos įvykius elgsenos detalėmis tik po to, kai vartotojas suteikė analizės sutikimą kliente.

Integravimo patvirtinimas

Patvirtinimo žingsnis yra tas, kurį leidėjai dažniausiai praleidžia, o reguliuotojai dažniausiai tikrina. Tinkamai integruotas Amplitude diegimas turi išlaikyti keturis patikrinimus. Pirma, naršyklė su rodomu sutikimo baneriu, bet be pasirinkimo, turėtų generuoti nulines užklausas į api.amplitude.com arba api.eu.amplitude.com ir nulinius AMP_ slapukus document.cookie. Antra, analizės kategorijos atsisakymas turėtų išlaikyti tą būseną — nei įvykių, nei slapukų, nei vietinės saugyklos įrašų su AMP_ prefiksu. Trečia, analizės priėmimas turėtų generuoti vieną identify, po kurio seka įvykių srautas, o AMP_ slapukas turėtų pasirodyti su SameSite atributu, atitinkančiu leidėjo CMP politiką. Ketvirta, vėlesnis sutikimo atsisakymas turėtų nedelsdamas sustabdyti tolimesnius įvykius ir išvalyti saugomus identifikatorius — vėluojantis valymas yra konstatavimas.

Audito pėdsakas svarbus atskirai. Pagal EDPB 2023 m. slapukų banerio gaires ir atnaujintas 2026 m. darbo grupės prioritetus reguliuotojai tikisi, kad leidėjas galės įrodyti bet kuriam Amplitude projekto įvykiui, kad jį sugeneravęs vartotojas fiksavimo metu davė galiojantį sutikimą. Tam reikia, kad CMP sutikimo žurnalas būtų užklausomas pagal įrenginio identifikatorių arba seanso identifikatorių, o Amplitude įvykio naudingoji apkrova turėtų sutikimo versijos lauką, susietą su tuo žurnalu. Sutikimo eilutės saugojimas kaip pasirinktinė vartotojo savybė kiekviename įvykyje yra paprasčiausias būdas padaryti tą ryšį audituojamu.

Tinkamo regiono ir duomenų rezidavimo pasirinkimas

Amplitude eksploatuoja du gamybos regionus: JAV (api.amplitude.com) ir ES (api.eu.amplitude.com). EEA ir JK srautui ES regionas yra tinkamas numatytasis — jis išlaiko duomenis EEA ribose ir sumažina perdavimo rizikos paviršių, kurį Schrems II sprendimas ir ES ir JAV duomenų privatumo sistema padarė centrine bet kokio analizės peržiūros tema. Regionų keitimas nėra retroaktyvus: esami duomenys lieka ten, kur pirmą kartą buvo paimti. Leidėjams, planuojantiems CMP diegimą, todėl verta patvirtinti regioną prieš mastelio keitimą ir verta dokumentuoti pasirinkimą privatumo pranešime, kad teisinio pagrindo grandinė būtų aiški nuo rinkimo iki saugojimo. Tinkamai pasirinktas regionas, kartu su tinkamai uždarytu SDK ir užklausojamu sutikimo žurnalu, paverčia Amplitude diegimą iš reguliavimo rizikos į gintiną analizės rinkinio dalį.