Session Replay, вебвизор, тепловые карты: что именно они собирают и как это отражать в документах

Невидимое видео: как инструменты поведенческой аналитики пишут каждый ваш клик — и что с этим делать по закону

Введение: зачем это знать прямо сейчас

Продуктовые команды, UX-дизайнеры и маркетологи ежедневно запускают тепловые карты и session replay — и считают, что это просто «аналитика». Юристы и специалисты по информационной безопасности смотрят на те же инструменты и видят совсем другую картину: поток персональных данных пользователей, который уходит к сторонним операторам без чёткого правового основания.

Разрыв между этими двумя взглядами существовал давно, но в 2025 году он превратился в финансовую угрозу. Закон № 420-ФЗ, вступивший в силу 30 мая 2025 года, превратил административные штрафы за нарушение работы с ПДн из символических в по-настоящему болезненные — до 500 млн рублей при повторных утечках [10]. Роскомнадзор параллельно усилил автоматизированный мониторинг сайтов [14].

Эта статья — попытка дать технически точный и юридически выверенный ответ на вопрос, который задают всё чаще: что именно собирают инструменты поведенческой аналитики, являются ли эти данные персональными, и как всё это оформить в документах так, чтобы не получить штраф.

Часть 1. Как устроены session replay, Вебвизор и тепловые карты — технически

1.1 Это не видео — это реконструкция по данным DOM

Главное заблуждение о session replay — то, что это видеозапись экрана пользователя. На самом деле запись происходит на уровне DOM — Document Object Model, программного интерфейса браузера, который представляет структуру веб-страницы в виде дерева объектов [20].

Работа инструмента делится на три фазы. Сначала — снимок (snapshot): при загрузке страницы берётся полная копия DOM-дерева, включая все HTML-элементы и CSS-стили [5, 26]. Затем — запись мутаций: любое изменение на странице (появление элемента, смена текста, результат заполнения формы) фиксируется как инкрементальный diff. Наконец — воспроизведение: система восстанавливает начальное состояние страницы и последовательно применяет зафиксированные изменения, создавая «видео» [2].

Именно поэтому такой подход значительно экономнее реального экранного захвата — передаётся несколько килобайт структурированных данных, а не мегабайты видеофайлов [3].

Большинство современных open-source реализаций session replay строится на библиотеке rrweb (record and replay the web). Её использует, например, Siteimprove [6]. Коммерческие платформы — FullStory, Hotjar, Mouseflow, Microsoft Clarity, Яндекс.Метрика Вебвизор — имеют собственные реализации той же концепции.

1.2 Что именно фиксируется: полный список данных

По данным из документации различных платформ [1, 2, 3, 4], инструменты session replay в типовой конфигурации собирают следующие категории данных:

1. Структура страницы — полный DOM-снимок включает весь HTML-контент, видимый пользователю в момент загрузки, в том числе тексты, изображения (как ссылки), атрибуты элементов.
2. Мутации DOM — все изменения структуры страницы: появление всплывающих окон, динамически загружаемого контента, изменение текстов.
3. Действия пользователя — клики с координатами (X, Y на странице), движения курсора мыши, скроллинг (позиция и скорость), касания на мобильных устройствах, изменение размеров окна браузера.
4. Ввод в формы — нажатия клавиш и символы, вводимые в текстовые поля (включая поисковые строки, поля логина, адресные формы) — если не настроено явное маскирование.
5. Навигация — URL каждой посещённой страницы в рамках сессии, переходы между страницами, время на каждой из них.
6. Технические метаданные — User Agent (тип и версия браузера, ОС), разрешение экрана, временная метка каждого события, идентификатор сессии.
7. Сетевые данные — IP-адрес пользователя (в большинстве инструментов — для определения геолокации, после чего может быть анонимизирован или усечён) [3, 22].

