Как собирать данные в Яндекс.Метрику без согласия, не нарушая закон

В соответствии с Федеральным законом № 152-ФЗ «О персональных данных» оператор не вправе собирать персональные данные на сайте без согласия субъекта. При этом закон прямо запрещает ставить пользователя перед фактом сбора данных или принуждать его к даче согласия. Оператор обязан обеспечить возможность полноценного пользования сайтом без передачи персональных данных.

Что это означает на практике? Яндекс Метрика и другие счётчики статистики не должны начинать работу до того момента, пока пользователь не подтвердит своё согласие на обработку данных.

Для владельцев сайтов и маркетологов такая ситуация оборачивается настоящей катастрофой. Рекламные кампании запущены, бюджет расходуется, а в аналитику попадают только те посетители, которые нажали кнопку «Принять» в баннере согласия. В зависимости от сайта конверсия в согласие составляет от 20 до 70 процентов. Остальная часть трафика просто невидима.

Последствия предсказуемы:

• Анализ рекламы теряет смысл. Невозможно корректно оценить эффективность каналов, стоимость конверсии, поведение аудитории.
• Сегментация становится невозможной. Нет данных. Нет сегментов для ретаргетинга и look-alike аудиторий.
• Отчётность превращается в фикцию. Цифры в отчётах не отражают реальной картины.

• `PHPSESSID`, `JSESSIONID` — сессиионные идентификаторы, умирают при закрытии вкладки
• Токены корзины интернет-магазина
• CSRF-токены защиты от подделки запросов

• `lang=ru` (выбор языка)
• `theme=dark` (тёмная тема)
• Куки, запоминающие регион

• Яндекс.Метрика: `_ym_uid` (уникальный идентификатор пользователя), `_ym_d` (дата первого визита), `yandexuid`
• Google Analytics: `_ga`, `_gid`
• Рекламные пиксели: ВК-пиксель, cookie ретаргетинга

В самом тексте 152-ФЗ слова «cookie» не встречаются ни разу. Статья 3 закона определяет персональные данные максимально широко: «любая информация, относящаяся к прямо или косвенно определённому или определяемому физическому лицу».

Роскомнадзор и суды трактуют эту формулировку так: связка «уникальный cookie-идентификатор + IP-адрес + история просмотров» позволяет косвенно определить конкретного человека. А с учётом того, что Яндекс обладает экосистемой сервисов (Поиск, Почта, Яндекс ID), он может связать этот «анонимный» идентификатор с конкретным аккаунтом реального человека.

Если вы попросите юриста найти в 152-ФЗ запрет на сбор cookie или IP-адресов без согласия, он его не найдёт. В тексте закона этих слов нет совсем. Юрист читает закон, не видит там слова «куки» и успокаивается.

Разработчик вставляет код Метрики, вообще не задумываясь о законе. Он видит «просто программный код», который должен работать.

А потом приходит проверка Роскомнадзора, который трактует «любую информацию, позволяющую косвенно идентифицировать лицо» именно как cookie и IP, и выписывает штраф.

Возникает следующая ситуация: технически мы передаём просто массив данных, а юридически (по толкованию РКН и условиям самого Яндекса) мы передаём персональные данные без согласия субъекта.

Юристы не могут объяснить программистам, как «вырезать» из запросов этот цифровой отпечаток. Программисты не читают разъяснения РКН. Возникает слепая зона, в которой бизнес получает штрафы.

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

Это вопрос, который неизбежно возникает у технически подкованных читателей. Действительно, любой веб-сервер (nginx, Apache, IIS) автоматически записывает IP-адрес каждого посетителя в свои логи (`access.log`) при каждом обращении к сайту. Без этого просто физически не работает протокол HTTP.

Всё дело в цели обработки и том, кто получает данные.

Ваш сервер собирает IP для технических нужд, и это законно.
Когда nginx пишет IP в `access.log`, он делает это в рамках обеспечения функционирования сайта и информационной безопасности: защита от DDoS-атак, расследование попыток взлома, техническая отладка. Закон (152-ФЗ, ст. 6) прямо разрешает такую «технически обусловленную обработку». Эти данные остаются внутри вашей компании и не используются для маркетинга. Согласие не требуется.

Когда скрипт Метрики отправляет тот же IP вместе с cookie-идентификатором и историей просмотров на серверы Яндекса, это уже передача данных третьему лицу для маркетинговой аналитики и профилирования. Для этого по 152-ФЗ обязательно нужно согласие.

В чём суть решения ITF? Мы не трогаем ваши серверные логи. Они остаются у вас для безопасности, это законно и необходимо. Мы настраиваем систему так, чтобы на этапе отправки данных в Яндекс.Метрику через API отрезались именно те параметры, которые превращают технические данные в персональные: IP-адрес и cookie-идентификаторы.

Мы в ITF разработали техническое решение, которое закрывает данную слепую зону. Суть проста по идее, но требует специальных знаний в реализации:

Передавать в Яндекс Метрику данные без IP-адреса и без постоянных cookie-идентификаторов.

Если в запросе нет IP и нет `_ym_uid`, мы имеем дело с обезличенной информацией. Обезличенные данные не являются персональными данными в понимании 152-ФЗ. Следовательно, для их сбора согласие пользователя не требуется.

Вместо стандартного скрипта Метрики, который автоматически фиксирует IP, cookie и другие идентифицирующие параметры, выстраивается промежуточный слой обработки данных:

1. Браузер пользователя фиксирует поведенческие метрики: просмотры страниц, клики, прокрутку, время на странице, UTM-метки, тип события.
2. Серверный слой получает эти данные и удаляет (или необратимо хеширует) все идентифицирующие параметры: IP-адрес, `_ym_uid`, полный User-Agent, точные геоданные.
3. API Яндекс Метрики принимает очищенные данные в формате, который система корректно обрабатывает.

В результате Метрика получает факт события: «кто-то перешёл по такой-то ссылке и совершил такое-то действие». Но не может ответить на вопрос «кто именно».

• Общее число визитов и просмотров
• Конверсии (цели) и их источники
• UTM-метки и эффективность рекламных каналов
• Поведенческие метрики: глубина просмотра, время на сайте, показатель отказов
• Воронки продаж с обезличенными данными

• Сегменты для ретаргетинга на основе индивидуального поведения, связанные с Яндекс Client ID
• Некоторые метрики, например IP.

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

В стандартной Метрике роль такого идентификатора выполняет cookie `_ym_uid`. Живёт годами, «узнаёт» пользователя при каждом визите, склеивает все его сессии в единую историю. Именно `_ym_uid` превращает набор разрозненных событий в профиль.

Если вы не передаёте `_ym_uid` и не генерируете ему полную замену, привязать события к конкретному человеку невозможно. Профиль не создаётся.

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

• Уровень 1 — обезличенная аналитика. Работает для всех посетителей без исключения. Собирает 100% трафика, конверсии, источники. Согласие не требуется.
• Уровень 2 — персонализированная аналитика. Включается только для тех, кто нажал «Принять» в баннере согласия. Собирает индивидуальные воронки, сегменты для ретаргетинга, пользовательские пути.