Баннер cookie против бота: почему половина сессий не доходит до контента

Сценарий отработал идеально: правильный отпечаток, живая мышь, естественная скорость скролла, переход из выдачи по нужному запросу. А в отчёте — отказ. Причина оказывается до обидного приземлённой: поверх страницы висит модальное окно с текстом про обработку данных и кнопкой «Принять», бот его не закрывает, контент под ним недоступен, и вся дорогая сессия превращается в двенадцать секунд разглядывания серой подложки.

Окна согласий давно перестали быть тонкой полоской внизу экрана. Сегодня это полноэкранные модальные слои с блокировкой скролла, с двумя-тремя уровнями настроек, иногда с отдельным экраном «Управление целями обработки». Для живого человека это раздражающая мелочь, для бота — стена. Ниже разбираем, как такие окна ломают и сам сценарий, и аналитику, которая должна этот сценарий подтверждать, и что с этим делать по обе стороны — в скрипте и на самой странице.

Что происходит, когда бот встречает модальное окно

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

Дальше возможны три исхода. Первый: окно появилось, скролл заблокирован свойством overflow: hidden на теле документа, бот честно шлёт события колеса мыши, страница не двигается, сценарий отрабатывает вхолостую. Второй: окно перехватывает клики, и все запланированные переходы по внутренним ссылкам не срабатывают — глубина просмотра остаётся единицей. Третий, самый коварный: окно не блокирует страницу технически, но перекрывает нижнюю треть экрана, и бот кликает по элементу, который находится под баннером — клик уходит в баннер.

Три типа окон, которые ломают сценарий по-разному

• Полноэкранная модалка с затемнением. Самая честная в своей агрессии: страница недоступна физически, пока не нажата кнопка. Ломает всё сразу — и скролл, и клики, и время на контенте.
• Липкая плашка снизу или сверху. Страницу не блокирует, но съедает от восьмидесяти до двухсот пикселей высоты экрана. На мобильных профилях это до четверти видимой области. Клики по элементам в этой зоне уходят мимо цели.
• Окно с несколькими экранами настроек. «Принять всё» на первом экране, но у части реализаций первая кнопка ведёт на второй экран с переключателями категорий. Сценарий, обученный на один клик, застревает на втором шаге.

Почему счётчик фиксирует именно отказ

Отказом считается визит, в котором не было второй просмотренной страницы и не сработали события, отмечающие вовлечённость. Бот, застрявший на первом экране, не выполняет ни того, ни другого: переходов нет, целевых событий нет, скролл-события либо не отправляются, либо отправляются с нулевым смещением. Формально это ровно тот профиль поведения, который счётчик обязан пометить как неудачный визит. И самое неприятное — такой визит портит не только конкретный сеанс, а общую статистику страницы, то есть работает против той самой задачи, ради которой запускался.

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

Таблица: типы окон согласия и их влияние на сценарий

Тип окна	Что блокирует	Риск для сессии
Полноэкранная модалка с затемнением	скролл, клики, выделение текста	критический: сессия мёртвая целиком
Липкая плашка снизу	клики в нижней зоне экрана	средний: часть переходов теряется
Плашка сверху со сдвигом контента	ничего, но сдвигает координаты	средний: клики по координатам промахиваются
Двухшаговое окно с настройками	всё до второго подтверждения	высокий: сценарий застревает на шаге два
Окно, появляющееся с задержкой	скролл после первых секунд	высокий: ломает середину сессии
Окно в теневом дереве документа	доступ к кнопке обычным селектором	высокий: кнопку не найти простым поиском

Последняя строка стоит отдельного пояснения. Часть готовых решений рисует окно внутри изолированного дерева элементов, куда обычный поиск по странице не достаёт. Скрипт, который ищет кнопку по тексту в основном документе, просто её не видит и уходит дальше по сценарию, будучи уверенным, что окна нет.

Аналитика, которой нет без согласия

Вторая половина проблемы тоньше первой. Многие сайты настраивают загрузку счётчиков в зависимости от решения пользователя: до нажатия кнопки счётчик либо не подключается вовсе, либо работает в урезанном режиме без записи сессии. Логика владельца сайта понятна, но для накрутки она означает вещь неприятную: визит, в котором бот не нажал согласие, для счётчика вообще не существует — или существует как обрывок.

