Ваша же защита режет вашу накрутку: конфликт антибота и ПФ

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

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

Где именно теряется трафик

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

Порядок прохождения запроса

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

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

Отсеянная защитой сессия не портит поведенческие показатели — она в них вообще не попадает. Проблема не в качестве метрики, а в том, что бюджет потрачен на визиты, которых для поисковой системы не существовало.

Почему обычная диагностика не находит причину

Типичная реакция на просадку — идти проверять качество трафика: отпечатки, профили, поведение. Всё это в данном случае может быть в полном порядке, потому что проблема не в трафике, а в том, что он не доехал.

Расхождение отчётов

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

Провал по конкретным сегментам

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

Ложный вывод про качество ботов

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

Таблица: на каком рубеже теряется сессия

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

Что именно срабатывает на вашем трафике

Репутация адреса выхода

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

Сетевой почерк соединения

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

Признаки автоматизации в окружении

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

Частота и плотность запросов

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

Таблица: признаки фильтрации против признаков плохого трафика

Наблюдение	Скорее фильтрация на входе	Скорее качество трафика
Разрыв отправлено и дошло	кратный, устойчивый	небольшой
Показатели дошедших визитов	нормальные	плохие: отказы, короткое время
Распределение потерь	сконцентрировано по подсетям	равномерное
Доля отсева по оценке качества	обычная	повышенная
Реакция на смену адресов	резкое улучшение	без изменений
Логи сервера	запросов вообще нет	запросы есть, поведение плохое

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

Как настраивать исключения, не снимая защиту

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

Разделить зоны по назначению

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

Снизить уровень, а не выключить

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

Списки исключений по адресам

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

Пересмотреть собственные правила

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

Убрать конфликт с ограничителем скорости

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

Порядок проверки, когда цифры не сходятся

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

Разбор кейса: половина бюджета уходила в стену

Интернет-магазин заказывал работу с поведенческими факторами и не понимал, почему при регулярной оплате движения почти нет. Внешне всё выглядело исправно: подрядчик показывал отчёты с выполненными заданиями, метрика показывала прирост визитов, но заметно меньше ожидаемого, а показатели дошедших сессий были при этом хорошими. Стандартная логика подсказывала искать проблему в качестве трафика, и первые две попытки шли именно туда: сменили пул адресов, потом инструмент.

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

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

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

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

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

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

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

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

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

Вывод

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

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