Политика cookie для сайта: как написать и связать с баннером

Короткий ответ

Cookie на сайте — это не только всплывающее окно с кнопкой «ОК». На практике tracking layer может включать cookie, localStorage, sessionStorage, first-party и third-party идентификаторы, счетчики аналитики, рекламные теги, чат-виджеты, подмену телефонов, встроенные карты, видео, Tag Manager и даже server-side отправку событий. Яндекс Метрика прямо пишет, что использует не только cookie, но и localStorage, а в актуальном перечне уже есть и sessionStorage; Google прямо пишет, что его теги устанавливают и читают cookie, а Measurement Protocol позволяет отправлять события на серверы Google по HTTP-запросам. Поэтому сильная cookie policy начинается с инвентаризации того, что реально грузится и что реально уходит с сайта, а не с баннера как отдельного текста.

Если на сайте стоят аналитика, рекламные теги, виджеты, карты, видео, чаты, call tracking или менеджер тегов, вам нужен не «баннер ради баннера», а связка из трех уровней: короткий интерфейсный слой для уведомления и выбора, отдельное раскрытие cookie/идентификаторов/скриптов, и базовая политика обработки персональных данных сайта. Закон о персональных данных требует публиковать документ, определяющий политику оператора в отношении обработки персональных данных, а Роскомнадзор отдельно напоминает об этой обязанности для сайтов, где собираются данные через интернет. При этом согласие по 152‑ФЗ должно быть конкретным, информированным и сознательным, а значит баннер без нормального раскрытия целей и состава tracking layer быстро превращается в слабое место.

Баннер, cookie policy и privacy policy

Cookie banner — это интерфейс. Он объясняет, что на сайте используются cookie и схожие технологии, дает короткое описание категорий и, если у вас реализовано управление выбором, позволяет принять, отклонить или настроить необязательные технологии. Но сам по себе баннер не заменяет документ: Google отдельно пишет, что Consent Mode не предоставляет баннер или widget, а работает с вашим баннером и подстраивает поведение тегов под выбор пользователя.

Cookie policy — это карта tracking layer. В ней вы по-человечески раскрываете, какие технологии стоят на сайте: cookie, localStorage, sessionStorage, Яндекс Метрика, Google Analytics, рекламные теги, чаты, подмена телефонов, видеовставки, карты, менеджер тегов, серверная передача событий. Здесь же раскрываются цели, возможные идентификаторы, провайдеры, способы отключения и связь с другими документами. Основа для такого документа — не абстрактный список «аналитические/маркетинговые», а фактическая инвентаризация сервисов. Это следует и из принципа целевого ограничения, и из запрета на избыточную обработку.

Privacy policy — базовый документ сайта по 152‑ФЗ. В нем раскрываются оператор, цели и правовые основания обработки, категории данных и субъектов, права субъекта, сведения о передаче, сроки обработки и другие обязательные блоки. Закон отдельно говорит, что субъект имеет право получить информацию о правовых основаниях и целях обработки, способах обработки, обрабатываемых данных, сроках обработки, предполагаемой трансграничной передаче и лицах, которым поручена обработка. Поэтому cookie policy обычно не заменяет privacy policy, а либо дополняет ее, либо выступает отдельным приложением/спецразделом, на который privacy policy ссылается.

Практически удобная логика такая: баннер отвечает на вопрос «что сейчас происходит и какой у вас выбор»; cookie policy отвечает на вопрос «какой tracking layer у сайта и как он устроен»; privacy policy отвечает на вопрос «кто и на каких основаниях вообще обрабатывает данные на сайте». Именно поэтому в статье про cookie разумно давать ссылку на политику ПДн, а не переписывать ее целиком.

Главная карта раскрытия

Ниже — рабочая таблица не «по учебнику», а для сайта, который нужно реально проверить. Она собрана из требований 152‑ФЗ к целям и объему обработки, из документации Яндекс Метрики по cookie и storage, а также из документации Google по cookie, consent mode и идентификаторам. Категории здесь практические, а не «закрытый юридический список».

Как сделать cookie inventory

