Pse Amplitude kërkon pëlqim

SDK-ja e parazgjedhur e Shfletuesit Amplitude dhe SDK-të mobile të Amplitude bëjnë shumë më tepër sesa regjistrimin e pamjeve të faqeve. Gjatë inicializimit ato vendosin një identifikues të pajisjes në ruajtjen e palës së parë, gjenerojnë një identifikues sesioni, kapin referuesin, analizojnë identifikuesit UTM dhe klikimeve nga URL-ja, dhe fillojnë të radhisin ngjarje të kapura automatikisht: pamje faqesh, klikime elementesh, ndërveprime formularësh, shkarkime skedarësh dhe — në publikimet e fundit — replyime sesionesh. Ato gjithashtu do të pasurojnë ato ngjarje me gjeovendndodhje të derivuar nga IP-ja, të dhëna pajisje të derivuara nga agjenti i përdoruesit dhe, nëse konfigurohet, pasurimin e palës së tretë nga partnerët e të dhënave.

Secili prej atyre hapave angazhon një bazë ligjore të veçantë pëlqimi. Ruajtja e një identifikuesi të pajisjes është një operacion ruajtje-dhe-aksesi nën Nenin 5(3) të Direktivës ePrivacy, i cili kërkon pëlqim paraprak, të dhënë lirisht, specifik, të informuar dhe të paqartë në Zonën Ekonomike Europiane, Mbretërinë e Bashkuar, dhe çdo juridiksion që ka importuar të njëjtin standard. Kapja e ngjarjeve të sjelljes të lidhura me atë identifikues është përpunim i të dhënave personale nën GDPR. Pasurimi me të dhëna të palës së tretë fut një marrëdhënie të dytë kontrolluesi. CCPA dhe CPRA klasifikojnë të njëjtin përpunim si një shitje ose ndarje nëse botuesi nuk ka një kontratë ofruesi shërbimi të përshtatshëm me Amplitude — e cila është e disponueshme, por vetëm nëse integrimi është konfiguruar për të çaktivizuar veçoritë e reklamave.

Çfarë mbledh Amplitude para pëlqimit — dhe çfarë duhet të shtypni

Gabimi më i zakonshëm i implementimit është trajtimi i Amplitude si një mjet analitike i lehtë që mund të funksionojë krahas banderolës cookie. Nuk mundet. Në një thirrje të parazgjedhur amplitude.init() SDK-ja do, brenda pikturimit të parë të faqes, të shkruajë të paktën një cookie ose hyrje ruajtje lokale, të dërgojë një thirrje identifikuese dhe të fillojë të bufferizojë ngjarje. Asnjë prej tyre nuk lejohet para se një përdorues të ketë pranuar në mënyrë pohore kategorinë e duhur të pëlqimit.

Prandaj një integrim i përputhshëm duhet të vonojë amplitude.init() derisa CMP-ja të ketë sinjalizuar se kategoria e pëlqimit të analitikës është dhënë. SDK-ja nuk duhet të ngarkohet fare nga një etiketë <script> e kontrolluar nga pëlqimi që varet nga sinjali i qëllimit 8 (analitikë) ose qëllimit 1 (ruajtje dhe akses) i CMP-së, varësisht nga kuadri që CMP-ja ekspozon. Nëse SDK-ja duhet të ngarkohet më herët — për shembull sepse është e mbledhur në kodin e aplikacionit dhe nuk mund të merret me vonesë — thirrja e inicializimit duhet të kalojë defaultTracking: false dhe optOut: true në mënyrë që asnjë ngjarje të mos lëshohet derisa të regjistrohet pëlqimi, dhe pastaj një ngjarje e vonuar e opt-in duhet të kthejë ato flamuj.

Cookie-t dhe ruajtja që shkruan Amplitude

SDK-ja e Shfletuesit 2.x shkruan një cookie të vetme të palës së parë të emërtuar AMP_{apiKey} si parazgjedhje, me një skadim një-vjeçar, që përmban identifikuesin e pajisjes dhe metadatat e sesionit. Versionet më të vjetra gjithashtu shkruanin amplitude_id_{apiKey}. SDK-të mobile ruajnë të njëjtin identifikues brenda ruajtjes sandbox të aplikacionit. Riluajtja e sesionit shton një cookie të dytë, AMP_MKTG_{apiKey}, dhe partnerët e pasurimit të Amplitude mund të vendosin cookie shtesë të palës së tretë nëse modulet e synimit të eksperimenteve ose audiencave janë të aktivizuara. Të gjitha këto janë jo-thelbësore dhe kërkojnë pëlqim.