Режим отложенной загрузки счётчика

Если на сайте настроено управление тегами с условной загрузкой, скрипт счётчика вставляется в страницу только после клика по кнопке принятия. Бот, который проигнорировал окно и честно отсидел на странице две минуты, с точки зрения статистики не сделал ничего. Хуже того: иногда счётчик всё-таки грузится, но с отключённой записью сеанса, и тогда поведение фиксируется как визит без единого действия — то есть ровно как отказ.

Что теряется в записи сессии

Запись сеанса — главный инструмент ручной проверки качества трафика. Если сессии обрываются на этапе баннера, вы лишаетесь единственного способа увидеть глазами, что делает ваш бот. В материале про запись сессий как детектор накрутки подробно разобрано, что именно там видно; здесь важно другое — если ваши сессии в записи выглядят как «открыл, постоял, ушёл», прежде чем винить сценарий, проверьте, не упирался ли он в окно согласия.

Окно согласия — это первый экран сайта для каждого профиля с чистым хранилищем. То есть для всей вашей фермы, всегда. Сценарий, который не умеет его закрывать, — это сценарий, который не умеет открывать сайт.

Как учесть окно согласия в сценарии

Ожидание появления, а не фиксированная пауза

Первая ошибка — жёсткий таймер «подождать одну секунду и кликнуть по координатам кнопки». Скрипт согласия грузится с разной скоростью в зависимости от канала, и на медленном мобильном прокси окно появится позже, чем на быстром. Правильно ждать появления элемента в дереве документа с разумным потолком ожидания — и только потом действовать. Если за отведённое время окно не появилось, сценарий идёт дальше как обычно.

Поиск кнопки по нескольким признакам

Универсального селектора кнопки согласия не существует: у каждого решения свои имена классов, свой текст, своя вложенность. Рабочий подход — искать по набору признаков: по тексту кнопки в нескольких вариантах написания, по служебным атрибутам, по расположению внутри контейнера с характерным именем. Для окон в изолированном дереве нужен отдельный проход с обходом теневых корней. Один селектор на все сайты — гарантия того, что на половине проектов сценарий будет мазать.

Пауза перед кликом, как у человека

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

Стабильность решения между визитами

Решение о согласии сохраняется в хранилище браузера. У живого пользователя оно там и остаётся: второй раз окно не появляется неделями. Если профиль возвращается на сайт и каждый раз видит окно заново, это косвенный признак того, что хранилище чистится между сессиями, — а вместе с ним чистится вся история профиля. Правильная работа с сохранёнными данными разобрана в материале про историю и сохранённые данные профиля; применительно к окнам согласия правило одно: принял — значит, при следующем визите окна быть не должно.

Разное поведение у разных профилей

Не все люди жмут «Принять всё». Часть закрывает окно крестиком, часть заходит в настройки и отключает лишние категории, часть игнорирует плашку и просто читает дальше, если она не блокирует страницу. Ферма, где сто процентов профилей за полсекунды жмут одну и ту же кнопку, выглядит однообразно. Разумно заложить распределение: большинство принимает, меньшая часть закрывает крестиком, единицы уходят в настройки. Это дешёвое разнообразие, которое ничего не стоит в реализации.

Таблица: что чинить в сценарии и что на странице

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

Что стоит поменять на самой странице

Не блокировать прокрутку

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

Отдать кнопке стабильный признак

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

Разделить согласие и загрузку счётчика

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

Не выводить окно повторно на каждом визите

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

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

1. Откройте целевую страницу в чистом профиле и засеките, через сколько миллисекунд появляется окно согласия. Это ваш минимальный порог ожидания в сценарии.
2. Проверьте, блокируется ли прокрутка: попробуйте прокрутить страницу, не закрывая окно.
3. Найдите кнопку принятия в дереве документа и убедитесь, что она доступна обычным поиском, а не спрятана в изолированном дереве.
4. Посмотрите, есть ли второй экран настроек за первой кнопкой.
5. Проверьте, грузится ли счётчик до нажатия согласия — по списку сетевых запросов страницы.
6. Закройте окно, перезагрузите страницу и убедитесь, что оно не появилось снова.
7. Повторите проверку на мобильном разрешении: там плашка часто ведёт себя иначе и занимает больше места.
8. Прогоните один тестовый визит и посмотрите его в записи сеансов: видно ли, что окно закрыто и сессия пошла дальше.

