Miks nõuab Amplitude nõusolekut

Amplitude'i vaikimisi brauserite SDK ja Amplitude'i mobiilsed SDK-d teevad palju enamat kui lihtsalt lehekülgede vaatamiste registreerimine. Initsialiseerimisel seavad nad esimese osapoole salvestusse seadme identifikaatori, genereerivad seansi identifikaatori, jäädvustavad viitaja, analüüsivad UTM ja klõpsiidentifikaatoreid URL-ist ning hakkavad järjekorda panema automaatselt jäädvustatud sündmusi: lehekülgede vaatamisi, elementide klõpse, vormi interaktsioone, failide allalaadimisi ja — viimastes versioonides — seansi kordusi. Samuti rikastavad nad neid sündmusi IP-põhise geolokatsiooni, kasutajaagendi-põhiste seadmeandmete ning, kui on konfigureeritud, andmepartnerite kolmanda osapoole rikastamisega.

Kõik need sammud tegelevad eraldi nõusoleku õigusliku alusega. Seadme identifikaatori salvestamine on salvestus-ja-juurdepääsu toiming vastavalt ePrivacy direktiivi artiklile 5(3), mis nõuab eelnevat, vabatahtlikku, konkreetset, teadlikku ja ühemõttelist nõusolekut Euroopa Majanduspiirkonnas, Ühendkuningriigis ning igas jurisdiktsioonis, mis on sama standardi üle võtnud. Käitumissündmuste jäädvustamine, mis on seotud selle identifikaatoriga, on isikuandmete töötlemine GDPR alusel. Kolmanda osapoole andmetega rikastamine toob kaasa teise vastutava töötleja suhte. CCPA ja CPRA klassifitseerivad sama töötlemise müügiks või jagamiseks, välja arvatud juhul, kui kirjastajal on Amplitude'iga nõuetekohaselt piiritletud teenuseosutaja leping — mis on olemas, kuid ainult juhul, kui integratsioon on seadistatud reklaamifunktsioonid keelama.

Mida Amplitude kogub enne nõusolekut — ja mida peate pärssima

Kõige levinum juurutamisviga on Amplitude'i käsitlemine kerge analüütika tööriistana, mis saab töötada koos küpsisebänneriga. See ei saa. Vaikimisi amplitude.init() kõne korral kirjutab SDK lehe esimese renderdamise ajal vähemalt ühe küpsise või kohaliku salvestuse kirje, saadab identifitseerimiskõne ja hakkab sündmusi puhverdama. Ükski neist ei ole lubatav enne, kui kasutaja on asjaomase nõusolekukategooria jaoks üheselt aktsepteerinud.

Seetõttu peab nõuetele vastav integratsioon viivitama amplitude.init() käivitamisega, kuni CMP on andnud signaali, et analüütika nõusolekukategooria on antud. SDK-d ei tohiks üldse laadida CMP-põhisest <script> sildist, mis sõltub CMP eesmärgi 8 (analüütika) või eesmärgi 1 (salvestus ja juurdepääs) signaalist, olenevalt sellest, millist raamistikku CMP paljastab. Kui SDK peab varem laadima — näiteks kuna see on ühendatud rakenduse koodiga ega saa laadida laiskalt — peaks initsialiseerimiskõne läbima defaultTracking: false ja optOut: true, et enne nõusoleku salvestamist ei saadetaks ühtegi sündmust, ning seejärel peaks lükatud opt-in sündmus need lipud ümber lülitama.

Küpsised ja salvestus, mida Amplitude kirjutab

Brauseri SDK 2.x kirjutab vaikimisi ühe esimese osapoole küpsise nimega AMP_{apiKey} üheaastase kehtivusajaga, mis sisaldab seadme identifikaatorit ja seansi metaandmeid. Vanemad versioonid kirjutasid ka amplitude_id_{apiKey}. Mobiilsed SDK-d salvestavad sama identifikaatori rakenduse liivakastiga salvestuses. Seansi kordus lisab teise küpsise, AMP_MKTG_{apiKey}, ja Amplitude'i rikastamispartnerid võivad seada täiendavaid kolmanda osapoole küpsiseid, kui eksperimentide sihtimise või vaatajaskondade moodulid on lubatud. Kõik need on mitteolulised ja nõuavad nõusolekut.

