аудит конверсии сайта: почему заявки не доходят и как это исправить

Аудит конверсии сайта — это проверка технической цепочки от клика по кнопке «отправить заявку» до появления лида в CRM или почте менеджера. Чаще всего трафик идёт нормально, а заявок мало не из-за дизайна, а из-за сломанной формы, неверной интеграции с CRM или блокировки скрипта аналитики — это находится за один-два дня проверки.

почему заявки теряются, хотя форма на сайте работает

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

Но письмо с заявкой ушло на почтовый адрес, который сменили полгода назад при переезде на новый домен, и никто не поправил в коде формы. Форма честно отправляла данные — просто в никуда. За две недели компания потеряла порядка 30-40 заявок, которые ушли конкурентам, потому что клиент не будет ждать и звонить сам, если сайт «принял» его обращение.

Похожая история — с интеграцией CRM. Скрипт формы шлёт запрос на старый API-ключ, который отозвали при смене тарифа amoCRM или Bitrix24, сервер отвечает ошибкой 401, но пользователь этого не видит: JS-код просто показывает заглушку «спасибо» независимо от ответа сервера. Форма выглядит рабочей на 100% случаев, а долетает 0%.

Третий частый сценарий — блокировка счётчиков и пикселей рекламными блокировщиками или настройками cookie-баннера. Если пиксель конверсии не сработал, «Яндекс.Директ» не увидит, что заявка была, и алгоритм будет оптимизировать показы на пустоту — бюджет тратится, а система обучается на неверных данных.

как исправить форму, которая «отправляет в пустоту»

Проверка идёт по цепочке, а не по одному звену. Сначала смотрят фронтенд: что именно происходит при нажатии кнопки — открывается ли сетевой запрос в консоли разработчика, какой код ответа возвращает сервер. Дальше проверяют бэкенд: куда реально уходят данные — на почту, в CRM через API, в Google Таблицу — и рабочий ли это адрес или ключ доступа.

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

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

что делать, если заявки продолжают теряться после починки формы

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

Второй частый повтор — почтовый провайдер начал помечать письма с сайта как спам после смены IP хостинга. Форма отправляет письмо исправно, сервер отвечает 200 OK, но само письмо оседает в папке «Спам» у менеджера или вообще не доходит из-за отсутствия SPF и DKIM записей у домена. Это не видно ни разработчику, ни маркетологу — нужен человек, который проверяет именно доставляемость, а не факт отправки.

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

как предотвратить повторные потери заявок

регулярная проверка вместо разовой

Разовая проверка формы закрывает проблему на сегодня, но не защищает от завтрашнего обновления плагина или смены хостинга. Компаниям с активной рекламной кампанией имеет смысл проверять цепочку «форма → CRM → менеджер» раз в месяц, а не раз в год после жалобы директора.

контрольные точки для мониторинга

• ✓Тестовая заявка с уведомлением ответственному раз в неделю — простой скрипт или ручная проверка
• ✓Проверка кода ответа сервера при отправке формы, а не только визуального «спасибо»
• ✓Контроль срока жизни API-ключей и токенов интеграции с CRM
• ✓Проверка SPF и DKIM записей домена, если письма уходят на почту менеджера
• ✓Логирование входящих заявок на сервере отдельно от CRM — на случай сбоя интеграции

Если сайт и база 1С висят на слабом или общем хостинге, форма может «зависать» именно в момент пиковой нагрузки — когда рекламная кампания даёт всплеск трафика. Перенос сайта и связанных сервисов на выделенный сервер 1С от 1 100 ₽/мес за пользователя снимает эту причину вместе с задержками при закрытии месяца в базе.

сколько стоит аудит конверсии и что входит в проверку

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

Если после аудита выясняется, что дело не в форме, а в нагрузке на сервер или медленной работе 1С при формировании заказа с сайта, дальнейшая настройка и сопровождение серверной части считается отдельно — по ставке сопровождения 1С и сисадмина от 3800 ₽/час, в зависимости от объёма работ.

почему стоит доверить аудит конверсии специалисту, а не проверять форму самому

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

❓ Частые вопросы

Как понять, что сайт теряет заявки из-за технической ошибки, а не из-за низкого трафика?

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

Сколько времени занимает аудит конверсии сайта?

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

Можно ли проверить форму самостоятельно, без привлечения специалиста?

Частично да — можно заполнить форму и убедиться, что письмо или заявка в CRM пришли. Но это не покажет скрытые сбои вроде истёкшего API-ключа CRM или писем, попадающих в спам, — для этого нужен просмотр серверных логов и настроек интеграции.

Что делать, если заявки то приходят, то нет?

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

Влияет ли скорость сайта на количество заявок?

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