Ką Clarity iš tikrųjų įrašo

Clarity SDK (įkeliama iš www.clarity.ms/tag/{project_id}) inicializuoja globalų clarity objektą ir identifikuoja lankytojus naudojant Microsoft priklausantį slapuką _clck ir sesijos slapuką _clsk. Nuo to momento scenarijus fiksuoja tankų elgesio srautą:

• Pelės ir lietimo įvestis — kiekvienas judesys, paspaudimas, prisilietimas, slinkimas ir gestas įrašomas su laiko žyma ir koordinatėmis.
• Formų sąveikos — fokusavimo, suliejimo ir įvesties įvykiai kiekviename formos lauke, taip pat nejautriųjų laukų tekstas, jei maskavimas nesukonfigūruotas.
• DOM momentinės kopijos — periodinės visos puslapio DOM momentinės kopijos, kad sesijų atkūrimas galėtų tiksliai atkurti vaizdinę būseną bet kuriuo metu.
• Pasirinktiniai įvykiai — bet kokie įvykiai, kuriuos programa aiškiai išsiunčia per clarity("event", "name") iškvietimus.
• Našumo ir klaidų duomenys — JavaScript klaidos, tinklo gedimai ir pagrindinių žiniatinklio gyvybinių rodiklių laikas.
• Identifikatoriaus duomenys — Clarity priklausantis slapukas ir IP pagrįsta geografinė vieta bei naudotojo agento pirštų atspaudų nuėmimas.

Šis derinys — ypač DOM momentinės kopijos ir formų laukų fiksavimas — daro Clarity funkciniu ekvivalentu lankytojo sesijos vaizdo įrašui. Reguliavimo klasifikavimas pagal GDPR yra paprastas: tai yra asmens duomenų tvarkymas, slapukai nėra esminiai, duomenys kerta sienas į Microsoft JAV infrastruktūrą, o reikiamas teisinis pagrindas yra sutikimas. CNIL 2024 metų vadovas dėl sesijų įrašymo yra nedviprasmiškas šiuo klausimu ir aiškiai įvardija įrankius Clarity kategorijoje.

Jautrių duomenų rizika

Sesijų įrašymo įrankiai turi specifinę privatumo grėsmę, kurios kiti analitikos įrankiai neturi: jie gali atsitiktinai fiksuoti jautrūs asmens duomenis. Naudotojas, įvedantis kredito kortelės numerį, sveikatos būklę, religinę priklausomybę arba nacionalinį identifikatorių bet kuriame formos lauke, bus Clarity įrašomas, jei laukas nėra aiškiai užmaskuotas. Pagal GDPR tai yra Article 9 jautrių asmens duomenų tvarkymas, kuriam reikalingas aiškus sutikimas ir kurio retai apima bendra rinkodaros sutikimo sprendimas.

Clarity palaiko turinio maskavimo konfigūraciją, kuri paslepia konkrečius laukus nuo įrašymo, tačiau numatytasis elgesys fiksuoja viską. Audito atsparios požiūris yra agresyvus maskavimas — laikant kiekvieną formos lauką jautriu, kol neįrodyta priešingai — ir aiškus maskavimo sprendimų dokumentavimas.

Natyvūs Clarity privatumo valdikliai

Microsoft per pastaruosius dvejus metus investavo į Clarity privatumo valdiklius. Platforma dabar atskleidžia keletą primityviųjų, kuriuos gali panaudoti CMP integracija.

Maskavimo atributas

Pridėjus data-clarity-mask="true" prie DOM elemento, jo turinys slepiamas nuo sesijų įrašymo. Pridėjus data-clarity-unmask="true" prie vaiko elemento, pakeičiama to pomedžio kaukė. Tinkamas numatytasis bet kuriam formos laukui, kuriame gali būti asmens duomenų, yra maskavimas, o tada aiškus atkaukavimas ten, kur tai saugu.

Sutikimo API

