- Регистрация
- 23 Авг 2023
- Сообщения
- 3,969
- Реакции
- 0
- Баллы
- 36
Ofline
Привет, Хабр! Делюсь своим подходом к работе с событиями аналитики. И немного расскажу про свой путь выстраивания аналитики для новосозданного проекта.
Статья будет полезна аналитикам, которые только входят в чудесный мир разметки и не хотят набивать шишки и плодить события пачками 🙂
Вся аналитика цифровых продуктов строится на событиях, которые обычно придуманы другими аналитиками задолго до того, как мы устраиваемся в компанию. Собственно, то, что мы видим в базах данных, — результат работы наших коллег, которые позаботились о том, чтобы нам было что анализировать.
В свою очередь, разметка в аналитике — это процесс отбора интересующих нас событий для дальнейшего их трекинга и сбора. События аналитики и продукт связаны между собой нерушимой связью, и в интересах аналитиков эту связь сохранять и улучшать.
События аналитики позволяют посчитать не только основные метрики (DAU, MAU, RR, Revenue и прочие), но и всё, что связано с поведением пользователей, эффективностью новых разделов приложений и многим другим.
Твой выбор на первой задаче по настройке событийной аналитике
Вариант с созданием событий вообще для всего может показаться наиболее приемлемым, так как для любой задачи будет возможность посчитать любую метрику. Но тут возникает ряд существенных проблем, с которыми придётся постоянно сталкиваться.
Поэтому лучше всего обратить внимание на два основных работающих подхода в событийной аналитике и маневрировать между ними:
Целевой подход
При этом подходе собираем данные о событиях, которые непосредственно связаны с конкретными бизнес-целями.
В таком случае их можно довольно быстро собрать и анализировать. Также из-за ограниченности событий упрощаются хранение, проверка и анализ.
Но плюсы также являются и минусами — простота анализа и ограниченность событий не позволяют углубляться в детали и смотреть на новый функционал приложения или сайта.
Экстенсивный/ проактивный подход
Диаметрально противоположный подход, при котором нет необходимости себя чем-либо ограничивать. Навешивать события можно на любой чих в приложении. Плюсами тут выступают гибкость подхода и возможность глубины анализа. Больше данных — больше инсайтов и гипотез!
А основные минусы — это утяжеление базы данных и сложность разбора событий. Часто возникает ситуация, когда событие использовалось для конкретного небольшого функционала в ограниченный период, а после уже никого не интересовало. Данные не нужны, но они всё ещё зря занимают память :с
Сравним подходы для наглядности:
Схема на самом деле примерная и основана только на моём опыте. В разных командах и даже проектах работа событийной аналитики может выстраиваться по-другому в зависимости от целей, срочности и прочих параметров.
Ну и отмечу, что в реальности правда всегда будет где-то посередине. Бизнес- и продуктовые цели оказывают огромное влияние на дерево метрик на проекте, а они, в свою очередь, будут влиять на выбор событий для трекинга.
Приведу простой пример с работы
У меня на проекте в одно время очень активно тестировали небольшие лендинги для проверки гипотез. Лендинги отличались между собой, но при этом у них была примерно одинаковая структура по визуальному наполнению и пользовательскому пути.
У нас была одна цель — посмотреть конверсию в отправку формы.
Нас гораздо в меньшей степени волновало, как именно пользователь доходит до нужной кнопки, куда дополнительно может нажать.
Также важным фактором было то, что все лендинги были временными. То есть на этой неделе они есть, а на следующей всё может поменяться.
Именно поэтому был выбран целевой подход с трекингом только самых важных событий и параметров. Ориентация была на события, которые помогут посчитать основную конверсию и прокси-метрики в рамках тестов.
После того, как определились с выбором подхода, стоит задуматься о том, что попадет в базу данных кроме самих названий событий.
Должно быть несколько уровней информации. Самые базовые:
А если начинаем говорить о дополнительных параметрах, то становится всё гораздо интереснее.
В параметры пользователя обычно попадают:
А для параметров события - используется то, что мы укажем при создании этого события. То есть то, что помогает нам идентифицировать конкретное действие на сайте.
Трекинговые системы (GA, Segment, Amplitude и др.) могут добавлять в доп параметры довольно большой список того, что доступно для отслеживания.
И под большим списком подразумевается 1000 - 2000 (и более) параметров. В моей практике количество нужных параметров обычно ограничивается объемом в 50 - 300. И на фоне этого тысячи уже выглядят пугающе.
Лимиты по событиям и Properties в бесплатной версии Amlitude
Отмечу, что такое количество параметров обычно есть только в моменте получения сырых данных. Когда дело касается наполнения нужной таблицы новыми строками - непозволительно тратить доступный объем без четких ограничений.
Для небольшого проекта, как в моем случае, хватает около 150 параметров (юзерские + параметры событий). Но можно было сократить и до 100 при более тщательном отборе.
После того как были определены бизнес- и продуктовые цели, выбран подход к сбору данных и мы определились с тем, что вообще собираемся трекать на сайте/мобилке, — можем приступать к формированию списка событий и необходимых параметров, а также к их названиям.
Не буду сильно погружаться в теорию на этом этапе, так как материалов на эту тему в открытом доступе более чем хватает. Постараюсь вкратце пробежаться по основным моментам.
Наименование события может состоять из 2 или 3 частей в зависимости от цели и необходимости конкретизации. Обычно событие состоит из объекта, действия над объектом и категории объекта, которая его конкретизирует.
Объекты — это экраны, кнопки, модалки или что угодно, с чем может взаимодействовать пользователь.
Действие — это то, как пользователь взаимодействует в приложении: нажатия, просмотры, свайпы, создание, удаление и т. п.
Категория — описание объекта, которое помогает аналитикам определить место срабатывания события в приложении. Описание ограничивается только нашим воображением, но чем проще и лаконичнее, тем лучше.
Обычно список возможных объектов и действий, а также порядок их записи в самом событии определяется заранее и один раз — для удобства работы в дальнейшем.
К примеру, использовать для кнопки три разных названия: button_tap / buttons_tap / pressbutton_tap — идея, мягко сказать, плохая.
В отличие от объектов и действий, категории чаще всего пополняются и обновляются с появлением нового функционала в приложении или устареванием старого. Поэтому задача по их созданию может возникать как при первичном формировании структуры событий, так и значительно позже этого момента.
Удобство универсальности структуры события аналитики
Чаще всего для создания события применяются базовые нотации (способы написания):
Кроме тех событий, которые были придуманы нами самостоятельно, есть ещё события, которые предоставляются трекерами. Они частично совпадают с тем, что мы хотим фиксировать, но могут не подходить из-за формата их названия, а также из-за отсутствия нужных параметров. В моей практике это, пожалуй, основное ограничение.
Пример для сравнения
Отличия налицо — в скрипте прописывать целиком событие от Амплитуды со скобками — не самое приятное занятие. Также параметр события выглядит менее удобно.
Событие, которое собрано по установленной структуре и с коротким названием параметра, — то, что нужно.
Конечно, не могу не отметить, что документация по событиям аналитики и параметрам должна быть и актуализироваться. Без чёткого и понятного описания того, что означает каждый параметр, нормальной аналитики может просто не получиться.
Выбор способа хранения и документирования всегда остаётся за командой, но часто Google Sheets — простой и удобный вариант для описания всей структуры и определения каждого события и параметра.
В первую очередь события аналитики должны помогать достигать целей анализа. Нет смысла трекать те события, которые потом никто ни разу не использует. И наоборот, отсутствие событий на основной воронке — полный провал задачи :с
На этом этапе нам чётко необходимо понимать всю структуру проекта и его юнит-экономику. Сложно придумать события без понимания того, как всё работает в приложении/на сайте в реальности.
Поэтому просмотр реального/тестового сайта или просмотр развёртки экранов, к примеру, в Figma — основной способ «потрогать» функционал и наложить уже своё видение будущих событий и их параметров.
При создании можем отталкиваться от следующих вариантов:
После создания структуры, документации и, собственно, самих событий аналитики эти данные передаются разработчикам для прописывания событий в коде.
Вуаля — рабочая таблица пополняется событиями и параметрами, которые мы хотим в ней видеть 🙂
Событийная аналитика — это не только технический сбор кликов. Она сильно завязана на понимании продукта и его целей, сопровождается планированием и предсказанием того, что может быть полезно в будущем для анализа.
Корректный подход к созданию событий аналитики влияет на скорость и качество работы не только самих аналитиков, но и остальной команды.
Еще больше полезных материалов в моем TG-канале. Подписывайтесь и читайте контент по ссылке.
Статья будет полезна аналитикам, которые только входят в чудесный мир разметки и не хотят набивать шишки и плодить события пачками 🙂
Немного вводных данных
Вся аналитика цифровых продуктов строится на событиях, которые обычно придуманы другими аналитиками задолго до того, как мы устраиваемся в компанию. Собственно, то, что мы видим в базах данных, — результат работы наших коллег, которые позаботились о том, чтобы нам было что анализировать.
В свою очередь, разметка в аналитике — это процесс отбора интересующих нас событий для дальнейшего их трекинга и сбора. События аналитики и продукт связаны между собой нерушимой связью, и в интересах аналитиков эту связь сохранять и улучшать.
События аналитики позволяют посчитать не только основные метрики (DAU, MAU, RR, Revenue и прочие), но и всё, что связано с поведением пользователей, эффективностью новых разделов приложений и многим другим.
Выбор подхода к сбору информации
Твой выбор на первой задаче по настройке событийной аналитике
Вариант с созданием событий вообще для всего может показаться наиболее приемлемым, так как для любой задачи будет возможность посчитать любую метрику. Но тут возникает ряд существенных проблем, с которыми придётся постоянно сталкиваться.
Поэтому лучше всего обратить внимание на два основных работающих подхода в событийной аналитике и маневрировать между ними:
Целевой подход
При этом подходе собираем данные о событиях, которые непосредственно связаны с конкретными бизнес-целями.
В таком случае их можно довольно быстро собрать и анализировать. Также из-за ограниченности событий упрощаются хранение, проверка и анализ.
Но плюсы также являются и минусами — простота анализа и ограниченность событий не позволяют углубляться в детали и смотреть на новый функционал приложения или сайта.
Экстенсивный/ проактивный подход
Диаметрально противоположный подход, при котором нет необходимости себя чем-либо ограничивать. Навешивать события можно на любой чих в приложении. Плюсами тут выступают гибкость подхода и возможность глубины анализа. Больше данных — больше инсайтов и гипотез!
А основные минусы — это утяжеление базы данных и сложность разбора событий. Часто возникает ситуация, когда событие использовалось для конкретного небольшого функционала в ограниченный период, а после уже никого не интересовало. Данные не нужны, но они всё ещё зря занимают память :с
Сравним подходы для наглядности:
Событие в приложении | Целевой | Эксенсивный |
События регистрации | ✅ | ✅ |
Показы страниц/ экранов | ✅ | ✅ |
Кнопки для любых действий | ✅ | ✅ |
События оплаты | ✅ | ✅ |
Технические события ошибок | ❌ (Не обязательно) | ✅ |
Показ рекламных баннеров | ✅ | ✅ |
Всплывающие баннеры (ошибки/ уведомления внутри приложения и пр.) | ❌ (Не обязательно) | ✅ |
Показы конкретных блоков на странице (при прокрутке страницы вниз) - часто используется при наличии ленты в приложении | ❌ (Не обязательно) | ✅ |
Сохранения/ шеринги Тут многое зависит от целей текущего проекта | ✅ (Не обязательно) | ✅ |
Схема на самом деле примерная и основана только на моём опыте. В разных командах и даже проектах работа событийной аналитики может выстраиваться по-другому в зависимости от целей, срочности и прочих параметров.
Ну и отмечу, что в реальности правда всегда будет где-то посередине. Бизнес- и продуктовые цели оказывают огромное влияние на дерево метрик на проекте, а они, в свою очередь, будут влиять на выбор событий для трекинга.
Приведу простой пример с работы
У меня на проекте в одно время очень активно тестировали небольшие лендинги для проверки гипотез. Лендинги отличались между собой, но при этом у них была примерно одинаковая структура по визуальному наполнению и пользовательскому пути.
У нас была одна цель — посмотреть конверсию в отправку формы.
Нас гораздо в меньшей степени волновало, как именно пользователь доходит до нужной кнопки, куда дополнительно может нажать.
Также важным фактором было то, что все лендинги были временными. То есть на этой неделе они есть, а на следующей всё может поменяться.
Именно поэтому был выбран целевой подход с трекингом только самых важных событий и параметров. Ориентация была на события, которые помогут посчитать основную конверсию и прокси-метрики в рамках тестов.
Из чего состоит событие
После того, как определились с выбором подхода, стоит задуматься о том, что попадет в базу данных кроме самих названий событий.
Должно быть несколько уровней информации. Самые базовые:
Имя события
Время события
Идентификатор пользователя
Базовые параметры пользователя (Страна, платформа, устройство, ОС)
Базовые параметры события (Позволяющие идентифицировать событие)
А если начинаем говорить о дополнительных параметрах, то становится всё гораздо интереснее.
В параметры пользователя обычно попадают:
Платформа
ОС
Язык
Страна
Регион
Amplitude ID
Device ID
и прочее
А для параметров события - используется то, что мы укажем при создании этого события. То есть то, что помогает нам идентифицировать конкретное действие на сайте.
Трекинговые системы (GA, Segment, Amplitude и др.) могут добавлять в доп параметры довольно большой список того, что доступно для отслеживания.
И под большим списком подразумевается 1000 - 2000 (и более) параметров. В моей практике количество нужных параметров обычно ограничивается объемом в 50 - 300. И на фоне этого тысячи уже выглядят пугающе.
Лимиты по событиям и Properties в бесплатной версии Amlitude
Отмечу, что такое количество параметров обычно есть только в моменте получения сырых данных. Когда дело касается наполнения нужной таблицы новыми строками - непозволительно тратить доступный объем без четких ограничений.
Для небольшого проекта, как в моем случае, хватает около 150 параметров (юзерские + параметры событий). Но можно было сократить и до 100 при более тщательном отборе.
Название событий и параметров
После того как были определены бизнес- и продуктовые цели, выбран подход к сбору данных и мы определились с тем, что вообще собираемся трекать на сайте/мобилке, — можем приступать к формированию списка событий и необходимых параметров, а также к их названиям.
Не буду сильно погружаться в теорию на этом этапе, так как материалов на эту тему в открытом доступе более чем хватает. Постараюсь вкратце пробежаться по основным моментам.
Наименование события может состоять из 2 или 3 частей в зависимости от цели и необходимости конкретизации. Обычно событие состоит из объекта, действия над объектом и категории объекта, которая его конкретизирует.
Объекты — это экраны, кнопки, модалки или что угодно, с чем может взаимодействовать пользователь.
Действие — это то, как пользователь взаимодействует в приложении: нажатия, просмотры, свайпы, создание, удаление и т. п.
Категория — описание объекта, которое помогает аналитикам определить место срабатывания события в приложении. Описание ограничивается только нашим воображением, но чем проще и лаконичнее, тем лучше.
Обычно список возможных объектов и действий, а также порядок их записи в самом событии определяется заранее и один раз — для удобства работы в дальнейшем.
К примеру, использовать для кнопки три разных названия: button_tap / buttons_tap / pressbutton_tap — идея, мягко сказать, плохая.
В отличие от объектов и действий, категории чаще всего пополняются и обновляются с появлением нового функционала в приложении или устареванием старого. Поэтому задача по их созданию может возникать как при первичном формировании структуры событий, так и значительно позже этого момента.
Удобство универсальности структуры события аналитики
Чаще всего для создания события применяются базовые нотации (способы написания):
all lowercase — page view;
snake_case — page_view;
camelCase — pageView;
Proper Case — Page View;
Sentence case — Page view.
Кроме тех событий, которые были придуманы нами самостоятельно, есть ещё события, которые предоставляются трекерами. Они частично совпадают с тем, что мы хотим фиксировать, но могут не подходить из-за формата их названия, а также из-за отсутствия нужных параметров. В моей практике это, пожалуй, основное ограничение.
Пример для сравнения
Event | Event_properties | |
Название события и параметров по нотации snake_case | main_screen_shown | type = landing_1 |
События и параметр, предоставляемые Amplitude | [Amplitude] Page Viewed | Page URL = https://landing_1.comp.org/ |
Отличия налицо — в скрипте прописывать целиком событие от Амплитуды со скобками — не самое приятное занятие. Также параметр события выглядит менее удобно.
Событие, которое собрано по установленной структуре и с коротким названием параметра, — то, что нужно.
Конечно, не могу не отметить, что документация по событиям аналитики и параметрам должна быть и актуализироваться. Без чёткого и понятного описания того, что означает каждый параметр, нормальной аналитики может просто не получиться.
Выбор способа хранения и документирования всегда остаётся за командой, но часто Google Sheets — простой и удобный вариант для описания всей структуры и определения каждого события и параметра.
Какие события пойдут в БД?
В первую очередь события аналитики должны помогать достигать целей анализа. Нет смысла трекать те события, которые потом никто ни разу не использует. И наоборот, отсутствие событий на основной воронке — полный провал задачи :с
На этом этапе нам чётко необходимо понимать всю структуру проекта и его юнит-экономику. Сложно придумать события без понимания того, как всё работает в приложении/на сайте в реальности.
Поэтому просмотр реального/тестового сайта или просмотр развёртки экранов, к примеру, в Figma — основной способ «потрогать» функционал и наложить уже своё видение будущих событий и их параметров.
При создании можем отталкиваться от следующих вариантов:
Основная воронка
Планируем и создаем события, опираясь на основные шаги воронки, и уже после добавлять вспомогательные события
События по экранам или по порядку
Подходит при работе с Figma, когда перед глазами есть все экраны. Удобно идти по порядку и фиксировать события так, как они могут работать в реальности (если юзер не пропускает ничего и пробует всё на сайте)
Полный сбор данных
Используется, если есть ресурсы и возможность хранить данные и при этом нет четкого понимания, что может пригодиться, а что нет. Также может быть полезно при тестировании новых страниц, когда надо понять, что больше привлекает внимание юзера, а уже после анализа сократить объем собираемой информации.
После создания структуры, документации и, собственно, самих событий аналитики эти данные передаются разработчикам для прописывания событий в коде.
Вуаля — рабочая таблица пополняется событиями и параметрами, которые мы хотим в ней видеть 🙂
Итог
Событийная аналитика — это не только технический сбор кликов. Она сильно завязана на понимании продукта и его целей, сопровождается планированием и предсказанием того, что может быть полезно в будущем для анализа.
Корректный подход к созданию событий аналитики влияет на скорость и качество работы не только самих аналитиков, но и остальной команды.
Еще больше полезных материалов в моем TG-канале. Подписывайтесь и читайте контент по ссылке.