Первое правило: проверяйте не шаблон сайта из Figma и не список сервисов «на словах», а живой сайт в браузере. Откройте главную, лендинг рекламы, каталог, карточку товара, checkout, форму заявки, thank-you page, личный кабинет и блог. Затем посмотрите три состояния: до взаимодействия с баннером, после принятия и после отказа. У Яндекс Метрики и Google есть сценарии, в которых работа tracking layer зависит не только от баннера, но и от настроек тегов: например, у Google basic consent mode до согласия не отправляет данные вовсе, а advanced consent mode может отправлять cookieless pings с технической и coarse-информацией при отказе.

Затем проверьте хранилища и сеть. На практике важно смотреть не только вкладку Cookies, но и localStorage, sessionStorage, а также network-запросы к сторонним доменам. Это критично, потому что localStorage хранится между сессиями браузера, а sessionStorage живет в пределах page session и вкладки; Яндекс Метрика использует обе технологии наряду с cookie. Если текст вашей политики написан только про «файлы cookie», а на сайте реально живут _ym<id>_lsid в localStorage и _ym_turbo_uid в sessionStorage, документ уже не совпадает с сайтом.

После этого спросите маркетолога, что подключено через рекламные кабинеты. Особенно важно не забыть про Google Ads, ретаргетинг, look-alike сценарии, call tracking, импорт офлайн-конверсий, чат-конверсии и связки аналитики с рекламой. Google прямо пишет, что cookies используются не только для Analytics, но и для remarketing, Google Ads и conversion measurement. Яндекс отдельно пишет, что chat goals и call tracking goals могут использоваться в Яндекс Директе и Яндекс Аудиториях. Это уже не про абстрактное «улучшение сайта», а про маркетинг и измерение рекламы.

Отдельный блок вопросов — разработчику. Нужны прямые вопросы: стоит ли Google Tag Manager; есть ли server-side tagging; используется ли Measurement Protocol; перевыставляются ли cookie сервером; подменяются ли номера; загружаются ли карты и видео сразу или только после клика; есть ли lazy-load; какие домены вызываются до согласия и после него. Это важно, потому что часть измерения уже может уходить не из браузера как видимый third-party script, а через server-to-server или server container. Google прямо описывает Measurement Protocol как отправку событий на свои серверы HTTP-запросами, а server-side Tag Manager — как отдельный слой, который принимает и маршрутизирует события.

Если вы используете Яндекс Метрику, пригодится и ее отладчик: он позволяет посмотреть, какие цели, ecommerce и параметры реально собираются. Для глубокой линии по аналитике здесь лучше дать ссылку на отдельный разбор — Метрика, Google Analytics, cookie и 152‑ФЗ.

Что проверить в Яндекс Метрике

У Яндекс Метрики на сегодня есть официальный перечень временных файлов. Из него для статьи про cookie policy особенно важны _ym_uid, который помогает различать посетителей, _ym_d, который хранит дату первого визита, _ym_isad, который используется для определения наличия блокировщиков рекламы, _ym_visorc_* для работы Вебвизора, а также ключи в localStorage, например _ym<номер счетчика>_lsid, _ym_hide_phones, _ym_retryReqs, и ключи в sessionStorage, например _ym_turbo_uid. Это уже достаточно, чтобы не писать в документе упрощенное «мы используем только cookie».

Дальше посмотрите не только на storage, но и на объем данных. В официальной таблице Яндекс перечисляет page URL, referrer, page titles, browser and version, OS, device, screen size, cookies, JavaScript, time zone, browser language, color depth, geography, JavaScript events, page loading parameters, file downloads, bounce, time on site и page depth. В документации по работе Метрики отдельно сказано, что JavaScript-код может отслеживать заполнение и отправку форм, клики по ссылкам и скролл, а также передавать данные о достигнутых целях. Это как раз то, что должно попасть в inventory, если на сайте используются цели, Вебвизор, формы или ecommerce.

Отдельно проверьте, используется ли ClientID и передается ли UserID. Яндекс пишет, что автоматически присваивает ClientID каждому уникальному пользователю сайта на уровне браузера, а при необходимости владелец сайта может передавать и свой UserID. Это особенно чувствительный момент: как только вы начинаете связывать поведение браузера с внутренним идентификатором пользователя, риск того, что набор данных попадет в периметр персональных данных, становится выше. При этом сама Яндекс Метрика в документации по user parameters отдельно рекомендует передавать как user parameters только те атрибуты, которые не содержат персональную информацию.

