Af hverju krefst Amplitude samþykkis

Sjálfgefinn Amplitude Browser SDK og Amplitude farsíma SDK gera mun meira en að skrá síðuskoðanir. Við frumstillingu setja þau upp tækjaauðkenni í geymslu fyrsta aðila, búa til lotaauðkenni, grípa vísitöluheimild, þátta UTM og smellauðkennur úr slóðinni, og hefja biðröð sjálfkrár uppteknanna viðburða: síðuskoðanir, smellir á hluti, eyðublaðasamskipti, skráarniðurhal og — í nýjustu útgáfum — lotaendurspilun. Þau munu einnig auðga þessa viðburði með IP-undirstaðaðri staðsetningarþjónustu, tækjagögnum úr notendamiðlara og, ef stillt, þriðja aðilaauðgun frá gagnasamstarfsaðilum.

Hvert þessara skrefa þarf sérstakan lagalegan samþykkisgrunn. Að geyma tækjaauðkenni er geymslu- og aðgangsaðgerð samkvæmt grein 5(3) í ePrivacy tilskipuninni, sem krefst fyrirfram, frjálslegra, sértækra, upplýstra og ótvíræðra samþykkis á Evrópska efnahagssvæðinu, Bretlandi og hvaða lögsögu sem hefur tekið upp sama staðal. Að grípa hegðunarviðburði tengda þessu auðkenni er vinnsla persónuupplýsinga samkvæmt GDPR. Auðgun með þriðja aðilagögnum kynnir til sögunnar annað stjórnandasamband. CCPA og CPRA flokka sömu vinnslu sem sölu eða deilingu nema útgefandinn hafi rétt afmarkað þjónustuveitusamning við Amplitude — sem er í boði, en aðeins ef samþætting er stillt til að slökkva á auglýsingareiginleikum.

Hvað safnar Amplitude fyrir samþykki — og hvað þarf að bæla

Algengasta framkvæmdavillan er að meðhöndla Amplitude sem léttt greiningartæki sem getur keyrt við hliðina á kúkuborðanu. Það getur það ekki. Við sjálfgefna amplitude.init() kall mun SDK, innan fyrstu málunar síðunnar, skrifa að minnsta kosti eina kúku eða staðbundinn geymsluatriðis, senda auðkenningarkall og byrja að biðraða viðburði. Ekkert af því er leyfilegt áður en notandi hefur sannfærilega samþykkt viðkomandi samþykktisflokkinn.

Samkvæmur samþætting verður því að seinka amplitude.init() þar til CMP hefur merkt að greiningarsamþykktarflokkurinn hefur verið veittur. SDK á alls ekki að hlaðast frá samþykkisskerðum <script> tagi sem er háð tilgangi 8 (greining) eða tilgangi 1 (geymsla og aðgangur) merki CMP, allt eftir því hvaða ramma CMP afhjúpar. Ef SDK verður að hlaðast fyrr — til dæmis vegna þess að það er bundið inn í forritskóðann og er ekki hægt að sækja seint — ætti frumstillingarkallið að senda defaultTracking: false og optOut: true þannig að engir viðburðir séu sendir út þar til samþykki er skráð, og þá ætti frestar opt-in viðburður að snúa við þessum fánum.

Kúkurnar og geymslan sem Amplitude skrifar

Browser SDK 2.x skrifar eina fyrstaðilakúku að nafni AMP_{apiKey} að sjálfgefnu, með eins árs gildistíma, sem inniheldur tækjaauðkennið og lotafrumlýsigögn. Eldri útgáfur skrifuðu einnig amplitude_id_{apiKey}. Farsíma SDK halda sama auðkenninu inni í sandkassageymslu forritsins. Lotaendurspilun bætir annarri kúku við, AMP_MKTG_{apiKey}, og auðgunarsamstarfsaðilar Amplitude geta sett upp viðbótar þriðja aðilakúkur ef tilraunaskilun eða hópeiningar eru virkjaðar. Allar þessar eru ekki nauðsynlegar og krefjast samþykkis.

Kortlagning Amplitude á samþykkisramma

