Wat Clarity daadwerkelijk registreert

De Clarity SDK (geladen van www.clarity.ms/tag/{project_id}) initialiseert een globaal clarity-object en identificeert bezoekers met een Microsoft-cookie genaamd _clck, naast een sessiecookie _clsk. Vanaf dat moment legt het script een compacte gedragsstroom vast:

• Muis- en aanraakinvoer — elke beweging, klik, tik, scroll en gebaar wordt geregistreerd met tijdstempel en coördinaten.
• Formulierinteracties — focus-, blur- en invoergebeurtenissen op elk formulierveld, plus de tekst van niet-gevoelige velden als masking niet is geconfigureerd.
• DOM-snapshots — periodieke volledige snapshots van de pagina-DOM zodat de sessieherhaling de exacte visuele toestand op elk moment kan reconstrueren.
• Aangepaste gebeurtenissen — alle gebeurtenissen die de applicatie expliciet uitzendt via clarity("event", "name")-aanroepen.
• Prestatie- en foutgegevens — JavaScript-fouten, netwerkstoringen en timings van core web vitals.
• Identificatorgegevens — de Clarity-cookie plus IP-afgeleid geolokatie en user-agent fingerprinting.

De combinatie — met name de DOM-snapshots en het vastleggen van formuliervelden — maakt Clarity functioneel equivalent aan een video-opname van de sessie van de bezoeker. De regelgevende classificatie onder de GDPR is eenduidig: dit is verwerking van persoonsgegevens, de cookies zijn niet-essentieel, de gegevens gaan over de grens naar de Amerikaanse infrastructuur van Microsoft, en de vereiste wettelijke grondslag is toestemming. De CNIL-leidraad van 2024 over sessieopname is op dit punt ondubbelzinnig en noemt expliciet tools in de categorie van Clarity.

Het risico van gevoelige gegevens

Sessieopnametools hebben een specifiek privacyrisico dat andere analyticstools niet hebben: ze kunnen per ongeluk gevoelige persoonsgegevens vastleggen. Een gebruiker die een creditcardnummer, een gezondheidstoestand, een religieuze overtuiging of een nationaal identificatienummer invoert in een formulierveld, wordt door Clarity geregistreerd als het veld niet expliciet gemaskeerd is. Onder de GDPR is dit verwerking van gevoelige persoonsgegevens op grond van Article 9, wat expliciete opt-in toestemming vereist en zelden gedekt is door een algemeen marketingtoestemmingsbesluit.

Clarity ondersteunt een inhoudsmaskingconfiguratie die specifieke velden verbergt voor opname, maar het standaardgedrag legt alles vast. De auditbestendige aanpak is agressief maskeren — ga ervan uit dat elk formulierveld gevoelig is totdat het tegendeel is bewezen — en de maskingbeslissingen expliciet documenteren.

Native privacycontroles van Clarity

Microsoft heeft de afgelopen twee jaar geïnvesteerd in de privacycontroles van Clarity. Het platform biedt nu diverse primitieven die een CMP-integratie kan benutten.

Het maskeerattribuut

Het toevoegen van data-clarity-mask="true" aan een DOM-element verbergt de inhoud voor de sessieopname. Het toevoegen van data-clarity-unmask="true" aan een onderliggend element overschrijft het masker voor die deelboom. De juiste standaard voor elk formulierveld dat persoonsgegevens kan bevatten is maskeren, vervolgens expliciet de masking verwijderen waar het veilig is.

De toestemmings-API

Clarity biedt een clarity("consent")-aanroep die, wanneer aangeroepen, signaleert dat toestemming is verleend en de SDK moet doorgaan. Zonder deze aanroep kan de SDK worden geconfigureerd om te stoppen na de eerste keer laden. Dit is het juiste primitief voor CMP-integratie aan de activatiekant.

IP-masking en identificatorverwerking

De projectinstellingen van Clarity bieden opties voor IP-afkapping en identifactormasking. Dit inschakelen is een maatregel voor diepteverdediging bovenop CMP-gating; het vervangt toestemming niet.

Automatische masking van gevoelige inhoud

Recente Clarity-releases proberen gevoelige velden automatisch te detecteren (creditcardpatronen, wachtwoordvelden, velden met de naam "ssn" of vergelijkbaar) en ze standaard te maskeren. De detectie is heuristisch en onvolledig; vertrouw er niet op als enige verdedigingslinie.

Stap-voor-stap CMP-integratie

De betrouwbare architectuur is om de Clarity SDK volledig uit te stellen totdat toestemming is verleend, en deze vervolgens expliciet te activeren via de toestemmings-API.

1. Verwijder de standaardtag uit de documentkop

Het Clarity-installatiefragment is een enkel inline script dat de SDK initialiseert bij het laden van de pagina. Vervang het door een tijdelijk scriptelement waarvan het type text/plain is en waarvan de data-category analytics of marketing is, afhankelijk van hoe uw CMP sessieopnametools categoriseert.

2. Beslis over de categoriemapping

Sessieopname is een betwiste categorie. De CNIL heeft het gevarieerd behandeld als analytics (wanneer de gegevens worden gebruikt voor intern UX-onderzoek) en als marketing (wanneer de gegevens personalisatiebeslissingen of externe deling voeden). De conservatieve mapping is marketing; de auditbestendige positie vereist dat u specifiek bent over hoe de opnames daadwerkelijk worden gebruikt.

