Cookie scanner не находит половину трекеров: где ломается
Cookie scanner обходит страницу как робот: загружает разметку, ждёт отрисовки, собирает запросы к сторонним доменам. Проблема в том, что реальный пользователь проходит по странице иначе — открывает модальные окна, соглашается с баннером, листает ленту, и только тогда подтягиваются скрипты аналитики, ретаргетинга и чатов. Сканирование cookie по умолчанию видит статический срез и пропускает всё, что подгружается по действию.
Самая частая причина — динамическая подгрузка. Скрипт вставляется в DOM после клика, скролла или таймаута, и в момент обхода его в разметке ещё нет. Вторая — сторонние скрипты, которые запускаются не напрямую, а через менеджер тегов: сканер видит один контейнер, а внутри него десяток тегов, каждый со своими cookie. Третья — скрытые пиксели и трекеры в iframe: они не отдают себя в основной документ, и обход их не фиксирует.
Отдельно ломают картину кэш и CDN. Сканер получает закэшированную версию страницы, где часть тегов уже вырезана или, наоборот, осталась от прошлой сборки. Если баннер согласия подгружается асинхронно, сканирование cookie может вообще не увидеть его в момент проверки — и в отчёте появится «чистая» страница, хотя на проде трекеры работают.
Итог: сканер показывает не реальный набор трекеров, а то, что успело выполниться за отведённое ему время. Поэтому корректная настройка начинается не с кнопки «Scan», а с воспроизведения пользовательских сценариев — разбираем, как это закрывается на уровне конфигурации обхода и менеджера тегов.
Что даёт корректная настройка сканера cookie
Настройка сканера cookie — это не «поставить баннер и забыть». Сканер обходит сайт по карте страниц, перехватывает запросы до и после взаимодействия с интерфейсом и собирает всё, что уходит в браузер: собственные скрипты, сторонние пиксели, встроенные виджеты, теги аналитики и рекламы. На выходе формируется реестр трекеров, где у каждого элемента есть источник, назначение, срок жизни и категория cookie. Если карта обхода неполная, часть трекеров остаётся вне реестра — и именно они становятся источником претензий при проверке соответствия.
Практика показывает: на типовом сайте с формами, чатом и встроенной аналитикой первичный обход находит заметно меньше трекеров, чем их есть на самом деле. Причина в том, что часть скриптов подгружается только после действия пользователя — отправки формы, открытия карты, клика по видео. Поэтому сканер настраивают в режиме сценариев: он проходит ключевые пользовательские пути, фиксирует изменения и добавляет найденное в реестр. После этого категории cookie перестают быть формальными — маркетинговые, аналитические и строго необходимые трекеры разносятся по своим группам, а не сваливаются в одну.
Отдельная работа — связка сканера с механизмом согласия. Пока баннер не получил явное действие пользователя, ни один необязательный трекер не должен стартовать; после отказа — не должен запускаться вовсе. Это проверяется не на глаз, а прогоном: сканер фиксирует, какие запросы уходят до согласия, какие после, и совпадает ли фактическое поведение с заявленным в политике. Расхождение здесь — самая частая причина, по которой проверка соответствия заканчивается предписанием.
Измеримый эффект от наведённого порядка складывается из нескольких вещей. Полнота реестра трекеров выходит на уровень, при котором новые скрипты ловятся на этапе добавления, а не через полгода. Доля корректных согласий растёт, потому что баннер перестаёт блокировать интерфейс и одновременно не пропускает трекеры раньше времени. Скорость прохождения проверок и аудит cookie занимают часы вместо недель — реестр, категории и логи согласий выгружаются одним отчётом. Класс претензий снижается: вместо спора о факте утечки данных обсуждается процедура, которая уже работает.
Способы развернуть сканер cookie: сравнение вариантов
Разворачивать сканер можно тремя способами, и выбор определяет не «модность» инструмента, а то, кто отвечает за актуальность базы трекеров и как быстро правка попадает на прод. Ниже — сравнение по реальным критериям: скорость подключения, контроль над данными, трудозатраты на поддержку и класс ограничений, который вы получаете вместе с каждым вариантом.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Облачный сканер | Нужен быстрый старт и регулярный пересканирование без своей инфраструктуры | Данные сканирования уходят на сторону вендора; глубина обхода ограничена тарифом и лимитом страниц; кастомные виджеты и скрипты, подгружаемые по действию, ловятся не всегда |
| Собственный сборщик на стороне сайта | Строгие требования к тому, где хранятся данные, или нестандартный стек | Нужно самим поддерживать обходчик, обновлять сигнатуры трекеров и следить за обновлениями браузерных политик; выше порог входа |
| Гибридная схема | Нужен контроль над данными плюс готовая база трекеров | Сложнее в отладке: расхождение между тем, что видит облако и что видит локальный сборщик, приходится разбирать вручную |
Ключевое ограничение любого сканера — он видит только то, что успел загрузить за время обхода. Скрипты, которые подключаются после согласия, при скролле или в модальных окнах, в базовый отчёт не попадают, поэтому подключение скрипта почти всегда дополняют ручной проверкой ключевых сценариев.
Гибридную схему выбирают, когда облачная база закрывает 80% типовых трекеров, а оставшиеся 20% — свои интеграции, которые нужно контролировать локально. Тогда облако отвечает за широту охвата, а собственный сборщик — за глубину по вашим сценариям.
Как мы внедряем сканер cookie: этапы работ
Внедрение начинаем не с баннера, а с инвентаризации: сканер обходит сайт по карте разделов и фиксирует, какие скрипты ставят cookie, к какому домену обращаются и до отправки согласия они грузятся или после. На этом шаге всплывают «забытые» счётчики, встроенные виджеты и пиксели, которые ставят сторонние подрядчики — именно они чаще всего ломают корректность баннера.
Дальше раскладываем найденное по категориям (строго необходимые, аналитические, маркетинговые, функциональные) и настраиваем поведение платформы: блокировку до согласия, повторный запрос при обновлении политики, срок хранения выбора, гео-правила для разных регионов. Категории сверяем с текстом политики cookie и перечнем в ней — расхождение между баннером и документом это первое, что находят проверяющие.
- Аудит страниц и инвентаризация скриптов: обход разделов, фиксация источников cookie и их назначения.
- Сверка с политикой конфиденциальности: приводим перечень cookie и категории к единому виду.
- Настройка категорий и триггеров: что блокируется до согласия, что грузится сразу, как работает отказ.
- Подключение платформы управления согласием и привязка к тегам и системам аналитики.
- Проверка на живом трафике: тестовые сессии, отказ и повторное согласие, мобильные браузеры, обновление страницы.
- Устранение расхождений: скрипты, которые ставят cookie в обход баннера, переносим под управление согласием.
- Передача документации и регламента сопровождения: как добавлять новые скрипты и когда пересматривать категории.
После запуска оставляем регламент: любой новый счётчик или виджет проходит через тот же контроль, а перечень cookie обновляется при изменении политики. Так сканер не превращается в разовую настройку — он остаётся рабочим инструментом, который держит согласия в актуальном состоянии.
Политики согласия и правила блокировки трекеров
Политика согласия — это не текст на странице, а исполняемая конфигурация: категории cookie, условия срабатывания баннера и правила, по которым скрипты либо грузятся сразу, либо ждут явного действия пользователя. Ниже — что заказчик получает на руки и по каким пунктам мы вместе проходим приёмку.
- Карта трекеров. Полный перечень скриптов, пикселей и тегов на всех шаблонах: имя, назначение, категория, момент загрузки. Сверяем с фактическим трафиком, а не с документацией подрядчиков — расхождения всплывают почти всегда.
- Категории cookie. Строго необходимые, аналитические, функциональные, маркетинговые. Границы прописаны так, чтобы спорный тег нельзя было отнести к «необходимым» по умолчанию.
- Правила срабатывания баннера. География, язык, повторный визит, отзыв согласия. Баннер не перекрывает контент и не блокирует интерфейс до согласия там, где это ломает сценарий.
- Список исключений. Теги, которые грузятся до согласия: защита от ботов, антифрод, балансировка. Каждое исключение обосновано и зафиксировано письменно.
- Журнал согласий. Что и когда выбрал пользователь, с какой версией политики, с возможностью выгрузки. Это доказательство при проверке и основа для повторного запроса при смене политики.
- Регламент обновления. Кто и как добавляет новый трекер, как он попадает в карту и категорию до выката в продакшн.
Отдельно фиксируем поведение при отказе: какие скрипты не стартуют, что удаляется из хранилища браузера, как отзыв согласия откатывает уже загруженные теги. Без этого политика остаётся декларацией, а блокировка трекеров — неполной.
Кейс: сканер cookie на сайте с десятками сторонних скриптов
Что было до
Клиент пришёл с типовой картиной: на сайте больше десятка сторонних скриптов — аналитика, рекламные пиксели, чат поддержки, карты, виджеты отзывов, — а баннер согласий показывал пользователю три категории и собирал отметки «на глаз». Автоматический сканер, запущенный в базовом режиме, находил 6-7 трекеров: он видел только те, что грузятся сразу при открытии страницы.
Остальные подключались позже — после прокрутки, клика по кнопке или через цепочку: один скрипт подтягивал второй, тот — третий. Такие трекеры сканер не фиксировал, и в реестре их просто не было. При этом часть из них ставила cookie до того, как пользователь вообще что-то нажал в баннере, — то есть согласие формально не собиралось, а данные уже уходили.
Что изменили
Мы перевели сканер в режим обхода сценариев: он проходил по страницам как реальный пользователь — открывал меню, доскролливал, отправлял формы, — и на каждом шаге фиксировал новые запросы и хранилища. Настроили периодический перезапуск, чтобы ловить скрипты, которые подключаются не каждый раз, и свели находки в единый реестр трекеров с указанием категории, назначения и момента срабатывания.
Дальше пересобрали логику баннера: категории согласий привязали к реальным группам трекеров из реестра, а загрузку каждого скрипта поставили в зависимость от полученного согласия. Технически это блокировка до явного разрешения — ни один трекер не стартует раньше, чем пользователь подтвердил соответствующую категорию. Инструмент — CookieBot, но подход переносится на любой сканер с поддержкой блокировки до согласия.
Что стало
| Метрика | До | После |
|---|---|---|
| Трекеров в реестре | 6-7 | 19 |
| Трекеров до согласия | 4 | 0 |
| Доля сессий с валидным согласием | ~60% | 94% |
| Ручные правки реестра в месяц | регулярные | по факту новых скриптов |
Реестр перестал быть неполным: новые скрипты, которые добавляют маркетологи, теперь попадают в него при следующем обходе, а не после жалобы. Проверка соответствия свелась к сверке реестра с фактическими запросами — расхождений нет.
Чем отличается сканер cookie от менеджера согласия?
Сканер cookie — это инструмент обнаружения. Он обходит страницы сайта как обычный посетитель, фиксирует, какие трекеры успевают запуститься до и после взаимодействия с баннером, и раскладывает их по категориям: строго необходимые, аналитические, маркетинговые. На выходе получается инвентарь — перечень скриптов с указанием источника, домена, срока жизни и назначения. Дальше этот перечень нужно поддерживать: стоит добавить новую форму, встроить чат или подключить рекламный пиксель — и инвентарь устаревает, пока сканирование не пройдёт заново.
Менеджер согласия решает другую задачу — он управляет баннером и хранением выборов. Именно он показывает посетителю окно с категориями, блокирует трекеры до получения согласия, записывает, что и когда человек разрешил или отозвал, и передаёт эти данные дальше — в аналитику и в журнал доказательств. Сканер сам по себе баннер не рисует и согласие не хранит; менеджер без сканера не знает полного списка того, что должен блокировать. Это и есть разница инструментов: один отвечает на вопрос «что у нас стоит на сайте», второй — «что посетитель разрешил и как мы это докажем».
На практике они работают в связке, и порядок важен. Сначала сканирование даёт полную карту трекеров, затем эти данные переносятся в настройки менеджера согласия — категории, правила блокировки, тексты баннера. После этого сканирование запускается повторно, уже с активным баннером: так проверяют, что до согласия не утекает ничего лишнего, а после — подключается ровно то, что разрешено. Регулярный прогон по расписанию ловит трекеры, которые добавили в обход процесса.
Для заказчика это означает простое разделение ответственности: сканер закрывает полноту и актуальность инвентаря, менеджер — корректность управления баннером и сохранность выборов. Когда оба настроены и связаны, проверка показывает, что ни один трекер не стартует раньше согласия, а журнал выборов готов к запросу в любой момент.
Частые технические сомнения по настройке сканера
Сканер cookie ведёт себя предсказуемо только на статичных страницах с серверным рендерингом. Как только появляются одностраничные приложения, отложенная подгрузка скриптов и агрессивный кэш на CDN, картина меняется: часть скриптов ставится уже после первого прохода, и сканер их не видит. Ниже — разбор ситуаций, с которыми сталкиваемся чаще всего.
Уже развёрнут другой сканер — переписывать всё заново?
Нет. Сначала снимаем текущую конфигурацию: какие категории заведены, по каким селекторам размечаются скрипты, как устроен баннер согласия и куда уходит журнал. Если разметка корректна, переносим её на новую платформу и меняем только то, что не покрывает требования. Полная замена нужна, когда категории не разделены или согласие не блокирует скрипты до его получения.
Одностраничное приложение — сканер видит не все скрипты. Что делать?
Проблема в том, что сканер обходит URL, а приложение подгружает модули по мере навигации. Настраиваем обход по реальным маршрутам, а не по одной точке входа, и добавляем ручную разметку для скриптов, которые ставятся по действию пользователя. После этого прогоняем сценарии: переход по разделам, открытие форм, авторизация — и сверяем, что каждый найденный скрипт попал в нужную категорию.
CDN и кэш отдают старую версию баннера. Как синхронизировать?
Сканер и баннер должны обновляться одной волной. Сбрасываем кэш на CDN после публикации конфигурации, версионируем сам скрипт баннера и проверяем, что на всех узлах отдаётся актуальная сборка. Иначе получается разрыв: сканер уже знает про новый скрипт, а посетителю приходит старая разметка без нужной категории.
Как часто запускать повторное сканирование?
Постоянно, а не разово. Ставим регулярный обход по расписанию и дополнительно — после каждого релиза, потому что новый код почти всегда тянет за собой новый скрипт. Результат каждого прохода сравниваем с предыдущим: появились неразмеченные cookie — сразу в работу, а не через месяц, когда это всплывёт на проверке.
Обсудим вашу задачу со сканером cookie
Разговор начинаем не с презентации, а с вашего сайта: сколько доменов и поддоменов, на чём собран фронтенд, как устроена выдача согласий и что уже настроено в текущем сканере. Этого достаточно, чтобы понять объём и не гадать по скриншотам.
Дальше работа идёт этапами, и на каждом вы видите результат, а не отчёт о занятости:
- Разбор текущего состояния — какие скрипты и трекеры реально грузятся, что из них до согласия пользователя, где сканер пропускает сторонние вставки.
- Сверка с требованиями — какие категории согласий нужны по вашей юрисдикции и модели работы с данными, что уже покрыто, а что нет.
- Оценка работ — объём правок в разметке и тегах, точки интеграции со сканером, трудозатраты по каждому блоку.
- План внедрения — последовательность шагов, что делаем на тестовом контуре, что выкатываем на прод и в каком порядке.
- Настройка и подключение — баннер, категории, правила блокировки до согласия, синхронизация с системами аналитики и рекламы.
- Проверка — прогон сканером, ручная проверка ключевых сценариев, сверка журнала согласий с фактическим поведением скриптов.
- Передача и сопровождение — доступы, документация по настройкам, регламент обновления при добавлении новых сервисов.
Поддержка сканера — отдельная часть работы: правила и категории устаревают, когда на сайт добавляют новый сервис или меняется разметка. Мы фиксируем, кто и как вносит изменения, чтобы баннер не расходился с реальным набором скриптов.
Опишите задачу: адрес сайта, текущий сканер и что беспокоит — пропущенные скрипты, устаревший баннер, отсутствие журнала согласий. Вернёмся с оценкой и планом работ.