Amplitude útfærir ekki Google Consent Mode v2, IAB TCF eða IAB Global Privacy Platform á innbyggðan hátt. Það er ekki galli — Amplitude er greiningarvettvangur fyrsta aðila, ekki auglýsingatæknileverandör — en það þýðir að samþætttingarábyrgðin hvílir á útgefandanum. Mynstrið sem virkar í reynd er að meðhöndla hvern Amplitude eininga sem aðskilinn samþykktsgátt og binda hann við ákveðið merki sem CMP afhjúpar nú þegar.

• Kjarnagreiningur viðburðir bindast við greiningartilganginn. Í TCF skilmálum er þetta oftast tilgangur 8 (mæla efnisárangur) ásamt tilgangi 1 (geyma og/eða fá aðgang að upplýsingum). Fyrir Google Consent Mode kortleggst þetta á analytics_storage.
• Lotaendurspilun ætti að vera á bak við strangara merki. Endurspilun tekur upp sýnda DOM, þar á meðal eyðublaðsgildi nema þau séu sérstaklega leyndir, þannig að aðskilið opt-in preferences eða functional er viðeigandi, og endurspilun ætti að vera sjálfgefið slökkt jafnvel þegar greining er veitt.
• Hópar, markhópar og þriðja aðilaauðgun bindast við markaðstilganginn. Í TCF skilmálum er þetta tilgangur 7 (mæla auglýsingaárangur) eða tilgangur 9 (beita markaðsrannsóknum). Fyrir Google Consent Mode kortleggst þetta á ad_storage og ad_user_data.
• Tilraunagerð — Amplitude Experiment getur keyrt með nafnlausri, skammvinnri úthlutun á grundvelli lögmætra hagsmuna, en varanleg úthlutun bundin notandaauðkenni krefst sama samþykkis og kjarnagreining.

Samþætttingarmynstrið sem virkar

Tilvísunarútfærslunin sem lifir af yfirferð eftirlitsaðila hefur fjóra hreyfanlega hluta: CMP sem afhjúpar rauntímaviðburð þegar notandinn breytir samþykki, seinkað SDK-hleðsla sem sækir aðeins Amplitude eftir að þessi viðburður kveikir fyrir viðkomandi flokk, lotastigsvarðmaður sem virðir opt-out án þess að missa fyrri nafnlaust tækjaauðkenni notandans þar sem lög leyfa, og netþjónahlið fyrir viðburði sem þurfa sannarlega innheimtu óháð samþykki — svo sem öryggisfjarmæling eða svikagreining — leidd í gegnum sérstakan endapunkt með eigin lagagrundvell.

Vefútfærsla

Á vefnum er hreinasta mynstrið að afhjúpa samþykkisástand CMP í gegnum window.__cmp_consent hlut eða staðlað __tcfapi endurköll, og síðan láta lítið ræsiforritsskrift gerast áskrifandi að samþykkisbreytingum. Þegar greiningarsamþykki snýst úr ósatt í satt, sækir ræsiforritið Amplitude SDK frá CMP-stýrðum CDN, kallar amplitude.init(apiKey, undefined, { defaultTracking: true }), og endurspila þá viðburði sem biðraðast voru í minni meðan samþykki var í bið. Þegar samþykki snýst aftur í ósatt kallar ræsiforritið amplitude.setOptOut(true), hreinsar AMP_ kúkuna í gegnum document.cookie gildistíma, og fjarlægir hvaða stöðu sem er í minni. Mikilvægt er að ræsiforritið megi aldrei seinlega frumstilla Amplitude í sömu beiðniflæðinu og borðafletjauppgjörin — SDK verður að bíða eftir skýrri veitingu.

Farsímaútfærsla

Á iOS er jafngildi þess að halda Amplitude ramma innfluttum en seinka Amplitude.instance().initialize(apiKey: apiKey) þar til samþykkisflæðið í forritinu hefur skilað jákvæðu greiningumerki. ATT kvaðning er aðskilið mál: ATT stjórnar IDFA, á meðan auðkenni Amplitude er eigið UUID SDK sem geymt er í forritsssandkassanum. Bæði krefjast samþykkis á EEA, en lagagrundvellir og kvaðningar eru aðskildar. Á Android gildir sama rök með Amplitude.getInstance().initializeApolloClient() eða jafngildi eftir SDK útgáfu.

