Zakaj Amplitude zahteva soglasje

Privzeti Amplitude Browser SDK in mobilni SDK-ji Amplitude naredijo veliko več kot le beleženje ogledov strani. Ob inicializaciji nastavijo identifikator naprave v shrambi prve strani, ustvarijo identifikator seje, zajamejo napotitelja, razčlenijo identifikatorje UTM in klikov iz URL-ja ter začnejo postavljati v čakalno vrsto samodejno zajete dogodke: oglede strani, klike na elemente, interakcije z obrazci, prenose datotek in — v najnovejših izdajah — ponovitve sej. Prav tako bodo te dogodke obogatili z geolokacijo, izpeljano iz IP, podatki o napravi, izpeljanimi iz brskalnikovega agenta, in, če je konfigurirano, obogatitvijo tretjih strank od podatkovnih partnerjev.

Vsak od teh korakov vključuje ločeno pravno osnovo soglasja. Shranjevanje identifikatorja naprave je operacija shranjevanja in dostopa po členu 5(3) direktive ePrivacy, ki v Evropskem gospodarskem prostoru, Združenem kraljestvu in vsaki jurisdikciji, ki je prevzela isti standard, zahteva predhodno, prostovoljno, posebno, obveščeno in nedvoumno soglasje. Zajemanje vedenjskih dogodkov, vezanih na ta identifikator, je obdelava osebnih podatkov po GDPR. Obogatitev s podatki tretjih strank uvaja drugi odnos upravljalca. CCPA in CPRA uvrščata enako obdelavo kot prodajo ali delitev, razen če ima založnik pravilno zajeto pogodbo o ponudniku storitev z Amplitude — ki je na voljo, vendar le, če je integracija konfigurirana za onemogočanje oglasnih funkcij.

Kaj Amplitude zbira pred soglasjem — in kaj morate zatreti

Najpogostejša napaka pri implementaciji je obravnavanje Amplitude kot lahkega analitičnega orodja, ki lahko deluje poleg pasice piškotkov. Ne more. Pri privzetem klicu amplitude.init() bo SDK ob prvi upodobitvi strani zapisal vsaj en vnos piškotka ali lokalne shrambe, poslal klic identify in začel medpomnjenje dogodkov. Nič od tega ni dovoljeno, preden je uporabnik pritrdilno sprejel ustrezno kategorijo soglasja.

Skladna integracija mora zato odložiti amplitude.init(), dokler CMP ni signaliziral, da je bila podeljena kategorija soglasja za analitiko. SDK sploh ne sme biti naložen iz oznake <script>, zaprte z soglasjem, ki je odvisna od signala namena 8 (analitika) ali namena 1 (shranjevanje in dostop) CMP, odvisno od tega, kateri okvir CMP izpostavlja. Če mora biti SDK naložen prej — na primer, ker je združen v kodi aplikacije in ga ni mogoče lenobno pridobiti — bi moral inicializacijski klic posredovati defaultTracking: false in optOut: true, da se ne oddajajo nobeni dogodki, dokler soglasje ni zabeleženo, nato pa bi odloženi dogodek opt-in moral obrniti te zastavice.

Piškotki in shramba, ki jo Amplitude zapisuje

Browser SDK 2.x privzeto zapisuje en piškotok prve strani z imenom AMP_{apiKey}, z enoletnim rokom veljavnosti, ki vsebuje identifikator naprave in metapodatke seje. Starejše različice so zapisale tudi amplitude_id_{apiKey}. Mobilni SDK-ji shranijo isti identifikator v peskovnik aplikacije. Ponovna predvajanja sej dodajo drugi piškotok, AMP_MKTG_{apiKey}, in partnerji za obogatitev Amplitude lahko nastavijo dodatne piškotke tretjih strank, če so omogočeni moduli za ciljanje poskusov ali občinstev. Vsi ti so nebistveni in zahtevajo soglasje.

Preslikava Amplitude v okvire soglasja

