Недавно прилетел вопрос от коллеги: «Как правильно размечать событиями сайт или приложение? Есть ли какие-то чек-листы или best practice?».
Вопрос настолько хороший и фундаментальный, что я вспомнил молодость и решил накатать целый пост-напоминалку. Потому что если с самого начала накосячить с разметкой, то и все последующие аналитические выводы могут оказаться красивой, но бессмысленной картинкой.
Когда-то я отвечал за событийную аналитику нескольких крупных проектов и уже тогда выработал простой и, что важно, масштабируемый принцип. Он отлично приживается и на сайтах, и в мобилках.
Представьте, что ваше приложение – это матрешка
У нас есть экраны: main, catalog, cart.
Каждый экран мы мысленно делим на крупные блоки (например, header, product_grid, recommendations_slider).
А эти блоки, в свою очередь, состоят из элементов (cart_button, favorite_icon, product_card).
Любое действие пользователя – это законченная история, которая собирается по четкому сценарию. Но как её записать? Здесь есть развилка, и нужно выбрать один из двух основных вариантов формирования события.
Вариант 1
Событие создается по правилам:
screen_name + block_name + element_name + action
Например:
catalog_product_grid_cart_button_click
Плюсы:
▪️Удобно анализировать в интерфейсе аналитических систем.
▪️Не нужно строить сложные фильтры, чтобы увидеть все клики в каталоге продуктов.
▪️По имени события сразу понятно, где, что и как произошло.
Минусы:
▪️Риск упереться в лимиты на количество уникальных событий. Если у вас очень сложное приложение, таких комбинаций может накопиться несколько тысяч.
Вариант 2
Событие состоит только из действия:
action
Но вся магия кроется в параметрах! В них мы и прописываем screen_name, block_name, element_name.
Например:
click
Параметры:
{screen_name: 'catalog', block_name: 'product_grid', element_name: 'cart_button'}
Плюсы:
▪️Простой и понятный список событий. У вас будет всего несколько десятков базовых действий. Система не захламлена.
▪️Легко добавить новый элемент или блок, не создавая новое уникальное событие.
Минусы:
▪️Требуется предварительная обработка. Для анализа вам постоянно придется фильтровать одно и то же событие по разным параметрам.
Независимо от выбранного варианта, душа события – это его параметры. Обязательно продумайте их: от базовых, вроде user_id и app_version, до кастомных, вроде product_id, promo_name или source.
Предостережение
Главный соблазн для любого начинающего аналитика – начать трекать ВСЁ. «А давайте еще повесим событие на скролл, на наведение курсора, на смену времени суток в приложении!». Стоп! Помните, что у всего есть своя цена.
Системы аналитики вроде Google Analytics, AppsFlyer или AppMetrica имеют лимиты на количество регистрируемых событий. Например, вот выдержка из доки:
В AppMetrica есть суточные лимиты на кастомные события, присылаемые через SDK и Post API. Суточный лимит — 3 250 000 событий на тарифе Free.
Упершись в потолок, вы можете начать терять важные данные. Да и хранение каждого события в вашей БД – это прямые серверные затраты.
Поэтому мой совет: раз в полгода-год проводите аудит. Удаляйте устаревшие события, которые больше никто не анализирует.
В общем, друзья, в разметке событиями нет ничего архисложного. Немного структуры, здравого смысла и планирования на старте, и ваша аналитика будет стоять на крепком фундаменте. Удачи в трекинге!
#опыт