Отдельная история — так называемые «явно переданные» данные: если сайт передаёт в аналитическую систему UserID, email или имя пользователя через API (например, для связывания сессии с конкретным клиентом в CRM), всё это также оседает в системе [4].

1.3 Тепловые карты: агрегация того же

Тепловые карты (heatmaps) — это не отдельный тип сбора данных, а визуализация агрегатов по данным сессий [19]. Существует несколько типов:

1. Click maps (карты кликов) — показывают, куда чаще всего кликают пользователи на странице. Данные: координаты каждого клика + идентификатор элемента + временная метка.
2. Scroll maps (карты скроллинга) — показывают, до какой глубины страницы доходят пользователи. Данные: позиция скролла + временная метка.
3. Move maps (карты движения мыши) — визуализируют траектории движения курсора. Основаны на предположении о корреляции взгляда и курсора, которое, по ряду исследований, не является надёжным [19].
4. Attention maps / Engagement zones — более продвинутые карты, показывающие зоны наибольшего внимания. Обычно комбинируют данные о времени, движении и кликах.

С технической точки зрения тепловая карта генерируется постфактум из тех же событийных данных, что и session replay. Инструмент собирает сырые данные о взаимодействии, а потом рендерит их в виде цветовой визуализации [30]. Это означает: если session replay собирает персональные данные, тепловые карты строятся на той же основе.

1.4 Вебвизор Яндекс.Метрики: российская специфика

Вебвизор — это реализация session replay в Яндекс.Метрике. По своей технике он работает аналогично описанному выше: фиксирует действия пользователя на сайте и позволяет их воспроизвести.

Сама Яндекс в условиях использования Метрики прямо указывает, что «все данные, собираемые и хранимые сервисом, Яндекс рассматривает как персональные данные и конфиденциальную информацию Пользователя» [7]. Справка Метрики перечисляет запрещённые к передаче идентификационные данные: паспортные данные, GPS-координаты, ИНН, медицинская информация [8].

Вебвизор по умолчанию маскирует содержимое полей ввода («звёздочками»), но настройки можно изменить. Пример из реальной политики конфиденциальности, опубликованной в открытом доступе, прямо фиксирует: «в настройках Вебвизора отключена опция "Записывать все поля"» — что означает, что по умолчанию эта опция существует и может быть включена [27].

Часть 2. Являются ли эти данные персональными? Позиции регуляторов

2.1 Что говорит 152-ФЗ

Федеральный закон № 152-ФЗ «О персональных данных» определяет персональные данные широко: это «любая информация, относящаяся к прямо или косвенно определённому или определяемому физическому лицу» [16]. Обработкой считается «любое действие или совокупность действий» с ПДн, включая сбор, запись, систематизацию, накопление, хранение, уточнение, извлечение, использование, передачу.

Применительно к session replay это означает следующее:

1. IP-адрес — относится к персональным данным, поскольку позволяет косвенно идентифицировать пользователя в совокупности с другими данными. Именно поэтому Роскомнадзор требует согласия на его обработку.
2. Cookie и идентификаторы сессий — служат для отслеживания конкретного пользователя при повторных визитах, что является косвенной идентификацией.
3. Поведенческие паттерны в совокупности — даже без имени и email комбинация IP + браузер + разрешение экрана + геолокация + поведенческая сигнатура может однозначно идентифицировать человека (так называемый browser fingerprint).
4. Данные форм — если пользователь ввёл имя или телефон, и эти данные не замаскированы — это прямые ПДн.

2.2 Позиция Роскомнадзора по Яндекс.Метрике

Роскомнадзор занял чёткую позицию: использование Яндекс.Метрики на сайте является обработкой персональных данных, требующей явного согласия посетителей [13]. Эта позиция основывается непосредственно на пользовательском соглашении сервиса, который сам классифицирует собираемую информацию как персональные данные [7].

На практике РКН выносил постановления компаниям, использовавшим Метрику без надлежащего уведомления пользователей [13].