Если на сайте есть звонки и чаты, не прячьте их внутри общей фразы «аналитика для улучшения сайта». Яндекс прямо пишет, что call tracking передает call data в Метрику через API, создает специальные цели, позволяет видеть номер и тип звонка, связывать динамические звонки с сессиями и использовать эти цели и сегменты для рекламы в Яндекс Директе. По чатам логика похожая: chat conversions создают отдельные цели, учитываются в отчетах и могут использоваться для оптимизации рекламы. Значит, в cookie policy и в inventory их лучше раскрывать как отдельный слой, а не растворять в слове «улучшение».

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

С Google важно не сводить все к одному тезису «на сайте стоит _ga». Официальная справка GA4 говорит, что JavaScript-tags используют first-party cookies для различения уникальных пользователей и уникальных сессий, а другая справка уточняет: client ID хранится в first-party cookie _ga, если analytics_storage не отключено через Consent Mode. Одновременно Google подчеркивает, что библиотекам не обязательно наличие cookie, чтобы передавать данные в Analytics. Это значит, что простой поиск _ga в браузере не всегда отвечает на вопрос «идет ли аналитика».

Дальше нужно смотреть, какие именно поля и параметры могут уходить. В конфигурации GA перечислены cookie-related settings (cookie_domain, cookie_expires, cookie_path, cookie_prefix) и другие поля, включая language, page_location, page_title, screen_resolution, user_id и user_properties. По умолчанию client_id псевдонимно идентифицирует экземпляр браузера и хранится как часть first-party Analytics cookie; домен для cookie по умолчанию — верхний возможный уровень домена, а срок жизни можно кастомизировать. Отдельная страница про User ID прямо говорит, что эти идентификаторы используются для связывания поведения одного пользователя между сессиями, устройствами и платформами. Если на сайте есть вход в кабинет и user_id включается после авторизации, об этом нельзя умолчать в inventory.

По consent mode критично понять, какая реализация стоит на сайте. Google прямо разделяет basic и advanced consent mode. В basic до согласия ничего не уходит; в advanced при отказе cookies не ставятся, но отправляются cookieless pings, которые могут включать timestamp, user agent, referrer, флаг consent state и другие сигналы. Сам Google подчеркивает, что consent mode не заменяет баннер и лишь получает выбор из вашего cookie banner или widget. Поэтому в inventory и в cookie policy полезно отдельно проверять и раскрывать: используются ли consent mode, какие consent types заданы (analytics_storage, ad_storage, ad_user_data, ad_personalization, а также functionality_storage, personalization_storage, security_storage), и как сайт ведет себя при отказе.

Наконец, посмотрите, не подключен ли Google Ads, ремаркетинг, Floodlight или server-side слой поверх Google tag. Google пишет, что tags set and read cookies to identify unique users, что Ads и conversion measurement тоже используют cookie, а Measurement Protocol позволяет отправлять события напрямую на серверы Google. Именно поэтому в статье не стоит писать категорично ни «Google Analytics запрещен», ни «Google Analytics — это только анонимная статистика». Технико-правовой ответ всегда зависит от реальной конфигурации: какие теги стоят, какие consent states заданы, есть ли user_id, какие рекламные связки включены и какие события уходят серверно. Для отдельного deep dive здесь логично дать ссылку на подробную статью про tracking layer.

Пиксели, ретаргетинг, чаты, call tracking, карты и видео

Главная практическая ошибка сайтов — спрятать весь сторонний слой за формулой «мы используем cookie для улучшения работы сайта». Это слабая формулировка по двум причинам. Во‑первых, 152‑ФЗ требует, чтобы цели обработки были заранее определенными и законными, а объем обрабатываемых данных соответствовал этим целям. Во‑вторых, официальные материалы Google и Яндекса показывают, что часть инструментов очевидно относится не только к «улучшению сайта»: рекламные cookies и consent types у Google касаются advertising, personalization и measurement; call tracking и chat goals в Метрике используются для сегментов и рекламы в Яндекс Директе.