3. Configureer agressieve masking vóór activering

Voeg data-clarity-mask="true" toe aan elk formulierelement, elk invoerveld, elke container die persoonsgegevens kan bevatten. Het standaardbeleid is standaard maskeren met expliciete uitmaskeeringuitzonderingen voor elementen waarvan bekend is dat ze veilig zijn (paginatitels, navigatielabels, blokken met openbare inhoud).

4. Activeer Clarity vanuit de toestemmingscallback

Wanneer de CMP de relevante categorie-geaccepteerde gebeurtenis activeert, herschrijft u de tijdelijke scripttag en roept u clarity("consent") aan om de SDK toestemming te geven om door te gaan. In de wachtrij staande gebeurtenissen die zijn gebufferd tijdens de periode vóór toestemming worden dan geleegd.

5. Handel herroeping expliciet af

Als de gebruiker toestemming intrekt, heeft de Clarity SDK geen schone "stop recording"-aanroep die equivalent is aan de activatie-API. Het praktische patroon is om clarity("consent", false) aan te roepen indien ondersteund in uw SDK-versie, en aanvullend de Clarity-cookies aan de clientzijde te wissen. Voor volledige verwijdering van historische opnames gebruikt u de gegevensverwerkingsworkflow in de Clarity-beheerinterface of de verwijder-API.

Veelgemaakte fouten

Vier integratiefouten zijn verantwoordelijk voor de meerderheid van de auditbevindingen bij Clarity-implementaties.

Clarity installeren "gewoon om te zien wat bezoekers doen"

Het meest voorkomende patroon: een productmanager installeert Clarity om een UX-probleem te onderzoeken, schakelt nooit toestemmings-gating in, configureert nooit masking en vergeet het script. Het opnameoppervlak blijft groeien. De remedie is Clarity volledig te verwijderen of het onder dezelfde toestemmingsarchitectuur te brengen als elke andere tracker.

Vertrouwen op automatische masking

De heuristische gevoelig-velddetectie van Clarity vangt voor de hand liggende gevallen op, maar mist domeinspecifieke gevallen — een "symptomen"-tekstvak op een zorgwebsite, een "rekeningnummer"-veld op een financiële website met een eigenzinnige naam. Maskeer expliciet; vertrouw niet op detectie.

Sessieopname behandelen als analytics

De CNIL heeft expliciet gemeld dat de sessieopname-categorie vanuit toestemmingsperspectief dichter bij marketing dan bij first-party analytics staat. Clarity beperken tot uitsluitend analytics-toestemming is alleen verdedigbaar als de opnames uitsluitend voor intern UX-onderzoek worden gebruikt en nooit buiten de organisatie worden gedeeld.

Aangepaste gebeurtenisladingen vergeten

Applicatiecode die clarity("event", "name", customProperties) aanroept, kan persoonsgegevens laten lekken in de Clarity-stroom via de customProperties-lading. Controleer elke aanroeplocatie en vermijd het doorgeven van gebruikersidentificatoren, e-mailadressen of enige persoonsgegevens in gebeurteniseigenschappen.

Auditchecklist

Zes concrete vragen om te beantwoorden voor elke Clarity-implementatie die EU-, UK-, Braziliaans of Californiaans verkeer raakt.

• Wacht Clarity op toestemming? Open de pagina in een privévenster en bevestig dat er geen clarity.ms-verzoeken worden verzonden voordat de banner is geaccepteerd.
• Is masking agressief? Bevestig dat elk formulierveld en elke container met mogelijk persoonlijke inhoud data-clarity-mask heeft toegepast.
• Is de categoriemapping gedocumenteerd? Bevestig dat er een schriftelijke vastlegging is of Clarity wordt geblokkeerd onder analytics of marketing, met de redenering.
• Is de toestemmings-API aangesloten? Bevestig dat de CMP-callback clarity("consent") aanroept bij verlening en het equivalent bij herroeping.
• Worden aangepaste gebeurtenissen gecontroleerd? Bevestig dat clarity("event", ...)-aanroepen geen identificerende of gevoelige gegevens doorgeven in hun eigenschapsladingen.
• Is verwijdering geautomatiseerd? Bevestig dat DSAR-verzoeken de verwijderingsworkflow van Clarity activeren, niet een handmatig supportticket.

Waar Clarity past in een toestemming-eerst-stack

Sessieopname is het gedragsvolgsurface met de hoogste informatiedichtheid in gewone implementatie, en Clarity is de tool die dit het meest agressief heeft gedemocratiseerd. De gratis prijscategorie en installatie zonder wrijving maken het de weg van de minste weerstand voor elk team dat zichtbaarheid in UX-gedrag wil. Diezelfde wrijvingsvrije installatie is wat Clarity de meest verkeerd geconfigureerde analyticstool maakt in audits van 2026. De juiste architectuur behandelt Clarity als elke andere identificerende tracker: beperk het achter expliciete toestemming, maskeer formuliervelden standaard agressief, documenteer de categoriemapping en sluit de toestemmings-API aan zodat de eigen primitieven van de SDK afdwingen wat de CMP heeft vastgelegd. Correct uitgevoerd blijft de UX-onderzoekswaarde waarvoor de tool is aangeschaft behouden, terwijl de regelgevende blootstelling daalt tot een fractie van wat een standaardinstallatie met zich meebrengt.