Как проверить воронку многошаговой формы по событиям

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

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

Разделите отправку формы и подтверждённую заявку

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

Для бизнес-результата задайте отдельное условие. В примере lead_confirmed появляется только после успешного ответа сервера и создания записи в CRM. В GA4 эту точку можно передать рекомендуемым событием generate_lead, если именно здесь бизнес считает лид созданным.

Название этапа должно описывать проверяемый факт. Клик по кнопке «Далее» не равен завершённому шагу, если поля не прошли валидацию. Показ экрана «Спасибо» не равен созданию лида, если он появляется до ответа CRM.

Учебная воронка: шесть начатых форм, два лида

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

Учебная воронка. Проценты считаются между соседними этапами; данные не относятся к реальному проекту.

Переходы получаются такими:

• старт → контакт: 5 / 6 = 83,3%;
• контакт → бриф: 4 / 5 = 80%;
• бриф → отправка: 3 / 4 = 75%;
• отправка → подтверждённый лид: 2 / 3 = 66,7%;
• старт → подтверждённый лид: 2 / 6 = 33,3%.

Самый низкий процент находится после отправки. Это не доказательство плохой формы: нужно открыть одну неподтверждённую строку и проверить ответ сервера, создание записи в CRM и повтор интеграции.

Проверьте расчёт на сохранённой выгрузке

Сохраните учебные события в form-events.csv:

journey_id,event_time_utc,event_name,form_id
j-001,2026-10-20T07:00:00Z,form_start,quote
j-001,2026-10-20T07:00:20Z,step_contact_complete,quote
j-001,2026-10-20T07:01:10Z,step_brief_complete,quote
j-001,2026-10-20T07:01:30Z,form_submit,quote
j-001,2026-10-20T07:01:31Z,lead_confirmed,quote
j-002,2026-10-20T07:05:00Z,form_start,quote
j-002,2026-10-20T07:05:25Z,step_contact_complete,quote
j-002,2026-10-20T07:06:20Z,step_brief_complete,quote
j-002,2026-10-20T07:06:40Z,form_submit,quote
j-002,2026-10-20T07:06:42Z,lead_confirmed,quote
j-003,2026-10-20T07:10:00Z,form_start,quote
j-003,2026-10-20T07:10:30Z,step_contact_complete,quote
j-003,2026-10-20T07:11:10Z,step_brief_complete,quote
j-004,2026-10-20T07:15:00Z,form_start,quote
j-005,2026-10-20T07:20:00Z,form_start,quote
j-005,2026-10-20T07:20:20Z,step_contact_complete,quote
j-005,2026-10-20T07:21:00Z,step_brief_complete,quote
j-005,2026-10-20T07:21:20Z,form_submit,quote
j-006,2026-10-20T07:25:00Z,form_start,quote
j-006,2026-10-20T07:25:20Z,step_contact_complete,quote

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

import csv
from collections import defaultdict

stages = [
    "form_start",
    "step_contact_complete",
    "step_brief_complete",
    "form_submit",
    "lead_confirmed",
]

journeys = defaultdict(set)
with open("form-events.csv", encoding="utf-8", newline="") as source:
    for row in csv.DictReader(source):
        if row["event_name"] in stages:
            journeys[row["journey_id"]].add(row["event_name"])

counts = {stage: sum(stage in events for events in journeys.values()) for stage in stages}
for index, stage in enumerate(stages):
    previous = stages[index - 1] if index else None
    rate = "—" if previous is None else f"{counts[stage] / counts[previous]:.1%}"
    print(stage, counts[stage], rate)

for journey_id, events in journeys.items():
    for index, stage in enumerate(stages[1:], start=1):
        if stage in events and stages[index - 1] not in events:
            print("BROKEN_SEQUENCE", journey_id, stage)

Контрольный результат: 6 → 5 → 4 → 3 → 2, а строк BROKEN_SEQUENCE нет. Если следующий этап оказался больше предыдущего, сначала ищите пропавшее событие, повторное срабатывание или возможность войти в форму с середины. Не объясняйте такой результат поведением пользователей до проверки измерения.

Как найти причину потери на конкретном переходе

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

Проведите приёмку до запуска рекламы

1. Зафиксируйте список этапов, условие успеха и источник каждого события.
2. Пройдите форму один раз без ошибок и проверьте последовательность в GA4 DebugView или собственном тестовом журнале.
3. Вызовите ошибку на каждом шаге: следующий этап не должен записываться до успешной валидации.
4. Имитируйте сбой сервера: form_submit допустим, lead_confirmed — нет; интерфейс должен показать понятное состояние.
5. Повторите отправку и убедитесь, что одна заявка не создаёт два подтверждённых лида. Для этого используйте отдельную проверку дублей по lead_id.
6. Сверьте узкую и широкую версии формы, а также полный путь с клавиатуры по чек-листу WiseLab.

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

Ограничения проверки

Учебный journey_id — непрозрачный технический ключ, а не телефон, email или имя. Google запрещает передавать в Analytics данные, по которым можно напрямую идентифицировать человека. Рабочую схему идентификаторов и срок хранения нужно согласовать с требованиями проекта и применимым законодательством.

Автоматические form_start и form_submit не заменяют приёмку. Если форма собрана виджетом, работает без элемента <form> или отправляется нестандартным скриптом, проверьте фактические события и при необходимости настройте собственные. Итог готов к использованию, когда один тестовый путь воспроизводится от первого поля до записи в CRM, а для каждого разрыва команда знает, какой журнал и какое условие открыть.

Базовую формулу показателя сверяйте с ответом «Как рассчитать конверсию сайта». Если отчёт показывает больше конверсий, чем заявок, продолжите с разбором двойных событий; доступность формы без мыши проверяется отдельным сценарием.

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.