Hvad Clarity faktisk optager

Clarity SDK (indlæst fra www.clarity.ms/tag/{project_id}) initialiserer et globalt clarity-objekt og identificerer besøgende med en Microsoft-ejet cookie kaldet _clck sammen med en sessionscookie _clsk. Fra det øjeblik fanger scriptet en tæt adfærdsstrøm:

• Mus- og berøringsinput — hver bevægelse, klik, tryk, scroll og gestus optages med tidsstempel og koordinater.
• Formularinteraktioner — fokus-, slør- og inputhændelser på hvert formularfelt, plus teksten i ikke-følsomme felter, hvis maskering ikke er konfigureret.
• DOM-snapshots — periodiske fulde snapshots af sidens DOM, så sessionsafspilningen kan rekonstruere den nøjagtige visuelle tilstand på et hvilket som helst tidspunkt.
• Tilpassede hændelser — enhver hændelse, som applikationen eksplicit udsender via clarity("event", "name")-kald.
• Ydelses- og fejldata — JavaScript-fejl, netværksfejl og tidsregistreringer for core web vitals.
• Identifikatordata — den Clarity-ejede cookie plus IP-afledt geolokation og bruger-agent-fingeraftryk.

Kombinationen — især DOM-snapshots og registrering af formularfelter — gør Clarity funktionelt ækvivalent med en videooptagelse af den besøgendes session. Den regulatoriske klassifikation under GDPR er enkel: dette er behandling af personoplysninger, cookies er ikke-essentielle, data krydser grænser til Microsofts amerikanske infrastruktur, og det krævede retsgrundlag er samtykke. CNILs vejledning fra 2024 om sessionsoptagelse er utvetydig på dette punkt og nævner eksplicit værktøjer i Claritys kategori.

Risikoen ved følsomme data

Sessionsoptagelsesværktøjer har en specifik privatlivsrisiko, som andre analyseværktøjer ikke har: de kan ved et uheld registrere følsomme personoplysninger. En bruger, der indtaster et kreditkortnummer, en helbredstilstand, en religiøs tilhørsforhold eller et nationalt identifikationsnummer i et formularfelt, optages af Clarity, hvis feltet ikke er eksplicit maskeret. Under GDPR er dette behandling af følsomme personoplysninger efter Article 9, hvilket kræver eksplicit opt-in-samtykke og sjældent er dækket af en generel markedsføringsamtykke-beslutning.

Clarity understøtter en konfiguration til indholdsmaskering, der skjuler specifikke felter fra optagelse, men standardadfærden registrerer alt. Den revisionsforsvarlige tilgang er at maskere aggressivt — antag, at hvert formularfelt er følsomt, indtil det modsatte er bevist — og dokumenter maskerings­beslutningerne eksplicit.

Claritys native privatlivskontroller

Microsoft har investeret i Claritys privatlivskontroller i løbet af de seneste to år. Platformen eksponerer nu flere primitiver, som en CMP-integration kan udnytte.

Maskeringsattributten

Tilføjelse af data-clarity-mask="true" til et DOM-element skjuler dets indhold fra sessionsoptagelsen. Tilføjelse af data-clarity-unmask="true" til et underordnet element tilsidesætter maskeringen for det pågældende undertræ. Den korrekte standard for ethvert formularfelt, der kan indeholde personoplysninger, er at maskere og derefter eksplicit afmaske, hvor det er sikkert.

Samtykke-API'en

Clarity eksponerer et clarity("consent")-kald, der, når det påkaldes, signalerer, at samtykke er givet, og at SDK'en skal fortsætte. Uden dette kald kan SDK'en konfigureres til at stoppe efter indledende indlæsning. Dette er den rette primitiv til CMP-integration på aktiveringssiden.

IP-maskering og identifikatorhåndtering

Clarity-projektindstillingerne eksponerer muligheder for IP-trunkering og identifikatormaskering. Aktivering af disse er en dybde­forsvars­foranstaltning oven på CMP-gating; det erstatter ikke samtykke.

Automatisk maskering af følsomt indhold

Seneste Clarity-udgivelser forsøger automatisk at opdage følsomme felter (kreditkortmønstre, adgangskodefelter, felter med navnet "ssn" eller lignende) og maskere dem som standard. Registreringen er heuristisk og ufuldstændig; stol ikke på den som den eneste forsvarslinje.

Trin-for-trin CMP-integration

Den pålidelige arkitektur er at udskyde Clarity SDK fuldstændigt, indtil samtykke er givet, og derefter aktivere det eksplicit via samtykke-API'en.

1. Fjern standardtagget fra dokumentets hoved

Clarity-installations­fragmentet er et enkelt inline-script, der initialiserer SDK'en ved sideindlæsning. Erstat det med et pladsholder-scriptelement, hvis type er text/plain, og hvis data-category er analytics eller marketing afhængigt af, hvordan din CMP kategoriserer sessionsoptagelsesværktøjer.

2. Beslut dig for kategorimapping

Sessionsoptagelse er en omstridt kategori. CNIL har behandlet det varierende som analyse (når dataene bruges til intern UX-forskning) og som markedsføring (når dataene driver personaliserings­beslutninger eller ekstern deling). Den konservative mapping er markedsføring; den revisionsforsvarlige position kræver, at du er specifik om, hvordan optagelserne faktisk bruges.

