ПРАКТИЧЕСКАЯ ИНСТРУКЦИЯ
План событий: какие действия клиента измерять
Как выбрать события сайта, описать правила учёта и проверить результат — на примере сайта компании.
После настройки аналитики в отчёте появились клики по кнопкам, открытия форм и прокрутки страниц. Но на вопрос владельца «Какая реклама приводит заявки на замер?» ответить по-прежнему трудно. Цель с названием «Заявка» срабатывает при нажатии кнопки. В CRM менеджер видит принятые заявки, но связать их с рекламой не получается.
До настройки стоит составить план событий — рабочую таблицу, в которой каждый нужный результат связан с вопросом бизнеса, правилом учёта и проверкой. Такой документ называют также tracking plan. По нему веб-аналитик и разработчик понимают, что настраивать, а руководитель — что должно получиться.
Вопросы и решения вы можете сформулировать самостоятельно. Условия срабатывания, параметры и технические проверки лучше подготовить вместе с исполнителем. Ниже пройдём этот путь на примере компании, которая устанавливает кондиционеры, и соберём заполненный план.
Содержание статьи
- ВопросЗачем измерять?
- ИсточникГде записан факт?
- ПравилоКогда учитывать?
- ПараметрыЧем различать?
- ПроверкаКак принять работу?
Что должно быть в плане событий
План удобно вести в Google Таблицах или Excel. Одна строка описывает событие, которое нужно учитывать: действие посетителя или изменение состояния заявки. Документ может объединять сайт, Метрику и CRM — с указанием, где фиксируется каждый факт.
| Поле | Что записать |
|---|---|
| Вопрос и решение | Что хотим узнать и как используем ответ. |
| Событие | Понятное описание действия или изменения статуса и его техническое название, если оно требуется. |
| Правило учёта | Когда засчитываем событие, когда исключаем его и что считаем одной единицей. |
| Параметры | Какие подробности нужны для отчёта и какие значения они могут принимать. |
| Источник и отчёт | Где сохраняются данные и по какому показателю будем отвечать на вопрос. |
| Проверка | Что сделать и какой результат ожидать, включая случаи, когда событие появляться не должно. |
| Ответственный и статус | Кто настраивает, что уже выполнено и когда проверено. |
Общего документа достаточно, даже если в разных системах используются разные названия. Например, событию из плана может соответствовать цель Метрики и поле CRM. Запишите это соответствие, чтобы исполнителю не пришлось угадывать его.
Шаг 1. Начните с вопросов, от которых зависит решение
Выберите несколько вопросов, ответы на которые понадобятся в ближайшей работе. Формулировка «понимать эффективность сайта» слишком общая: из неё не следует, какие данные собирать. Полезнее спросить, какие рекламные кампании приводят подходящие заявки, и договориться, как сравнить результат с расходами.
В нашем учебном примере компания устанавливает кондиционеры. На сайте есть калькулятор стоимости, две формы — «Заказать замер» и «Получить консультацию», телефон и ссылка на мессенджер. Заявкой считается запрос, который менеджер проверил и принял в CRM. Спам исключают, повторную отправку того же запроса связывают с уже существующей заявкой. Компания и условия примера вымышлены.
Владелец хочет разобраться в трёх вопросах:
- Какие кампании приводят принятые заявки через форму «Заказать замер» и сколько из этих заявок доходят до назначения замера? Эти данные нужны для оценки рекламы вместе с расходами на неё.
- Связано ли использование калькулятора с отправкой формы замера или консультации? Сравнение поможет понять, стоит ли подробнее изучить калькулятор и проверить изменения в его работе или расположении.
- На какие ссылки для связи нажимают чаще: телефон в шапке, контактах или подвале, мессенджер в контактах? Ответ поможет оценить размещение этих ссылок.
Для этих вопросов нужны разные показатели. В первом считаем принятые заявки именно из формы замера, во втором — успешные отправки обеих форм, в третьем — клики. Чтобы оценивать реальные звонки или переписку, понадобятся данные телефонии, коллтрекинга или сервиса сообщений.
Шаг 2. Найдите данные для каждого ответа
Для первого вопроса нужны два факта из CRM: заявку приняли и по ней назначили замер. Одного события отправки формы недостаточно — оно ещё не отделяет подходящий запрос от спама. Чтобы сравнивать рекламу, в карточке также должны сохраняться тип формы и кампания, из которой пришёл посетитель.
Во втором вопросе обе части ответа находятся на сайте: посетитель получил расчёт и отправил одну из двух форм. У обеих форм будет одно событие отправки, а различать их поможет параметр form_name. Для третьего достаточно учитывать нажатия на ссылки для связи и различать их расположение. Так получаются пять событий: три на сайте и два в CRM.
Сайт / Метрика
calculator_resultrequest_form_successcontact_clickОтдельно настраиваем передачу типа формы и кампании в CRM.
CRM / номер заявки
request_acceptedmeasurement_scheduledПрокрутку страниц и клики по фотографиям пока не добавляем: ни для одного выбранного вопроса они не нужны. Новое событие можно включить позже, когда появится задача, для которой этих данных не хватает. Уже настроенные цели сначала проверьте — возможно, часть из них подходит и повторная настройка не потребуется.
Шаг 3. Договоритесь, когда засчитывать событие
Запись «отправка формы» допускает разные трактовки: нажатие кнопки, успешную проверку полей браузером или подтверждение от сервера. В примере будем учитывать отправку после того, как сервер подтвердил, что сохранил данные для обработки. Разработчик должен назвать конкретный сигнал, по которому сайт узнаёт об этом.
- НажатиеЕщё не засчитываем
- Поля провереныЕщё не засчитываем
- Сервер сохранил+1 успешная отправка
Сразу определите, что не должно увеличивать счётчик. Ошибка в обязательном поле, отказ сервера, повторное нажатие кнопки во время отправки и обновление страницы «Спасибо» не означают новую успешную отправку. Если человек позже отправил другой запрос, это уже отдельное действие.
Попробуйте сценарии и посмотрите, что засчитывается
Кнопки изменяют только этот учебный пример. Они ничего не отправляют на сайт, в Яндекс Метрику или CRM.
Принятие заявки и назначение замера в этой модели считаются по уникальному запросу, а не по числу смен статуса.
Начните с расчёта или успешной отправки формы.
- Сценарий ещё не запускался.
Правило зависит от того, что считаем. Повторный расчёт в калькуляторе — новое событие. Но при сравнении визитов с калькулятором и без него каждый визит учитывается один раз, независимо от числа расчётов. Перенос даты уже назначенного замера — не новая заявка с назначенным замером. В плане это нужно написать прямо.
Уточните выполнимость условия до начала работ. Если сторонняя форма не сообщает сайту об успешном приёме данных, может понадобиться доработка или другой источник события. Подмена успешной отправки кликом меняет смысл показателя — её нельзя незаметно внести в настройку.
Шаг 4. Выберите названия и параметры
Параметр добавляет подробность к событию. Обе формы передают событие request_form_success, а параметр form_name различает их: zamer — форма замера, consultation — форма консультации. Для клика по контакту нужно знать, на какую ссылку нажали. Вместе с событием contact_click передадим параметр contact_point: например, header_phone означает телефон в шапке, а contacts_messenger — мессенджер в разделе контактов.
Для каждого параметра запишите список допустимых значений. Иначе один разработчик назовёт телефон в шапке header_phone, другой — phone_top, и клики по одной ссылке окажутся в разных строках отчёта.
Одно событие — две формы
Переключите форму и посмотрите, что меняется в передаваемых данных. Код события остаётся одинаковым.
Для собственных идентификаторов удобно договориться о строчных латинских буквах и подчёркиваниях: calculator_result, request_form_success. Имя должно описывать действие и сохранять смысл после редизайна. Если инструмент требует специального названия или использует своё поле, укажите соответствие в плане.
Собирайте параметры для конкретного вопроса. В этом примере не нужно отдельно передавать в Метрику устройство или источник визита. Но для CRM нужно настроить сохранение типа формы и рекламной кампании: наличие этих сведений в Метрике не означает, что они появились в карточке заявки.
Телефоны, email и комментарии клиентов не включайте в параметры целей. Для описанных отчётов достаточно сведений о событиях, конкретной ссылке для связи и рекламной кампании. Контактные данные нужны менеджеру в CRM.
Шаг 5. Сразу запишите проверки
У каждого события должны быть проверка успешного сценария и проверка исключений. Формулировка «проверить цель» слишком неопределённа. Запись «отправить форму с пустым обязательным полем — новых событий нет» уже задаёт понятное действие и ожидаемый результат.
В Метрике передачу целей можно проверить через панель отладки: добавьте к адресу страницы ?_ym_debug=2, а если в адресе уже есть знак вопроса — &_ym_debug=2. Выполните действие и проверьте событие и параметры. Если панель недоступна, в справке Метрики описана проверка через консоль браузера с _ym_debug=1. После обработки данных проверьте и отчёт: отправка события и правильный подсчёт показателя — разные этапы проверки.
Проводите сценарии отдельно и отмечайте, сколько новых событий появилось после каждого действия. Иначе результат предыдущего теста легко принять за новый. Отправьте обе формы и проверьте, что form_name в Метрике и тип формы в CRM совпадают. Для CRM используйте заявки с признаком «ТЕСТ»: они должны быть видны в отдельной проверочной выборке и исключены из рабочих показателей.
Успешный тест подтверждает работу проверенного сценария. Полноту исторических данных он не доказывает. Если счётчик запускается только после согласия посетителя, отказавшиеся в эти отчёты не попадут; часть событий также может блокироваться браузером. Условия теста и известные ограничения запишите рядом с результатом.
Пример плана событий для компании по установке кондиционеров
Ниже пять записей одного плана. Для удобства чтения каждая показана отдельной таблицей. Все записи пока имеют статус «Запланировано»: события сайта настраивают аналитик и разработчик, учёт в CRM — администратор системы вместе с руководителем продаж.
В CRM сохраняются уникальный номер заявки, канал поступления — форма сайта, тип формы (zamer или consultation), дата принятия, дата первого назначения замера, кампания визита с отправкой формы и признак теста. Если кампанию определить не удалось, оставляем «Не определено». Факты принятия и назначения сохраняются после последующих смен статуса.
1. Расчёт в калькуляторе · Сайт · Метрика
Назначение
Вопрос 2 — связать использование калькулятора с отправкой формы.
Событие и источник
calculator_result → цель Метрики типа «Целевое событие» с таким же идентификатором. Дополнительных параметров нет.
Когда и сколько раз
Калькулятор завершил расчёт и показал стоимость. Один раз на расчёт; повторный расчёт учитывается отдельно.
Исключения
Открытие калькулятора без расчёта, ошибка ввода, повторная отрисовка уже полученного результата.
Проверка
Получить результат — одно событие. Изменить площадь и выполнить новый расчёт — ещё одно. Отдельно открыть калькулятор без расчёта и попробовать расчёт с незаполненным обязательным полем — новых событий нет.
2. Успешная отправка формы · Сайт · Метрика
Назначение
Вопрос 2 — учитывать успешные отправки обеих форм в визитах с калькулятором и без него.
Событие и источник
request_form_success → цель Метрики типа «Целевое событие» с таким же идентификатором.
Когда и сколько раз
Сервер подтвердил сохранение данных для обработки. Один раз на принятую сервером отправку.
Исключения
Ошибка полей или сервера, повторная передача события по той же отправке, обновление или повторное открытие страницы «Спасибо».
Параметры
form_name: zamer — «Заказать замер»; consultation — «Получить консультацию».
Проверка
Успешно отправить каждую форму — по одному событию с form_name = zamer или consultation; соответствующий тип должен сохраниться и в CRM. В одном визите последовательно отправить обе формы с интервалом в несколько секунд — два события с разными значениями form_name, но один целевой визит по общей цели; обе отправки должны быть правильно отражены в тестовых данных CRM. Проверить пустое обязательное поле и согласованный с разработчиком сценарий ошибки сервера для обеих форм — новых событий нет. При двойном нажатии во время отправки в отладчике одна передача события, в CRM одна запись по этой отправке. После обновления страницы «Спасибо» новых событий нет.
3. Клик по контакту · Сайт · Метрика
Назначение
Вопрос 3 — сравнить число кликов по ссылкам для связи.
Событие и источник
contact_click → цель Метрики типа «Целевое событие» с таким же идентификатором.
Когда и сколько раз
Посетитель активировал ссылку телефона или мессенджера. Один раз на нажатие; повторное нажатие — новое событие.
Исключения
Просмотр блока, выделение номера как текста, нажатие рядом со ссылкой.
Параметры
contact_point: header_phone, contacts_phone, contacts_messenger, footer_phone. Это четыре ссылки в нашем примере.
Проверка
Нажать каждую ссылку — по одному событию с нужным значением. Повторить нажатие через несколько секунд — ещё одно. Проверить исключения — новых событий нет. Клик должен учитываться и тогда, когда на устройстве не удалось начать звонок.
4. Заявка принята в CRM · CRM
Назначение
Вопрос 1 — посчитать принятые заявки из формы «Заказать замер» по рекламным кампаниям.
Событие и источник
request_accepted — обозначение в плане. Источник — сохранённый факт и дата принятия заявки в CRM.
Когда и сколько раз
Менеджер проверил запрос и принял его в работу. Одна заявка учитывается один раз по её уникальному номеру.
Исключения
Непроверенная карточка, спам, повтор того же запроса. Тестовые заявки исключаются из рабочих показателей.
Поля для отчёта
Номер заявки, дата принятия, канал «Форма сайта», тип формы (zamer / consultation), рекламная кампания, признак теста.
Проверка
Перейти по ссылке с метками тестовой кампании и отправить форму замера, затем форму консультации. В CRM проверить тип формы, канал поступления и кампанию каждой записи. До принятия заявка не входит в показатель; после принятия заявка из формы замера видна один раз в тестовой выборке, а консультация не входит в показатель вопроса 1. Спам и дубль показатель не увеличивают. В рабочем отчёте тестовые записи исключены.
5. По заявке назначен замер · CRM
Назначение
Вопрос 1 — определить, по каким из принятых заявок на замер хотя бы раз согласовали дату.
Событие и источник
measurement_scheduled — обозначение в плане. Источник — дата первого назначения замера в CRM.
Когда и сколько раз
Клиент подтвердил дату, менеджер сохранил назначение. Один раз на уникальный номер заявки.
Исключения
Предварительная дата без подтверждения клиента, перенос уже согласованного замера. Тестовые заявки исключаются из рабочих показателей.
Поля для отчёта
Номер той же принятой заявки из формы замера, дата первого назначения. Кампания берётся из её карточки.
Проверка
У принятой тестовой заявки сохранить предварительную дату — показатель не изменился. Подтвердить назначение — заявка вошла в тестовую выборку один раз. Перенести дату — число заявок не выросло. После смены текущего статуса факты принятия и первого назначения остаются в отчёте; в рабочей выборке тест исключён.
Как получить ответы по этому плану
Для первого вопроса отберите в CRM принятые за выбранный месяц заявки из формы «Заказать замер» (form_name = zamer). Консультации в этот показатель не включайте. По каждой кампании посчитайте уникальные заявки и среди них — те, которым назначили замер к дате отчёта. Не сравнивайте заявки, принятые в одном месяце, со всеми назначениями другого периода. Назначенный замер ещё не означает, что он состоялся. Расходы на кампании добавьте из рекламного кабинета, если переходите к решению о бюджете.
Для второго вопроса сравните долю визитов с успешной отправкой любой из двух форм в двух группах: с расчётом в калькуляторе и без него. Период и остальные фильтры должны совпадать. В каждой группе один визит входит в числитель один раз, даже если расчётов или отправок было несколько. Расчёт и отправка здесь учитываются в пределах одного визита. Общая конверсия показывает долю визитов, в которых успешно отправили хотя бы одну из двух форм. Разбивка по form_name помогает увидеть, какие запросы оставляют чаще — на замер или консультацию. Если обе формы отправлены в одном визите, он попадёт в обе группы по типу формы, а в общей конверсии будет учтён только один раз: поэтому суммировать целевые визиты по типам форм нельзя. Разница между визитами с калькулятором и без него покажет связь, но не докажет влияние калькулятора: им могут чаще пользоваться люди, уже готовые оставить заявку.
Если важно проверить, отправляют ли форму именно после расчёта, сравните время событий внутри каждого визита. Например, калькулятор использовали в 100 визитах. В 25 из них посетители также отправили хотя бы одну форму, но в 6 из этих 25 визитов отправки были только до расчёта. Значит, отправка после расчёта произошла в 19 визитах. Доля визитов с такой последовательностью среди всех визитов с расчётом — 19 из 100, или 19%. В знаменатель входят и визиты без отправки формы. Отношение 19 к 25 показывает долю среди визитов с обоими действиями, но не конверсию всех визитов с калькулятором. Для такой проверки нужны идентификатор визита и время отдельных событий: одних суммарных показателей целей недостаточно. Даже подтверждённая последовательность не доказывает, что именно калькулятор побудил посетителя отправить форму.
Для третьего вопроса в Метрике нужен отчёт по параметрам события или цели contact_click с показателем «Количество событий» и разбивкой по contact_point. Отчёты «Параметры событий» и «Параметры целей» позволяют работать с такими данными. Проверьте две разные ссылки в одном визите: в отчёте должно быть по одному событию для каждого значения. Не подменяйте число кликов числом визитов, в которых встречался параметр. Эти данные показывают нажатия, а состоявшиеся звонки и отправленные сообщения требуют отдельного учёта.
Как передать план в работу
До настройки обсудите с исполнителем условия, источники данных и отчёты. Отдельно договоритесь, как тип формы попадёт в CRM. Если в задачу входит проверка последовательности действий, дополнительно согласуйте, где взять время событий и идентификатор визита. Если часть плана пока нельзя реализовать, запишите причину, необходимую доработку и ответственного. Каждое изменение правила должно быть видно в документе.
При приёмке попросите результат по каждой строке: что сделали, что появилось в отладчике, CRM и отчёте, какие параметры получили и какие исключения проверили. Снимок экрана полезен вместе с описанием сценария. Отдельно должны быть перечислены отклонения и незавершённые задачи.
После запуска обновляйте план вместе с измеряемыми формами, калькулятором и процессом работы в CRM. При таких изменениях повторяйте связанные проверки. Таблица должна оставаться у компании: тогда новый аналитик сможет разобраться в правилах, не восстанавливая их по коду и настройкам счётчика.
План действий
Задача: Подготовить план событий для настройки и приёмки аналитики.
Шаги:
- Выбрать вопросы и решения, для которых нужны данные.
- Связать каждый вопрос с событиями и источниками.
- Описать условия учёта, параметры и проверки.
- Согласовать выполнимость и ответственных с исполнителем.
Инструменты:
- Google Таблицы или Excel — вести общий план.
- Яндекс Метрика — проверять события сайта и отчёты.
- CRM — учитывать принятые заявки и назначенные замеры.
Результат: У каждого вопроса есть источник данных и понятный способ получить ответ; по каждой записи плана исполнитель знает, что настроить и как подтвердить работу.
Чек-лист готовности плана
Вопрос-ответ
Можно ли оставить автоматические цели Метрики?
Да, если они соответствуют нужному действию и проходят проверки из плана. Убедитесь, что цель формы не срабатывает при ошибке. Если нужно отличать конкретные формы или места клика, проверьте, доступны ли нужные подробности. При необходимости добавьте собственное событие, а роль прежней цели пересмотрите, чтобы в отчётах не смешивались разные правила.
Что делать, если аналитика уже работает, а плана нет?
Сначала опишите существующие цели и их фактическое поведение. Затем сопоставьте их с вопросами бизнеса: что можно использовать, что нужно исправить, каких данных не хватает. Этот список и станет первой версией плана. Порядок проверки разобран в статье «Аналитика уже настроена: с чего начать проверку».
Заменяет ли план событий техническое задание разработчику?
План задаёт, что измерять и как принимать результат. Для реализации могут понадобиться дополнительные решения: откуда получать подтверждение отправки, как передавать событие, кто дорабатывает CRM. Их согласуют аналитик и разработчик. Для небольшой настройки план может стать основой задания, если эти детали и ответственность уже определены.
Полезные материалы
Веб-аналитика · Настроить сбор