Куда исчезают заявки: как найти сломанное звено между рекламой, сайтом, Метрикой и CRM

Рекламный кабинет показывает двадцать конверсий. В Метрике их двенадцать. В CRM — восемь лидов, а менеджер помнит только пять. Обычно после этого рекламщик, аналитик и отдел продаж начинают защищать свои цифры.

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

Сначала договоритесь, что называется заявкой

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

Запишите определения:

Событие	Где возникает	Что подтверждает
нажатие	браузер	пользователь попытался начать действие
успешная форма	сайт и сервер	данные приняты
цель Метрики	счётчик	аналитика получила событие
лид CRM	интеграция	запись создана или обновлена
квалифицированный лид	продажи	контакт подходит и подтвердил интерес

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

Звено 1. Реклама привела не на тот адрес

Проверьте финальный URL объявления после всех редиректов. Параметры могут потеряться при переходе с HTTP на HTTPS, смене домена, сокращателе ссылок или самописном перенаправлении.

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

Проверьте:

• доступность страницы на мобильном интернете;
• соответствие домена настройкам счётчика;
• сохранение utm_source, utm_medium, utm_campaign;
• регистр значений: Метрика различает его;
• отсутствие внутренних UTM-ссылок, которые перезаписывают источник;
• загрузку нужного счётчика на конечной странице.

Правила именования и проверка отчёта разобраны в статье UTM-метки и Яндекс Метрика.

Звено 2. Страница загрузилась, но счётчик — нет

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

Откройте страницу в чистом браузере и проверьте:

1. Загружается ли счётчик до взаимодействия.
2. Нет ли ошибки в консоли.
3. Работает ли после принятия или отказа в consent-баннере.
4. Не создаются ли два счётчика на одном действии.
5. Не ломает ли форму блокировка сторонних скриптов.

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

Звено 3. Цель настроена на красивый, но неверный сигнал

Частая ошибка — цель на просмотр /thanks, которая срабатывает при повторной загрузке страницы или не срабатывает в одностраничном приложении. Другая — JavaScript-цель вызывается до того, как сервер подтвердил приём.

Для каждой формы создайте тестовую карту:

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

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

Звено 4. Браузер отправил форму, сервер её потерял

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

Минимальный журнал:

• время;
• идентификатор формы;
• идентификатор отправки;
• URL;
• UTM и реферер;
• технический результат;
• идентификатор CRM после передачи;
• причина отказа без хранения лишних персональных данных.

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

Звено 5. Интеграция с CRM отвечает не тем, чем кажется

HTTP 200 не всегда означает, что лид создан. Посредник может принять задачу в очередь, а CRM позже отклонит её из-за обязательного поля, истёкшего токена, лимита или неверного значения справочника.

Проверяйте два подтверждения:

1. интеграция приняла событие;
2. CRM вернула идентификатор созданной или обновлённой записи.

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

Звено 6. Дедупликация скрыла заявку

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

Это не всегда потеря. Нужно решить, что считать:

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

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

Звено 7. Заявка есть, но менеджер её не увидел

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

Проверьте маршрут:

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

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

Звено 8. Отчёт сравнивает разные часы и статусы

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

При сверке используйте:

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

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

Контрольная сверка за 30 минут

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

Затем последовательно отметьте:

1. появился ли визит;
2. сохранился ли источник;
3. сработала ли цель;
4. есть ли серверное подтверждение;
5. создано ли обращение;
6. куда оно попало;
7. получил ли ответственный уведомление;
8. видно ли событие в итоговом отчёте.

Первое место расхождения и есть участок диагностики. Не меняйте одновременно счётчик, форму и CRM-интеграцию: вы потеряете причинность.

Постоянный мониторинг без тяжёлой сквозной аналитики

Раз в день сравнивайте контрольные числа:

• успешные серверные отправки;
• достижения аналитической цели;
• созданные обращения;
• ошибки передачи;
• необработанные лиды;
• квалифицированные лиды.

Разница важнее абсолютного равенства. Блокировщики создадут небольшой устойчивый разрыв между сервером и аналитикой. А резкое изменение разрыва покажет поломку.

Настройте пороги по собственной базе, а не универсальные «допустимые 5%». Для десяти заявок один сбой заметен вручную; для десяти тысяч нужен статистический коридор.

Как помогает «Система»

В «Системе» отчёты Яндекс.Метрики связываются с UTM и страницами входа, Аналитик сопоставляет этапы цепочки, а Coding-агент может подготовить проверяемое исправление формы или события. При аномалии платформа создаёт задачу с конкретным звеном, а не сообщение «конверсий стало меньше».

Например, Метрика показывает падение цели, но сервер продолжает принимать прежнее число форм. Это сразу сужает поиск до счётчика и отправки события. Если серверные формы тоже упали, агент проверяет трафик, доступность и изменения страницы.

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

Как считать стоимость после исправления

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

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

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

Источники

• Яндекс Метрика: как определяется источник трафика
• Яндекс Метрика: обработка меток
• Яндекс Метрика: обзор отчётов