Разбор кейса: сценарий работал, а метрика не двигалась

Региональный проект в услугах запускал накрутку на группу коммерческих страниц. Инструментарий был выстроен аккуратно: отпечатки закрыты, прокси разогреты, движения курсора нейросетевые, сценарий предполагал переход из выдачи, чтение страницы, два внутренних перехода и возврат. По логам самого сервиса накрутки всё выполнялось. По счётчику сайта доля отказов на этих страницах не падала, а глубина просмотра держалась около единицы.

Разбирательство заняло полчаса и закончилось на первой же записи сессии. На видео было видно, как страница открывается, поверх неё выезжает полноэкранное окно согласия с затемнением, курсор начинает плавно двигаться по экрану, скролл-события уходят в никуда, потому что прокрутка заблокирована, и через полторы минуты вкладка закрывается. Все сто процентов визитов выглядели одинаково. Кнопка принятия при этом находилась в изолированном дереве элементов, и селектор, прописанный в сценарии, её не видел — скрипт считал, что окна нет.

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

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

• Считать окно согласия мелочью. Это первый экран сайта для каждого чистого профиля, а значит — для всей фермы.
• Фиксированная пауза вместо ожидания элемента. На медленном канале окно появляется позже, и клик уходит в пустоту.
• Один селектор кнопки на все проекты. Реализации разные, и на части сайтов кнопка вообще недоступна обычным поиском.
• Мгновенный клик по кнопке. Реакция за сорок миллисекунд — сама по себе аномалия в биометрии.
• Чистка хранилища между визитами. Возвращающийся профиль, который каждый раз видит окно заново, выглядит как новый пользователь с той же историей.

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

Можно ли просто удалять окно из документа вместо клика по кнопке? Технически можно, но тогда решение о согласии не сохраняется, счётчик при условной загрузке не подключается, а при следующем визите окно появится снова. Клик по настоящей кнопке решает все три задачи разом и стоит ровно на секунду дороже.

Влияет ли закрытие окна на распознавание бота? Само по себе — нет, это обычное действие. Подозрительным становится однообразие: если все профили за одинаковое время жмут одну и ту же кнопку с точностью до миллисекунд, это уже паттерн. Разброс по времени реакции и по варианту ответа снимает вопрос.

Как понять, что проблема именно в окне, а не в сценарии? Самый быстрый способ — посмотреть запись сессии. Если на видео курсор двигается, а страница стоит на месте под затемнением, диагноз очевиден. Косвенный признак — глубина просмотра строго единица при нормальном времени на странице.

Нужно ли учитывать окна на страницах, куда бот попадает внутренними переходами? Обычно нет: решение сохраняется на весь домен, и на второй странице окно уже не появится. Но проверить стоит — некоторые реализации выводят окно заново при переходе на поддомен, и это ломает сессию в середине.

Вывод

Окно согласия — самый недооценённый источник мёртвых сессий в накрутке поведенческих факторов: оно встречает каждый чистый профиль, блокирует прокрутку и клики, перехватывает нажатия, прячет кнопку в изолированном дереве, а при условной загрузке счётчика вдобавок делает визит невидимым для аналитики. Лечится это с двух сторон одновременно — в сценарии нужно ждать появления окна, а не отсчитывать фиксированную паузу, искать кнопку по нескольким признакам с обходом теневых корней, делать человеческую задержку перед кликом, распределять варианты ответа между профилями и сохранять хранилище между визитами; на самой странице стоит отказаться от блокировки прокрутки, дать кнопке устойчивый служебный атрибут, продлить срок жизни записи о согласии и трезво оценить цену условной загрузки счётчика. Проверяется всё это за десять минут через запись одной тестовой сессии, и начинать диагностику любой «необъяснимо плохой» накрутки разумно именно отсюда — прежде чем перебирать прокси и отпечатки, стоит убедиться, что бот вообще видит контент, за которым пришёл. Отдельно полезно свериться с материалом про сегмент роботности в счётчике: там видно, как выглядит доля неудачных визитов, и резкий её рост при неизменном сценарии почти всегда указывает на изменения в интерфейсе сайта, а не в качестве трафика.

Больше о поведенческом продвижении и других услугах — на главной странице ProfSEO24.