Семь заявок из 9 оказались ботами: почему цифра конверсий в отчете практически постоянно неправда

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

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

Дело было так. Веб-сайт лифтовой компании, месячный отчет, все как постоянно. В Yandex Метрике за окно 15 достижений цели «Выслал форму» из органики. Цифра приятная, ее можно нести клиенту. Но перед отправкой я по привычке залез в базу форм поглядеть, о чем люди пишут.

Настоящих заявок там было три. Другие 80% написал бот.

С этого началась история, которая завершилась проверкой всех 13-ти счетчиков. Выяснилось, что цифра «заявок» лжет как минимум 3-мя различными методами, при этом два из их никак не соединены со мусором.

Как смотрится бот, который заполняет ваши формы?

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

«Хороший денек! Нужен расчет: ваша услуга / ваше предложение. Принципиально уложиться в бюджет. Жду звонка».

Жив человек так не пишет никогда. Он пишет предметно: сколько этажей в доме, какого года постройка, что конкретно сломалось. Разница видна с первой строчки, если эти строчки совершенно кто-то читает.

Далее признаки, которые видно уже в базе:

• Один номер под различными именами. На лифтовом веб-сайте один номер (привожу его отчасти, +7 968 554-XX-XX) пришел поначалу как Максим, позже как Полина. На втором веб-сайте, о котором ниже, один номер отметился как Альбина, Екатерина и Лена.

• Датацентровые сабсети. Заявки шли с 196.244.192.43-46 и 82.118.29.64/66. Это не домашние провайдеры и не мобильный веб, это хостинг.

• Ротация браузеров. Chrome 122, Firefox 123, Edge 122 по кругу, при схожем поведении на веб-сайте.

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

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

2-ой веб-сайт: бот, который надувал не только лишь заявки

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

Из 79 заявок за три месяца ботами оказались 71, другими словами 90%. Настоящих воззваний за этот же период было восемь записей от 5 человек, а в июле не было ни одной. При всем этом отчеты за июнь и июль я уже выслал, и числа в их были «отличные».

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

Различается она в массе: 6 различных субсетей за два месяца, номера повторяются под различными именами, ни 1-го вопросца по делу.

Но самое увлекательное на этом веб-сайте было не в формах. Этот же бот с зимы надувал посещаемость, и вот это проверяется методом, который доступен любому за две минутки.

В феврале Метрика демонстрировала 324 визита из органики, из их 153 из Гугл. Search Console за этот же февраль отдавала 9 кликов. Девять.

Расхождение меж Метрикой и Search Console бывает постоянно, атрибуция различная, и двух-трехкратная разница никого не поражает. Семнадцатикратная значит, что кто-то прогуливается на веб-сайт мимо поиска и представляется поисковым трафиком.

Прекрасное следствие: когда бот начал истончаться, посещаемость в Метрике «свалилась» с 324 до 178 визитов, и это смотрелось как провал. По Search Console за то же время клики выросли с 9 до 30-42 за месяц, а показы с 2 206 до 6 150. Другими словами веб-сайт все это время рос, а отчет по Метрике демонстрировал падение.

«У нас не девять заявок, у нас поток»

Тут просто сделать возражение: девять воззваний за 5 дней это небольшой веб-сайт, у нас таковых цифр не бывает.

В том и дело. Когда заявок девять, замену видно очами за 5 минут: сел, прочел, узрел шаблон. Когда их несколько сотен за месяц, базу попорядку не читает никто, а сводка в аналитике смотрится так же внушительно. Те же 80% мусора расслабленно живут в отчетах месяцами, просто их некоторому увидеть.

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

Почему это разламывает не только лишь отчет?

Дело не в одной безобразной цифре.

Отчет клиенту. Вы приносите рост заявок, клиент лицезреет рост заявок, а отдел продаж лицезреет мусор. Далее разговор идет по понятному сценарию: «у вас в отчете пятнадцать, а у нас три, вы там что рисуете».

Работа менеджеров. На лифтовом веб-сайте заявки уходили письмами на весь отдел продаж, четыре адреса. Любая ботовая заявка это чей-то звонок в никуда.

Оптимизация под цель. Если вы настраиваете рекламу либо правите странички, ориентируясь на цель, в какой 80% мусора, вы оптимизируетесь под поведение бота. Он приходит размеренно, конвертируется отлично и никогда ничего не покупает. Автостратегии в маркетинговых кабинетах обучаются на этих же данных, так что далее система сама начинает находить для вас побольше похожей аудитории.

Сопоставление периодов. Это самое противное. Если бот работал в прошедшем году, а в этом его вычистили, хоть какой отчет «год к году» покажет падение там, где был рост. По таковым веб-сайтам динамику по Метрике совершенно недозволено брать: лишь Search Console и Веб-мастер, где бот не отражается.

Помогает ли тут рекапча?

1-ое, что дают в таковой ситуации, это поставить reCAPTCHA. Я от нее на собственных проектах отказался, и вот почему.

