Как составить план событий для одной пользовательской воронки заявки

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

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

Что должно получиться на выходе

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

Если вы используете Google Analytics 4, сама логика здесь событийная: взаимодействия передаются как события с именем и параметрами, а проверять их удобно в Realtime и DebugView. На веб-странице с установленным Google tag событие отправляют вызовом gtag('event', ...) ниже тега. Но сначала полезно договориться не о коде, а о смысле: в какой точке пользовательского пути событие имеет право считаться случившимся.

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

Граница пользовательского действия

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

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

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

Словарь событий и параметров

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

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

Учебная таблица плана

Заметьте, здесь нет события вроде submit_click. Для этой конкретной воронки оно не обязательно. Если ваш вопрос — «сколько людей увидели форму, начали ввод и дошли до успеха», трёх событий достаточно. Дополнительные точки стоит добавлять только тогда, когда вы заранее понимаете, какой новый вопрос они решают.

Учебная проверка дублирующих отправок

Учебный пример. Допустим, на лендинге за день форма была реально показана 120 раз. Из них 80 пользователей начали ввод, а после проверки логики оказалось, что успешных заявок было 36. До исправления счётчик form_submit_success показывал 41 событие, потому что обработчик срабатывал дважды у части отправок: на ответе от сервера и на повторном рендере блока успеха.

Если бы вы построили воронку по сырым событиям, получили бы искажённую картину. Конверсия из просмотра в успех выглядела бы как 41 / 120 = 34,2%, хотя реальное значение 36 / 120 = 30,0%. Конверсия из начала заполнения в успех выглядела бы как 41 / 80 = 51,3%, а после удаления дублей — 36 / 80 = 45,0%. Для одной формы это уже заметное различие: команда может ошибочно искать проблему не на том шаге.

Чтобы такой сбой поймать, полезно ввести технический параметр submit_attempt_id для каждой попытки отправки. Это не персональные данные, а служебный идентификатор попытки, который помогает сравнить число событий успеха с числом уникальных попыток. Если событий 41, а уникальных submit_attempt_id только 36, у вас не «выросла конверсия», а появились дубли.

// Учебный фрагмент для проверки логики, не готовая интеграция.
// Среда: веб-страница с уже подключённым gtag.js ниже Google tag.
const sent = { view: false, start: false };
let lastSuccessAttemptId = null;

function sendFormView() {
  if (sent.view) return;
  sent.view = true;
  gtag('event', 'form_view', {
    funnel_name: 'lead_request',
    form_id: 'main_request_form',
    form_variant: 'short',
    placement: 'hero'
  });
}

function sendFormStart() {
  if (sent.start) return;
  sent.start = true;
  gtag('event', 'form_start', {
    funnel_name: 'lead_request',
    form_id: 'main_request_form',
    form_variant: 'short',
    placement: 'hero'
  });
}

function sendFormSubmitSuccess(attemptId) {
  if (lastSuccessAttemptId === attemptId) return;
  lastSuccessAttemptId = attemptId;
  gtag('event', 'form_submit_success', {
    funnel_name: 'lead_request',
    form_id: 'main_request_form',
    form_variant: 'short',
    placement: 'hero',
    submit_attempt_id: attemptId
  });
}

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

Как согласовать план с реализацией и отчётом

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

Для одной воронки обычно достаточно трёх основных расчётов: доля form_start / form_view, доля form_submit_success / form_view и доля form_submit_success / form_start. Тогда каждое событие сразу связано с ответом на понятный вопрос: форма видна, заполнение начато, отправка завершена. Если в отчёте появляется показатель, который нельзя вывести из утверждённого словаря без новых допущений, значит план событий ещё не закончен.

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

Если хотите потренироваться не только в составлении такого плана, но и в связке с аналитическими инструментами, в программе курса «Профессия Специалист по контекстной рекламе» указаны темы по настройке систем веб-аналитики, Google Tag Manager, Google Analytics и Яндекс Метрике, а также отдельный блок по подготовке кастомизированных отчётов и размещению событий для пикселей рекламных площадок.