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

Предыстория

Изначально для передачи событий в системы аналитики использовался Google Tag Manager (GTM). Однако из-за изменений в законодательстве и требований безопасности заказчика было решено перейти на Яндекс Тег Менеджер (YTM). Также мы рассматривали Matomo Tag Manager, но установка на сервер и настройка показались лишними.

При внедрении Яндекс Тег Менеджера мы столкнулись с ограничением: на тот момент сервис не поддерживал передачу переменных, поэтому мы не могли передавать ID и стоимость товаров. А это был важный момент, так как одной из задач являлось внедрение электронной торговли Яндекс Метрики.

Поэтому в итоге мы выбрали комбинированную схему с привлечением разработчиков.

Процесс внедрения у нас выглядел следующим образом:

Составил карту событий Написал ТЗ на кастомные события разработчикам
Далее разработчики настроили кастомные события и передали их в dataLayer.
После этого я подготовил дополнительное ТЗ для внедрения Электронной торговли Яндекс Метрики.
На следующем шаге проверил реализованные события
И уже дальше через Яндекс Тег Менеджер (YTM) по событиям из dataLayer настроил передачу нужных событий в Яндекс Метрику.

Конечно, технически передать цели в Яндекс Метрику можно как напрямую из кода сайта, так и с использованием тег-менеджеров, минуя dataLayer.

Однако в нашем случае такой подход оказался менее надёжным. Сайт был реализован на JavaScript, и тег-менеджер не всегда корректно отслеживал пользовательские действия. Кроме того, как я упоминал ранее, на тот момент Яндекс Тег Менеджер был ещё достаточно сырым и имел ограничения в работе с переменными.

Поэтому мы выбрали вариант с вызовом событий напрямую из кода сайта в нужные моменты — это позволило точнее контролировать логику срабатывания. К тому же такой подход дал дополнительное преимущество — возможность переиспользовать события для других систем аналитики без повторного привлечения разработчиков.

Алгоритм разработки карты событий

Проработка структуры карты событий

На первом этапе я начал определять структуру будущей карты событий.

Для этого создал таблицу (Google Sheets), в которой фиксировал:

Категорию событий
Описания событий
Логику срабатывания
Так же фиксировал куда передаётся событие (например, Яндекс Метрика или datalayer)
Проставлял статусы: где событие уже фиксируется а где еще нет

Эта информация очень помогла на этапах:

Тестирования событий
Постановки ТЗ разработчикам

Аудит точек касания

На этом этапе я провел анализ сайта:

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

Все это помогло понять:

Какие формы существуют
В какой момент они и отправляются
Зафиксировать полученную информацию в карте событий

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

Составление списка событий

В результате изучения и тестирования сайта я составил список целевых действий / событий и зафиксировал их в карте.

При составлении списка событий я старался придерживаться нескольких принципов:

Использовать понятные и логичные названия
Придерживаться единого стиля именования событий
При необходимости использовал переводчик или транслит

Пример:

view_catalog_1
fast_order_send

Главное чтобы названия были читаемыми и понятными участникам проекта.

Результат

В результате я получил карту событий в виде таблицы (пример ниже). Она позволяет:

Фиксировать настроенные события
Взаимодействовать с разработчиками
Тестировать аналитику
Не путаться в том, что уже настроено, а что нет

Эта таблица станет основой для постановки задач разработчикам и настройки аналитики.

Категория события	Описание	Активация	Event_Name Метрика	Фиксируется в Метрике	Название в Метрике	Передается в DataLayer	Событие в DataLayer
Каталог / подкаталог 1	Просмотр каталога 1	Активация в момент просмотра каталога 1 и всех подкатегорий	view_catalog_1	Да	Просмотр каталога 1	Да	view_catalog_1
Каталог / подкаталог 2	Просмотр каталога 2	Активация в момент просмотра каталога 2	view_catalog_2	Да	Просмотр каталога 2	Да	view_catalog_2
Каталог / подкаталог 3	Просмотр каталога 3	Активация в момент просмотра каталога 3	view_catalog_3	Да	Просмотр каталога 3	Да	view_catalog_3

Форма быстрого заказа (открыли форму)	Открытие формы быстрого заказа	Активация в момент открытия формы (Быстрый заказ)	fast_order_open	Да	Форма быстрого заказа (открыли)	Да	fast_order_open
Форма быстрого заказа (отправили)	Отправка формы быстрого заказа	Активация в момент успешной отправки формы (Быстрый заказ)	fast_order_send	Да	Форма быстрого заказа (отправили)	Да	fast_order_send