С Google Analytics ситуация сложнее из-за возможной трансграничной передачи данных: данные российских пользователей могут уходить на серверы за пределы РФ, что дополнительно нарушает требования локализации ч. 5 ст. 18 152-ФЗ.

2.3 Что происходит в 2025–2026 году с регулированием

С 2025 года Роскомнадзор продолжает усиливать контроль за технической локализацией баз данных и интерпретирует использование cookie-файлов как сбор персональных данных, требующий явного согласия пользователей [14]. Автоматизированная система «Ревизор» анализирует трафик сайтов и геолокацию серверов.

Параллельно вступил в силу закон 420-ФЗ, кратно увеличивший штрафы. Ключевые изменения с 30 мая 2025 года [10, 18]:

1. За нарушение порядка обработки ПДн (ч. 1 ст. 13.11 КоАП) — до 150–300 тыс. рублей для организаций (ранее 60–100 тыс.).
2. За обработку ПДн без согласия — до 300–700 тыс. рублей для организаций.
3. За утечку данных от 1 000 до 10 000 человек — от 3 до 5 млн рублей для организаций [18].
4. При повторных нарушениях — оборотные штрафы от 1 до 3% годовой выручки, минимум 25 млн рублей, максимум 500 млн рублей [28].
5. Уголовная ответственность по ст. 272.1 УК РФ — штраф до 300 тыс. рублей или лишение свободы до 4 лет за незаконный сбор и использование ПДн [28].

Часть 3. Какие данные реально уходят к вендору — разбор по инструментам

3.1 Яндекс.Метрика + Вебвизор

Яндекс собирает через Метрику: IP-адреса, cookies, HTTP-заголовки, информацию об устройстве, дату и время доступа, геолокацию [7]. Через Вебвизор — записи сессий: клики, скроллы, движения мыши, а при включённой опции «Записывать все поля» — содержимое полей ввода.

Данные хранятся на серверах Яндекса на территории РФ, что закрывает вопрос локализации [12]. Яндекс выступает обработчиком персональных данных по поручению владельца сайта.

Важно: Яндекс.Метрика позволяет отложить загрузку кода счётчика до получения согласия пользователя через специальный механизм cookie-баннера [9]. Это технически правильный подход — данные не собираются до подтверждения.

3.2 Microsoft Clarity

Clarity собирает данные об устройстве, разрешение экрана, движения мыши, клики, скроллинг, записи сессий с анонимизированным содержимым. IP-адреса обрабатываются с частичным усечением [22]. По умолчанию чувствительные поля маскируются.

Принципиальное отличие: Microsoft использует данные, собранные через Clarity, для обучения собственных AI-моделей [23]. Это требует отдельного анализа при оценке рисков — особенно если на сайте обрабатываются данные B2B-клиентов или чувствительная тематика. При этом серверы Clarity находятся в инфраструктуре Microsoft, то есть для российских сайтов возникает вопрос трансграничной передачи.

3.3 Hotjar, Fullstory, Mouseflow и другие западные инструменты

Западные инструменты поведенческой аналитики собирают принципиально те же категории данных [24, 19], но хранят их на серверах за пределами России. Для российских сайтов это автоматически означает трансграничную передачу данных, регулируемую ст. 12 152-ФЗ. Использование этих инструментов требует уведомления Роскомнадзора о трансграничной передаче с указанием принимающей страны и правовых оснований.

Большинство западных платформ предлагают Data Processing Agreement (DPA) — юридически это аналог поручения на обработку ПДн по российскому праву [15].

3.4 Собственные (self-hosted) решения на rrweb или PostHog

Альтернативный вариант — развертывание open-source инструмента (например, PostHog, Matomo с плагином Heatmap & Session Recording [30]) на собственной инфраструктуре или на российских серверах. В этом случае данные не уходят к сторонним вендорам, вопрос трансграничной передачи снимается. Однако остаются обязательства по технической защите, разграничению доступа и документированию.