Amplitude kaardistamine nõusoleku raamistikele

Amplitude ei rakenda algselt Google Consent Mode v2, IAB TCF ega IAB Global Privacy Platform. See ei ole puudus — Amplitude on esimese osapoole analüütika platvorm, mitte reklaamtehnoloogia müüja — kuid see tähendab, et integratsiooni vastutus langeb kirjastajale. Praktikas toimiv muster on käsitleda iga Amplitude moodulit eraldi nõusoleku väravana ja siduda see konkreetse signaali juurde, mille CMP juba paljastab.

• Põhilised analüütika sündmused seotakse analüütika eesmärgiga. TCF terminites on see kõige sagedamini eesmärk 8 (sisu toimivuse mõõtmine) kombineerituna eesmärgiga 1 (teabe salvestamine ja/või juurdepääs). Google Consent Mode jaoks vastab see analytics_storage.
• Seansi kordus peaks olema rangema signaali taga. Kordus jäädvustab renderdatud DOM-i, sealhulgas vormi väärtusi, kui need pole selgesõnaliselt maskeeritud, seega on eraldi eelistuste või funktsionaalse opt-in asjakohane ja kordus peaks vaikimisi olema välja lülitatud isegi siis, kui analüütika on antud.
• Vaatajaskonnad, kohordid ja kolmanda osapoole rikastamine seotakse turunduse eesmärgiga. TCF terminites on see eesmärk 7 (reklaami toimivuse mõõtmine) või eesmärk 9 (turundusuuringute rakendamine). Google Consent Mode jaoks vastab see ad_storage ja ad_user_data.
• Eksperimenteerimine — Amplitude Experiment saab töötada anonüümse, ajutise jaotamisega legitiimsete huvide alusel, kuid püsiv jaotamine, mis on seotud kasutaja identifikaatoriga, nõuab sama nõusolekut nagu põhianalüütika.

Toimiv integratsioonimuster

Regulaatori ülevaatuse läbival viitejuurutamisel on neli liikuvat osa: CMP, mis paljastab reaalajas sündmuse, kui kasutaja nõusolekut muudab, lükatud SDK laadur, mis toob Amplitude'i ainult pärast selle sündmuse käivitumist asjakohase kategooria jaoks, seansi taseme kaitsja, mis austab opt-out-i ilma kasutaja eelneva anonüümse seadme identifikaatorit kaotamata, kus seadus lubab, ja serveripoolne sild sündmuste jaoks, mis tõepoolest nõuavad kogumist sõltumata nõusolekust — nagu turbetelemetria või pettuste tuvastamine — suunatuna läbi eraldi lõpp-punkti oma õigusliku alusega.

Veebijuurutamine

Veebis on puhtaim muster paljastada CMP nõusolekuolek window.__cmp_consent objekti kaudu või standardse __tcfapi tagasihelistamise kaudu, seejärel lasta väikesel bootstrap-skriptil nõusolekumuutustele tellida. Kui analüütika nõusolek lülitub väärast tõeseks, toob bootstrap Amplitude SDK CMP-hallatavalt CDN-ilt, kutsub amplitude.init(apiKey, undefined, { defaultTracking: true }) ja kordab mälusse järjekorda pandud sündmused, kuni nõusolek ootas. Kui nõusolek lülitub tagasi vääraks, kutsub bootstrap amplitude.setOptOut(true), kustutab AMP_ küpsise document.cookie kehtivuse lõpu kaudu ning eemaldab kõik mälus oleva oleku. Kriitiliselt ei tohi bootstrap iialgi Amplitude'i laisa initsialiseerimisega laadida samas päringuvoos kui bänneri renderdamine — SDK peab ootama selge loa.

Mobiilne juurutamine

