Маскирование и персональные данные

Маскирование в ActionPulse собрано из нескольких независимых слоёв, и у каждого своя точная область действия. Эта страница отвечает на два вопроса, в которых чаще всего ошибаются: какой атрибут разметки что именно исключает и на какую автоматическую редакцию персональных данных полагаться нельзя.

Атрибуты разметки

Атрибут	Что делает точно
data-pp-block	исключает элемент и его содержимое из автосбора и скрывает его в записях сессий
data-pp-ignore	исключает элемент и его содержимое только из автосбора; на записи сессий не влияет
data-pp-hover	обязательная метка: без неё намеренные наведения на элементе не собираются вовсе
data-pp-track	делает элемент корнем клика и даёт ему устойчивый селектор
data-pp-section	объявляет раздел для события просмотра раздела и даёт устойчивый селектор
data-pp-id	только устойчивый селектор, на состав сбора не влияет
data-testid, data-test-id	используются как устойчивый селектор, если своих атрибутов нет

Как именно применяется исключение

Проверка идёт по ближайшему предку: элемент считается исключённым, если атрибут стоит на нём самом или на любом элементе выше по дереву. Значение атрибута не имеет значения — достаточно его наличия, data-pp-block без значения работает.

<section data-pp-block>
  <h2>Паспортные данные</h2>
  <input name="passport_series" />
  <p>Серия и номер как в документе</p>
</section>

На что исключение действует:

• клики, включая производные от них ярость-клики и «мёртвые» клики;
• намеренные наведения;
• просмотры разделов;
• фокус и потеря фокуса в полях форм;
• отправка формы — если атрибут стоит на самой форме.

На что оно не действует:

• просмотры страниц и глубина прокрутки — это события страницы, а не элемента;
• ошибки JavaScript и метрики загрузки — они не привязаны к элементу;
• ваши собственные вызовы отправки событий — состав свойств там определяете вы.

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

Маскирование по умолчанию

В записях сессий, без каких-либо настроек и на любом тарифе:

Что	Как
Все поля ввода	маскируются всегда, отключить нельзя
Пароли	маскируются отдельным правилом дополнительно
Весь текст страницы	маскируется в строгом текстовом режиме — он включён по умолчанию
Ссылки на внешние ресурсы	заменяются нейтральным адресом перед отправкой
Обработчики событий, стили, srcdoc	вырезаются
canvas, шрифты, встроенные изображения, кросс-доменные фреймы	не записываются вовсе

Что маскирование не покрывает:

• Свойства событий, которые отправляете вы. Это другой поток данных, и маскирование записей к нему не применяется — см. следующий раздел.
• user_id. Идентификатор субъекта не редактируется ни одним слоем. Что вы туда положили, то и будет видно в событиях, профилях и выгрузках.
• Селекторы и стабильные атрибуты. Значения id, data-pp-id, data-testid попадают в события как часть селектора. Трекер не берёт значение, похожее на секрет или прямой идентификатор, и строит структурный путь — но это грубая эвристика, а не гарантия. Не кладите в id элемента адрес почты или номер заказа клиента.
• Структуру и геометрию страницы. Запись сохраняет разметку: по маскированной форме видно, сколько в ней полей и какой они длины.

Переключатель «Текст на странице»

В настройках проекта есть выбор между строгим режимом (маскировать весь текст) и стандартным (маскировать только ввод и пароли). Важная деталь, которую не видно из интерфейса: локальный строгий режим трекера всегда сильнее серверного.

Подключение	Локальный режим	Что получится при выборе «Стандартный» в кабинете
Тегом скрипта, автоматическая инициализация	строгий: тег не умеет задавать режим	текст всё равно не собирается — ни в событиях, ни в записях
Явный вызов инициализации без указания режима	строгий по умолчанию	то же
Явный вызов инициализации с нестрогим режимом	нестрогий	текст собирается: до 64 символов в событиях клика и наведения, в записях текст не маскируется

То есть ослабить маскирование текста одной настройкой в кабинете нельзя: нужно ещё и явное решение в коде подключения. Обратное действие работает всегда — строгий режим в кабинете перекрывает любую локальную настройку, и строгим же режим становится, если трекер не смог получить конфигурацию сбора.

Даже в стандартном режиме текст не собирается с элементов, которые содержат поля ввода или находятся внутри них.

Как не отправить персональные данные в свойствах

Правило одно: не отправлять. Все слои редакции — страховка от ошибки, а не основной механизм защиты. Ниже — что каждый из них действительно делает.

Слой 1, в браузере, до постановки в очередь. Свойства проходят редакцию по именам ключей (password, token и его формы, secret, api_key, cookie, session_id, sid, otp, jwt, ticket, mfa_code, recovery_code) и по виду значения (заголовок авторизации, Set-Cookie, JWT, ключи ActionPulse). Персональные данные этот слой не распознаёт намеренно — за них отвечает сервер. Границы: глубина 12 уровней и 1000 значений; при их превышении, при циклической ссылке или неподдерживаемой структуре весь объект свойств заменяется на пустой.

