Какво всъщност записва Clarity

Clarity SDK (зареден от www.clarity.ms/tag/{project_id}) инициализира глобален обект clarity и идентифицира посетителите с бисквитка, собственост на Microsoft, наречена _clck, заедно с бисквитка за сесия _clsk. От този момент скриптът улавя плътен поведенчески поток:

• Въвеждане с мишка и докосване — всяко движение, клик, натискане, превъртане и жест се записва с времеви печат и координати.
• Взаимодействия с формуляри — събития за фокус, замъгляване и въвеждане за всяко поле на формуляр, плюс текста на нечувствителните полета, ако маскирането не е конфигурирано.
• DOM снапшоти — периодични пълни снапшоти на DOM на страницата, за да може повторното изпълнение на сесията да реконструира точното визуално състояние във всеки момент.
• Персонализирани събития — всякакви събития, които приложението изрично излъчва чрез извиквания на clarity("event", "name").
• Данни за производителност и грешки — грешки в JavaScript, мрежови неизправности и времена на core web vitals.
• Данни за идентификатори — бисквитката на Clarity плюс геолокация, получена от IP, и отпечатък на потребителския агент.

Комбинацията — особено DOM снапшотите и улавянето на полетата на формуляри — прави Clarity функционално еквивалентна на видеозапис на сесията на посетителя. Регулаторната класификация съгласно GDPR е ясна: това е обработка на лични данни, бисквитките са несъществени, данните пресичат граници към американската инфраструктура на Microsoft и изискваното правно основание е съгласие. Насоките на CNIL от 2024 г. относно записа на сесии са недвусмислени по този въпрос и изрично назовават инструменти от категорията на Clarity.

Рискът от чувствителни данни

Инструментите за запис на сесии имат специфична опасност за поверителността, каквато другите инструменти за анализ нямат: те могат случайно да уловят чувствителни лични данни. Потребител, въвеждащ номер на кредитна карта, здравословно състояние, религиозна принадлежност или национален идентификатор в което и да е поле на формуляр, се записва от Clarity, ако полето не е изрично маскирано. Съгласно GDPR това е обработка на чувствителни лични данни по Article 9, което изисква изрично съгласие за включване и рядко се покрива от общо решение за маркетингово съгласие.

Clarity поддържа конфигурация за маскиране на съдържание, която скрива конкретни полета от записа, но поведението по подразбиране улавя всичко. Подходът, защитим при одит, е да се маскира агресивно — приемайте всяко поле на формуляр за чувствително, докато не се докаже противното — и да се документират решенията за маскиране изрично.

Вградените контроли за поверителност на Clarity

Microsoft е инвестирала в контролите за поверителност на Clarity през последните две години. Платформата вече предоставя няколко примитива, които интеграцията с CMP може да използва.

Атрибутът за маскиране

Добавянето на data-clarity-mask="true" към DOM елемент скрива съдържанието му от записа на сесията. Добавянето на data-clarity-unmask="true" към дъщерен елемент замества маската за това поддърво. Правилната настройка по подразбиране за всяко поле на формуляр, което може да съдържа лични данни, е да се маскира, след което да се демаскира изрично там, където е безопасно.

API за съгласие

Clarity предоставя извикване на clarity("consent"), което, когато се извика, сигнализира, че е дадено съгласие и SDK трябва да продължи. Без това извикване SDK може да бъде конфигуриран да спре след първоначалното зареждане. Това е правилният примитив за интеграция с CMP от страната на активирането.

Маскиране на IP и обработка на идентификатори

Настройките на проекта в Clarity предоставят опции за съкращаване на IP и маскиране на идентификатори. Активирането им е мярка за задълбочена защита в допълнение към CMP портата; тя не замества съгласието.

Автоматично маскиране на чувствително съдържание

