Что подтверждает событие формы
Чтобы проверить принятие заявки, найдите запись принимающей системы об этой отправке. Сопоставьте её с ответом, который получил браузер. Доставку письма, качество лида и сделку проверяйте отдельно.
В улучшенной статистике GA4 событие form_start фиксирует первое взаимодействие с формой за сеанс, а form_submit фиксирует отправку формы. Эти события описывают использование формы; их определения не требуют, чтобы ваш сервер сохранил заявку. Проверьте поведение конкретной формы и тегов, особенно если отправкой управляет JavaScript. См. определения улучшенной статистики Google.
| Наблюдение | Какой вывод допустим |
|---|---|
| Клик, событие формы или сообщение об успехе | Интерфейс или тег дошёл до этого шага. Принятие нужно проверить отдельно. |
| Сохранённая сервером запись с ID принятия | Принимающая система приняла эту отправку по своему описанному правилу. |
| Почтовый провайдер принял запрос на отправку | Провайдер принял запрос. Получение письма нужным ящиком остаётся отдельным фактом. |
| Получатель нашёл соответствующее письмо | Получение этого письма подтверждено. Качество лида ещё нужно оценить. |
| Человек отметил квалификацию или завершённую сделку | Этот последующий бизнес-результат известен в пределах подтверждающей его записи. |
До подсчёта согласуйте с владельцем формы, что означает «принята». В этой статье принимающее приложение проверило отправку и создало одну запись. Другая система может считать принятием постановку в очередь или передачу провайдеру. Явно запишите её правило. Сам по себе HTTP 200 слишком мало говорит о результате приложения.
Проследите одну отправку
Используйте разрешённую тестовую среду и вымышленные данные. Согласуйте исключение тестовых записей из бизнес-итогов. Пример для скачивания ниже уже изолирован: он не отправляет заявку в Extcorp.
- Запишите контекст. Укажите страницу, форму, среду, время и часовой пояс. Для GA4 добавьте проверяемые ресурс, веб-поток и конфигурацию тегов.
- Найдите правило принятия. Узнайте у владельца приложения, где создаётся запись, какой ответ её подтверждает и какой ID связывает ответ с записью. Анимации успеха для этого недостаточно.
- Проверьте отказ. Сверьте ответ и отсутствие новой записи о принятии в разрешённом тестовом хранилище. Проверьте ошибку приложения даже при HTTP 200.
- Проверьте принятие. Прочитайте тело ответа и найдите соответствующую запись. Сохраните время принятия и ID в закрытом журнале проверки. Контактные данные не должны попадать в аналитику или общие скриншоты.
- Повторите ту же логическую отправку. Используйте прежний ключ повтора и проверьте, что сервер вернул существующий ID принятия. Проверьте и потерю ответа: браузер может показать сетевую ошибку после сохранения заявки сервером.
- Отдельно проверьте последующие результаты. Если вы не смотрели данные почтового провайдера, ящик получателя или запись о квалификации, укажите
UNKNOWN. Неизвестный исход не добавляет ни подтверждённый успех, ни подтверждённый отказ.
После сетевой ошибки принятие остаётся неизвестным до сверки с принимающей системой. Потеря ответа сама по себе не повод создавать новый ключ: так повтор может превратиться в ещё одну запись.
Запустите заполненный пример
Учебный пример выполняет шесть запросов к временному серверу на вашем компьютере через loopback. Ключи и ID вымышлены. Записи хранятся в памяти, контактных полей нет; после проверки программа завершается. Внешних запросов, загрузки тега GA4 и отправки почты нет.
Скачайте пример для Node.js и запустите его в Node.js 22 или новее:
node ga4-enquiry-demo.mjs
Программа сама выбирает свободный локальный порт. Все шесть запросов и итоговые числа выводятся в JSON. При несовпадении проверка останавливает запуск; checks: "PASS" подтверждает ожидаемые результаты учебного сценария. Если политика компьютера блокирует локальные соединения, тест не пройдёт. Запускайте его только там, где такие соединения разрешены.
| Попытка | Что видит браузер | Запись сервера |
|---|---|---|
| 1. Валидация не пройдена | HTTP 422, accepted: false | Запись не создана |
| 2. Приложение отклоняет запрос | HTTP 200, accepted: false | Запись не создана |
| 3. Принятие demo-A | HTTP 201, accepted: true, demo-001 | Создана demo-001 |
| 4. Повтор demo-A | HTTP 200, demo-001, duplicate: true | Возвращена существующая demo-001 |
| 5. Принятие demo-B; ответ потерян | Сетевая ошибка; принятие UNKNOWN | demo-002 создана до закрытия соединения |
| 6. Повтор demo-B | HTTP 200, demo-002, duplicate: true | Возвращена существующая demo-002 |
Итоговая проверка сервера объясняет пятую попытку. В тот момент только по браузеру нельзя было узнать, сохранилась ли заявка. Шестая попытка восстанавливает тот же ID.
6 попыток → 3 положительных ответа браузеру → 2 уникальные принятые записи. В локальной имитации аналитики 2 записи generate_lead. Настоящие события GA4: NOT_SENT. Принятие провайдером, получение письма, квалификация и сделка: UNKNOWN.
Имитация добавляет локальную запись, когда браузер впервые видит каждый принятый ID, включая восстановленный ответ в шестой попытке. В этот локальный массив попадает только вымышленный form_id. Ключ повтора и ID принятия остаются внутри примера. Шесть попыток заданы сценарием: это не прогноз числа событий form_submit, которые собрала бы GA4.
Пример показывает различие состояний и не служит готовым рабочим сервером. При выходе его память очищается. Реальной реализации нужны постоянное хранилище, атомарное правило уникальности, срок действия ключа повтора и правило для изменившихся данных запроса. Перезагрузка страницы не должна сбрасывать защиту сервера от дублей.
Посчитайте заявки без повторов
Для выбранного периода и среды посчитайте уникальные ID в основном хранилище принятых заявок. Исключите тестовые записи и примените описанное правило принятия. Используйте время первого принятия записи: поздний повтор не переносит её в новый период.
В примере множество равно {demo-001, demo-002}, поэтому итог: 2. Сумма трёх положительных ответов посчитала бы demo-001 дважды. Подсчёт шести попыток включил бы оба отказа и попытку с потерянным ответом.
Так исключаются повторы передачи с одним ключом. Этот способ не распознаёт человека, который прислал то же коммерческое обращение с новым ключом или другого устройства. Для таких случаев ведите отдельную проверяемую отметку дубля. Число принятых заявок также отличается от числа квалифицированных лидов.
При сравнении с GA4 согласуйте период, часовой пояс, форму, среду и определение события. Не рассчитывайте конверсию по двум итогам, пока не понятны состав и полнота каждой выборки. Пропуски аналитики могут быть связаны с согласием, блокировщиками, настройками или обработкой. Отсутствие серверных доказательств оставляйте неизвестным, а не нулевым результатом.
Проверьте GA4 после принятия
Google рекомендует generate_lead для отправленной формы или запроса информации. Событие требует отдельной настройки; событие формы из улучшенной статистики не настраивает его автоматически. Для этой диагностики задайте запуск по подтверждённому ответу о принятии и зафиксируйте это правило. Google не определяет generate_lead как серверную квитанцию. См. справочник рекомендуемых событий.
Ответственному за измерения нужно проверить следующее в разрешённой тестовой среде:
- Включить режим отладки для тестового устройства и открыть Admin → Data display → DebugView («Администратор → Отображение данных → DebugView»). Сопоставить имя, параметры и время события с результатом приложения. Одного запроса в разделе Network браузера недостаточно для подтверждения получения нужным ресурсом GA4.
- Убедиться, что отказ валидации и отказ приложения не запускают событие принятия. Проверить, что повтор подтверждённого ответа не добавляет ещё одно событие для той же логической отправки. Проверить, не отслеживают ли одно действие одновременно автоматический и пользовательский теги.
- Передавать только согласованные параметры без личных данных, например постоянное обозначение формы. Проверить также URL и автоматически собираемые параметры. Имена, email, телефоны, текст обращения и содержимое CRM должны оставаться вне аналитики. Для этой процедуры храните связующий ID в закрытом журнале приложения; пример не передаёт его в GA4.
- Если событие обозначает важное для бизнеса действие, редактор с доступом может отметить его как ключевое событие. Способ подсчёта тоже требует проверки. «Один раз на событие» может учитывать повторные срабатывания, а «Один раз за сеанс» объединять разные заявки одного сеанса. Ни одна настройка не заменяет исключение дублей в хранилище принятых заявок.
DebugView проверяет сбор событий устройства. Доставку почты и качество лида он не подтверждает. По документации Google, настройки конфиденциальности или отсутствие согласия на Analytics могут скрыть события в DebugView. Сбор и обработка отчётов также могут задерживать или ограничивать сравнение. Полноту сбора гарантировать нельзя. Чтобы отключить отладку, удалите параметр debug_mode; значение false её не отключает.
Источники проверены 13 октября 2026: DebugView, ключевые события, способы подсчёта и исключение личных данных. Настройки и права конкретного аккаунта нужно проверять в самом ресурсе.
Выберите следующую проверку
Если GA4 показывает событие, а запись о принятии недоступна, проверьте валидацию и сохранение в приложении. Если запись есть, но события нет, проверьте сбор и согласие. Если принятие подтверждено, но письма нет, найдите доказательства у почтового провайдера и получателя. Для каждой ветки нужен свой источник.
Квалификация требует согласованных критериев и отдельной оценки. Продажа требует записи о сделке или транзакции. Google также определяет отдельные события qualify_lead и close_convert_lead. Их наличие в справочнике не означает, что эти результаты уже наступили или отслеживаются на вашем сайте.
Для вопроса о трафике есть существующая услуга трафика для GA4. Можно отправить короткий вопрос о трафике GA4; сайт и детали отчёта можно прислать позже. Изменения тегов, обработки формы или интеграций требуют отдельно согласованного объёма работ. Различия собственных данных и внешних оценок разобраны в сравнении платформ трафика.