Слой 2, на приёме, всегда. Секреты вырезаются независимо от настроек проекта: чувствительные ключи на любой глубине, присваивания секретов в свободном тексте, учётные данные в самом адресе, ключи ActionPulse, JWT и ссылки-возможности вида приглашения или сброса пароля.

Слой 3, на приёме, персональные данные. Три шаблона: адрес электронной почты, российский номер телефона (+7/8 с разделителями) и российский паспорт (четыре цифры серии и шесть номера). Совпавшее значение свойства заменяется целиком на [redacted]; в объектах и массивах проверяются строковые значения на любой глубине. В облаке этот слой не отключается — в интерфейсе соответствующая настройка показана только для чтения. Разрешить сохранение ПДн как есть может лишь оператор установки на своих серверах, отдельным флагом проекта.

Данные в свойстве	Распознаются
Адрес электронной почты	да
Российский номер телефона строкой	да
Серия и номер российского паспорта	да
Тот же телефон, отправленный числом	нет
Иностранный номер телефона	нет
Фамилия, имя, отчество	нет
Адрес проживания	нет
Дата рождения	нет
Номер банковской карты	нет
Номер иностранного документа	нет

Про номер карты отдельно: в свойствах события он не распознаётся и сохранится как есть. На экране профиля человека действует дополнительная маскировка при чтении — по именам ключей и по длинным последовательностям цифр, — но она не меняет сохранённое значение и не распространяется на выгрузки и SQL-консоль.

Что делать вместо этого:

1. Отправляйте внутренние идентификаторы, а не значения. Вместо email — user_id, вместо номера телефона — признак phone_verified.
2. Договоритесь о запрете на уровне схемы, а не на уровне ревью кода: реестр событий умеет отклонять и вычищать такие свойства сам.
3. Проверяйте url. Персональные данные чаще уезжают не в свойствах, а в адресах страниц: ?email=, ?phone=, идентификатор документа в пути. В адресах редакция точечная — вырезается только совпавший фрагмент, схема, домен, путь и UTM сохраняются, — но паспортный шаблон к адресам сознательно не применяется, чтобы не портить числовые идентификаторы в путях.

Запрет на уровне реестра событий

Классификация свойства	Что происходит на приёме
forbidden	свойство удаляется из сохранённого события, поднимается нарушение forbidden_property
potential_pii	значение принудительно проходит проверку на ПДн и заменяется на [redacted] при совпадении
обычное	проверяется только тип и ограничения значения

Работает это в режимах наблюдения и строгой проверки; в выключенном режиме проверки схемы нет вовсе. У нового проекта режим — наблюдение, то есть удаление запрещённых свойств уже действует. Подробнее — в статье про реестр событий.

У управляемого события полей формы четыре свойства объявлены запрещёнными на уровне платформы — value, field_value, keystrokes, change_value. Автосбор их не формирует, а попытка передать их вручную приводит к удалению свойства и нарушению. Содержимое поля не попадёт в аналитику даже по ошибке разработчика.

Если персональные данные уже отправлены

Порядок действий, именно в этой последовательности:

1. Перекройте источник. Уберите свойство из кода, пометьте его в реестре как запрещённое, разметьте область страницы атрибутом data-pp-block. Пока источник работает, любое удаление будет догонять новые события.
2. Удалите данные субъекта. Это отдельная процедура в кабинете, доступная администратору и владельцу проекта и не ограниченная тарифом. Она удаляет события человека, связки идентификаторов и фрагменты записей его сессий — см. удаление данных субъекта.
3. Если проблема в формах — удалите собранные данные форм проекта целиком: Настройки → Сбор и приватность → Данные форм. Операция удаляет оба управляемых события форм за всё время и не зависит от переключателя сбора. Отчёт «Формы» после неё станет пустым.
4. Если данные попали в записи сессий — уменьшите долю записываемых сессий или выключите записи, пока источник не перекрыт. Удаление субъекта заберёт и его фрагменты записей.

Что проверить

1. Найдите на своих страницах все поля с персональными и платёжными данными и убедитесь, что каждый такой блок помечен data-pp-block, а не data-pp-ignore.
2. Включите записи сессий на тестовом проекте, откройте свою запись и убедитесь, что помеченные области действительно не видны, а поля ввода маскированы.
3. Откройте несколько последних событий в списке событий проекта и поищите значения [redacted]: каждое такое значение — след того, что в свойствах уже уезжало лишнее.
4. Проверьте адреса страниц в событиях: в них не должно быть параметров с почтой, телефоном или токенами.
5. Зафиксируйте запрет в реестре событий для свойств, которые не должны приходить никогда, и включите режим наблюдения — он покажет нарушителей, не отклоняя события.