Microsoft Clarity munkamenet-rögzítési cookie-beleegyezési integrációs útmutató 2026-ra
A Microsoft Clarity 2020-ban jelent meg ingyenes, kvótamentes alternatívaként a Hotjar és a Smartlook munkamenet-rögzítési, hőtérkép- és interakcióelemzési megoldásaival szemben. Öt évvel később a világ közép- és kisvállalkozásainak webhelyein számottevő részesedéssel bír, részben azért, mert valóban hasznos, részben pedig azért, mert a telepítés egyetlen sor JavaScript, amelyet a legtöbb üzemeltető további megfontolás nélkül illeszt be. Adatvédelmi szempontból pontosan ez a könnyű telepíthetőség a probléma. A Clarity rögzíti az egérmozdulatokat, a görgetési viselkedést, a kattintásokat, a billentyűleütéseket, az ürlapinterakciókat és a teljes oldal DOM-pillanatképeit, és a szkript betöltésének pillanatától mindent továbbít a Microsoft szervereire. Az EU-, UK-, EEA-, brazil vagy kaliforniai forgalmat érintő bármely telepítés esetén az alapértelmezett konfiguráció nem megfelelő, és a munkamenet-rögzítés betartatásában legaktívabb hatóságok — a CNIL, az olasz Garante, az UK ICO — egyértelműen kijelentették, hogy az elemzés az eszköz árkategóriájától vagy gyártójától függetlenül érvényes. Ez az útmutató bemutatja, mit rögzít a Clarity, hogyan működik a beleegyezési határ, és milyen az auditot kiálló integrációs minta.
Mit rögzít valójában a Clarity
A Clarity SDK (a www.clarity.ms/tag/{project_id} címről töltve be) inicializál egy globális clarity objektumot, és a látogatókat egy Microsoft-tulajdonú _clck nevű sütivel, valamint egy _clsk munkamenet-sütivel azonosítja. Ettől a pillanattól a szkript sűrű viselkedési adatfolyamot rögzít:
- Egér- és érintőbemenetek — minden mozgás, kattintás, érintés, görgetés és mozdulat rögzítésre kerül időbélyeggel és koordinátákkal.
- Ürlapinterakciók — fókusz-, blur- és beviteli események minden ürlapmezőn, valamint az érzékeny mezők szövege, ha a maszkálás nincs konfigurálva.
- DOM-pillanatképek — az oldal DOM rendszeres teljes pillanatképei, hogy a munkamenet-visszajátszás bármely pillanatban pontosan rekonstruálhassa a vizuális állapotot.
- Egyéni események — az alkalmazás által a clarity("event", "name") hívásokkal explicit módon kibocsátott események.
- Teljesítmény- és hibaadatok — JavaScript-hibák, hálózati meghibásodások és alapvető webes életjelek időzítései.
- Azonosítóadatok — a Clarity-tulajdonú süti, valamint IP-alapú geolokáció és felhasználói ügynök ujjlenyomata.
A kombináció — különösen a DOM-pillanatképek és az ürlapmező-rögzítés — funkcionálisan egyenértékűvé teszi a Clarity-t a látogató munkamenetének videofelvételével. A GDPR szerinti szabályozási besorolás egyértelmű: személyes adatok feldolgozásáról van szó, a sütik nem alapvetők, az adatok a Microsoft US-infrastruktúrájára kerülnek, és a szükséges jogalap a beleegyezés. A CNIL 2024-es munkamenet-rögzítési útmutatója ezen a ponton egyértelmű, és explicit módon nevezi meg a Clarity kategóriájába tartozó eszközöket.
Az érzékeny adatok kockázata
A munkamenet-rögzítő eszközöknek van egy specifikus adatvédelmi veszélyük, amellyel más elemzőeszközök nem rendelkeznek: véletlenül rögzíthetnek érzékeny személyes adatokat. Az a felhasználó, aki bankkártyaszámot, egészségügyi állapotot, vallási hovatartozást vagy személyi azonosítót gépel bármely ürlapmezőbe, rögzítésre kerül a Clarity által, ha a mező nincs explicit módon maszkálva. A GDPR értelmében ez az Article 9 szerinti érzékeny személyes adatok feldolgozása, amely explicit hozzájárulást igényel, és ritkán fedezi egy általános marketing-beleegyezési döntés.
A Clarity támogat egy tartalommaszkálási konfigurációt, amely elrejti a konkrét mezőket a rögzítésből, de az alapértelmezett viselkedés mindent rögzít. Az auditvédett megközelítés az agresszív maszkálás — minden ürlapmezőt érzékenynek feltételezve, amíg az ellenkezője be nem bizonyosodik — és a maszkálási döntések explicit dokumentálása.
A Clarity natív adatvédelmi vezérlői
A Microsoft az elmúlt két évben befektetett a Clarity adatvédelmi vezérlőibe. A platform mostanra több primitívet is elérhetővé tett, amelyeket egy CMP-integráció kiaknázhat.
A maszk attribútum
A data-clarity-mask="true" hozzáadása egy DOM-elemhez elrejti annak tartalmát a munkamenet-rögzítésből. A data-clarity-unmask="true" hozzáadása egy gyermekelemhez felülbírálja a maszkot az adott részfánál. A megfelelő alapértelmezett bármely személyes adatot tartalmazható ürlapmező esetén a maszkálás, majd az explicit maszk feloldása a biztonságos helyeken.
A beleegyezési API
A Clarity elérhetővé tesz egy clarity("consent") hívást, amely meghívásakor jelzi, hogy a beleegyezés megadásra került, és az SDK folytathatja. E hívás nélkül az SDK konfigurálható úgy, hogy a kezdeti betöltés után leálljon. Ez a megfelelő primitív a CMP-integráció aktiválási oldalán.
IP-maszkálás és azonosítókezelés
A Clarity projektbeállításai lehetőségeket kínálnak az IP-csonkolásra és az azonosítómaszkálásra. Ezek engedélyezése mélyített védelmi intézkedés a CMP-kapuzás felett; nem helyettesíti a beleegyezést.
Érzékeny tartalom automatikus maszkálása
A legutóbbi Clarity-kiadások megkísérlik automatikusan felismerni az érzékeny mezőket (bankkártyaminták, jelszómezők, “ssn” vagy hasonló nevű mezők) és alapértelmezés szerint maszkot alkalmaznak. A felismerés heurisztikus és hiányos; ne hagyatkozzunk rá egyetlen védelmi vonalként.
Lépésről lépésre: CMP-integráció
A megbízható architektúra az, hogy a Clarity SDK-t teljesen elhalasztjuk a beleegyezés megadásáig, majd explicit módon aktiváljuk a beleegyezési API-n keresztül.
1. Távolítsa el az alapértelmezett taget a dokumentum fejlécéből
A Clarity telepítési kódrészlete egyetlen beágyazott szkript, amely inicializálja az SDK-t az oldal betöltésekor. Cserélje le egy helyőrző szkript elemre, amelynek type értéke text/plain, és amelynek data-category értéke analytics vagy marketing, attól függően, hogy a CMP hogyan kategorizálja a munkamenet-rögzítő eszközöket.
2. Döntse el a kategórialeképezést
A munkamenet-rögzítés vitatott kategória. A CNIL hol analitikusként kezelte (amikor az adatokat belső UX-kutatáshoz használják), hol marketingként (amikor az adatok személyre szabási döntéseket vagy külső megosztást táplálnak). A konzervatív leképezés a marketing; az auditvédett álláspont megköveteli, hogy pontosan meghatározza, hogyan használják ténylegesen a felvételeket.
3. Konfigurálja az agresszív maszkálást az aktiválás előtt
Adjon hozzá data-clarity-mask="true" minden ürlapmezőhöz, minden beviteli mezőhöz, minden személyes adatot tartalmazható tárolóhoz. Az alapértelmezett irányelv az alapértelmezett maszkálás, explicit maszk feloldási kivételekkel az ismerten biztonságos elemekhez (oldalcímek, navigációs feliratok, nyilvános tartalomblokkok).
4. Aktiválja a Clarity-t a beleegyezési visszahívásból
Amikor a CMP elindítja a vonatkozó kategória-elfogadási eseményt, írja át a helyőrző szkript taget és hívja meg a clarity("consent") funkciót az SDK folytatási engedélyének megadásához. A beleegyezés előtti időszakban pufferelt sorban álló események ekkor töltődnek ki.
5. A visszavonás explicit kezelése
Ha a felhasználó visszavonja a beleegyezést, a Clarity SDK-nak nincs tiszta rekordleállító hívása, amely egyenértékű lenne az aktiválási API-val. A gyakorlati minta a clarity("consent", false) meghívása, ha az SDK-verzió támogatja, és ezenkívül az ügyfél oldalán a Clarity sütik törlése. A korábbi felvételek teljes törléséhez használja a Clarity adminisztrációs felületének adattörlési munkafolyamatát vagy a törlési API-t.
Általános buktatók
Négy integrációs hiba teszi ki a Clarity-telepítések auditjain talált megállapítások többségét.
A Clarity telepítése — csak azért, hogy lássuk, mit csinálnak a látogatók
A leggyakoribb minta: egy termékmenedzser telepíti a Clarity-t egy UX-probléma kutatásához, soha nem engedélyezi a beleegyezési kapuzást, soha nem konfigurálja a maszkálást, és elfelejti a szkriptet. A rögzítési felület tovább halmozódik. Az orvoslás: vagy teljesen eltávolítják a Clarity-t, vagy ugyanolyan beleegyezési architektúra alá vonják, mint minden más követőeszközt.
Az automatikus maszkálásban való bizakodás
A Clarity heurisztikus érzékeny mező felismerése elkapja a nyilvánvaló eseteket, de kihagyja a tartomány-specifikusakat — egy egészségügyi oldal tünetek szövegmezőjét, egy pénzügyi oldal idiosinzkratikus nevű számlaszám mezőjét. Maszkáljunk explicit módon; ne hagyatkozzunk a felismerésre.
A munkamenet-rögzítés analitikusként való kezelése
A CNIL egyértelműen kijelentette, hogy a munkamenet-rögzítési kategória beleegyezési szempontból közelebb áll a marketinghez, mint az első féltől származó analitikához. A Clarity analitikai-beleegyezési kapu alá helyezése csak akkor védhető, ha a felvételeket kizárólag belső UX-kutatáshoz használják, és soha nem osztják meg a szervezeten kívül.
Az egyéni esemény adattartalmainak elfelejtése
Az olyan alkalmazáskód, amely a clarity("event", "name", customProperties) funkciót hívja, személyes adatokat szivárogtathat a Clarity-adatfolyamba a customProperties adatterhelésen keresztül. Auditálja az összes hívási helyet, és kerülje a felhasználói azonosítók, e-mail-címek vagy bármely személyes adat átadását az esemény tulajdonságokban.
Audit-ellenőrzőlista
Hat konkrét kérdés, amelyet meg kell válaszolni minden EU-, UK-, brazil vagy kaliforniai forgalmat érintő Clarity-telepítés esetén.
- Megvárja-e a Clarity a beleegyezést? Nyissa meg az oldalt privát ablakban, és ellenőrizze, hogy az értesítési sáv elfogadása előtt nem kerül elküldésre clarity.ms kérés.
- Agresszív-e a maszkálás? Ellenőrizze, hogy minden ürlapmező és minden potenciálisan személyes adatot tartalmazó tároló rendelkezik-e a data-clarity-mask attribútummal.
- Dokumentált-e a kategórialeképezés? Ellenőrizze, hogy van-e írásos feljegyzés arról, hogy a Clarity analitika vagy marketing alatt van-e kapuzva, az indoklással együtt.
- Be van-e kötve a beleegyezési API? Ellenőrizze, hogy a CMP visszahívása meghívja-e a clarity("consent") funkciót megadáskor és az egyenértékűt visszavonásakor.
- Auditáltak-e az egyéni események? Ellenőrizze, hogy a clarity("event", ...) hívások nem adnak-e át azonosító vagy érzékeny adatokat a tulajdonság adatterheleikben.
- Automatizált-e a törlés? Ellenőrizze, hogy a DSAR-kérések elindítják-e a Clarity törlési munkafolyamatát, és nem manuális támogatási jegyet igényelnek-e.
Hol helyezkedik el a Clarity a beleegyezés-első veremben
A munkamenet-rögzítés a legmagasabb információsűrűségű viselkedési nyomon követési felület az általánosan alkalmazott megoldások között, és a Clarity az az eszköz, amely a legtöbb erővel demokratizálta azt. Az ingyenes árszint és a súrlódásmentes telepítés az ellenállás legcsekélyebb útjává teszi minden olyan csapat számára, amely láthatóságot szeretne az UX-viselkedésbe. Ugyanez a súrlódásmentes telepítés az, ami a Clarity-t a 2026-os auditok leggyakrabban helytelenül konfigurált elemzőeszközévé teszi. A megfelelő architektúra a Clarity-t ugyanolyan azonosító követőként kezeli, mint minden más: explicit beleegyezés mögé kapuzza, alapértelmezés szerint agresszívan maszkál az ürlapmezőkön, dokumentálja a kategórialeképezést, és bekötik a beleegyezési API-t, hogy az SDK saját primitívei érvényesítsék azt, amit a CMP rögzített. Ha helyesen van megvalósítva, az eszköz megvásárlásának alapját képező UX-kutatási érték megmarad, míg a szabályozási kitettség az alapértelmezett telepítés által hordozottak töredékére csökken.