Amplitude ne implementira Google Consent Mode v2, IAB TCF ali IAB Global Privacy Platform nativno. To ni pomanjkljivost — Amplitude je platforma za analitiko prve strani, ne prodajalec oglasnih tehnologij — vendar pomeni, da odgovornost za integracijo leži na založniku. Vzorec, ki deluje v praksi, je obravnavati vsak modul Amplitude kot ločeno vrata soglasja in ga vezati na specifičen signal, ki ga CMP že izpostavlja.

• Osnovi analitični dogodki so vezani na namen analitike. V izrazih TCF je to najpogosteje namen 8 (merjenje zmogljivosti vsebine) v kombinaciji z namenom 1 (shranjevanje in/ali dostop do informacij). Za Google Consent Mode se to preslika v analytics_storage.
• Ponovna predvajanja sej bi morala biti za strožjim signalom. Ponovna predvajanja zajamejo upodobljeni DOM, vključno z vrednostmi obrazcev, razen če so izrecno maskirane, zato je primerna ločena privolitev za preferences ali functional, ponovna predvajanja pa bi morala biti privzeto izklopljena, tudi ko je analitika podeljena.
• Občinstvo, kohorte in obogatitev tretjih strank so vezani na trženjski namen. V izrazih TCF je to namen 7 (merjenje zmogljivosti oglasov) ali namen 9 (uporaba tržnih raziskav). Za Google Consent Mode se to preslika v ad_storage in ad_user_data.
• Eksperimentiranje — Amplitude Experiment lahko deluje z anonimno, efemerno dodelitvijo na podlagi zakonitega interesa, vendar trajna dodelitev, vezana na identifikator uporabnika, zahteva enako soglasje kot osnovna analitika.

Vzorec integracije, ki deluje

Referenčna implementacija, ki preživi pregled regulatorja, ima štiri premikajočce se dele: CMP, ki izpostavlja dogodek v realnem času, ko uporabnik spremeni soglasje, odložen nalagalnik SDK, ki pridobi Amplitude šele po aktiviranju tega dogodka za ustrezno kategorijo, varovalka na ravni seje, ki spoštuje odjavo, ne da bi izgubila predhodni anonimni identifikator naprave uporabnika, kjer to dovoljuje zakon, in most na strani strežnika za dogodke, ki resnično zahtevajo zbiranje ne glede na soglasje — kot je varnostna telemetrija ali zaznavanje goljufij — usmerjeni prek ločene končne točke z lastno pravno osnovo.

Spletna implementacija

Na spletu je najčistejši vzorec izpostaviti stanje soglasja CMP prek objekta window.__cmp_consent ali standardnega povratnega klica __tcfapi, nato pa imeti majhen skript bootstrap, ki se naroči na spremembe soglasja. Ko se soglasje za analitiko preklopi z false na true, bootstrap pridobi SDK Amplitude iz CDN, ki ga upravlja CMP, pokliče amplitude.init(apiKey, undefined, { defaultTracking: true }) in ponovi vse dogodke, ki so bili v čakalni vrsti v pomnilniku, medtem ko je soglasje čakalo na rešitev. Ko se soglasje preklopi nazaj na false, bootstrap pokliče amplitude.setOptOut(true), izbriše piškotke AMP_ prek preteka document.cookie in odstrani kakršno koli stanje v pomnilniku. Ključno je, da bootstrap nikoli ne sme lenobno inicializirati Amplitude v istem toku zahtev kot upodabljanje pasice — SDK mora počakati na izrecno podelitev.

Mobilna implementacija

Na iOS-u je enakovrednost ohraniti uvoženo ogrodje Amplitude, vendar odložiti Amplitude.instance().initialize(apiKey: apiKey), dokler potek soglasja v aplikaciji ni vrnil pozitivnega analitičnega signala. Poziv ATT je ločena zadeva: ATT ureja IDFA, medtem ko je identifikator Amplitude lastni UUID SDK-ja, shranjen v peskovniku aplikacije. Oba zahtevata soglasje v EGP, vendar sta pravni osnovi in poziva ​​različna. Na Androidu se enaka logika nanaša z Amplitude.getInstance().initializeApolloClient() ali enakovrednim glede na različico SDK.

