Событийная аналитика: как считать шаги воронки, а не только заявки

Что такое событийная модель и чем она отличается от набора целей

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

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

Разница на практике: цель говорит «было 7 заявок», событийная модель говорит «форму открыли 90 человек, к полю телефона дошли 30, форму отправили 7». Из этого ряда сразу видно, где потери: между открытием и шагом с телефоном ушло втрое больше людей, чем потом. Именно там и стоит искать проблему.

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

Какие события стоит отслеживать

Набор событий зависит от того, как устроен сайт и что важно понять. Но есть общий список, который покрывает большинство ситуаций.

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

Именование событий: чтобы через полгода был понятен смысл

Через полгода в Метрике будет отчёт с событиями вроде btn_click, send, step2. Кто такой btn_click? Какая кнопка, на какой странице? Что значит step2: второй шаг формы или второй экран лендинга?

Хорошее именование строится по схеме действие_объект или действие_объект_место. Примеры:

• form_open: открытие формы (если форма одна на сайте)
• form_step_phone: переход к шагу с полем телефона
• form_success: форма успешно принята сервером
• cta_click_hero: клик по кнопке на первом экране
• tel_click: клик по номеру телефона

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

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

Воронка в Метрике на основе событий

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

Например, составная цель из трёх шагов:

1. JavaScript-событие form_open
2. JavaScript-событие form_step_phone
3. JavaScript-событие form_success

Метрика покажет, сколько пользователей прошли каждый шаг. Если на шаге с телефоном остаётся треть от тех, кто открыл форму, это сигнал. Возможно, поле телефона обязательное, но люди не хотят его давать. Или форма сбрасывает введённые данные при ошибке и люди сдаются. Чтобы посмотреть поведение таких пользователей в Вебвизоре, создайте в Метрике сегмент из двух условий: достигли form_open и не достигли form_step_phone. Применив этот сегмент к Вебвизору, вы увидите именно те записи, где воронка оборвалась. Подробнее о разборе сессий читайте в статье про анализ сессий в Вебвизоре.

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

Что даёт событийная модель на практике

Событийная аналитика объясняет вещи, которые без неё остаются загадкой. Вот два типичных примера.

Много кликов по CTA, мало открытий формы

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

Форма открывается, но на шаге с телефоном уходит большинство

Это частая история с многошаговыми формами. Первые шаги (вопросы о задаче, бюджете, сроках) проходятся легко. А потом наступает шаг с личными данными — именно здесь значительная часть людей останавливается. Возможные причины: поле телефона обязательное без объяснения зачем, нет уточнения о конфиденциальности, или шаг некорректно отображается на телефоне.

Без события на этом шаге причина оттока невидима. С событием видно, где именно происходит разрыв.

Инструменты: Метрика против Google Tag Manager

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

ym(XXXXXX, 'reachGoal', 'form_success');

Здесь XXXXXX — номер счётчика Метрики, form_success— идентификатор цели, созданной заранее в интерфейсе Метрики.

Google Tag Manager нужен в нескольких ситуациях:

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

На старте, и для большинства небольших сайтов, Метрика справляется. GTM оправдан тогда, когда вы конкретно упрётесь в её ограничения, а не заранее.

Минимальный набор событий для небольшого сайта

Если вы только начинаете и не хотите тратить несколько недель на настройку, начните с пяти событий. Их достаточно, чтобы увидеть воронку и найти первые точки потерь.

1. form_open: пользователь начал взаимодействовать с формой.
2. form_success: форма успешно принята. Лучший вариант: вызов через JavaScript в обработчике успешного ответа от сервера, а не на клик по кнопке.
3. tel_click: клик по номеру телефона. Это второй путь к заявке, который часто не учитывается вообще.
4. cta_click: клик по главной кнопке CTA. Помогает понять, реагируют ли на призыв к действию.
5. page_spasibo: посещение страницы подтверждения, если она есть как отдельный URL. Альтернатива JavaScript-событию.

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

Событийная модель — это не разовая настройка. Она растёт вместе с вашим пониманием сайта и вашими вопросами.

Итог

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

• Событийная модель — это система, а не набор целей. Связанные события дают воронку, несвязанные дают просто цифры.
• Начните с двух полюсов: открытие формы и успешная отправка. Остальное добавляйте по мере необходимости.
• Называйте события понятно: form_success лучше, чем send. Через полгода это сэкономит час разбирательств.
• Для небольшого сайта достаточно Метрики. GTM нужен тогда, когда упрётесь в конкретное ограничение, а не заранее.
• Финальное событие — через JavaScript в success-callback, не на клик по кнопке. Иначе конверсия будет считаться, даже когда форма ушла с ошибкой.

Как только события настроены, появляется инструмент для ежедневной работы. В каком разрезе смотреть данные и как читать отчёты Метрики: читайте в статье про 7 отчётов Яндекс.Метрики. Если вопрос в том, как правильно настроить отдельную цель на форму: разбор в статье про цели в Яндекс.Метрике.