Clarity atskleidžia clarity("consent") iškvietimą, kuris, kai iškviečiamas, signalizuoja, kad sutikimas buvo suteiktas ir SDK turėtų tęsti. Be šio iškvietimo SDK gali būti sukonfigūruota sustoti po pradinio įkėlimo. Tai tinkamas primityvus CMP integracijai aktyvavimo pusėje.

IP maskavimas ir identifikatoriaus tvarkymas

Clarity projekto nustatymai atskleidžia IP sutrumpinimo ir identifikatoriaus maskavimo parinktis. Jų įjungimas yra giluminės gynybos priemonė, papildanti CMP ribojimą; tai nepakeičia sutikimo.

Automatinis jautraus turinio maskavimas

Naujausios Clarity versijos bando automatiškai aptikti jautrius laukus (kredito korteles, slaptažodžių laukus, "ssn" ar panašiai pavadintus laukus) ir pagal nutylėjimą juos maskuoti. Aptikimas yra euristinis ir neišsamus; nepasikliaukite juo kaip vienintele gynybos linija.

CMP integravimas žingsnis po žingsnio

Patikima architektūra — visiškai atidėti Clarity SDK iki sutikimo suteikimo, tada jį aiškiai aktyvuoti per sutikimo API.

1. Pašalinkite numatytąjį žymą iš dokumento antraštės

Clarity diegimo iškarpa yra vienas įterptinis scenarijus, kuris inicializuoja SDK puslapio įkėlimo metu. Pakeiskite jį vietos žymiklio scenarijaus elementu, kurio type yra text/plain ir kurio data-category yra analytics arba marketing, priklausomai nuo to, kaip jūsų CMP kategorizuoja sesijų įrašymo įrankius.

2. Apsispręskite dėl kategorijų susiejimo

Sesijų įrašymas yra ginčijama kategorija. CNIL ją traktavo įvairiai — kaip analitiką (kai duomenys naudojami vidaus UX tyrimams) ir kaip rinkodarą (kai duomenys maitina personalizavimo sprendimus ar išorinį dalijimąsi). Konservatyvus susiejimas yra rinkodara; audito atspari pozicija reikalauja konkretumo, kaip įrašai iš tikrųjų naudojami.

3. Sukonfigūruokite agresyvų maskavimą prieš aktyvavimą

Pridėkite data-clarity-mask="true" prie kiekvieno formos elemento, kiekvieno įvesties lauko, kiekvieno konteinerio, kuriame gali būti asmens duomenų. Numatytoji politika yra maskavimas pagal nutylėjimą su aiškiomis atkaukavimo išimtimis elementams, apie kuriuos žinoma, kad jie yra saugūs (puslapių pavadinimai, naršymo etiketės, viešo turinio blokai).

4. Aktyvuokite Clarity iš sutikimo atgalinio iškvietimo

Kai CMP suaktyvina atitinkamą kategorijos priėmimo įvykį, perrašykite vietos žymiklio scenarijaus žymą ir iškvieskite clarity("consent"), kad SDK gautų leidimą tęsti. Eilėje laukiantys įvykiai, buferinti išankstinio sutikimo laikotarpiu, tada bus iššvirkšti.

5. Aiškiai tvarkykite atšaukimą

Jei naudotojas atšaukia sutikimą, Clarity SDK neturi švario įrašymo sustabdymo iškvietimo, lygiaverčio aktyvavimo API. Praktinis modelis yra iškviesti clarity("consent", false), jei tai palaikoma jūsų SDK versijoje, ir papildomai išvalyti Clarity slapukus kliento pusėje. Visam istorinių įrašų ištrynimui naudokite Clarity administravimo UI duomenų ištrynimo darbo eigą arba ištrynimo API.

Dažnos kliūtys

Keturios integravimo klaidos sudaro daugumą audito išvadų Clarity diegimuose.

Clarity diegimas tik tam, kad pamatytume, ką daro lankytojai

Dažniausias modelis: produkto vadybininkas įdiegia Clarity UX problemai tirti, niekada neįgalina sutikimo ribojimo, niekada nekonfigūruoja maskavimo ir pamiršta scenarijų. Įrašymo paviršius toliau kaupiasi. Taisymas — visiškai pašalinti Clarity arba perkelti jį po ta pačia sutikimo architektūra kaip ir kiekvienas kitas sekiklis.

