Hva Clarity faktisk registrerer

Clarity SDK (lastet fra www.clarity.ms/tag/{project_id}) initialiserer et globalt clarity-objekt og identifiserer besøkende med en Microsoft-eid informasjonskapsel kalt _clck, sammen med en økt-informasjonskapsel _clsk. Fra det øyeblikket fanger skriptet en tett atferdsstrøm:

• Mus- og berøringsinput — hver bevegelse, klikk, trykk, rull og gest registreres med tidsstempel og koordinater.
• Skjemainteraksjoner — fokus-, blur- og inputhendelser på hvert skjemafelt, pluss teksten til ikke-sensitive felt hvis maskering ikke er konfigurert.
• DOM-øyeblikksbilder — periodiske fullstendige øyeblikksbilder av siden-DOM slik at øktavspillingen kan rekonstruere den nøyaktige visuelle tilstanden til enhver tid.
• Tilpassede hendelser — alle hendelser som applikasjonen eksplisitt sender ut via clarity("event", "name")-kall.
• Ytelses- og feildata — JavaScript-feil, nettverksfeil og tidsangivelser for kjerne-webvitaler.
• Identifikatordata — Clarity-informasjonskapselen pluss IP-utledet geolokasjon og brukeragent-fingeravtrykk.

Kombinasjonen — særlig DOM-øyeblikksbildene og skjemafeltinnhentingen — gjør Clarity funksjonelt ekvivalent med en videoopptak av besøkendes økt. Den regulatoriske klassifiseringen under GDPR er entydig: dette er behandling av personopplysninger, informasjonskapslene er ikke-essensielle, dataene krysser grenser til Microsofts amerikanske infrastruktur, og det nødvendige rettslige grunnlaget er samtykke. CNILs 2024-veiledning om øktopptak er utvetydig på dette punktet og nevner eksplisitt verktøy i Claritys kategori.

Risikoen for sensitive data

Øktopptaksverktøy har en spesifikk personvernfare som andre analytikkverktøy ikke har: de kan utilsiktet fange opp sensitive personopplysninger. En bruker som skriver inn et kredittkortnummer, en helsetilstand, en religiøs tilhørighet eller et nasjonalt identifikasjonsnummer i et skjemafelt, registreres av Clarity dersom feltet ikke er eksplisitt maskert. Under GDPR er dette behandling av sensitive personopplysninger etter Article 9, som krever eksplisitt opt-in-samtykke og sjelden dekkes av en generell markedsføringsamtykkebeslutning.

Clarity støtter en innholdsmaskingkonfigurasjon som skjuler spesifikke felt fra opptak, men standardatferden fanger opp alt. Den revisjonsforsvarbare tilnærmingen er å maskere aggressivt — anta at hvert skjemafelt er sensitivt inntil det motsatte er bevist — og å dokumentere maskingbeslisningene eksplisitt.

Innebygde personvernkontroller i Clarity

Microsoft har investert i Claritys personvernkontroller de siste to årene. Plattformen eksponerer nå flere primitiver som en CMP-integrasjon kan benytte seg av.

Maskeringsattributtet

Å legge til data-clarity-mask="true" på et DOM-element skjuler innholdet fra øktopptaket. Å legge til data-clarity-unmask="true" på et underelement overstyrer masken for det undertreet. Riktig standard for ethvert skjemafelt som kan inneholde personopplysninger er å maskere, deretter eksplisitt fjerne masken der det er trygt.

Samtykke-APIet

Clarity eksponerer et clarity("consent")-kall som, når det påkalles, signaliserer at samtykke er gitt og at SDK-en bør fortsette. Uten dette kallet kan SDK-en konfigureres til å stoppe etter innledende lasting. Dette er det rette primitivet for CMP-integrasjon på aktiveringssiden.

IP-maskering og identifikatorhåndtering

Clarity-prosjektinnstillingene eksponerer alternativer for IP-avkorting og identifikatormasking. Å aktivere disse er et forsvarsdybdetiltak på toppen av CMP-gating; det erstatter ikke samtykke.

Automatisk maskering av sensitivt innhold

Nylige Clarity-utgivelser forsøker å automatisk oppdage sensitive felt (kredittkortnummermønstre, passordfelt, felt kalt "ssn" eller lignende) og maskere dem som standard. Deteksjonen er heuristisk og ufullstendig; stol ikke på den som eneste forsvarslinje.

Trinn-for-trinn CMP-integrasjon

Den pålitelige arkitekturen er å utsette Clarity SDK helt til samtykke er gitt, deretter aktivere det eksplisitt via samtykke-APIet.

1. Fjern standard-taggen fra dokumenthodet

Clarity-installasjonsfragmentet er et enkelt inline-skript som initialiserer SDK-en ved sidelasting. Erstatt det med et plassholderskriptelement der type er text/plain og der data-category er analytics eller marketing avhengig av hvordan CMP-en din kategoriserer øktopptaksverktøy.

2. Bestem kategorimapping

Øktopptak er en omstridt kategori. CNIL har behandlet det på ulike måter som analyser (når dataene brukes til intern UX-forskning) og som markedsføring (når dataene mater personaliseringsavgjørelser eller ekstern deling). Den konservative mappingen er markedsføring; den revisjonsforsvarbare posisjonen krever at du er spesifikk om hvordan opptakene faktisk brukes.