Hartëzimi i Amplitude me kuadret e pëlqimit

Amplitude nuk implementon natyrshëm Google Consent Mode v2, IAB TCF ose Platformën Globale të Privatësisë IAB. Kjo nuk është defekt — Amplitude është një platformë analitike e palës së parë, jo një shitës teknologjie reklamash — por do të thotë se përgjegjësia e integrimit qëndron me botuesin. Modeli që funksionon në praktikë është trajtimi i çdo moduli Amplitude si një portë e veçantë pëlqimi dhe lidhja e tij me një sinjal specifik që CMP-ja tashmë ekspozon.

• Ngjarjet kryesore të analitikës lidhen me qëllimin e analitikës. Në termat TCF kjo zakonisht është qëllimi 8 (mat performancën e përmbajtjes) i kombinuar me qëllimin 1 (ruaj dhe/ose akseso informacionin). Për Google Consent Mode kjo hartohet te analytics_storage.
• Riluajtja e sesionit duhet të qëndrojë pas një sinjali më të rreptë. Riluajtja kap DOM të renderizuar, duke përfshirë vlerat e formularit nëse nuk maskohen shprehimisht, kështu që një opt-in i veçantë preferences ose functional është i përshtatshëm, dhe riluajtja duhet të parazgjedhet si e çaktivizuar edhe kur analitika është dhënë.
• Audiencët, grupet dhe pasurimi i palës së tretë lidhen me qëllimin e marketingut. Në termat TCF kjo është qëllimi 7 (mat performancën e reklamave) ose qëllimi 9 (apliko kërkimin e tregut). Për Google Consent Mode kjo hartohet te ad_storage dhe ad_user_data.
• Eksperimentimi — Amplitude Experiment mund të funksionojë me alokimin anonim, efemer nën një bazë interesi legjitim, por alokimi i qëndrueshëm i lidhur me një identifikues përdoruesi kërkon të njëjtin pëlqim si analitika kryesore.

Modeli i integrimit që funksionon

Implementimi referues që mbijetohet nga rishikimi i një rregullatori ka katër pjesë lëvizëse: një CMP që ekspozon një ngjarje në kohë reale kur përdoruesi ndryshon pëlqimin, një ngarkues SDK të vonuar që merr Amplitude vetëm pasi ajo ngjarje ndizet për kategorinë e duhur, një roje niveli sesioni që respekton opt-out pa humbur identifikuesin e mëparshëm anonim të pajisjes ku e lejon ligji, dhe një urë nga ana e serverit për ngjarje që vërtet kërkojnë mbledhje pavarësisht nga pëlqimi — si telemetria e sigurisë ose zbulimi i mashtrimeve — të drejtuar nëpërmjet një pika fundore të veçantë me bazën e vet ligjore.

Implementimi Web

Në web, modeli më i pastër është ekspozimi i gjendjes së pëlqimit të CMP-së nëpërmjet një objekti window.__cmp_consent ose kthesës standarde __tcfapi, pastaj të kesh një skript të vogël bootstrap që abonohet në ndryshimet e pëlqimit. Kur pëlqimi i analitikës kalon nga false në true, bootstrap-i merr SDK-në Amplitude nga CDN-ja e menaxhuar nga CMP, thërret amplitude.init(apiKey, undefined, { defaultTracking: true }), dhe riluajt ngjarjet e radhitura në memorie ndërkohë që pritej pëlqimi. Kur pëlqimi kalon sërish në false, bootstrap-i thërret amplitude.setOptOut(true), pastron cookie-n AMP_ nëpërmjet skadimit të document.cookie, dhe heq çdo gjendje në memorie. Kritikisht, bootstrap-i nuk duhet të inicializojë Amplitude me vonesë në të njëjtin rrjedhë kërkese si render-i i banderolës — SDK-ja duhet të presë për një grant eksplicit.

Implementimi Mobile

Në iOS ekuivalenti është mbajtja e kuadrit Amplitude të importuar por vonesa e Amplitude.instance().initialize(apiKey: apiKey) derisa fluksi i pëlqimit brenda aplikacionit të ketë kthyer një sinjal pozitiv analitike. Kërkesa ATT është një shqetësim i veçantë: ATT qeverisin IDFA, ndërsa identifikuesi i Amplitude është UUID i vet i SDK-së i ruajtur në sandbox të aplikacionit. Të dyja kërkojnë pëlqim në EEA, por bazat ligjore dhe kërkesat janë të ndryshme. Në Android e njëjta logjikë zbatohet me Amplitude.getInstance().initializeApolloClient() ose ekuivalentin varësisht nga versioni i SDK.

