AdPump — Безопасность данных в Яндекс Метрике: cookies, согласия и что нельзя передавать открытым текстом

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

Коротко: Метрика работает через cookies и обезличенный ClientID. По 152-ФЗ и требованиям к cookie-уведомлениям на сайте должно быть согласие на обработку данных. В параметры событий и user params нельзя передавать телефон, email или ФИО в открытом виде — только хешированные значения или обезличенные идентификаторы.

← Каталог: Метрика · Введение · Системы аналитики · Счётчик и код · Основы HTML/JS · Карта настройки · Типы целей · Цели · Автоцели и ecommerce · ЯТМ на практике · Тег Менеджер · Фильтры и операции · Доступы и роли · Вебвизор и карты · Карты и формы · Семплирование · Отчёты · Стандартные отчёты · Атрибуция · Сегментация · Офлайн-конверсии · ClientID и идентификаторы · Measurement Protocol · CRM и интеграции · Битрикс24 и Albato · Мессенджеры · Воронки · AppMetrica · API: введение · API: возможности · API: архитектура · API: окружение · API: отчёты на практике · API: Logs · DataLens · Чек-лист · Справка Яндекс Метрики

Содержание

Правовая база: 152-ФЗ и согласие на cookies
Что собирает счётчик по умолчанию
Что не светить: правило для параметров событий
Хранение и срок жизни данных
Практика: что проверить на сайте

Правовая база: 152-ФЗ и согласие на cookies

Обработка данных посетителей сайта в России регулируется 152-ФЗ «О персональных данных». Практическое следствие для владельца сайта — на странице должна быть политика обработки персональных данных, а на сайте — заметное уведомление о использовании cookie-файлов с возможностью согласиться или отказаться.

Важно: Отсутствие cookie-уведомления не отключает счётчик технически, но создаёт юридический риск для владельца сайта — это ответственность бизнеса, а не только «настройка Метрики».

Что собирает счётчик по умолчанию

Стандартно счётчик фиксирует обезличенные данные: ClientID (см. ClientID и идентификаторы), URL страницы, источник трафика, устройство, браузер, регион по IP, действия на странице (клики, скролл, заполнение форм — без содержимого полей). Пароли и номера банковских карт Вебвизор скрывает по умолчанию — это встроенная защита, а не дополнительная настройка.

Что не светить: правило для параметров событий

При настройке целей и параметров пользователей частая ошибка — передавать в открытом виде телефон, email или ФИО как значение параметра события. Это персональные данные, и передавать их в аналитическую систему в чистом виде не следует.

Нельзя передавать как есть	Как делать правильно
Телефон в параметре события ("+7912...")	Хешировать (например, SHA-256) перед отправкой, если хеш нужен для матчинга
Email в параметре события	Использовать ClientID/UserID вместо email для связки с CRM
ФИО клиента в названии цели или параметре	Передавать только статус/факт события, ФИО оставлять в CRM

Для связки визита с продажей в CRM правильный ключ — ClientID, а не телефон или email в открытом виде.

Хранение и срок жизни данных

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

Практика: что проверить на сайте

Есть видимое уведомление о cookie с возможностью согласия/отказа.
Опубликована политика обработки персональных данных, доступная со всех страниц.
В параметры событий и user params не передаются телефон/email/ФИО в открытом виде.
Формы с чувствительными полями (пароль, номер карты) не попадают в записи Вебвизора — проверено, что защита включена по умолчанию.

Чек-лист безопасности данных

Cookie-уведомление на сайте с возможностью согласия/отказа
Политика обработки персональных данных опубликована и доступна
Параметры событий и user params не содержат телефон/email/ФИО в открытом виде
ClientID, а не персональные данные, используется как ключ связки с CRM

Комментарий эксперта

Екатерина Марченкова
Руководитель отдела по работе с клиентами Monster Context. Работает с аналитикой рекламных кабинетов с 2012 года.

На аудите аккаунтов регулярно вижу email или телефон клиента прямо в названии параметра события — это не про аналитику, а про юридический риск для клиента. Первое, что правим при приёме проекта.

Частые вопросы

Метрика сама нарушает 152-ФЗ, если её просто установить?
Нет, ответственность за уведомление о cookies и политику обработки данных лежит на владельце сайта, а не на счётчике аналитики.

Можно ли передавать хешированный телефон в параметрах цели?
Да, хеширование (например, SHA-256) — стандартная практика для матчинга без передачи данных в открытом виде.

Что делать, если разработчик уже передаёт email в параметре события?
Заменить передачу email на ClientID/UserID для связки с CRM, а email оставить только внутри CRM-системы.

См. также: ClientID и идентификаторы, Офлайн-конверсии.

Материал подготовлен редакцией AdPump совместно со специалистами Monster Context (m-context.ru) на основе практики ведения аккаунтов Яндекс Директа и обновлений Яндекс Метрики 2026 года.

Перейти в инструмент