iOS-is on vastav toiming hoida Amplitude raamistik imporditud, kuid lükata Amplitude.instance().initialize(apiKey: apiKey) edasi kuni rakendusesisene nõusolekuvoog on tagastanud positiivse analüütika signaali. ATT viip on eraldi mure: ATT reguleerib IDFA-d, samas kui Amplitude'i identifikaator on SDK-i enda UUID, mis on salvestatud rakenduse liivakastis. Mõlemad nõuavad nõusolekut EEA-s, kuid õiguslikud alused ja viibad on erinevad. Androidis kehtib sama loogika Amplitude.getInstance().initializeApolloClient() või vastavaga sõltuvalt SDK versioonist.

Serveripoolne režiim

Amplitude toetab serveripoolset kogumist HTTP V2 API kaudu. Serveripoolsed sündmused ei ole nõusolekust vabastatud — õiguslik alus järgib andmeid, mitte transporti — kuid serveripoolne kogumine annab kirjastajale täieliku kontrolli selle üle, milliseid välju saadetakse, mis muudab osalise nõusoleku austamise lihtsamaks. Tavaline muster on jäädvustada minimaalne oluline sündmuste kogum serveripoolselt legitiimse huvi alusel ja rikastada neid sündmusi käitumuslike üksikasjadega alles pärast seda, kui kasutaja on kliendil analüütika nõusoleku andnud.

Integreerimise valideerimine

Valideerimissamm on see, mille kirjastajad enamasti vahele jätavad ja regulaatorid enamasti kontrollivad. Õigesti integreeritud Amplitude juurutus peaks läbima neli kontrolli. Esiteks peaks brauser, milles on küpsisebänner näidatud, kuid valikut pole tehtud, tootma null päringut api.amplitude.com või api.eu.amplitude.com ning null AMP_ küpsist document.cookie-s. Teiseks peaks analüütika kategooria tagasilükkamine seda olekut säilitama — ei sündmusi, küpsiseid ega kohaliku salvestuse kirjeid AMP_ eesliitega. Kolmandaks peaks analüütika aktsepteerimine tootma ühe identify, millele järgneb sündmuste liiklus, ning AMP_ küpsis peaks ilmuma SameSite atribuudiga, mis vastab kirjastaja CMP poliitikale. Neljandaks peaks nõusoleku tagasivõtmine koheselt peatama edasised sündmused ja kustutama salvestatud identifikaatorid — viivitatud puhastus on leid.

Auditijälg on eraldi oluline. EDPB 2023. aasta küpsisebännerite suuniste ja uuendatud 2026. aasta töörühma prioriteetide kohaselt ootavad regulaatorid, et kirjastaja suudaks tõestada, et iga Amplitude'i projekti sündmuse jaoks oli sündmuse loonud kasutaja andnud kehtiva nõusoleku jäädvustamise hetkel. See nõuab, et CMP nõusoleku logi oleks päritav seadme identifikaatori või seansi identifikaatori järgi ja Amplitude'i sündmuse kasulik koormus kannaks nõusoleku versiooni välja, mis viitab tagasi sellele logile. Nõusolekustringi salvestamine kohandatud kasutaja atribuudina iga sündmuse kohta on lihtsaim viis selle seose auditeeritavaks muutmiseks.

Õige piirkonna ja andmete residentsuse valimine

Amplitude opereerib kaht tootmispiirkonda: USA (api.amplitude.com) ja EL (api.eu.amplitude.com). EEA ja Ühendkuningriigi liikluse jaoks on EL-i piirkond õige vaikimisi — see hoiab andmed EEA-s ja vähendab ülekande riskipinda, mille Schrems II otsus ja EL-USA andmeprivaatsuse raamistik on muutnud iga analüütika ülevaatuse keskseks. Piirkondade vahetamine ei ole retroaktiivne: olemasolevad andmed jäävad sinna, kus need esmakordselt koguti. Kirjastajate jaoks, kes planeerivad CMP kasutuselevõttu, tasub seega enne skaleerimist piirkond kinnitada ja valiku dokumenteerida privaatsusteates, et õiguslik aluste ahel oleks kogumisest salvestamiseni puhas. Õigesti valitud piirkond, mis on ühendatud õigesti suletud SDK ja päritava nõusoleku logiga, muudab Amplitude'i juurutuse regulatiivsest riskist analüütika stacki kaitstavaks osaks.