Часть 4. Как отражать эти инструменты в юридических документах

4.1 Политика конфиденциальности: обязательные элементы

Политика конфиденциальности должна прямо описывать использование инструментов поведенческой аналитики. Отсутствие упоминания при фактическом использовании — прямое нарушение принципа прозрачности 152-ФЗ, за которое Роскомнадзор вправе привлечь оператора к ответственности [25].

Для каждого инструмента (Метрика, Clarity, Hotjar и т.д.) необходимо указать следующее:

1. Наименование инструмента и его правообладатель — например, «Сервис веб-аналитики "Яндекс.Метрика", предоставляемый ООО "Яндекс"».
2. Категории собираемых данных — IP-адрес, cookie, данные об устройстве, данные о поведении на сайте (клики, скроллинг, просмотренные страницы).
3. Цель обработки — аналитика использования сайта, улучшение пользовательского опыта, выявление ошибок.
4. Правовое основание — согласие субъекта ПДн (ст. 6 ч. 1 п. 1 152-ФЗ). Именно согласие, а не «легитимный интерес» — российский закон не знает этой европейской конструкции.
5. Срок хранения — конкретный, например: «данные хранятся в течение 12 месяцев с момента последнего визита».
6. Возможность отказа — ссылка на инструкцию по блокировке (например, «блокировщик Яндекс.Метрики»).
7. Статус вендора как обработчика — «Яндекс обрабатывает данные в интересах владельца сайта в соответствии с условиями использования сервиса».

Типового шаблона политики конфиденциальности не существует — каждый оператор адаптирует текст под реальные процессы [16]. Использование конструкторов (Tilda, Роском Онлайн и др.) допустимо как отправная точка, но требует ручной доработки.

4.2 Cookie-баннер: требования и механика

Согласие на обработку ПДн через cookie и аналитические сервисы должно быть:

1. Предшествующим — баннер должен появляться до загрузки счётчиков и до сбора данных. Ни Метрика, ни Clarity не должны стартовать до подтверждения [5, 9].
2. Явным — «просто пользуясь сайтом, вы соглашаетесь» не является корректным согласием. Нужна активная форма: нажатие кнопки «Принять» или аналогичное действие.
3. Отзываемым — пользователь должен иметь возможность отозвать согласие в любой момент и отказаться от аналитических cookie, не теряя доступа к сайту.
4. Гранулированным (желательно) — отдельно для «технически необходимых» cookies и для аналитических.

Яндекс.Метрика предоставляет готовый механизм отложенной загрузки счётчика [9]: код счётчика не инициализируется, пока пользователь не нажал «Принять» в баннере. Это технически верная реализация.

Текст баннера должен содержать: что собирается, зачем, ссылку на политику конфиденциальности, кнопки «Принять» и «Отказаться» [30].

4.3 Поручение на обработку персональных данных

Когда владелец сайта подключает внешний сервис аналитики, он передаёт ПДн своих пользователей третьей стороне. По 152-ФЗ это требует оформления поручения на обработку персональных данных (ст. 6 ч. 3).

Для Яндекс.Метрики такое поручение оформляется через принятие условий использования сервиса [7] — Яндекс в своём соглашении прямо берёт на себя обязательства по 152-ФЗ. Для западных инструментов поручение оформляется через подписание DPA (Data Processing Agreement) с вендором.

В поручении должны быть указаны: перечень действий с ПДн, цели обработки, обязанность конфиденциальности, требования к защите по ст. 19 152-ФЗ [11].

4.4 Уведомление Роскомнадзора

Если инструмент поведенческой аналитики используется для обработки ПДн российских пользователей — а это так в подавляющем большинстве случаев — оператор обязан зарегистрироваться в реестре операторов ПДн Роскомнадзора. С 2025 года это требование распространяется на всех юридических лиц, ИП и самозанятых, систематически собирающих ПДн [21].

