Защищаем свой сайт от негативной накрутки и скликивания контекстной рекламы

Наблюдаю ровно с начала апреля 2020 года:

  • рост трафика низкого качества из результатов поиска «Яндекса»;
  • существенное увеличение трафика низкого качества из сервиса контекстной рекламы «Яндекс.Директ»;
  • 90% всплеска низкокачественного органического трафика по московскому региону;
  • всплеск низкокачественного платного трафика из рекламной сети «Яндекса» по всем регионам, в которых настроены кампании.
  • из SERP Google ничего не прилетало;
  • в Google Ads всё ровно, всплесков нет;
  • ботного реферального трафика нет.

Всю эту прелесть я заметил на клиентских сайтах, кто продвигается в России.

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

 

Оглавление статьи:

Первый звоночек

  • Вырос объём кликов из контекстной рекламы без увеличения бюджета.
  • В то же время конверсия в контекстной рекламе немного снизилась.
  • Начался плавный рост поискового трафика из московского региона без каких-либо причин на это.
  • Выросло количество сессий по 0–5 секунд с однотипным поведением в Hotjar и вебвизоре «Яндекс.Метрики».
  • Было много сессий с долгим пребыванием пользователей на сайте, по 5–15 минут, но 99% этого времени — бездействие и судорожное перемещение курсора.
  • Google Analytics начал уведомлять о подозрительном трафике низкого качества.

У большинства владельцев сайтов в рунете установлена «Яндекс.Метрика», вот как это будет выглядеть там:

Апрель: 18,7% — отказы с поискового трафика. Обычный показатель: 8–10% отказов.

Апрель: 65,6% — отказы с трафика из рекламной сети «Яндекса». Обычный показатель в нише клиента: 25–35% отказов.

Чтобы было понятно, 65,6% отказов — это тысячи заходов, за которые списалась определенная цена за клик.

Поздравляю, вы стали свидетелем так называемой «мягкой накрутки» негативных поведенческих факторов и скликивания контекстной рекламы.

Всё это негативно сказывается на поисковом трафике (он будет падать или как минимум не расти) и бесполезной (для рекламодателя) растрате рекламного бюджета.

Вроде какие-то показатели незначительно изменились, да и трафик подрос, надо вроде как радоваться. Но если детально посмотреть сессии, на самом деле всё плохо.

Ещё бывает «резкая накрутка» и более бодрое скликивание, вот их признаки

  • Резкий рост показателя отказов в ЯМ или GA.
  • Резкий рост сессий 0–5 секунд (чаще 0–10).
  • До кучи накидываются пачками прямые заходы на сайт.
  • По ключам начинает идти лавинообразный трафик из SERP или контекстной рекламы.

Какой тип накрутки будет у вас, зависит только от узколобости и прямоты рук злоумышленников. Тут полный рандом, может быть и микс.

Как самостоятельно определить тип накрутки?

Прямая накрутка — на сайт идет прямой трафик, все сессии обычно 0–10 секунд, самый распространенный тип накрутки.

Переходы по фразам из поисковых систем — вводят ключевое слово в строку поиска, ищут ваш сайт, кликают, проводят 0–10 секунд, возвращаются обратную в поисковую выдачу. CTR вашего сайта на поиске падает, у конкурентов растёт, ваш сайт уходит в закат.

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

Скликивание контекстной рекламы (на поиске, в РСЯ или КМС) — рост сессий 0–10 секунд, рост числа повторных визитов с сессиями 0–10 секунд.

Точка невозврата

  • +100 сессий в день с типом накрутки: прямая, переход по фразе из поисковых систем, переход с других сайтов, обвалят поисковых трафик через 1–2 суток.
  • При бездействии в течение 2–3 недель будет фильтр от Google и «Яндекс», придётся менять домен.

Как это делают

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

Сервисы типа «Юзератора» и прочих, которые представлены в рунете, — это просто безобидная детская погремушка, которая блокируется на рас, по сравнению с тем, что можно словить в топе Google по ВЧ, например, в теме страховая в US.