Поэтому практическое правило простое. Если инструмент участвует в атрибуции, ретаргетинге, ремаркетинге, audience building, measurement рекламы, импорте офлайн-конверсий, оптимизации кампаний по чатам или звонкам — описывайте его как рекламный/маркетинговый/измерительный слой, а не как «функциональность сайта». Если на странице встроены карта или видео стороннего сервиса, не пишите, что это «только визуальный элемент». Корректнее писать, что при загрузке таких элементов сайт может обращаться к стороннему провайдеру, и их нужно отдельно учитывать в inventory и раскрытии third-party services. Здесь лучше использовать модальную формулировку «может» и проверять сеть фактически на вашем сайте, а не обещать то, чего вы не проверили.

Это особенно важно еще и потому, что в публичном реестре операторов на портале персональных данных Роскомнадзора встречаются записи, где к обработке относят сведения, собираемые посредством метрических программ, cookie-файлы, cookie-идентификаторы, IP‑адреса, сведения о браузере, а также ClientID. Это не означает, что любой cookie автоматически всегда квалифицируется одинаково, но точно означает, что писать категорично «Метрика не относится к персональным данным» — плохая идея. Закон определяет персональные данные широко: это любая информация, относящаяся прямо или косвенно к определенному или определяемому физическому лицу. Плюс отдельный риск возникает, когда browser ID связывается с CRM, номером телефона, аккаунтом, user_id, чатом или звонком.

Что написать в cookie policy человеческим языком

Хорошая cookie policy не должна звучать как страшный реестр unknown-тегов или как рекламный текст. Ее задача — честно объяснить, что на сайте используются cookie и похожие технологии, какие именно группы сервисов стоят, для чего они нужны и как они связаны с privacy policy. Юридическая база здесь простая: у пользователя есть право знать правовые основания, цели, способы, категории и сроки обработки, а оператор обязан публиковать политику обработки персональных данных на страницах сайта, где идет сбор данных. Поэтому cookie policy может быть отдельным документом, но должна вести к базовой privacy policy и не конфликтовать с ней.

Рабочая структура документа для сайта Правослой может быть такой:

Что охватывает документ. Сразу напишите, что речь идет не только о cookie, но и о схожих технологиях хранения и идентификации: localStorage, sessionStorage, пиксели, счетчики, script tags, SDK-like identifiers, embedded services. Это важно технически и подтверждается хотя бы тем, что и Метрика, и веб-платформа браузеров используют не только cookie-механику.

Какие сервисы используются. Не абстрактные «аналитические инструменты», а конкретные названия: Яндекс Метрика, Google Analytics, рекламные инструменты Google, чат-виджет, call tracking, карты, видео, менеджер тегов. Если сервис уже отключен, не держите его в документе; если сервис включен не на всех страницах, так и напишите.

Для каких целей используются технологии. Делайте формулировки конкретными: обеспечение входа в аккаунт, сохранение пользовательских настроек, веб-аналитика, измерение рекламных кампаний, связь звонка с посещением сайта, учет обращений в чат, отображение стороннего контента. Это лучше, чем общая формула «для улучшения сайта», потому что закон требует заранее определенных целей, а РКН в практике проверок отдельно фиксирует отсутствие перечня собираемых данных и проблемы с описанием cookie/метрик.

Какие данные и идентификаторы возможны. Здесь лучше писать не исчерпывающий хеш всех ключей, а честный диапазон: cookie IDs, storage keys, session IDs, IP‑адрес, URL страницы, referrer, данные о браузере/устройстве/языке/часовом поясе, ad-click identifiers, события форм/чата/звонка, user_id — если реально используется. По Google и Яндексу такие классы данных прямо описаны в официальной документации.

Как это связано с персональными данными. Самая аккуратная формула выглядит так: *«В зависимости от конфигурации сайта и сочетания с иными данными отдельные идентификаторы и технические сведения могут относиться к персональным данным или использоваться в рамках их обработки»*. Такая формула лучше, чем любой категоричный тезис. Ее поддерживает широкий критерий персональных данных в 152‑ФЗ и практика официального реестра операторов, где cookie/идентификаторы нередко перечисляются как часть обрабатываемых данных.