Уведомление подаётся онлайн через портал РКН или Госуслуги. В нём нужно указать: категории данных, цели обработки, правовые основания, сроки хранения, меры защиты, а также — если используются западные сервисы — сведения о трансграничной передаче данных.

За непредставление уведомления с 30 мая 2025 года штраф для юрлиц составляет от 100 до 300 тысяч рублей [10].

4.5 Трансграничная передача: особый случай

Если используются Google Analytics, Hotjar, Fullstory, Microsoft Clarity (как международный сервис) или другие западные инструменты — данные российских пользователей уходят за рубеж. Это требует:

1. Предварительного уведомления Роскомнадзора о трансграничной передаче с указанием принимающего государства и правовых оснований (ст. 12 152-ФЗ).
2. Оценки, обеспечивает ли принимающая страна «адекватный уровень защиты» ПДн. Для США такая оценка неоднозначна.
3. Отражения трансграничной передачи в политике конфиденциальности.

Отдельный вопрос — Microsoft Clarity: серверы Microsoft могут располагаться в разных странах, и без явного указания страны хранения определить её сложно.

Часть 5. Технические меры защиты: что нужно настроить

5.1 Маскирование чувствительных полей

Любой профессиональный инструмент session replay предоставляет возможность маскировать (заменять «звёздочками» или полностью блокировать) содержимое полей ввода [17]. Это необходимо настроить для:

1. Полей с паролями (большинство инструментов блокируют автоматически).
2. Полей с платёжными данными (номер карты, CVV).
3. Полей с личными данными (ФИО, дата рождения, СНИЛС, паспорт).
4. Полей с медицинскими данными (если это медицинский сайт или телемедицина).
5. Поисковых строк, если пользователи могут вводить в них личную информацию.

В Яндекс.Метрике это настраивается через CSS-классы или параметры инициализации счётчика [8, 27]. В Microsoft Clarity — через режимы маскирования (relaxed, balanced, strict) [22].

5.2 Анонимизация IP-адресов

Большинство инструментов предлагают усечение или хэширование IP-адреса. Это важно: полный IP-адрес, привязанный к поведенческим данным, является персональными данными. Усечённый или хэшированный — уже сложнее однозначно соотнести с конкретным человеком.

Для Яндекс.Метрики — РКН требует согласия на обработку IP в любом случае [13], поэтому анонимизация IP снижает риски, но не устраняет их полностью.

5.3 Семплирование и ограничение записи

Запись 100% сессий увеличивает объём хранимых ПДн и, соответственно, риски. Большинство инструментов позволяют настроить sampling rate — долю сессий, которые фактически записываются. Siteimprove, например, по умолчанию записывает 0,25% визитов [6].

Правило минимизации данных (ст. 5 152-ФЗ) прямо обязывает операторов не собирать данных больше, чем нужно для заявленной цели. Если цель — понять UX на ключевых страницах, нет необходимости записывать 100% сессий.

5.4 Сроки хранения и удаление данных

Данные должны храниться ровно столько, сколько нужно для цели обработки, и уничтожаться после её достижения. New Relic по умолчанию хранит данные session replay 8 дней [5]; Pendo — 30 дней с возможностью расширения до 90 [11]; Hotjar — до 365 дней на платных тарифах [24].

Срок хранения должен быть указан в политике конфиденциальности и соответствовать реальным настройкам платформы. Разрыв между задекларированным сроком и фактическим — нарушение принципа достоверности.

Часть 6. Типичные ошибки и как их избежать

6.1 «Мы ничего личного не пишем — только клики»

Это самое распространённое заблуждение. IP-адрес сам по себе является ПДн в позиции Роскомнадзора. Идентификатор cookie, привязанный к поведенческой истории, — тоже. Браузерный fingerprint (UA + разрешение + timezone + язык) создаёт квазиидентификатор, который в сочетании с другими данными позволяет выделить конкретного человека [3].