3. Konfigurer aggressiv maskering før aktivering

Legg til data-clarity-mask="true" på hvert skjemaelement, hvert inndatafelt, hver beholder som kan inneholde personopplysninger. Standardpolicyen er maskering-som-standard med eksplisitte avmaskerings-unntak for elementer som er kjent trygge (sidetitler, navigasjonsetiketter, offentlige innholdsblokker).

4. Aktiver Clarity fra samtykke-tilbakekallet

Når CMP-en utløser den relevante kategorien-akseptert-hendelsen, omskriver du plassholderskript-taggen og kaller clarity("consent") for å gi SDK-en tillatelse til å fortsette. Køede hendelser som ble bufret i perioden før samtykke, vil da tømmes.

5. Håndter tilbakekalling eksplisitt

Hvis brukeren trekker tilbake samtykket, har Clarity SDK ikke et rent "stopp opptak"-kall som tilsvarer aktiverings-APIet. Det praktiske mønsteret er å kalle clarity("consent", false) hvis dette støttes i din SDK-versjon, og i tillegg slette Clarity-informasjonskapslene på klientsiden. For fullstendig sletting av historiske opptak bruker du dataslettings-arbeidsflyten i Clarity-administrasjonsgrensesnittet eller slette-APIet.

Vanlige fallgruver

Fire integrasjonsfeil utgjør flertallet av revisjonsfunn ved Clarity-distribusjoner.

Installere Clarity «bare for å se hva besøkende gjør»

Det vanligste mønsteret: en produktsjef installerer Clarity for å undersøke et UX-problem, aktiverer aldri samtykkegating, konfigurerer aldri maskering og glemmer skriptet. Opptaksflaten fortsetter å akkumuleres. Utbedringen er enten å fjerne Clarity helt eller å bringe det inn under den samme samtykkearkitekturen som alle andre sporere.

Å stole på automatisk maskering

Claritys heuristiske deteksjon av sensitive felt fanger opp åpenbare tilfeller, men går glipp av domenespesifikke — et "symptomer"-tekstfelt på et helseside, et "kontonummer"-felt på en finansside med et særegent navn. Maskér eksplisitt; stol ikke på deteksjon.

Behandle øktopptak som analyser

CNIL har vært eksplisitt på at kategorien for øktopptak fra et samtykkeperspektiv er nærmere markedsføring enn førstepartsanalyser. Å begrense Clarity under kun analyserelatert samtykke er forsvarlig bare hvis opptakene brukes utelukkende til intern UX-forskning og aldri deles utenfor organisasjonen.

Glemme tilpassede hendelsesnyttelaster

Applikasjonskode som kaller clarity("event", "name", customProperties) kan lekke personopplysninger inn i Clarity-strømmen gjennom customProperties-nyttelasten. Revider hvert kallsted og unngå å sende brukeridentifikatorer, e-postadresser eller personopplysninger i hendelsesegenskaper.

Revisjonskontrolliste

Seks konkrete spørsmål å svare på for enhver Clarity-distribusjon som berører EU-, UK-, brasiliansk eller californisk trafikk.

• Venter Clarity på samtykke? Åpne siden i et privat vindu og bekreft at ingen clarity.ms-forespørsler sendes før banneret er akseptert.
• Er maskering aggressiv? Bekreft at hvert skjemafelt og hver beholder med potensielt personlig innhold har data-clarity-mask pålagt.
• Er kategorimappingen dokumentert? Bekreft at det finnes en skriftlig registrering av om Clarity er begrenset under analyser eller markedsføring, med begrunnelsen.
• Er samtykke-APIet koblet til? Bekreft at CMP-tilbakekallet kaller clarity("consent") ved innvilgelse og tilsvarende ved tilbakekalling.
• Er tilpassede hendelser revidert? Bekreft at clarity("event", ...)-kall ikke sender identifiserende eller sensitive data i egenskapsnyttelastene sine.
• Er sletting automatisert? Bekreft at DSAR-forespørsler utløser Claritys slettingsarbeidsflyt, ikke en manuell støtteforespørsel.

Hvor Clarity passer inn i en samtykke-først-stack

Øktopptak er atferdssporingsflaten med høyest informasjonstetthet i vanlig distribusjon, og Clarity er verktøyet som har demokratisert det mest aggressivt. Det gratis prisnivået og friksjonsløs installasjon gjør det til minste-motstands-veien for ethvert team som ønsker synlighet i UX-atferd. Den samme friksjonsfrielle installasjonen er det som gjør Clarity til det vanligst feilkonfigurerte analyseverktøyet i revisjoner fra 2026. Den riktige arkitekturen behandler Clarity som alle andre identifiserende sporere: begrens det bak eksplisitt samtykke, maskér skjemafelt aggressivt som standard, dokumentér kategorimappingen og koble samtykke-APIet slik at SDK-ens egne primitiver håndhever det CMP-en registrerte. Gjort riktig, bevares UX-forskningsverdien verktøyet ble kjøpt for, mens den regulatoriske eksponeringen faller til en brøkdel av det en standardinstallasjon medfører.