Modaliteti nga ana e serverit

Amplitude mbështet gëlltitjen nga ana e serverit nëpërmjet HTTP V2 API. Ngjarjet nga ana e serverit nuk janë të përjashtuara nga pëlqimi — baza ligjore ndjek të dhënat, jo transportin — por gëlltitja nga ana e serverit i jep botuesit kontroll të plotë mbi cilat fusha dërgohen, gjë që e bën më të lehtë respektimin e pëlqimit të pjesshëm. Një model i zakonshëm është kapja e një seti minimal ngjarjesh vetëm-thelbësore nga ana e serverit nën interes legjitim, dhe pasurimi i atyre ngjarjeve me detaje sjelljeje vetëm pasi përdoruesi ka dhënë pëlqimin e analitikës në klient.

Validimi i integrimit

Hapi i validimit është ai që botuesit më shpesh anashkalojnë dhe rregullatorët më shpesh kontrollojnë. Një vendosje e saktë e Amplitude duhet të kalojë katër kontrolle. Së pari, një shfletues me banderolën e pëlqimit të shfaqur por asnjë zgjedhje të bërë duhet të prodhojë zero kërkesa për api.amplitude.com ose api.eu.amplitude.com dhe zero cookie-t AMP_ në document.cookie. Së dyti, refuzimi i kategorisë së analitikës duhet të ruajë atë gjendje — asnjë ngjarje, asnjë cookie, asnjë hyrje ruajtje lokale me një prefiks AMP_. Së treti, pranimi i analitikës duhet të prodhojë një identify të vetëm të ndjekur nga trafiku i ngjarjeve, dhe cookie-ja AMP_ duhet të shfaqet me një atribut SameSite të qëndrueshëm me politikën CMP të botuesit. Së katërti, tërheqja e pëlqimit pas faktit duhet të ndalojë menjëherë ngjarjet e mëtejshme dhe të pastrojë identifikuesit e ruajtur — një pastrimi i vonuar është një gjetje.

Gjurma e auditimit ka rëndësi veçmas. Nën udhëzimet e EDPB për banderolën cookie të 2023 dhe prioritetet e ripërtëritura të grupit të detyrave 2026, rregullatorët presin që botuesi të jetë në gjendje të provojë, për çdo ngjarje të dhënë në projektin Amplitude, që përdoruesi që e gjeneroi kishte dhënë pëlqim të vlefshëm në momentin e kapjes. Kjo kërkon që regjistri i pëlqimit i CMP-së të jetë i pyetshëm sipas identifikuesit të pajisjes ose identifikuesit të sesionit, dhe ngarkesa e ngjarjes Amplitude të mbajë një fushë versioni-pëlqimi që lidhet me atë regjistër. Ruajtja e vargut të pëlqimit si një pronë e personalizuar e përdoruesit në çdo ngjarje është mënyra më e thjeshtë për të bërë atë lidhje të auditueshme.

Zgjedhja e rajonit të duhur dhe vendbanimit të të dhënave

Amplitude operon dy rajone produksioni: SHBA (api.amplitude.com) dhe BE (api.eu.amplitude.com). Për trafikun e EEA dhe MB rajoni i BE-së është i parazgjedhuri i duhur — i mban të dhënat brenda EEA dhe zvogëlon sipërfaqen e rrezikut të transferimit që vendimi Schrems II dhe Kuadri i Privatësisë së të Dhënave BE-SHBA e kanë bërë qendror në çdo rishikim analitike. Ndërrimi i rajoneve nuk është retroaktiv: të dhënat ekzistuese qëndrojnë ku u gëlltit për herë të parë. Për botuesit që planifikojnë një zbatim CMP vlen prandaj të konfirmohet rajoni para shkallëzimit, dhe të dokumentohet zgjedhja në njoftimin e privatësisë në mënyrë që zinxhiri i bazës ligjore të jetë i pastër nga mbledhja deri te ruajtja. Një rajon i zgjedhur saktë, i çiftëzuar me një SDK të mbyllur saktë dhe një regjistër pëlqimi të pyetshëm, është ajo që e kthen një vendosje Amplitude nga një rrezik rregullator në një pjesë të mbrojtur të grumbullit analitik.