Защищаем свой сайт от накрутки

Метод №1. Смотри сессии через вебвизор «Яндекса»

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

Включаем столбцы:

Устанавливаем активность:

Получаем перечень сессий с низкой активностью, начинаем анализ. Нужно обращать внимание на странные закономерности:

  • много сессий с одной и той же IP-сети;
  • много сессий с мобильной IP-сети, но заход был выполнен с ПК;
  • много сессий с пустым User-Agent;
  • много сессий с непопулярными User-Agent вроде типа Linux, CentOS, PaleMoon;
  • много сессий с повторяющимися визитами;
  • много сессий из одного региона или страны;
  • много сессий из московского региона по фразам, которые относятся к другим регионам;
  • много сессий с ПК, но разрешение экрана 360х720.

Вот пример подозрительной сессии:

  • IP-сеть Metropolitan branch of OJSC MegaFon AS25159 31.173.0.0/18;
  • заход был с ПК ОС Windows 10;
  • регион — Москва, ключевое слово относится к Питеру.

Что тут странного? Выполнен вход на сайт из московского метро с персонального компьютера из результатов поиска по ключевому слову, которое относится к Питеру. Сессия длилась 1 минуту 21 секунду, из которых 1 минута 19 секунд — время бездействия.

Задача: выявить максимальное количество подозрительных сессий и их IP-сети через вебвизор «Яндекс.Метрики», записать IP-сети в файл, даже если в поле IP-сеть фигурирует только название, например “Mobile subscribers pool” или “Biterika Grupp OOO”. Файл с перечнем IP-сетей понадобиться нам далее.

Ищем IP-сеть по названию

Допустим, мы знаем только название сети, например “Mobile subscribers pool”, идём в Google и ищем IP-сети используя следующий запрос “Mobile subscribers pool cidr” или “Mobile subscribers pool ip network”.

Получаем адреса вида 85.140.0.0/21, заносим их в файл.

Можно искать по номеру AS, если он есть в названии IP-сети, как в случае с Metropolitan branch of OJSC MegaFon AS25159.

Берем AS25159 и вводим в поиск на сайте ipinfo.io, кликаем слева в менюшке IP Address Ranges, записываем в файл все диапазоны, которые начинаются с “Metropolitan branch of OJSC MegaFon”.

Метод №2. Собираем IP-адреса сессий

В Google Analytics и «Яндекс.Метрика» по умолчанию нельзя собирать IP-адреса пользователей. Приватность, все дела. Но нам нужно решать свои задачи, поэтому есть два способа.

Первый способ: через Google Tag Manager

Заходим в GTM, Tags → New → Custom HTML, добавляем это:

<script type="application/javascript"> function getIP(json) { dataLayer.push({"event":"ipEvent","ipAddress" : json.ip}); } </script> <script type="application/javascript" src="https://api.ipify.org?format=jsonp&callback=getIP"></script>

Заходим в Triggers → New → Page View, нажимаем This trigger fires on Some Page Views. Выбираем Referrer → does not contain, вводим адрес своего сайта:

Далее заходим сюда: Navigate to Variables → User-Defined Variables → New → Data Layer Variable. Устанавливаем поле Data Layer Variable Name = ipaddress.

Заходим сюда: Navigate to Triggers → New → Custom Event, вводим имя события ipevent.

Всё готово, переходим в режим предварительного просмотра, там появится запись об IP-адресе.

Второй способ: через сервер

Тут всё зависит от хостинга. Можно собирать данные, включая IP-адреса пользователей из логов сервера.

При использовании Apache + nginx можно собирать сессии пользователей, предварительно установив модуль rpaf.

Логи можно лицезреть тут: /var/log/apache2/access.log.

Отсеиваем подозрительные IP-адреса, проверяем каждый тут ipinfo.io в строке поиска, получаем перечень подсетей, записываем в файл.

Третий способ: блокируем все страны, кроме той, где продвигаемся

Берем список ip-сетей с распределением по странам тут: www.ipdeny.com/ipblocks/

