Роботный трафик в Яндекс Метрике: как найти и очистить данные

Роботы способны превратить обычный день в «рекорд посещаемости», поднять отказы, сократить глубину и заполнить формы мусором. Но резкий график ещё не доказывает бот-атаку: причиной может быть рекламная кампания, ошибка счётчика, внутренний мониторинг или небольшая выборка с необычными визитами. Яндекс Метрика даёт отдельные способы увидеть и исключить определённый роботный трафик, если правильно понимать, что именно измеряет каждый отчёт.

Главное различие: отчёт «Роботы» в Метрике не является серверным логом. Он показывает отправки данных счётчиком о действиях, отнесённых к роботам, кроме отправок Вебвизора. Серверный журнал, напротив, фиксирует HTTP-запросы к серверу, включая обращения, при которых код Метрики вообще не выполнился. Эти источники дополняют друг друга, но их числа нельзя сравнивать как одну и ту же метрику.

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

Какие роботы попадают в аналитику

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

Метрика определяет роботов по нескольким признакам. Некоторые клиенты сами называют себя в User-Agent; такие известные роботы исключаются из обычной статистики и отображаются в специальном отчёте. Другие маскируются, и сервис применяет поведенческие и технические сигналы. В строке поведенческой фильтрации конкретное имя может не показываться, потому что вывод основан не на честно заявленном User-Agent.

Отдельная категория связана с отсутствием JavaScript и Referer. Счётчик включает JavaScript и невидимое изображение в noscript. Если JavaScript недоступен, просмотр может передаваться загрузкой изображения; отсутствие Referer при такой загрузке становится основанием отнести действие к роботу. Это правило не следует переводить в утверждение «любой браузер без JavaScript — злоумышленник».

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

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

Что показывает отчёт «Роботы»

Отчёт находится по пути «Отчёты → Мониторинг → Роботы». Он показывает активность, которую Метрика отнесла к роботам, с разбивкой по правилам фильтрации. Для представившихся клиентов может отображаться имя из User-Agent, а поведенческие правила идут отдельной строкой без детальной идентификации каждого клиента.

Ключевая метрика — «Отправка данных». Это количество отправок счётчиком о просмотрах и служебных событиях, включая вызов hit и неотказ. Это не число уникальных людей, не обязательно число визитов и не полный объём HTTP-запросов к инфраструктуре. Отправки Вебвизора в таблицу отчёта не входят.

Один робот может вызвать несколько отправок на одной странице, а другой получить HTML без исполнения JavaScript и не появиться как обычный счётчиковый визит. Поэтому строку 10 000 нельзя переводить в «10 000 ботов атаковали сайт». Формулировка отчёта должна сохранять единицу: 10 000 отправок данных, классифицированных определённым правилом.

Отчёт помогает сопоставить период всплеска с типами известной активности. Рядом откройте «Нагрузка на сайт»: по дням он показывает «Запросы в секунду (максимум)» для просмотров страниц и «Посетители онлайн (максимум)». Это максимумы интенсивности, а не суточная сумма HTTP-запросов. Даже совпадение двух отчётов не заменяет инфраструктурное расследование: для кодов 500, 429 и нагрузки нужны серверные метрики, CDN и журналы запросов.

Фильтруйте по дате и сравнивайте с журналом изменений: публикацией, рассылкой, новым мониторингом, рекламой, импортом каталога или релизом счётчика. Без контекста нормальный обход обновлённого раздела выглядит как подозрительный пик. Если нужны сведения именно о поведении поискового робота по URL, используйте подход из материала об анализе серверных логов.

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

Как сравнить данные с роботами и без них

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

Сравнивайте не только общий объём. Добавьте отказы, глубину, время, конверсии, страницы входа, источники, устройства, регионы и браузеры. Боты часто концентрируются на нескольких URL и дают короткие одноэкранные визиты, но универсального шаблона нет. Автоматизированный тест браузера может выполнять JavaScript, переходить по страницам и проводить минуты в сессии.

Начните с достаточно длинного стабильного окна и затем сузьте его до даты аномалии. В маленькой выборке один длинный визит меняет среднее, а один бот — долю конверсии. Медиана и распределение полезнее одной средней. Значение времени на сайте и глубины раскрывает отдельное руководство по поведенческим метрикам.

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

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

