Антифрод и CRM: как не потерять реальные обращения при фильтрации трафика

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

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

В публикации iConText Group о проекте T2 на Cossa описан риск ошибочного отсечения мобильного трафика при единых правилах для разных каналов. Это рассказ участников проекта о закупке установок, а не независимая оценка любого антифрода. Его полезно использовать как повод проверить собственные критерии, сохраняя различие между установкой приложения и обращением в CRM.

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

Что означает отметка «подозрительно»

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

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

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

Проверить качество событий до изменения порогов

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

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

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

Добавить обратную связь из продаж

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

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

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

Испытать фильтр до необратимого отсечения

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

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

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

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

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

Контекст обращения и решение о его качестве

В Dent-Picks я связал входящие звонки на IVR с созданием лидов в GoHighLevel и добавил AI-анализ того, кто и зачем звонил. Это подтверждённый пример сохранения контекста обращения. Он не является кейсом антифрод-системы: публичное описание не заявляет распознавание мошенничества или оценку ложных блокировок. Для проверки качества лида такой контекст может быть входом в отдельное решение сотрудника, а не готовым основанием для отказа.

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

Источники

Источники проверены 7 октября 2026 года.