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

01

Сначала локализуйте разрыв в пути заявки

Фраза «не приходят заявки с сайта» описывает симптом, а не причину. После обновления одновременно могли измениться шаблон формы, обработчик PHP, политика cookie, адрес получателя, вебхук CRM, контейнер аналитики или рекламная посадочная страница. Если сразу поручить разработчику «починить формы», он может исправить видимый элемент, хотя проблема находится в очереди CRM или в падении целевого трафика.

Разложите процесс на цепочку: пользователь открыл страницу → увидел форму → заполнил поля → браузер отправил запрос → сервер обработал данные → создан лид или сделка → менеджер получил уведомление → аналитика записала событие. У каждой точки есть свой наблюдаемый след. Посещения видны в Метрике или GA4, сетевой запрос — в DevTools, ошибка PHP — в журнале сервера, запись — в CRM, а уведомление — в почте или мессенджере.

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

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

03

Как отличить падение трафика от ошибки формы

Маркетологу не нужно читать код, чтобы отделить проблему спроса от сбоя сайта. Откройте отчёт по дням и сегментируйте его по источнику, устройству и целевой странице. Сначала проверьте рекламные кампании: не остановились ли показы, не изменились ли ссылки, не ведут ли объявления на 404 или редирект без UTM. Затем посмотрите органический трафик и прямые заходы. Одновременное снижение по всем источникам часто связано с доступностью сайта, robots.txt, редиректами или счётчиком, а не с формой.

Если трафик стабилен, проверьте микроэтапы воронки. В Метрике это могут быть цели «клик по кнопке», «открытие формы» и «успешная отправка». В GA4 — события form_start, form_submit либо ваши собственные события. Резкое исчезновение form_submit при сохранении form_start — сильный признак поломки формы. Но событие «успех» иногда отправляется по клику, а не после ответа сервера, поэтому оно не заменяет тестовую заявку.

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

04

Проверка формы: браузер, сервер и защита

Надпись «Спасибо, заявка отправлена» не доказывает, что данные ушли. После обновления часто ломается JavaScript: изменился селектор формы, не загрузился обработчик, конфликтуют минификация и кеш, браузер блокирует запрос из-за CORS или смешанного контента. Откройте DevTools → Network, отправьте тест и найдите запрос формы. Важны URL, HTTP-статус, тело ответа и время ответа. Коды 4xx обычно говорят о валидации, токене или правах, 5xx — о сбое серверной части.

На сайте на 1С-Битрикс проверьте, не изменились ли обработчик компонента, почтовое событие, CAPTCHA, согласие на обработку данных и поля инфоблока или CRM-формы. Для AJAX-формы отдельно важны корректный session_id и ответ в JSON. Документация по журналу событий и отладке доступна в материалах разработчика 1С-Битрикс; доступ к журналам должен быть у технической команды, а не у посетителя сайта.

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

05

Почему заявки доходят до сайта, но не попадают в CRM

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

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

Для теста используйте уникальные телефон, email и метку. Найдите запись не только в лидах: проверьте контакты, сделки, неразобранное и журнал роботов. Сверьте дату создания по часовому поясу сервера. В Битрикс24 разработчик может проверить параметры вебхука и права приложения по справке по входящим вебхукам.

06

Проверьте, не сломалась ли аналитика вместо заявок

Иногда лиды продолжают создаваться, но отчёт показывает ноль конверсий. Причина — удалённый контейнер, смена ID счётчика, блокировка скрипта политикой Content Security Policy, новое доменное имя или изменённое условие цели. Это проблема измерения, но она опасна не меньше поломки формы: маркетинг отключает работающую рекламу или неверно оценивает эффективность канала.

Сопоставьте независимые источники: созданные CRM-записи, входящие письма, звонки, заказы и отчёт аналитики. Возьмите тестовую заявку с UTM и убедитесь, что сохранены не только utm_source и utm_campaign, но и landing page, referer, client ID или другой доступный технический идентификатор. Не передавайте в аналитику телефон, email и другие персональные данные.

Событие отправки должно срабатывать после подтверждённого успешного ответа сервера. Если фронтенд отправляет goal при нажатии кнопки, отказы валидации и ошибки CRM будут искусственно повышать конверсию. Зафиксируйте это правило в постановке задачи и в сценарии регрессионной проверки каждого релиза.

1. 1

   Сверьте период. Сравните даты, часовой пояс, фильтры и источник данных в CRM и аналитике.

2. 2

   Найдите тест. Отфильтруйте CRM по уникальному телефону, метке и времени отправки.

3. 3

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

4. 4

   Проверьте UTM. Откройте карточку CRM и сверьте сохранённые метки с URL тестового визита.

5. 5

   Зафиксируйте эталон. Сохраните параметры рабочего теста для проверки после следующего обновления.

07

Что запросить у разработчика после диагностики

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

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

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

08

Чек-лист перед следующим обновлением сайта

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

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

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

09

Когда проблему можно считать решённой

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

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

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