Последните версии на Clarity се опитват автоматично да открият чувствителни полета (модели на кредитни карти, полета за пароли, полета с имена „ssn" или подобни) и да ги маскират по подразбиране. Откритието е евристично и непълно; не разчитайте на него като единствена линия на защита.

Стъпка по стъпка интеграция с CMP

Надеждната архитектура е да се отложи изцяло Clarity SDK до даването на съгласие, след което да се активира изрично чрез API за съгласие.

1. Премахнете тага по подразбиране от заглавната секция на документа

Фрагментът за инсталиране на Clarity е единичен вграден скрипт, който инициализира SDK при зареждане на страницата. Заменете го с елемент скрипт-заместител, чийто type е text/plain и чийто data-category е analytics или marketing в зависимост от това как вашият CMP категоризира инструментите за запис на сесии.

2. Определете картографирането на категориите

Записът на сесии е оспорвана категория. CNIL я е третирал по различен начин — като анализ (когато данните се използват за вътрешни UX изследвания) и като маркетинг (когато данните захранват решения за персонализация или външно споделяне). Консервативното картографиране е маркетинг; позицията, защитима при одит, изисква да сте конкретни относно това как действително се използват записите.

3. Конфигурирайте агресивно маскиране преди активирането

Добавете data-clarity-mask="true" към всеки елемент на формуляр, всяко поле за въвеждане, всеки контейнер, който може да съдържа лични данни. Политиката по подразбиране е маскиране по подразбиране с изрични изключения за демаскиране за елементи, за които е известно, че са безопасни (заглавия на страници, етикети за навигация, блокове с публично съдържание).

4. Активирайте Clarity от обратното извикване за съгласие

Когато CMP задейства съответното събитие за приета категория, презапишете тага на скрипта-заместител и извикайте clarity("consent"), за да предоставите на SDK разрешение да продължи. Събитията в опашката, буферирани по време на периода преди съгласие, ще бъдат изчистени.

5. Обработвайте оттеглянето изрично

Ако потребителят оттегли съгласието си, Clarity SDK няма чисто извикване за „спиране на записа", еквивалентно на API за активиране. Практическият модел е да се извика clarity("consent", false), ако се поддържа в SDK версията, и допълнително да се изчистят бисквитките на Clarity от страната на клиента. За пълно изтриване на исторически записи използвайте работния процес за изтриване на данни в административния UI на Clarity или API за изтриване.

Чести грешки

Четири грешки при интегрирането представляват по-голямата част от констатациите при одит на внедрявания на Clarity.

Инсталиране на Clarity „само за да се види какво правят посетителите"

Най-честият модел: продуктов мениджър инсталира Clarity, за да изследва UX проблем, никога не активира портата за съгласие, никога не конфигурира маскиране и забравя за скрипта. Повърхността за запис продължава да се натрупва. Решението е или да се премахне Clarity изцяло, или да се постави под същата архитектура за съгласие като всеки друг тракер.

Доверяване на автоматичното маскиране

Евристичното откриване на чувствителни полета на Clarity улавя очевидните случаи, но пропуска специфичните за домейна — полето „симптоми" на здравен сайт, полето „номер на сметка" на финансов сайт с нестандартно наименование. Маскирайте изрично; не разчитайте на автоматичното откриване.

Третиране на записа на сесии като анализ

CNIL е категоричен, че категорията за запис на сесии е по-близо до маркетинга, отколкото до анализа на първа страна от гледна точка на съгласието. Поставянето на Clarity под съгласие само за анализ е защитимо само ако записите се използват изключително за вътрешни UX изследвания и никога не се споделят извън организацията.

Забравяне на полезните натоварвания на персонализираните събития

Кодът на приложението, който извиква clarity("event", "name", customProperties), може да изтече лични данни в потока на Clarity чрез полезното натоварване на customProperties. Одитирайте всяко място за извикване и избягвайте предаване на идентификатори на потребители, имейл адреси или каквито и да е лични данни в свойствата на събитията.

Контролен списък за одит

Шест конкретни въпроса, на които трябва да се отговори за всяко внедряване на Clarity, засягащо трафик от EU, UK, Бразилия или Калифорния.

• Чака ли Clarity за съгласие? Отворете страницата в частен прозорец и потвърдете, че никакви заявки към clarity.ms не се задействат преди приемане на банера.
• Маскирането агресивно ли е? Потвърдете, че всяко поле на формуляр и всеки контейнер с потенциално лично съдържание има приложен data-clarity-mask.
• Документирано ли е картографирането на категориите? Потвърдете, че има писмен запис дали Clarity е поставена под анализ или маркетинг, заедно с обосновката.
• Свързан ли е API за съгласие? Потвърдете, че обратното извикване на CMP извиква clarity("consent") при предоставяне и еквивалента при оттегляне.
• Одитирани ли са персонализираните събития? Потвърдете, че извикванията на clarity("event", ...) не предават идентифициращи или чувствителни данни в полезните натоварвания на свойствата им.
• Изтриването автоматизирано ли е? Потвърдете, че заявките DSAR задействат работния процес за изтриване на Clarity, а не ръчен тикет за поддръжка.

Мястото на Clarity в стек с приоритет на съгласието

Записът на сесии е повърхността за поведенческо проследяване с най-висока информационна плътност при обичайно внедряване, а Clarity е инструментът, който го е демократизирал най-агресивно. Безплатното ценово ниво и безпроблемната инсталация го правят пътя на най-малкото съпротивление за всеки екип, желаещ видимост в UX поведението. Същата тази безпроблемна инсталация е причината Clarity да е най-честно неправилно конфигурираният инструмент за анализ при одити за 2026 г. Правилната архитектура третира Clarity като всеки друг идентифициращ тракер: поставете я зад изрично съгласие, маскирайте полетата на формуляри агресивно по подразбиране, документирайте картографирането на категориите и свържете API за съгласие, за да могат собствените примитиви на SDK да прилагат това, което CMP е записал. Когато е направено правилно, изследователската стойност на UX, заради която инструментът е бил закупен, се запазва, докато регулаторното излагане пада до малка част от това, което носи инсталацията по подразбиране.