Содержание
На сайте появился cookie-баннер – и кажется, что вопрос с персональными данными закрыт. Но баннер только спрашивает посетителя о выборе. Он не показывает, какие сервисы уже успели загрузиться, что отправляет форма и куда попадают оставленные данные.
Бояться самого баннера не нужно, как и срочно переделывать весь сайт. Проверять стоит то, что происходит до выбора и после него. Иногда достаточно убедиться, что лишние сервисы не запускаются. Иногда нужно проследить весь путь заявки.
Начать можно без чтения закона по статьям и сложных инструментов. Сначала достаточно понять, есть ли на странице аналитика, внешние виджеты, формы или личный кабинет. От этого зависит, насколько глубокой должна быть проверка. Ниже – простая развилка, а затем подробный технический маршрут.
Нужно ли проверять сайт и с чего начать
Посмотрите на страницу обычными глазами и выпишите всё, что связывает её с внешними сервисами или позволяет человеку оставить сведения о себе. Этого достаточно, чтобы выбрать первый шаг и не превращать проверку в бесконечный аудит всего подряд.
- Форм, аналитики и виджетов нетНе заказывайте переделку из тревоги. Зафиксируйте фактическое состояние и отдельно уточните, что хранит хостинг и какие документы относятся к сайту.
- Есть аналитика, чат, карта или видеоНужна техническая проверка: что загружается до выбора, что меняется после отказа и соответствует ли код обещанию интерфейса.
- Есть форма, заказ или личный кабинетПроверяйте весь путь данных: сайт, почту, CRM, Telegram, базы, сроки хранения и возможность удаления. Одного браузера здесь уже недостаточно.
- Глубина проверки зависит от сайтаЧем больше способов собрать или передать данные, тем длиннее маршрут. Если таких элементов нет, достаточно зафиксировать состояние и отдельно проверить хостинг и документы.
Главное: cookie-баннер не решает задачу автоматически и не доказывает, что всё настроено правильно. Сначала определите реальные потоки данных – и только потом решайте, что действительно нужно исправлять.
Баннер показывает выбор, но не доказывает поведение сайта
Самая частая ошибка начинается с правильного намерения. Владелец узнаёт о требованиях к персональным данным, ставит плашку, добавляет ссылку на политику и считает задачу завершённой. Посетитель видит два понятных действия. Вроде бы теперь всё под контролем.
Но баннер – это интерфейс. Под ним продолжает работать код: аналитика, виджет, шрифты, карта, видео, форма, чат, пиксель, менеджер тегов. Один скрипт загружается сразу, второй ставит идентификатор после прокрутки, третий отправляет текущий URL, четвёртый хранит выбор в браузере. Ничто из этого не обязано остановиться только потому, что поверх страницы появился вежливый вопрос.
Я увидел это на собственном портфолио. До технической пересборки Метрика начинала загружаться после действия, прокрутки или ожидания, а резервный noscript-запрос мог сработать без JavaScript. Страница политики возвращала ошибку. ИИ-виджет создавал постоянный идентификатор посетителя до отдельного выбора. Формы и внешние шрифты добавляли свои маршруты. Каждый элемент можно было объяснить по отдельности. Вместе они образовывали систему, которой никто не нарисовал карту.
Поэтому я не начинаю проверку с вопроса «есть ли cookie-баннер». Я начинаю с чистого браузера и смотрю, какие внешние соединения, cookie и записи в хранилищах появляются до любого нажатия.
Что здесь важно: наличие баннера – наблюдаемый факт об интерфейсе. Отсутствие необязательной передачи до выбора – отдельный факт, который нужно проверять.
Сначала я составляю карту данных, а не список установленных сервисов
Названия инструментов мало что говорят сами по себе. Яндекс Метрика может работать в базовой конфигурации, а может получать дополнительные события, параметры посетителя, содержимое URL и данные из других систем. Форма может ничего не отправлять, а может складывать обращения одновременно в почту, CRM и Telegram. Два внешне одинаковых сайта способны иметь совершенно разные потоки.
Если поток начинается с формы, полезно отдельно проверить, что спросить у разработчика перед запуском, а затем увидеть, где остаются копии заявки и кто может их удалить. Это два соседних участка одной карты.
Для каждого элемента я записываю пять вещей: какие сведения возникают, когда это происходит, куда они уходят, зачем нужны и как посетитель может изменить выбор. Получается не юридическая таблица ради таблицы, а техническая схема, на которой сразу видны странности.
Например, сам Яндекс пишет, что Метрика использует анонимные идентификаторы браузера в cookie и localStorage. В отдельной документации Яндекс запрещает передавать идентификационные сведения через UserID, параметры визита, JavaScript-события, поля форм, UTM, URL и заголовки страниц вне специально предусмотренных функций. Значит, проверить только наличие _ym_uid недостаточно: нужно посмотреть конфигурацию счётчика и данные, которые сайт добавляет к событиям. Документация о cookie и localStorage ↗, ограничения на идентификационные данные ↗.
Полезно отдельно отметить необходимые технические данные. Сайт вправе помнить выбранный язык, содержимое корзины или сам факт отказа от аналитики, если без этого не работает заявленная функция. Но слово «необходимое» нельзя назначить элементу за хорошее поведение. Нужно объяснить, без какой функции он действительно не обойдётся.
Практический вывод: проверяйте не «Метрику» или «форму» целиком, а конкретную связку: данные → момент → получатель → цель → способ изменить выбор.
Один сайт нужно проверить как минимум в четырёх состояниях
Открывать страницу в своём обычном браузере почти бесполезно. Там уже лежат старые cookie, сохранённое согласие, расширения и следы предыдущих тестов. Для первого прохода нужен чистый профиль или новое приватное окно с открытыми инструментами разработчика.
Первый визит без выбора. Не нажимаем ничего и ждём дольше любого таймера. Смотрим внешние запросы, cookie, localStorage и sessionStorage. Прокручиваем страницу, открываем меню и другие обычные элементы. Необязательная аналитика не должна включаться от нетерпения сайта.
Явный отказ. Выбираем только необходимое, переходим на другую страницу и обновляем её. Отказ должен сохраниться, а запрещённые запросы – не появиться. Если плашка исчезла, но счётчик начал работу, интерфейс и код договорились о разных версиях реальности.
Положительный выбор. Разрешаем аналитику и проверяем, что загружается один ожидаемый счётчик с заявленной конфигурацией. Яндекс показывает технический способ отложить загрузку до согласия, но отдельно предупреждает: пример текста не является гарантией соответствия законодательству. Это хорошая граница между документацией инструмента и решением оператора. Пример отложенной загрузки Метрики ↗.
Повторный визит и изменение решения. Закрываем сайт, возвращаемся, открываем настройки и отзываем согласие. После обновления Метрика не должна продолжать отправку. В её документации предусмотрено свойство disableYaCounter…, которое блокирует выставление cookie, сбор и передачу данных для посетителя. Но техническое отключение будущих запросов ещё не доказывает удаление сведений, полученных раньше. Механизм отказа Метрики ↗.
В каждом проходе я сохраняю короткий журнал: действие, ожидаемое событие, фактический запрос или запись, расхождение. Не обязательно превращать проверку в дипломную работу. Иногда одна строка «до выбора загрузился внешний скрипт» полезнее двадцати скриншотов аккуратного баннера.
Промежуточный итог: четыре состояния не доказывают идеальную работу сайта навсегда, но обнаруживают рассинхрон между обещанием интерфейса и поведением кода.
Браузер не видит оператора целиком
Техническая проверка хорошо отвечает на вопросы «что загрузилось», «куда ушёл запрос», «какой идентификатор появился» и «изменилось ли поведение после отказа». Но она не показывает, подано ли уведомление в Роскомнадзор, где фактически находятся базы, что хранится в резервных копиях, кому поручена обработка и кто выполнит запрос на удаление.
Закон определяет оператора не как автора баннера, а как лицо, которое организует обработку и определяет её цели, состав данных и действия с ними. Статья 9 требует, чтобы согласие было конкретным, предметным, информированным, сознательным и однозначным, а обязанность подтвердить его получение возлагает на оператора. Статьи 18 и 18.1 описывают обязанности при сборе и меры оператора, включая публичную политику. Статья 22 устанавливает обязанность уведомить уполномоченный орган до начала обработки, кроме предусмотренных законом случаев. Статья 9 ↗, статьи 18 и 18.1 ↗, статья 22 ↗.
Из этих норм нельзя вывести универсальную кнопку «сделать правильно». Основание обработки, применимость исключений, состав документов и обязанности конкретного владельца зависят от реальной деятельности. Поэтому я не считаю честным заканчивать технический аудит фразой «сайт полностью соответствует 152‑ФЗ». Код может быть аккуратным, а процесс удаления – существовать только в бодром обещании. Бывает и наоборот: документы подготовлены, но старый пиксель продолжает жить собственной жизнью.
На своём сайте после технических исправлений я всё равно оставил отдельный список владельческих вопросов: статус оператора, уведомление, фактические хранилища и резервные копии, получатели данных, сроки удаления, договоры и внешние кабинеты. Это не слабость результата. Это честная передача задачи следующему владельцу.
Граница: разработчик подтверждает наблюдаемое поведение сайта. Юридические основания, документы и организационные процедуры подтверждаются отдельно.
Исправлять нужно найденный поток, а не тревогу целиком
После карты и четырёх проходов задача обычно становится меньше. Если аналитика запускается до выбора, её загрузку переносят за положительное действие. Если отказ не сохраняется, чинят состояние настроек. Если URL или событие содержат email, телефон или другой идентификатор, убирают эти данные из передачи. Если политика недоступна, восстанавливают маршрут и сверяют текст с фактической системой.
В Portfolio я отключил автоматический запуск Метрики и noscript-запрос, оставил только базовую конфигурацию без Вебвизора, карты кликов, ecommerce, ручной передачи полного URL и referrer. ИИ-виджет стал локальным рассказчиком без постоянного посетительского идентификатора и сетевого API. Неиспользуемые формы перестали изображать боевой сбор заявок. Внешние шрифты были заменены локальными. Это конкретные технические изменения, а не заявление о полном соответствии оператора.
Если проверка не нашла необязательных запросов до выбора, отказ сохраняется, согласие включает только описанную конфигурацию, а изменение решения работает – не нужно переделывать сайт ради ощущения серьёзности. Зафиксируйте результат и переходите к владельческим вопросам. Хорошая проверка умеет завершаться не только списком работ, но и спокойным «в коде здесь ничего чинить не требуется».
Практический вывод: результат технического разбора – перечень подтверждённых потоков, точечных исправлений и вопросов, которые переданы владельцу, юристу или ответственному за данные.
После cookie-баннера проверьте не текст, а систему
Начните с карты: какие данные, когда, куда, зачем и как человек меняет выбор. Затем пройдите сайт в четырёх состояниях: до решения, после отказа, после согласия и при повторном визите или отзыве. Исправьте обнаруженные рассинхроны и отдельно зафиксируйте то, чего браузер не знает.
Cookie-баннер полезен, если он управляет реальным поведением сайта. Если он только сообщает о процессе, который уже начался, это дорогая табличка «не входить» на двери без стены.
И главное: не требуйте от технического аудита обещания, которого он не может дать. Его сильный результат – не сертификат спокойствия, а доказуемая карта фактов и следующий ответственный за каждую оставшуюся неизвестность.
Главный вывод: баннер – начало проверки. Техническая работа заканчивается, когда обещание интерфейса совпадает с кодом, а всё, что лежит за границей кода, явно передано владельцу.
Частые вопросы после установки cookie-баннера
Баннер сам делает сайт соответствующим требованиям?
Нет. Он показывает интерфейс выбора. Отдельно проверяются фактические запросы, формы, внешние сервисы, цели обработки и действия сайта до решения человека.
Достаточно проверить сайт один раз?
Нет. Новый виджет, аналитика, форма или обновление платформы могут изменить потоки. Нужна повторная проверка после существенных изменений.
Может ли разработчик провести всю проверку?
Он может показать техническое поведение браузера. Оператор данных, цели, основания и внутренние процессы определяет компания, при необходимости вместе с профильным юристом.
Можно ли считать проверку завершённой после настройки кнопки «Отклонить»?
Нет. Нужно проверить фактическое поведение страницы до выбора, после согласия, после отказа и при повторном визите, включая внешние запросы и сохранение выбора.
Что делать, если владелец не знает назначение установленного сервиса?
Сначала выяснить, какие данные и куда он передаёт, кто отвечает за его использование и нужен ли он бизнесу. Неизвестный поток нельзя закрыть одной формулировкой в баннере.
Первоисточники и границы проверки
Основные нормы собраны внизу, чтобы практический текст не превращался в перечень ссылок. Конкретная правовая оценка зависит от фактов компании.
