Как отслеживать ошибки формы заявки в GA4 и Метрике

Начните с проверки: отправьте тестовую заявку и убедитесь, что она дошла до системы, в которой вы принимаете обращения. Затем настройте в GA4 и Яндекс Метрике отдельные события для начала заполнения, ошибки и успешной отправки. Так вы сможете найти этап, на котором посетитель останавливается, и отличить неудобную форму от технического сбоя. В статье разберём, какие события передать разработчику, как проверить их работу и по каким признакам искать причину потери заявок.

Какие события нужны для проверки формы заявки?

Нажатие кнопки «Отправить» ещё не подтверждает, что бизнес получил обращение. Форма может показать ошибку, сервер — отклонить запрос, а сообщение об успехе — появиться раньше, чем сайт сохранит заявку. Поэтому сначала определите, какое действие на вашем сайте подтверждает приём обращения.

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

Ниже — пример собственной схемы событий. Эти названия нужно настроить; они не означают, что GA4 и Метрика уже собирают такие данные автоматически.

• form_start — посетитель впервые начал заполнять конкретную форму.
• form_attempt — посетитель попытался отправить заявку.
• form_error — форма показала ошибку проверки или получила отказ от сервера.
• form_success — сайт подтвердил, что принял заявку.

К событию добавьте form_id — постоянное обозначение формы, например request_main. Для ошибки предусмотрите error_type: required_field для пустого обязательного поля, invalid_format для неверного формата, server_error для сбоя на сервере. Это примеры технических обозначений, которые разработчик может адаптировать к сайту.

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

Как настроить события в GA4 и Яндекс Метрике?

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

1. Опишите формы. Для каждой запишите страницу, form_id и место, куда должна поступить заявка.
2. Задайте условия событий. Начало фиксируйте при первом взаимодействии с полем, ошибку — при появлении сообщения, успех — после подтверждения от сайта.
3. Настройте передачу в GA4. Если используете GTM, свяжите события формы с тегами событий GA4 и передайте параметры form_id и error_type.
4. Настройте цели Метрики. Создайте цели типа «JavaScript-событие» и вызывайте reachGoal при соответствующем состоянии формы.
5. Выберите результат для отчётов. Успешную отправку отметьте как ключевое событие GA4, а в Метрике используйте отдельную цель успеха.

Автоматические события взаимодействия с формами в GA4 проверяйте отдельно. Событие с названием form_submit само по себе не доказывает, что обращение принято: сначала сопоставьте его с поведением вашей формы. Если автоматический сбор и собственная настройка описывают одно действие, не складывайте их показатели.

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

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

Как проверить, что ошибки и успешные заявки попадают в отчёты?

Проверяйте отдельно поведение сайта и запись событий. Сообщение «Заявка отправлена» подтверждает только то, что вы увидели на экране. Откройте режим предварительного просмотра GTM, если используете этот инструмент, и DebugView в GA4. В Метрике проверьте вызовы целей в режиме отладки счётчика.

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

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

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

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

Как по событиям найти причину потери заявок?

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

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

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

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

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

Когда форма проверена, добавьте разрез по источникам трафика. Предварительно проверьте UTM-метки и ошибки разметки, чтобы не связать проблему формы с неверно определённой рекламной кампанией. UTM-параметры помогают аналитике разделять переходы по источникам, кампаниям и объявлениям (источник: Cropas, «UTM-метки для рекламы»).

Типичные ошибки при настройке аналитики форм

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

• Успех считают по нажатию кнопки. Перенесите событие на подтверждение приёма заявки сайтом.
• Все формы передают одинаковое событие без form_id. Добавьте постоянное обозначение каждой формы.
• Ошибка фиксируется при каждом вводе символа. Настройте событие на показ ошибки после проверки поля или попытки отправки.
• Событие одновременно отправляют код сайта и GTM. Оставьте один согласованный способ передачи для каждого действия.
• После обновления формы никто не повторяет тест. Включите проверку ошибки и успеха в приёмку изменений сайта.

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

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