Как избежать: не нужно доказывать, что данные «не персональные» — проще исходить из того, что они персональные, и выстроить соответствующие процессы.

6.2 Шаблонная политика конфиденциальности без упоминания конкретных инструментов

Миллионы сайтов в РФ используют одинаковый шаблон политики, который не упоминает ни Яндекс.Метрику, ни тепловые карты, ни session replay. При проверке РКН это будет нарушением.

Как избежать: перечислить каждый используемый инструмент с указанием категорий данных и цели. Если инструменты меняются — обновлять документ.

6.3 Баннер «для галочки» — без реальной блокировки сбора

На многих сайтах cookie-баннер существует, но счётчики уже загружены и начали сбор до нажатия «Принять». Это технически некорректная реализация.

Как избежать: использовать механизм отложенной загрузки (для Метрики — встроенный [9]), или CMP (Consent Management Platform), который управляет инициализацией всех трекеров.

6.4 Забытые «дочерние» инструменты

Аналитическая платформа может подключать субпроцессоров — например, Hotjar хранит данные на AWS, Fullstory — на Google Cloud. Вендор является обработчиком, но он сам передаёт данные в облачную инфраструктуру.

Как избежать: при выборе инструмента запрашивать у вендора список субпроцессоров и оценивать, куда именно уходят данные.

6.5 Непонимание, где ещё хранятся ПДн

Самая глубокая проблема: компании не имеют актуальной картины того, где в их ИТ-ландшафте реально обрабатываются персональные данные. Данные о поведении пользователей могут появляться в неожиданных местах — в логах, в CRM после интеграции с аналитической платформой, в Data Lake при выгрузке.

Часть 7. Кейсы и примеры из практики

7.1 Как выглядит корректная политика конфиденциальности с Вебвизором

Пример реального раздела из публично доступной политики конфиденциальности российского сайта, упомянутой в открытых источниках [27]:

Владелец сайта прямо указывает: используется Яндекс.Метрика включая функцию Вебвизора, в настройках которого отключена опция «Записывать все поля» — содержимое полей заменяется «звёздочками». При первом посещении отображается баннер об использовании cookies и Вебвизора. Пользователю предоставлена возможность отказаться от сбора данных через установку блокировщика Метрики.

Это пример грамотной политики: конкретный инструмент, конкретная настройка, механизм отказа.

7.2 Позиция РКН: прецедент с Яндекс.Метрикой

Роскомнадзор вынес конкретные предписания компаниям, использовавшим Яндекс.Метрику без явного согласия пользователей на передачу данных Яндексу [13, 25]. Ведомство ссылается на пользовательское соглашение самого Яндекса, в котором данные Метрики классифицированы как персональные.

Это создаёт прецедент: даже для российского сервиса с серверами в РФ и соблюдением локализации — согласие обязательно.

7.3 Microsoft Clarity и вопрос использования данных для AI

Сервис Mouseflow в своём сравнительном анализе открыто указывает: Microsoft использует данные, собранные через Clarity, для обучения AI-моделей [23]. Это означает, что данные посетителей сайта фактически становятся частью обучающего датасета Microsoft. Для компаний, обрабатывающих чувствительную информацию или работающих в регулируемых отраслях, это существенный риск, выходящий за рамки формального соответствия 152-ФЗ.

Часть 8. Тренды и будущее регулирования

8.1 Автоматизация надзора

Роскомнадзор применяет систему «Ревизор» для автоматического мониторинга сайтов [14]. В перспективе автоматизированный анализ будет включать проверку наличия cookie-баннеров и корректности их реализации. Это значит, что нарушения будут выявляться не только при плановых проверках раз в три года, но и в режиме непрерывного мониторинга.

8.2 Рост требований к «privacy by design»

Европейский опыт GDPR показывает: регуляторы всё активнее требуют встраивания защиты данных в архитектуру продукта, а не прикладывания документов постфактум. В России этот принцип пока не закреплён нормативно, но в методических рекомендациях РКН прослеживается движение в эту сторону.

