Как составить карту событий и целей сайта

Начните с решения бизнеса

Список «отслеживать все кнопки» создаёт много данных, но не объясняет их назначение. Сначала сформулируйте вопросы: где посетитель прекращает оформление, какие услуги получают подходящие обращения, сколько заказов оплачено. Затем определите события, необходимые для ответа.

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

Опишите контракт события

Добавьте владельца события и версию определения. Если смысл изменился, старые и новые данные могут требовать раздельного анализа даже при одинаковом названии.

Разделите этапы формы

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

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

Разделите заказ и оплату

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

Не отправляйте покупку повторно при каждом открытии страницы результата. Используйте связь с операцией и предусмотренные механизмы учёта. Отмена, возврат и изменение заказа требуют отдельного согласованного отражения, если они входят в аналитическую задачу.

Продумайте источники и контекст

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

Источник истины зависит от события. Браузер знает о нажатии, сервер — о сохранённой записи, CRM — о квалификации по установленным правилам. Система аналитики получает наблюдение, а не становится автоматически владельцем всех бизнес-состояний.

Учебный пример контракта

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

Если событие отправляется через клиентский метод reachGoal, учитывайте доступность счётчика и ограничения браузера. Успех серверного действия не гарантирует, что аналитика получила сигнал. Это ожидаемая граница, которую нужно знать при сверке.

Проверка перед использованием отчётов

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

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

Пример карты трёх событий формы

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

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

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

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

Заполненная спецификация для разработчика

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

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

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

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