Приступаем к блокировке

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

Беру для примера Apache 2.4, на нём работает множество сайтов.

Итак, у нас есть перечень IP-сетей и нежелательных User-Agent, которым мы хотим заблокировать доступ к нашему сайту.

Открываем в корне сайта файл .htaccess и вводим следующее:

  • Блокировка IP-сетей, пример:

<RequireAll>
Require all granted
Require not ip 31.173.0.0/18
Require not ip 31.173.80.0/21
Require not ip 213.87.160.0/22
Require not ip 213.87.128.0/19
Require not ip 91.193.178.0/23
</RequireAll>

  • Блокировка нежелательных User-agent, пример:

<IfModule mod_setenvif.c>
SetEnvIf User-agent ^-?$ bad
SetEnvIfNoCase User-Agent Embedly bad
SetEnvIfNoCase User-Agent TweetmemeBot bad
SetEnvIfNoCase User-Agent discobot bad
SetEnvIfNoCase User-Agent Linux bad
SetEnvIfNoCase User-Agent PaleMoon bad
SetEnvIfNoCase User-Agent Pale Moon bad
<Limit GET POST HEAD>
Order Allow,Deny
Allow from all
Deny from env=bad
</Limit>
</IfModule>

Строка SetEnvIf User-agent ^-?$ bad отвечает за блокировку доступа к сайту для сессий с пустым User-Agent.

  • Блокировка реферального спама (переход с других сайтов на ваш сайт), пример:

фиксируем паразитные переходы с сайтов semalt.com, buttons-for-website.com

RewriteCond %{HTTP_REFERER} semalt\.com [NC,OR]

RewriteCond %{HTTP_REFERER} buttons-for-website\.com [NC,OR]

RewriteRule .* – [F]

  • Перенаправление пользователей с определенными IP на другой сайт

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

Делается это вот так:

RewriteEngine On
RewriteCond expr "! -R '83.180.64.0/18'"
RewriteRule .* https://site.com/ [R=301,L]

83.180.64.0/18 — подозрительная подсеть, https://site.com/ — сайт, на который автоматически будут перенаправлены пользователи.

Как проверить, что всё настроено верно

Проверяем статус ответа сервера тут calcus.ru/proverka-otveta-servera, актуально, если заблокирован доступ для определенных User-Agent:

На скриншоте видно, что сервер возвращает ошибку 403 (доступ запрещен) при попытке открыть сайт пользователем с User-Agent: Linux.

Также, смотрим статус ответа сервера тут webmaster.yandex.ru/tools/server-response/, должно быть так:

Код 200 говорит о том, что запрос успешно обработан и сайт доступен для основного робота «Яндекса».

Как отсечь нежелательные IP-адреса из контекстной рекламы

«Яндекс.Директ»: можно отключить максимум 25 IP-адресов в каждой кампании в разделе "Специальные настройки".

Решение по отсечению ботов в «Яндекс.Директ»:

  • Создаем сегмент в «Яндекс.Метрика» с теми, кто заходил на сайт и провел на нём менее 5–10 секунд, сохраняем сегмент.
  • Создаём аудиторию на основе сегмента в сервисе «Яндекс.Аудитории».
  • В настройках кампании ищем пункт «Корректировка ставок», добавляем сохраненный сегмент с корректировкой минус 100%.
  • Profit.

Google Ads: можно отключить по-человечески всё, что тебе нужно, и какие угодно IP-адреса, включая ipv6, и подсети, в разделе кампании «Настройки» → «Исключение IP-адресов».

На 100% отключить скликивание контекстной рекламы можно только если выключить саму рекламу.

В Google Ads рекомендую сделать анализ времени до конверсии и повторные заходы с рекламы, далее всё это отсечь через списки ремаркетинга.

Самые эффективные методы защиты

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

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

Правило №1 - разрешаем полный доступ всем известным ботам поисковых систем, социальных сетей, собственным серверам, api и так далее.

Правило №2 - полная блокировка доступа к интернет-магазину из всех стран, кроме России, а также блокировка по user-agent десятков сервисов анализа и мониторинга конкурентов.

