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

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

Предыстория

Изначально для передачи событий в системы аналитики использовался 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.

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

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

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

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

javascriptdataLayer.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.

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