Automatiniam maskavimui pasitikėjimas

Clarity euristinis jautrių laukų aptikimas fiksuoja akivaizdžius atvejus, tačiau praleidžia specifinius domenui — sveikatos priežiūros svetainės simptomų tekstinį lauką, finansų svetainės idiosinkratiniu pavadinimu sąskaitos numerio lauką. Maskuokite aiškiai; nepasikliaukite aptikimu.

Sesijų įrašymo traktavimas kaip analitika

CNIL aiškiai pareiškė, kad sesijų įrašymo kategorija yra arčiau rinkodaros nei pirmos šalies analitikos sutikimo požiūriu. Clarity ribojimas tik analitikos sutikimu gali būti ginamas tik tuo atveju, jei įrašai naudojami išimtinai vidaus UX tyrimams ir niekada nesidalijama už organizacijos ribų.

Pasirinktinių įvykių krovinių pamiršimas

Programos kodas, iškviečiantis clarity("event", "name", customProperties), gali nutekinti asmens duomenis į Clarity srautą per customProperties krovinį. Patikrinkite kiekvieną iškvietimo vietą ir venkite naudotojų identifikatorių, el. pašto adresų ar bet kokių asmens duomenų perdavimo įvykių ypatybėse.

Audito kontrolinis sąrašas

Šeši konkretūs klausimai, į kuriuos reikia atsakyti bet kokiam Clarity diegimui, lietis EU, UK, Brazilijos ar Kalifornijos srautui.

• Ar Clarity laukia sutikimo? Atidarykite puslapį privačiame lange ir patvirtinkite, kad jokios clarity.ms užklausos nesutrikdomos prieš priimant reklamjuostę.
• Ar maskavimas agresyvus? Patvirtinkite, kad kiekvienam formos laukui ir kiekvienam konteineriui su potencialiai asmeniniu turiniu pritaikytas data-clarity-mask.
• Ar kategorijų susiejimas dokumentuotas? Patvirtinkite, kad yra rašytinis įrašas, ar Clarity yra ribojamas pagal analitiką ar rinkodarą, su pagrindžiamuoju paaiškinimu.
• Ar sutikimo API sujungta? Patvirtinkite, kad CMP atgalinis iškvietimas iškviečia clarity("consent") suteikiant ir atitinkamą atšaukiant.
• Ar pasirinktiniai įvykiai audituoti? Patvirtinkite, kad clarity("event", ...) iškvietimai nenurodo identifikuojančių ar jautrių duomenų savybių kroviniuose.
• Ar ištrynimas automatizuotas? Patvirtinkite, kad DSAR užklausos suaktyvina Clarity ištrynimo darbo eigą, o ne rankinį palaikymo bilietą.

Kur Clarity tinka į sutikimo pirmą eiliją

Sesijų įrašymas yra elgesio sekimo paviršius su didžiausiu informacijos tankiu bendrame diegime, o Clarity yra įrankis, kuris tai demokratizavo agresyviausiai. Nemokamas kainodaros lygis ir trintis ruda diegimas daro jį mažiausio pasipriešinimo keliu bet kuriai komandai, kuri nori matomumo į UX elgesį. Tas pats trinties nediegimas yra tai, kas daro Clarity labiausiai dažnai klaidingai sukonfigūruotu analitikos įrankiu 2026 metų audituose. Tinkama architektūra traktuoja Clarity kaip bet kurį kitą identifikuojantį sekiklį: riboja jį už aiškaus sutikimo, pagal nutylėjimą agresyviai maskuoja formos laukus, dokumentuoja kategorijų susiejimą ir sujungia sutikimo API, kad SDK savieji primityviečiai vykdytų tai, ką CMP įrašė. Tinkamai atlikta, UX tyrimų vertė, dėl kurios įrankis buvo pirktas, išsaugoma, o reguliavimo poveikis sumažėja iki dalies to, ką neša numatytasis diegimas.