3. Konfigurer aggressiv maskering inden aktivering

Tilføj data-clarity-mask="true" til hvert formularelement, hvert inputfelt, hver container, der kan indeholde personoplysninger. Standardpolitikken er maskering som standard med eksplicitte afmaskeringsundtagelser for elementer, der er kendte for at være sikre (sidetitler, navigationsnavne, offentlige indholdsblokke).

4. Aktiver Clarity fra samtykke-callback'et

Når CMP udløser den relevante kategori-accepteret hændelse, omskriv pladsholder-scripttagget og kald clarity("consent") for at give SDK'en tilladelse til at fortsætte. Hændelser i køen, der blev bufret under pre-samtykkeperioden, tømmes derefter.

5. Håndter tilbagekaldelse eksplicit

Hvis brugeren tilbagekalder samtykket, har Clarity SDK ikke et rent "stop optagelse"-kald svarende til aktiverings-API'en. Det praktiske mønster er at kalde clarity("consent", false), hvis det understøttes i din SDK-version, og derudover rydde Clarity-cookies på klientsiden. For fuldstændig sletning af historiske optagelser skal du bruge Clarity-admininterfacets dataslette-workflow eller slette-API'en.

Almindelige faldgruber

Fire integrationsfejl tegner sig for størstedelen af revisionsfundene ved Clarity-implementeringer.

Installation af Clarity "bare for at se, hvad besøgende gør"

Det mest almindelige mønster: en produktchef installerer Clarity til at undersøge et UX-problem, aktiverer aldrig samtykke-gating, konfigurerer aldrig maskering og glemmer scriptet. Optagelsesfladen fortsætter med at akkumulere. Afhjælpningen er enten at fjerne Clarity helt eller at bringe den under den samme samtykkearkitektur som enhver anden tracker.

At stole på automatisk maskering

Claritys heuristiske registrering af følsomme felter fanger åbenlyse tilfælde, men går glip af domænespecifikke — et sundhedswebsteds "symptoms"-tekstområde, et finanswebsteds "account number"-felt med et idiosynkratisk navn. Maskér eksplicit; stol ikke på registreringen.

At behandle sessionsoptagelse som analyse

CNIL har været eksplicit om, at sessionsoptagelses­kategorien er tættere på markedsføring end på first-party analyse fra et samtykkeperspektiv. At gate Clarity under kun-analyse-samtykke er forsvarligt kun, hvis optagelserne udelukkende bruges til intern UX-forskning og aldrig deles uden for organisationen.

At glemme tilpassede hændelsesloads

Applikationskode, der kalder clarity("event", "name", customProperties), kan lække personoplysninger ind i Clarity-strømmen gennem customProperties-payloaden. Auditér hvert kaldested og undgå at sende brugeridentifikatorer, e-mailadresser eller personoplysninger i hændelsesegenskaber.

Revisionscheckliste

Seks konkrete spørgsmål, der skal besvares for enhver Clarity-implementering, der berører trafik fra EU, UK, Brasilien eller Californien.

• Venter Clarity på samtykke? Åbn siden i et privat vindue og bekræft, at der ikke sendes clarity.ms-anmodninger, før banneret accepteres.
• Er maskeringen aggressiv? Bekræft, at hvert formularfelt og hver container med potentielt personligt indhold har data-clarity-mask anvendt.
• Er kategorimappingen dokumenteret? Bekræft, at der er en skriftlig registrering af, om Clarity er gated under analyse eller markedsføring, med begrundelsen.
• Er samtykke-API'en tilkoblet? Bekræft, at CMP-callback'et kalder clarity("consent") ved tildeling og det tilsvarende ved tilbagekaldelse.
• Er tilpassede hændelser auditeret? Bekræft, at clarity("event", ...)-kald ikke sender identificerende eller følsomme data i deres egenskabsloads.
• Er sletning automatiseret? Bekræft, at DSAR-anmodninger udløser Claritys slette-workflow og ikke en manuel supportbillet.

Hvor Clarity passer ind i en samtykke-first-stak

Sessionsoptagelse er den adfærdsmæssige sporings­overflade med den højeste informationstæthed i almindelig brug, og Clarity er det værktøj, der har demokratiseret det mest aggressivt. Det gratis prisniveau og den friktionsfrie installation gør det til vejen med mindst modstand for ethvert team, der ønsker synlighed i UX-adfærd. Den samme friktionsfrie installation er det, der gør Clarity til det mest fejlkonfigurerede analyseværktøj i 2026-revisioner. Den rigtige arkitektur behandler Clarity som enhver anden identificerende tracker: gate den bag eksplicit samtykke, maskér formularfelter aggressivt som standard, dokumentér kategorimappingen og tilslut samtykke-API'en, så SDK'ens egne primitiver håndhæver det, CMP registrerede. Gjort korrekt bevares den UX-forskningsværdi, værktøjet blev købt for, mens den regulatoriske eksponering falder til en brøkdel af, hvad en standardinstallation medfører.