Как отказаться или изменить выбор. Если у сайта есть real control center — пишите, где включить/отключить категории. Если такой функции нет, не обещайте «настроить cookie», когда фактически пользователь может только закрыть баннер. Корректно описать можно браузерные настройки, удаление cookie и обращение через контакты сайта, но если вы заявляете кнопки «Отклонить» или «Настроить», они должны реально работать. Это особенно важно на фоне требований к доказуемости согласия и права на отзыв согласия.

Связь с privacy policy. В конце сделайте связку с политикой ПДн и, если на сайте есть формы, с согласиями. Формулировка здесь должна быть спокойной: cookie policy раскрывает tracking layer, privacy policy описывает общий контур обработки персональных данных, а тексты согласий закрывают конкретные сценарии, где они действительно используются.

Ниже — компактный пример тональности для такого документа:

Мы используем файлы cookie и схожие технологии хранения и идентификации, включая localStorage, sessionStorage, счетчики веб-аналитики, теги и сторонние виджеты. Эти технологии помогают сайту работать, сохранять настройки, измерять посещаемость, анализировать эффективность рекламы, а в отдельных сценариях — учитывать обращения в чат или по телефону. В зависимости от конфигурации сайта отдельные идентификаторы и технические данные могут использоваться в рамках обработки персональных данных. Подробные сведения об операторе, целях и правовых основаниях обработки приведены в Политике обработки персональных данных.

Плохие и хорошие формулировки баннера

Ниже — пары bad/good не как «единственно правильная форма», а как редакционный ориентир. Смысл один: не обещать больше, чем реально умеет сайт, и не прятать маркетинговый слой за нейтральной лексикой. Такой подход лучше соответствует требованию к конкретному и информированному согласию и практике проверок, где РКН отдельно смотрит на cookie, метрические программы, механизм согласия и наличие документов.

Частые ошибки

РКН в публичных сообщениях о контрольных мероприятиях регулярно фиксирует проблемы именно вокруг cookie, метрических программ, согласия и отсутствия документов. На практике для сайта это выливается в типовой набор ошибок.

Чеклист перед запуском рекламы

Перед запуском рекламных кампаний имеет смысл пройти короткий контрольный список. Он сильно полезнее, чем переписывать баннер в последний вечер перед стартом трафика.

1. Проверьте главную, лендинг, каталог, карточку, формы, checkout и thank-you pages в трех состояниях: до выбора, после принятия, после отказа.
2. Зафиксируйте все storage и third-party запросы: cookie, localStorage, sessionStorage, script/iframe domains.
3. Подтвердите реальный стек у маркетолога: Метрика, Google Analytics, Google Ads, пиксели, chat tracking, call tracking, offline conversions.
4. Подтвердите реальный стек у разработчика: GTM, server-side tagging, Measurement Protocol, server-set cookies, lazy-load embeds.
5. Проверьте, что баннер не обещает того, чего сайт не умеет: отклонение, настройку, сохранение выбора.
6. Проверьте, что cookie policy перечисляет не только cookie, но и похожие технологии, а privacy policy не противоречит ей.
7. Если есть формы, свяжите тексты с согласиями и с общим чеклистом 152‑ФЗ.
8. Если запускаете рекламу, добавьте внутрь статьи ссылку на что должно быть на сайте перед запуском рекламы.
9. После изменений в рекламе, аналитике, форме, чате или checkout — повторите inventory.
10. Храните простую внутреннюю карту: сервис, цель, где стоит, что пишет в storage, что отправляет, где раскрыт в документах.

Что делать дальше

Следующий шаг после этой статьи — не писать «идеальный общий текст», а сверить документы с реальным сайтом. Для владельца сайта это обычно означает четыре проверки: что реально грузится в браузере; что уходит через аналитику и рекламу; как устроены формы и согласия; и совпадают ли баннер, cookie policy и privacy policy между собой. Для этого в экосистеме Правослоя логично вести читателя в общий hub документов для сайта в 2026, в статью про privacy policy и в материал про tracking layer Метрики и Google Analytics. Мягкий CTA здесь такой: сначала проверить cookie, аналитику, формы и рекламу на живом сайте, а уже потом связывать документы в единую систему — без громких юридических гарантий и без паники.

Источники и дата проверки