Корзина	Добавить в корзину	Активация после успешного добавления товара в корзину	basket_step_1	Да	Добавить в корзину	Да	basket_step_1
Корзина	Начало оформления заказа	Активация после того как пользователь начал оформлять заказ	basket_step_2	Да	Начало оформления заказа	Да	basket_step_2
Корзина	Успешное оформление заказа	Активация после успешного оформления заказа	basket_step_2	Да	Успешное оформление заказа	Да	basket_step_3

Ecommerce (ЕТ)	Просмотр товара	Активация в момент открытия страницы с карточкой товара		Да		Да	detail
Ecommerce (ЕТ)	Добавление товара в корзину	Активация в момент добавления заказа в корзину		Да		Да	add
Ecommerce (ЕТ)	Удаление товара из корзины	Активация в момент удаления заказа из корзины		Да		Да	remove
Ecommerce (ЕТ)	Покупка	Активация в момент подтверждения заказа		Да		Да	purchase

Теперь можно приступать в подготовке технического задания для разработчиков.

Пример ТЗ для разработчиков

Подготовка ТЗ для разработчиков (кастомные события)

Далее я создал документ (Google Docs) с возможностью комментирования.

В документе я описал:

Что нужно реализовать.
Зачем это нужно.
Список событий.
Логика их вызова.
Пример кода.

Пример описания:
Для передачи информации о целевых действиях пользователя на сайте необходимо реализовать отправку событий в dataLayer с использованием метода dataLayer.push().

Пример событий:

Просмотр каталога 1
Событие: view_catalog_1
Срабатывает при просмотре каталога 1 и всех его подкатегорий.

dataLayer.push({
  event: 'view_catalog_1'
});

Форма быстрого заказа (успешная отправка)
Событие: fast_order_send
Срабатывает при успешной отправке формы.

dataLayer.push({
  event: 'fast_order_send'
});

Таким образом я описал все необходимые события.

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

Подготовка ТЗ для электронной торговли (Ecommerce)

Тут я так же создал отдельный документ (Google Docs), в котором указал:

Что нужно реализовать.
Зачем это нужно.
Список событий.
Логика их вызова.
Пример кода.

Пример описания:
Необходимо настроить передачу данных с сайта в электронную торговлю («Ecommerce») Яндекс Метрики. Это даст возможность собирать и анализировать следующие метрики:

Анализировать товары, заказы и суммы продаж.
Рассчитывать средний чек.
Отслеживать конверсии в целевые действия.
Определять популярные товары, частоту добавлений в корзину и совершенные покупки

Для внедрения необходимо:

Включить опцию «Электронная коммерция» в настройках счётчика.
После включения опции обновить код счётчика (если используется старая версия).
Настроить передачу данных через dataLayer.

Важно соблюдать формат данных для Яндекс Метрики. Подробные требования к структуре Ecommerce-объектов и описание всех полей приведены в официальной справке: https://yandex.ru/support/metrica/ru/ecommerce/data

Основные поля которые необходимо использовать.
products — список товаров
id — ID товара
name — название
price — цена
brand — бренд
category — категория

Пример события:

Просмотр товара
Событие: detail
Активация в момент открытия карточки товара

javascript
dataLayer.push({
  ecommerce: {
    currencyCode: "RUB",
    detail: {
      products: [
        {
          id: "P15432",
          name: "Футболка",
          price: 477.60,
          brand: "Яндекс",
          category: "Одежда / Мужская одежда / Футболки",
          variant: "Красный",
          list: "Результаты поиска",
          position: 1
        }
      ]
    }
  }
});

Сложности с которыми столкнулся в процессе

Некорректный вызов события purchase

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

Путаница с параметрами события для электронной торговли

В процессе настройки передачи данных в электронную торговлю, разработчики заменили название параметров id, name и тд на собственные item.id, item.name а так же изменили структуру объекта ecommerce. Это привело к тому что Яндекс Метрика не смогла корректно принимать данные в Электронную Торговлю и параметры заказов были недоступны в отчетах. Таким образом как я уже писал выше, для ecommerce-событий необходимо соблюдать формат передачи данных указанный в справке Яндекс Метрики. В результате мы исправили наименования параметров, скорректировали структуру объекта ecommerce и все заработало.

P.S.

Карта событий — это не просто список событий, а важная часть аналитики. Она помогает структурировать аналитику и упрощает настройку передачи данных.

Карта событий как фундамент аналитики: практический кейс для E-commerce