Що насправді записує Clarity

Clarity SDK (завантажений з www.clarity.ms/tag/{project_id}) ініціалізує глобальний об'єкт clarity та ідентифікує відвідувачів за допомогою файлу cookie у власності Microsoft під назвою _clck разом із файлом cookie сесії _clsk. Відтоді скрипт фіксує щільний потік поведінкових даних:

• Введення мишею та сенсорним екраном — кожен рух, клік, дотик, прокрутка та жест записується з міткою часу та координатами.
• Взаємодії з формами — події фокуса, розфокуса та введення в кожному полі форми, а також текст нечутливих полів, якщо маскування не налаштоване.
• Знімки DOM — periodical повні знімки DOM сторінки, щоб відтворення сесії могло відновити точний візуальний стан у будь-який момент.
• Спеціальні події — будь-які події, які додаток явно видає через виклики clarity("event", "name").
• Дані продуктивності та помилок — помилки JavaScript, відмови мережі та часові показники основних веб-показників.
• Дані ідентифікатора — файл cookie у власності Clarity плюс геолокація, отримана за IP, та відбиток user-agent.

Комбінація — особливо знімки DOM та захоплення полів форми — робить Clarity функціонально еквівалентним відеозапису сесії відвідувача. Регуляторна класифікація за GDPR є однозначною: це обробка персональних даних, файли cookie не є необхідними, дані перетинають кордони до американської інфраструктури 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, і додатково очистити файли cookie Clarity на стороні клієнта. Для повного видалення історичних записів використовуйте робочий процес видалення даних у адміністративному інтерфейсі Clarity або API видалення.

Поширені помилки

Чотири помилки інтеграції становлять більшість знахідок аудиту при розгортаннях Clarity.

Встановлення Clarity "просто щоб подивитися, що роблять відвідувачі"

Найпоширеніша схема: менеджер продукту встановлює Clarity для дослідження проблеми UX, ніколи не вмикає контроль згоди, ніколи не налаштовує маскування та забуває про скрипт. Поверхня запису продовжує накопичуватися. Усунення наслідків — або повністю видалити Clarity, або підпорядкувати його тій самій архітектурі згоди, що й кожен інший трекер.

Довіра до автоматичного маскування

Евристичне виявлення чутливих полів Clarity виявляє очевидні випадки, але пропускає специфічні для домену — textarea "symptoms" медичного сайту, поле "account number" фінансового сайту з ідіосинкратичною назвою. Маскуйте явно; не покладайтеся на виявлення.

Ставлення до запису сесій як до аналітики

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-досліджень, задля якої був придбаний інструмент, зберігається, тоді як регуляторна схильність знижується до частки того, що несе стандартне встановлення.