Netþjónahlið

Amplitude styður netþjónainnlagningu í gegnum HTTP V2 API. Netþjónaviðburðir eru ekki undanþegnir samþykki — lagagrundvöllurinn fylgir gögnum, ekki flutningstæki — en netþjónainnlögn gefur útgefandanum fullan stjórn á því hvaða reiti eru sendir, sem gerir það auðveldara að virða hlutasamþykki. Algengt mynstur er að sækja lágmarks-nauðsynleg atriði eingöngu á netþjónahlið á grundvelli lögmætra hagsmuna, og aðeins auðga þessa viðburði með hegðunarsmáatriðum eftir að notandinn hefur veitt greiningarsamþykki á biðlaranum.

Staðfesting samþætttingarinnar

Staðfestingarskrefið er það sem útgefendur sleppa oftast og eftirlitsaðilar athuga oftast. Rétt samþætt Amplitude dreifing ætti að standast fjórar athuganir. Í fyrsta lagi ætti vafri með samþykkisborða sýndur en enginn kostur gerður að framleiða núll beiðnir til api.amplitude.com eða api.eu.amplitude.com og núll AMP_ kúkur í document.cookie. Í öðru lagi ætti hafnun á greiningaflokknum að halda þessu ástandi — engir viðburðir, engar kúkur, engar staðbundnar geymsluatriðis með AMP_ forskeyti. Í þriðja lagi ætti samþykki á greining að framleiða eina identify á eftir viðburðaumferð, og AMP_ kúkan ætti að birtast með SameSite eigind sem er í samræmi við CMP stefnu útgefandans. Í fjórða lagi ætti afturköllun samþykkis á eftir að stöðva frekari viðburði tafarlaust og hreinsa geymdar auðkenningar — seinkuð hreinsun er niðurstaða.

Endurskoðunarsporið skiptir máli sérstaklega. Samkvæmt EDPB 2023 kúkuborðaleiðbeiningum og endurnýjuðum 2026 verkefnishópforgangsröðun búast eftirlitsaðilar við að útgefandinn geti sannað, fyrir hvern viðburð í Amplitude verkefninu, að notandinn sem bjó hann til hafi gefið gilt samþykki á þeim tíma sem hann var tekinn upp. Það krefst þess að samþykktsskrá CMP sé fyrirspurnarhæf eftir tækjaauðkenni eða lotaauðkenni, og að Amplitude viðburðarfarmi beri samþykktarútgáfureit sem tengist aftur í þá skrá. Að geyma samþykktarstrenginn sem sérsniðna notandaeiginleika á hverjum viðburði er einfaldasta leiðin til að gera þetta tengsl endurskoðunarhæft.

Val á réttu svæði og gagnageymslustaðsetningu

Amplitude rekur tvær framleiðslusvæði: Bandaríkin (api.amplitude.com) og ESB (api.eu.amplitude.com). Fyrir EEA og breska umferð er ESB svæðið rétt sjálfgefna — það heldur gögnum inni á EEA og dregur úr flutningsáhættuyfirborði sem Schrems II dómurinn og EU-US Data Privacy Framework hafa gert miðlægt í hverri greiningaryfirferð. Skipt um svæði er ekki afturvirkt: fyrirliggjandi gögn eru þar sem þau voru fyrst innlögð. Fyrir útgefendur sem eru að skipuleggja CMP dreifingu er þess vegna vert að staðfesta svæðið áður en þess er breytt, og vert að skjalfesta valið í persónuverndaryfirlýsingunni þannig að löglegar heimildarkeðjan er hreinn frá safni til geymslu. Rétt valið svæði, parað við rétt girt SDK og fyrirspurnarhæfa samþykktsskrá, er það sem breytir Amplitude dreifingu úr reglugerðaráhættu yfir í varnarfæran hluta greiningarstafla.