Для инструментов поведенческой аналитики это означает тренд на: самоисключение чувствительных данных из записи на уровне SDK, автоматическую анонимизацию по умолчанию, инструменты для реализации права на удаление.

8.3 Оборотные штрафы как переломный момент

Введение оборотных штрафов (до 3% выручки, минимум 25 млн рублей) делает тему ПДн вопросом совета директоров, а не только юридического отдела [28, 29]. Компании, которые ещё несколько лет назад могли позволить себе игнорировать требования из-за незначительных штрафов, сейчас находятся в принципиально иной ситуации.

Часть 9. Практический чек-лист

Если ваша компания использует session replay, Вебвизор или тепловые карты — пройдитесь по этому списку:

1. Инвентаризация инструментов — составьте список всех аналитических сервисов, установленных на сайте или в приложении. Включите всё: пиксели, счётчики, SDK.
2. Классификация данных — для каждого инструмента определите, какие категории ПДн он обрабатывает.
3. Обновление политики конфиденциальности — упомяните каждый инструмент с описанием данных, цели, сроков хранения, правового основания и способа отказа.
4. Реализация cookie-баннера — убедитесь, что счётчики не запускаются до согласия. Проверьте технически (DevTools → Network — нет запросов к metrika.yandex.ru до нажатия «Принять»).
5. Настройка маскирования — все поля с ПДн должны быть замаскированы. Проведите ревью настроек каждого инструмента.
6. Анонимизация IP — включите усечение IP там, где это доступно.
7. Проверка сроков хранения — настройки в инструменте должны соответствовать задекларированным срокам в политике.
8. Поручение на обработку — оформите для каждого вендора (для Яндекса — принятие условий использования, для западных — DPA).
9. Уведомление РКН — убедитесь, что организация зарегистрирована как оператор ПДн; при необходимости подайте уведомление или обновите его.
10. Трансграничная передача — если используются западные инструменты, уведомите РКН о трансграничной передаче.
11. Регулярный аудит — не реже раза в год проверяйте актуальность инвентаризации: ИТ-ландшафт меняется, появляются новые счётчики и интеграции.

Заключение

Session replay, Вебвизор и тепловые карты — мощные инструменты, которые действительно помогают улучшать продукты. Но они работают с персональными данными — и это не вопрос интерпретации, это позиция Роскомнадзора и самих вендоров.

Хорошая новость: большинство ведущих инструментов предоставляют технические средства для минимизации рисков — маскирование, анонимизацию, механизмы согласия. Плохая новость: сами по себе эти средства не работают — их нужно настроить, задокументировать и поддерживать в актуальном состоянии.

Главная системная проблема — не незнание закона, а отсутствие непрерывного контроля: компании не знают в каждый момент времени, где и какие персональные данные у них обрабатываются. ИТ-ландшафт меняется постоянно: маркетолог подключил новый пиксель, разработчик добавил форму, появилась интеграция с CRM — и данные уже «вытекают» в новое место.

Именно эту задачу решает платформа Пятый фактор — on-prem система автоматического обнаружения и инвентаризации персональных данных в корпоративных системах. В контексте аналитических инструментов это означает: вы всегда видите, какие системы на вашем сайте или в приложении собирают данные, какие поля содержат ПДн, кто является владельцем этих данных и что изменилось. При этом сама платформа работает только с метаданными и структурой — без хранения и передачи «сырых» ПДн, — что означает, что она не создаёт новых рисков в процессе контроля. Для компаний, которые готовятся к аудиту РКН или просто хотят держать руку на пульсе — это переход от разовых ручных проверок к непрерывному процессу.

Источники

[1] Fullstory: Session Replay — The Definitive Guide — https://www.fullstory.com/blog/session-replay/

[2] Amplitude: What Is Session Replay — https://amplitude.com/explore/analytics/session-replay