Какая фильтрация обратима, а какая нет

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

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

Яндекс рекомендует такой вариант, когда используется Logs API и нужны неагрегированные данные уже без роботов. В остальных случаях официальная справка предлагает менять режим отображения в отчётах. Это важная поправка к мифу «базовая фильтрация Метрики необратима»: базовый сравнительный просмотр обратим; необратима конкретная настройка исходных будущих данных.

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

Известные представившиеся роботы уже исключаются из обычной статистики и доступны в отчёте «Роботы». Не создавайте поверх этого самодельный фильтр по названию браузера или нулевому времени: он уберёт реальных людей и не поймает качественную автоматизацию. Дополнительные IP-фильтры применяйте только к известным собственным системам и документируйте диапазоны.

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

Чем Метрика отличается от серверных логов

Серверный лог создаётся веб-сервером, балансировщиком или CDN при обработке запроса. Он может содержать время, метод, URL, код ответа, объём, User-Agent, Referer и сетевой адрес. Там видны обращения к HTML, robots.txt, Sitemap, API, картинкам и другим ресурсам. Запрос появится даже тогда, когда клиент не выполняет JavaScript счётчика.

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

User-Agent сам по себе не подтверждает поискового робота: злоумышленник может написать любое имя. Для Googlebot и YandexBot используют документированные сетевые или DNS-проверки и официальные диапазоны, а не доверяют строке. Пошаговый процесс есть в статье о проверке поисковых роботов.

Разница в числах ожидаема. Один HTTP-запрос может привести к нескольким счётчиковым событиям, а тысяча запросов к изображениям — ни к одному визиту Метрики. Webvisor имеет отдельные отправки, которые не входят в таблицу «Роботы». Logs API Метрики тоже не равен серверному логу: он экспортирует неагрегированные данные, собранные самой Метрикой.

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

Как диагностировать аномальный трафик

Начните с проверки самого симптома. Сравните абсолютные визиты с обычным диапазоном, одинаковые дни недели и источники. Убедитесь, что счётчик не продублирован после релиза и AJAX-приложение не отправляет несколько hit на один экран. Если выросло только число просмотров без посетителей, возможна ошибка измерения, а не новая аудитория.

Затем включите сравнение с роботами и без них. Найдите страницы входа, часы, браузеры, страны и источники, где возникает разница. Массовые однотипные визиты на форму, поиск или случайные URL подозрительнее равномерного роста статей. Но неизвестный браузер не равен боту: корпоративные приложения и встроенные WebView тоже выглядят необычно.

Откройте отчёт «Роботы» на тот же период и сохраните правило классификации и число отправок. Если одновременно выросла нагрузка или ошибки 500, переходите к серверным метрикам. Сопоставьте URL, User-Agent, коды, частоту и сеть. Настройки WAF должны учитывать проверенных crawler; практические ограничения разобраны в материале про WAF, CDN и поисковых роботов.

Проверьте собственные системы: uptime-мониторинг, предпросмотр, тесты, сканер качества, CRM, calltracking, рекламные проверки и разработчиков. Их активность можно исключить точечно или изменить частоту. Блокировка всех дата-центров способна повредить легитимным сервисам и поиску.

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

Сформулируйте вывод вероятностно: «Метрика отнесла 2 400 визитов к роботам по поведению; серверные данные показывают всплеск запросов к /search с такой-то частотой». Это точнее фразы «нас атаковали 2 400 хакеров». Если доказательств недостаточно, продолжайте наблюдение и не удаляйте данные необратимой настройкой.

Как очистить рабочие отчёты

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

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

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

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

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

Как проверить ложные срабатывания

Любая классификация допускает ошибки. Необычный человек может отключить JavaScript, использовать приватный браузер, корпоративный прокси или вспомогательную технологию. Автоматический браузер, наоборот, может выполнять скрипты, хранить cookies и проходить типичные страницы. Поэтому решение о блокировке нельзя принимать только по строке Метрики.

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

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

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

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

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

Числовой пример сравнения сегментов

За неделю Метрика показала 12 000 визитов в режиме с поведенчески определёнными роботами. Сегмент без них содержит 9 600 визитов, значит роботными классифицированы 2 400: 12 000 − 9 600 = 2 400. Их доля составляет 2 400 / 12 000 × 100 = 20%. Это классификация Метрики, а не число уникальных программ.

