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

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

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

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

В этой статье разберём:

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

Почему мусорный трафик нельзя определять по нескольким лидам

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

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

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

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

Допустим, из потока периодически приходят заявки с некорректными номерами. Это один сценарий. Если же за короткий промежуток из одного subID приходит серия лидов с похожими контактами и одинаковой причиной отклонения — уже другой. Во втором случае появляется конкретный сегмент, который имеет смысл проверять отдельно.

Поэтому при первых невалидных лидах полезнее зафиксировать не только их количество, но и:

  • причину отклонения каждой заявки;
  • время поступления;
  • кампанию, креатив, плейсмент и subID;
  • долю таких заявок внутри соответствующего сегмента;
  • повторяется ли отклонение в следующих обработанных лидах.

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

Три причины просадки, которые часто смешивают

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

Отличия слабой связки, невалидных лидов и фрода

Различать эти ситуации удобнее по тому, на каком этапе ломается воронка.

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

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

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

Признаки того, что проблема находится в оффере или воронке

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

Например, повторяющиеся ответы «дорого» могут указывать не только на высокую стоимость продукта. Возможно, креатив не сформировал достаточную ценность или пользователь ожидал другую цену. Если люди спрашивают об акции, подарке или условии, которых нет в предложении оператора, стоит проверить соответствие креатива и преленда фактическому офферу. А если пользователи не понимают назначение продукта, проблема может находиться уже в подаче самого предложения.

Условно причины можно сопоставить с элементами воронки:

Признаки проблем в воронке нутра-связки

Полезно отдельно сверить цепочку обещаний от первого контакта до звонка оператора: что пользователь увидел в рекламе → что ему объяснили на преленде → какие условия были на лендинге → что озвучил колл-центр. Чем сильнее меняется предложение по пути, тем выше вероятность получить заявку от реального человека, который затем откажется от покупки.

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

Как отличить обычные колебания от аномалии в трафике

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

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

Для этого текущий поток можно сравнить сразу в нескольких разрезах:

  • с предыдущими периодами: изменилась ли доля невалидных заявок относительно обычного уровня;
  • между кампаниями: одинаковая ли проблема наблюдается во всех запусках;
  • по плейсментам и subID: не формирует ли основную часть невалидов один сегмент;
  • по причинам отклонения: выросли все категории одновременно или только, например, «неверный номер»;
  • по времени: рост происходил постепенно или появился сразу после изменения креатива, формы, источника либо настроек кампании.

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

Полезно смотреть и на динамику в абсолютных значениях и в долях одновременно. При масштабировании количество невалидных заявок естественным образом может увеличиться вместе с общим объёмом трафика. Поэтому рост с 5 до 20 невалидов ещё не означает ухудшения качества, если за тот же период общий объём вырос со 100 до 500 лидов: доля, наоборот, снизилась с 5% до 4%.

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

Какие признаки выдают мусорный трафик и возможный фрод

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

На возможную искусственную генерацию заявок могут указывать:

  • серии лидов за аномально короткий промежуток времени: особенно если раньше источник давал заявки равномерно;
  • повторяющиеся контактные данные: одинаковые номера, имена или email либо их незначительно изменённые варианты;
  • совпадающие технические параметры: большое количество заявок с одинаковыми или подозрительно похожими характеристиками устройств, соединений или сессий;
  • аномально короткий путь до конверсии: пользователь якобы успевает перейти на страницу, ознакомиться с предложением и заполнить форму за время, которое для обычного поведения нетипично;
  • концентрация аномалий в одном subID или плейсменте: остальной поток при этом сохраняет привычные показатели;
  • массовое отрицание заявок при звонке: пользователи отвечают оператору, но сообщают, что не заполняли форму и не интересовались продуктом; единичный случай ещё не доказывает фрод, но повторение внутри одного сегмента требует проверки;
  • разрыв между frontend- и backend-метриками: CR резко растёт, но увеличение числа лидов не сопровождается сопоставимой динамикой аппрува и выкупа;
  • мотивированный трафик под видом обычного: пользователь оставляет контакты ради обещанного вознаграждения или другого стимула, не связанного с покупкой продукта.

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

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

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

Что проверить до полной остановки кампании

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

Для первичной диагностики достаточно пройти семь шагов.

1. Разбить поток на сегменты.
Посмотрите результаты отдельно по кампаниям, креативам, плейсментам и subID. Чем глубже разбивка, тем проще увидеть точку, после которой показатели начинают отличаться от остального трафика.

2. Разложить отклонённые лиды по причинам.
Не объединяйте все проблемные заявки в одну категорию. Отдельно посчитайте дубли, неверные номера, отказы, недозвоны и другие доступные статусы. Это покажет, с каким типом отклонения вы имеете дело и где продолжать проверку.

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

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

5. Сравнить подозрительный сегмент с контрольным.
Возьмите часть потока, где показатели остаются стабильными, и сравните её с проблемной по одинаковым метрикам. Если отклонение воспроизводится только в одном плейсменте, креативе или subID, нет необходимости автоматически распространять вывод на всю кампанию.

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

7. Ограничить проблему точечно.
Если источник отклонения удалось локализовать, сначала можно поставить на паузу конкретный плейсмент, subID, креатив или кампанию. Остальной поток при этом продолжит собирать данные и покажет, действительно ли отключённый сегмент был причиной просадки.

Главный результат такой проверки — не обязательно решение «продолжать» или «останавливать». Гораздо полезнее получить конкретную гипотезу с привязкой к сегменту: например, «аномалия возникает только в placement X после изменения формы» или «доля отклонений выросла по всем источникам одновременно». С такой формулировкой следующий шаг уже можно выбирать на основании данных, а не общей просадки показателей.

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

Не все причины просадки вебмастер может определить только по своей статистике. Чтобы подтвердить или исключить мусорный трафик, frontend-данные нужно сопоставить со статусами обработки лидов на backend.

При работе с M1 такую проверку можно провести вместе с менеджером. Чтобы быстрее сопоставить обе стороны воронки и локализовать проблему, подготовьте:

  • оффер, GEO и источник трафика;
  • период запуска и общий объём лидов;
  • кампании, плейсменты и subID;
  • ID и время спорных заявок;
  • ссылки или скриншоты креатива, преленда и лендинга;
  • информацию об используемой форме;
  • статистику кликов, лидов и CR;
  • доступные данные по устройствам, площадкам и времени конверсии;
  • изменения, которые вносились в кампанию перед появлением просадки.

Чем точнее исходные данные, тем проще сопоставить конкретный сегмент со статусами на стороне M1. Менеджер может проверить результаты обработки лидов, причины отклонения и backend-показатели, а затем сравнить их с данными вебмастера.

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

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

Как принять решение по итогам проверки

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

Решения по итогам проверки на мусорный трафик

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

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

В M1 вебмастеру не приходится разбираться с такими ситуациями только по данным рекламного кабинета. Менеджеры помогают сопоставить frontend со статусами и результатами обработки на backend, проверить спорные лиды и понять, где именно возникла проблема.

Хотите тестировать и масштабировать связки, имея доступ к данным и поддержке со стороны партнёрской сети — регистрируйтесь в M1.

А чтобы не пропускать новые разборы, исследования, кейсы и материалы по работе с нутра-трафиком, подписывайтесь на Telegram-канал M1.

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