Она тянет около 300 КБ чужого скрипта на каждую страничку веб-сайта, а не только лишь на ту, где форма. Она посылает данные гостей в Гугл, а для 152-ФЗ это трансграничная передача, которую нужно обрисовывать в политике, и ее там обычно нет.

И основное: она молчком разрезает заявки с низким «рейтингом доверия». Человек с VPN, старенькым браузером либо просто со необычной для Гугл историей надавливает «Выслать», лицезреет «произошла ошибка» и уходит к сопернику. Вы о этом никогда не узнаете, поэтому что в базу таковая заявка не попадает и в отчете ее нет.

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

Что работает заместо нее?

Связка из 2-ух дешевеньких вещей на стороне веб-сайта и правил разбора на стороне базы.

Ловушка. В форму дописывается избыточное поле, которое человек не лицезреет и не заполняет, а бот заполняет исправно. Прятать его нужно уводом за экран (`position:absolute; left:-9999px`), а не через `display:none`: часть роботов сокрытые display-ом поля пропускает.

Метка времени. К форме прикладывается подписанная метка о моменте ее отрисовки. Если форма ушла резвее 3-х секунд, человек на физическом уровне не успел бы ее заполнить.

Далее правила разбора в том порядке, в котором они срабатывают:

1. Блок-лист субсетей, с которых уже прилетало.
2. Незакрытые плейсхолдеры в тексте («ваша услуга», фигурные скобки).
3. Шаблон: два и наиболее дежурных оборота из известного банка фраз.
4. Прохладное коммерческое предложение (это отдельный жанр, для вас дают SEO через вашу же форму).
5. Ссылка в тексте заявки.
6. Телефон не русского формата.
7. Этот же номер под остальным именованием за крайние 90 дней.

Крайнее правило самое полезное и самое доступное: историю можно брать прямо из таблицы с заявками, отдельное хранилище не надо.

Инспектировать фильтр нужно на прошедших заявках, а не на будущих. Я прогнал через него всю историю формы, 41 запись: все семь роботов и прохладное коммерческое предложение отбились, три настоящие заявки прошли. Заодно выяснилось, что текстовые правила ловят этих роботов и без блок-листа адресов, другими словами смена сабсети фильтр не обходит.

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

Основное правило фильтра: сомневаешься – пропускай

Одну вещь я сообразил не сходу, и она важнее всех правил совместно взятых.

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

Потому асимметрия обязана быть заложена в код. У меня, к примеру, если метки времени в запросе нет совершенно (кеш, древняя вкладка, отключенные скрипты), заявка пропускается без дискуссий. И человеку, чью заявку все-же отбили, показывается телефон кабинета и почта отдела продаж, чтоб он не уперся в стенку.

Цель, которая считает один клик 5 раз

Далее я начал двигаться по остальным счетчикам и отыскал вторую механику вранья, к мусору дела не имеющую.

На одном веб-сайте 5 различных целей демонстрировали за 30 дней ровно по 2 197 достижений. Полностью однообразное число у 5 целей значит одно: условия пересекаются, и один клик засчитывается во все 5 сходу. В сумме вышло 11 516 достижений при 1 396 визитах из органики.

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

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

Цель, которая молчит два года

И 3-я механика, самая досадная, поэтому что лжет она в другую сторону.

На одном мед веб-сайте форма не высылала письма 20 месяцев. Никто не увидел. Не поэтому что все дурачины, а поэтому что в аналитике не было ни 1-го главного действия: ноль заявок смотрелся как «ну, ниша таковая».

На другом проекте действия исправно отчаливали все это время (одних лишь заявок 737 в месяц), но ни одно не было отмечено главным, и аналитика демонстрировала ноль конверсий при практически 7 тыщах сессий. Когда действия отметили, картина по каналам развернулась: у 1-го канала конверсия оказалась 21,7%, у органики 2,9%. Ранее все каналы выглядели идиентично никак.

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

Как проверить свои числа за час?

Порядок, в каком я сейчас прохожу хоть какой новейший проект.

1. Сравните органику в Метрике и клики в Search Console за один и этот же месяц. Разница в два-три раза нормальна, в 10 и больше значит, что на веб-сайт кто-то прогуливается мимо поиска.
2. Откройте базу форм и прочитайте крайние 20 заявок попорядку. Не сводку, а тексты. Шаблон виден сходу.
3. Отсортируйте заявки по номеру телефона и поглядите повторы под различными именами.
4. Поглядите на IP отправителей: датацентровые сабсети в заявках от личных лиц – это аномалия.
5. Сравните числа достижений у всех целей. Совпадение до единицы значит дубль.
6. Отправьте тестовую заявку с каждой формы и удостоверьтесь, что письмо дошло. Не «обязано доходить», а дошло.
7. Проверьте, отмечены ли действия главными. Ноль конверсий при живом трафике практически постоянно значит разметку, а не нишу.
8. Если по веб-сайту в прошедшем году работал бот, честно скажите клиенту, что сопоставление год к году по Метрике не имеет смысла, и покажите Search Console.

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

Если вы ловили такие же заявки либо понимаете остальные методы отличить бота от человека, поведайте в комментах: тема жива, а банк признаков излишним не бывает.