Način na strani strežnika

Amplitude podpira vnos na strani strežnika prek HTTP V2 API. Dogodki na strani strežnika niso izvzeti iz soglasja — pravna osnova sledi podatkom, ne prenosu — vendar vnos na strani strežnika daje založniku popoln nadzor nad tem, katera polja so poslana, kar olajša spoštovanje delnega soglasja. Pogost vzorec je zbiranje minimalnega, samo-bistvenega nabora dogodkov na strani strežnika pod zakonitim interesom in obogatitev teh dogodkov z vedenjskimi podrobnostmi šele po tem, ko je uporabnik na odjemalcu podelil soglasje za analitiko.

Preverjanje integracije

Korak preverjanja je tisti, ki ga založniki najpogosteje preskočijo in regulatorji najpogosteje preverijo. Pravilno integrirana namestitev Amplitude bi morala prestati štiri preverjanja. Prvič, brskalnik s prikazano pasico soglasja, a brez narejene izbire, bi moral ustvariti nič zahtevkov na api.amplitude.com ali api.eu.amplitude.com in nič piškotkov AMP_ v document.cookie. Drugič, zavrnitev kategorije analitike bi morala ohraniti to stanje — brez dogodkov, brez piškotkov, brez vnosov lokalne shrambe s predpono AMP_. Tretjič, sprejetje analitike bi moralo ustvariti en identify, ki mu sledi promet z dogodki, piškotki AMP_ pa bi morali biti prikazani z atributom SameSite, skladnim s pravilnikom CMP založnika. Četrtič, umik soglasja naknadno bi moral takoj ustaviti nadaljnje dogodke in izbrisati shranjene identifikatorje — zamudno čiščenje je ugotovitev.

Revizijska sled je ločeno pomembna. V skladu s smernicami EDPB za pasice piškotkov iz leta 2023 in prenovljenimi prednostnimi nalogami delovne skupine za leto 2026 regulatorji pričakujejo, da bo založnik sposoben dokazati, za kateri koli dani dogodek v projektu Amplitude, da je uporabnik, ki ga je ustvaril, dal veljavno soglasje v trenutku zajema. To zahteva, da je dnevnik soglasij CMP mogoče poizvedovati po identifikatorju naprave ali identifikatorju seje, in da koristni tovor dogodka Amplitude nosi polje različice soglasja, ki se veže nazaj na ta dnevnik. Shranjevanje niza soglasja kot lastne lastnosti uporabnika pri vsakem dogodku je najprepostejši način, da naredite to povezavo revizijsko sledljivo.

Izbira pravega območja in rezidentnosti podatkov

Amplitude deluje v dveh produkcijskih regijah: ZDA (api.amplitude.com) in EU (api.eu.amplitude.com). Za promet iz EGP in Združenega kraljestva je regija EU pravilna privzeta vrednost — ohranja podatke znotraj EGP in zmanjšuje površino tveganja prenosa, ki sta jo odločitev Schrems II in Okvir za zasebnost podatkov med EU in ZDA postavila v osrčje vsakega analitičnega pregleda. Menjava regij ni retroaktivna: obstoječi podatki ostanejo tam, kjer so bili prvič zajeti. Za založnike, ki načrtujejo uvedbo CMP, se zato splača potrditi regijo pred skaliranjem in splača se dokumentirati izbiro v obvestilu o zasebnosti, da je veriga pravne osnove čista od zbiranja do shranjevanja. Pravilno izbrana regija, skupaj s pravilno zaprtim SDK in poizvedovalnim dnevnikom soglasij, je tisto, kar Amplitude namestitev spremeni iz regulativnega tveganja v zagovorljiv del analitičnega niza.