В общей статистике было 19 200 просмотров и 3 600 отказов: глубина 19 200 / 12 000 = 1,6, доля отказов 3 600 / 12 000 × 100 = 30%. Без роботов осталось 16 320 просмотров и 1 440 отказов: глубина 16 320 / 9 600 = 1,7, отказы 1 440 / 9 600 × 100 = 15%.

Проверка арифметики сходится: 9 600 + 2 400 = 12 000, 16 320 + 2 880 = 19 200, 1 440 + 2 160 = 3 600. Глубина роботного сегмента равна 2 880 / 2 400 = 1,2, доля отказов — 2 160 / 2 400 × 100 = 90%. Именно этот сегмент искажал общее среднее.

Серверная проверка обнаружила частые запросы к внутреннему поиску и спам формы, а не доказала тождество каждого запроса визиту Метрики. После ограничения частоты и защиты формы в сопоставимую неделю осталось 9 600 человеческих и 600 классифицированных роботных визитов, всего 9 600 + 600 = 10 200. Роботная доля стала 600 / 10 200 × 100 ≈ 5,88%, а число таких визитов снизилось на (2 400 − 600) / 2 400 × 100 = 75%.

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

Какие показатели и пороги задать

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

Инфраструктурные показатели включают запросы в секунду, коды 429 и 5xx, время ответа, нагрузку и долю запросов к дорогим URL. Они берутся не из поведенческого отчёта и не заменяются Метрикой. Алерт должен вести к источнику: дашборду аналитики, журналу сервера или WAF, а не к общей фразе «много ботов».

Порог задавайте по базовой линии сайта. Например, предупреждение возникает, когда доля поведенческих роботов выше 12% два часа и абсолютный объём превышает 300 визитов; авария — когда одновременно растут 5xx или спам-цели. Числа являются внутренним примером, а не нормой Яндекса. Пересмотрите их после сезонной кампании и роста проекта.

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

Не используйте долю роботов как KPI SEO-специалиста. На неё влияют популярность сайта, открытые API, безопасность, мониторинги и внешние сервисы. Цель — достоверные отчёты и управляемая нагрузка. Для сравнения каналов фиксируйте сегмент и не меняйте методику в середине периода.

Как построить постоянный регламент

Назначьте владельцев аналитики, инфраструктуры и безопасности. Аналитик обнаруживает и сегментирует аномалию, инженер проверяет запросы и нагрузку, владелец формы оценивает спам, SEO-специалист защищает доступ легитимных crawler. Один человек может совмещать роли, но путь эскалации должен быть записан.

Ежедневно контролируйте резкие отклонения визитов и целей, еженедельно сравнивайте режимы с роботами и без них, ежемесячно проверяйте настройки адресов и собственные системы. После релиза счётчика, SPA, CDN или WAF запускайте отдельный smoke-тест. Не ждите квартального отчёта, если формы уже получают сотни ложных заявок.

Сохраняйте небольшой набор эталонных отчётов и точные единицы: визиты, просмотры, отправки данных, HTTP-запросы. Не называйте всё «трафиком» в таблице расследования. Это предотвращает ложное равенство между 40 тысячами запросов к картинкам и 40 тысячами посетителей.

Закрывайте каждый инцидент короткой ретроспективой. В ней должны быть исходный сигнал, подтверждённая причина, затронутые URL, влияние на аналитику и инфраструктуру, выполненная мера и результат повторного измерения. Отдельно укажите, что осталось неизвестным: Метрика могла классифицировать сегмент, но не назвать конкретную программу. Через неделю проверьте, не вернулся ли паттерн с другим адресом или параметром. Накопленные карточки помогают настроить собственную базовую линию и отличать сезонный обход от действительно нового сценария автоматизации.

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

Главный вывод

Чистая аналитика начинается с правильных единиц. Отчёт «Роботы» показывает отправки счётчика, обычные отчёты — визиты и события, а серверные логи — HTTP-запросы. Сначала сравнивайте обратимые режимы с роботами и без них, проверяйте URL и технические источники. Необратимой является только отдельная настройка удаления будущих поведенческих роботов из исходных данных; включать её без необходимости и сохранённой базовой линии не следует.