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

Предыстория

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

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

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

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

1. Составил карту событий Написал ТЗ на кастомные события разработчикам

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

3. После этого я подготовил дополнительное ТЗ для внедрения Электронной торговли Яндекс Метрики.

4. На следующем шаге проверил реализованные события

5. И уже дальше через Яндекс Тег Менеджер (YTM) по событиям из dataLayer настроил передачу нужных событий в Яндекс Метрику.

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

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

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

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

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

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

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

• Категорию событий

• Описания событий

• Логику срабатывания

• Так же фиксировал куда передаётся событие (например, Яндекс Метрика или datalayer)

• Проставлял статусы: где событие уже фиксируется а где еще нет

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

• Тестирования событий

• Постановки ТЗ разработчикам

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

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

• Изучил страницы, разделы и пользовательские сценарии

• Проанализировал формы, виджеты и элементы интерфейса

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

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

• Какие формы существуют

• В какой момент они и отправляются

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

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

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

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

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

• Использовать понятные и логичные названия

• Придерживаться единого стиля именования событий

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

Пример:

• view_catalog_1

• fast_order_send

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

Результат

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

• Фиксировать настроенные события

• Взаимодействовать с разработчиками

• Тестировать аналитику

• Не путаться в том, что уже настроено, а что нет

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

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

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

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

Далее я создал документ (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.

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

Просмотр товара
Событие: 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.

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