Сюда же включается защита важных административных разделов сайта и файлов с доступом только с определенных ip. При этом хорошие боты получат доступ к сайту из любой страны.

Правило №3 - все запросы с ipv6 или по http получат капчу. Большие пулы адресов ipv6 можно получить очень дешево, чуть ли не бесплатно. Их используют для парсинга, накрутки и манипуляций, от которых мы хотим защититься.

В России на клиентских сетях ipv6 почти не распространён, поэтому потенциально затрагивается крошечный процент пользователей. Также все запросы по http получат капчу и затем 301-редирект на https - отлично помогает от некоторых паблик-сервисов накрутки пф и ddos-ботов.

Правило №4 - трафик с протоколами ниже http/2 и все прямые заходы попадают на 5-ти секундную JS-проверку. Данное правило отлично фильтрует паразитный трафик и тонны непотребства.

Поведенческие боты и люди с поддержкой JS в браузере успешно пройдут проверку и попадут на сайт. В Яндекс.Метрике трафик уйдет из прямых заходов в внутренние переходы.

На сегодняшний день старенькие мобильные браузеры не поддерживают http/2, поэтому небольшой процент реальных пользователей также может попасть на JS проверку.

Некоторые хитроботы маскируются под реальных посетителей с http/2 или http/3. Мы их будем фильтровать на втором барьере защиты.

Какие настройки не помогут от поведенческих ботов:

  • включение under attack mode;
  • bot fight mode и super bot fight mode на платном тарифе.

На скриншоте выше можно увидеть столбец CSR (Challenge Solve Rate) - это соотношение количества запросов прошедших проверку на бота к общему количеству запросов. Если CSR > 3% значит что-то настроено неверно и правило цепляет много реальных пользователей.

Как видно из аналитики - фаервол предотвращает ~100к паразитных запросов к сайту в сутки. Данные запросы стопаются на Cloudflare и не доходят до веб-сервера.

В качестве второго барьера защиты мы используем сервис Antibot.Cloud. На сегодняшний день это является самым гибким решением для защиты от негативной накрутки.

Большинство пользователей с белыми fingerprints, cookies и ip проходят проверку автоматически. Подозрительным пользователям и ботам показывается окно в выбором цвета (реферер не имеет значения).

В таком конфиге поведенческие боты фильтруются замечательно и не могут получить доступ к интернет-магазину. Яндекс.Метрика таких ботов также не видит, в cookies бота будут отсутствовать записи о посещении сайта.

Всю статистику мы отслеживаем в веб-интерфейсе и оперативно добавляем правила фильтрации трафика в пару кликов.

С таким фаерволом мы обеспечиваем:

  • защиту от поведенческих и спам-ботов;
  • защиту от любых парсеров (прокси, http-заголовки и user-agent не имеют значения);
  • защиту от фейк-ботов с user-agent как у официальных роботов поисковых систем;
  • защиту от проксирования сайта дорвеями;
  • проверку ботов по PTR-записям;
  • снижение нагрузки на веб-сервер.

Чем больше поискового трафика на сайте - тем сложнее опрокинуть ему поведенческие факторы. При наращивании поискового трафика до ~300 000 уников в месяц мы подключаем в конфиг сайта Antibot.Cloud только для трафика из соц. сетей, непопулярных поисковых систем и прямых заходов.

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

Антибот не препятствует нашим ботам для положительной накрутки пф. Для этого перед заходом в интернет-магазин наши боты переходят сначала на секретный url с php скриптом, где каждый бот получает секретный cookie-ключ.

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

При проведении SEO-работ одной из базовых вещей является парсинг и анализ конкурентов. На этом строится множество технологий и сервисов по анализу текстов, структуры, семантики, ссылок и прочего.

В интернет-магазинах конкуренты часто парсят цены и делают у себя немного дешевле. В итоге веб-сервер попусту нагружается, конверсия снижается, а другие интернет-магазины получают преимущества в результате активных SEO-работ.