[3] Mouseflow: How Session Replays Work — https://mouseflow.com/blog/how-session-replays-work/

[4] Fullstory: GDPR and Fullstory — https://www.fullstory.com/resources/gdpr-and-fullstory/

[5] New Relic: Session Replay Documentation — https://docs.newrelic.com/docs/browser/browser-monitoring/browser-pro-features/session-replay/

[6] Siteimprove: Session Replays Technical Documentation — https://help.siteimprove.com/support/solutions/articles/80001185436-session-replays-technical-documentation-and-data-collection

[7] Яндекс: Условия использования сервиса Яндекс Метрика — https://yandex.ru/legal/metrica_termsofuse/ru/

[8] Яндекс: Конфиденциальность персональных данных (справка Метрики) — https://yandex.ru/support/metrica/general/confidential-data.html

[9] Яндекс: Предупреждение о сборе статистики — https://yandex.ru/support/metrica/general/notification.html

[10] КонсультантПлюс: Штрафы за персональные данные с 30 мая 2025 года — https://www.consultant.ru/legalnews/28492/

[11] Pendo: Session Replay Privacy — https://support.pendo.io/hc/en-us/articles/18049064847515-Session-Replay-privacy

[12] ICTech: Яндекс.Метрика и персональные данные — https://ic-tech.ru/blog/faq/questions-152fz-site/kakie-personalnye-dannye-sobiraet-yandeks-metrika-i-kak-ih-legalizovat/

[13] Botman.one: РКН о Яндекс.Метрике как сборе ПДн — https://botman.one/blog/post?post_id=59

[14] Krivoshein.site: Роскомнадзор 2025 — cookie и локализация — https://krivoshein.site/roskomnadzor-v-2025-godu-tehnicheskie-aspekty-lokalizatsii-personalnyh-dannyh-i-novye-trebovaniya-k-cookie/

[15] Fullview: What Is Session Replay — https://www.fullview.io/blog/what-is-session-replay

[16] B-152.ru: Ответы на вопросы по обработке персональных данных — https://b-152.ru/faq

[17] hoop.dev: GDPR Compliance for Session Replay — https://hoop.dev/blog/gdpr-compliance-for-session-replay-a-privacy-first-approach

[18] it-pnk.ru: Увеличение штрафов за персональные данные 2025 — https://it-pnk.ru/news/uvelichenie-shtrafov-pd/

[19] Heap.io: What Are Session Replays — https://www.heap.io/topics/session-replays-recordings

[20] Glassbox: What is Session Replay — https://www.glassbox.com/session-replay/

[21] web-revenue.ru: Регулирование сайтов РФ — https://web-revenue.ru/internet-pravo/regulirovanie-otnosheniy

[22] Cookie-Script: Microsoft Clarity & GDPR — https://cookie-script.com/guides/microsoft-clarity-session-replay-gdpr

[23] Mouseflow: Best Session Replay and Heatmap Tools 2026 — https://mouseflow.com/blog/best-session-replay-and-heatmap-tools/

[24] Hotjar: What Are Session Recordings — https://www.hotjar.com/session-recordings/

[25] seolt.ru: Проверка сайта на соответствие 152-ФЗ — https://seolt.ru/blog/sooetvetstvie-saita-zakony-o-personal-dannyh

[26] Datadog: Session Replay — https://docs.datadoghq.com/session_replay/browser/

[27] Пример политики конфиденциальности с Вебвизором — https://sg-rnd.ru/index/privacy-policy.html

[28] Saby-SBIS: Штрафы за персональные данные с 30 мая 2025 — https://saby-sbis.ru/blog/shtrafy-pri-rabote-s-personalnymi-dannymi-s-30-maya-2025-goda

[29] data-sec.ru: Штрафы за ПДн в 2026 году — https://data-sec.ru/personal-data/fines/

[30] Matomo Plugins: Heatmap & Session Recording — https://plugins.matomo.org/HeatmapSessionRecording