Amplitude для новичков, часть 3

Какие данные отправлять в систему и как называть события

В закладки

Это третья статья из цикла об аналитике в Amplitude. В первой разобрали регистрацию и настройку аккаунта, во второй поговорили о том, как система определяет пользователей. Сегодня погрузимся в события — event на языке Amplitude. Материал поможет лучше понять свой продукт и его структуру, даже если вы работаете с другой системой аналитики.

Что такое события (event) в Amplitude

Событие — это любое явное действие пользователя, которое он может выполнить в продукте, или какая-то деятельность, связанная с пользователем. Например, запуск игры или добавление товара в корзину, пуши, внутренние уведомления.

Какие события отслеживать

Amplitude нужна для принятия обоснованных управленческих решений. Поэтому все данные, которые вы отправляете в систему, надо сверять с ключевыми метриками бизнеса. Только тогда аналитика принесет пользу. В справке Amplitude есть четыре принципа качественной подготовки к запуску аналитики:

— определить важнейшие бизнес-метрики; — измерять только то, что необходимо;

— разобраться, как Amplitude считает и отслеживает пользователей;

— систематизировать события и их свойства в таблице и дать им простые имена.

Определить основные бизнес-метрики

Чтобы определить эти метрики, надо задаться вопросом — какие цели стоят перед бизнесом и что мы хотим узнать о своём продукте или улучшить в нём? Например, продуктовая команда решила улучшить показатели user aquisition (привлечение пользователей), user retention (возврат пользователей) и конверсию в оплаты. Теперь надо понять, какие события помогут изучить эти показатели.

Изображение с официального сайта Amplitude

Измерять только необходимое

Общий принцип — измерять надо только те события, которые на самом деле помогают достичь бизнес-целей. Сначала лучше взять только ключевые, самые важные события. Так продуктовая команда быстрее освоит Amplitude и принципы работы с аналитикой. Большинство клиентов Amplitude «тормозят», когда пытаются понять, что означают те или иные события и где в продукте они срабатывают. Когда команда освоится с базовыми событиями, можно добавить новые.

Систематизировать события и свойства и дать им имена

События надо называть просто и понятно. Если в команде пока ещё нет стандартной схемы именования, можно взять рекомендованный Amplitude формат: глагол + существительное (clicked signup) или существительное + глагол (signup clicked). У Amplitude есть даже шаблоны и примеры таксономии для разных сегментов. Перевёл их и открыл для комментариев — полезно использовать в своих проектах, даже если вы измеряете события в не в Amplitude.

Принципы качественной аналитики в Amplitude

Разделять данные тестов и текущие продуктовые метрики. Для тестов и текущих показателей лучше создать разные проекты — смотрите первую статью цикла. В основной проект новые метрики включайте только после тщательного тестирования.

Ограничивать свойства событий и свойства пользователей. Команда Amplitude не рекомендует добавлять событиям и пользователям больше 20 свойств. Больше 20 свойств нормально измерять и применять в работе практически невозможно — будет только путаница.

Создать кросс-платформенный проект (по возможности). Данные с веба и мобайла лучше считать в одном проекте — но только если сам продукт и таксономия событий в них одинаковые — это поможет понять, как пользователи перемещаются между разными платформами. Но есть случаи, когда стоит создать проекты для каждой версии продукта:

  • Компания предлагает несколько разных продуктов, например «Игра А» и «Игра Б», приложение «Всадник» и приложение «Водитель».
  • Версии продукта и таксономия для разных платформ (например, веб и мобайл) существенно отличаются.
  • Под каждую платформу работает отдельная продуктовая команда.

Цели бизнеса и аналитика

Основа чёткой и глубокой аналитики — это тщательная подготовка перед внедрением. Из-за Плохая подготовка приведёт к пропуску событий, мутному пространству имен, неправильному использованию свойств и другим проблемам. Итог — данные станут менее эффективными и прозрачными.

Вопросы, на которые надо ответить перед созданием таксономии:

  • Над чем работает ваша команда?
  • Какова главная цель бизнеса?
  • Для чего вы хотите использовать Amplitude в первую очередь?
  • Каких бизнес-показателей поможет достичь Amplitude?

Распространенные цели пользователей Amplitude:

  • Определить стратегию развития продукта.
  • Повысить рентабельность инвестиций.
  • Улучшить конверсию.
  • Увеличить retention и LTV.

Поняв, какая цель — главная, надо разобраться, как к ней идти, и установить внятные KPI.

Пример KPI для увеличения конверсии

  • Улучшить конверсию при онбординге.
  • Улучшить конверсию оформления заказа.

Цели и KPI необходимо определить до того, как начнётся работа над таксономией событий. Тогда в систему будут поступать только те данные, которые помогут достичь поставленных бизнес-показателей.

Выбор событий для отслеживания

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

Когда вы определите ключевое событие, выясните, какие ещё категории событий связаны с ним и помогут изучить его лучше. Ведь недостаточно знать, сколько людей оформили заказ или забронировали сеанс, надо понимать, какие факторы заставили их сделать это.

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

Делите события на категории — так аналитика станет понятнее. Плюс категории событий помогут лучше понять продукт и его структуру. Так вы сможете определить список событий для отправки в Amlitude и правильно организовать их в интерфейсе системы. Важно, чтобы каждая категория вела хотя бы одной бизнес-цели или KPI.

Примеры категорий

  • Регистрация.
  • Адаптация.
  • Оформление заказа.

Когда вы составите список категорий, разложите каждую из них на отдельные события. Начинайте с самых приоритетных событий — то есть тех, которые больше остальных связаны с бизнес-целями и KPI.

Ещё раз: отслеживать все события в продукте — плохая стратегия. Аналитика станет зашумленой, а таксономия — сложной для понимания. К тому же почти все команды ограничены в ресурсах и времени. Поэтому стартуйте с 20–30 событий. Когда их немного, легче сфокусироваться на каждом и принимать обоснованные управленческие решения.

Циклы измерений в Amplitude

Основа отслеживания событий в Amplitude — итерации, повторяющиеся циклы. Сначала внедряем и отслеживаем самые важные события и получаем ответы на главные вопросы, потом добавляем новые события и отвечаем на следующий круг вопросов — и так далее. Это поможет команде подружиться с данными и мягко погрузиться в аналитику.

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

Примеры важных вопросов

  • Почему некоторые пользователи не завершают процесс онбординга?
  • Как много пользователей конвертируются в оплаты?
  • Сколько раз пользователи выполняют событие А, а сколько — событие Б?
  • Что делают новые пользователи после установки приложения?
  • Какие группы пользователей привлеклись фичей В?

Подсказка: главные события в основном совпадают с вопросами о бизнесе, на которые команда уже ищет ответы. Например, чтобы понять действия самых вовлеченных пользователей и как они «бьются» с удержанием, важно отслеживать конкретные события: «добавить в корзину», «начать игру», «воспроизвести». События типа обновления страницы настроек обычно не так существенны и замерять их можно уже в будущих итерациях.

Критический путь (critical path)

У каждого приложения есть критический путь (critical path), по которому должен пройти пользователь. Критический путь — это последовательность действий пользователя, которые согласуются с целью продукта. Все события из критического пути обязательно должны отправляться в Amplitude.

Пример критического пути в e-commerce

Поиск —> Просмотр товаров —> Добавление в корзину —> Оформление заказа —> Подтверждение заказа

Критический путь игрового приложения может начинаться с регистрации и туториала.

Изображение с официального сайта Amplitude

Весь процесс с картинки можно разбить на ряд событий: «Открытие приложение», «Регистрация — заполнение личной информации», «Регистрация — выбор аватара», «Регистрация — завершение», «Обучение — начало» и «Обучение — просмотрено».

Изображение с официального сайта Amplitude

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

События, связанные с просмотром страниц и экрана

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

Плюсы просмотра страниц

Просмотры страниц помогают понять, как пользователи перемещаются между страницами. Имейте в виду, что просмотр любой страницы (экрана) — это всегда клик или «посадка» пользователя на страницу из какого-то источника. Например, есть два варианта оформления событий, если вы захотите узнать, как пользователь попал на страницу продукта:

  • Событие: «оформление: отправка заказа».
  • Событие: «просмотр страниц: заказ».

То есть просмотр страницы просто показывает, что пользователь выполнил какое-то действие внутри продукта.

Минусы просмотра страниц

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

Как отслеживать просмотры страниц / экранов

Структур событий — просмотров страниц — зависит от вопроса, на который вы пытаетесь найти ответ.

Вариант 1. Одно событие для нескольких страниц

В таком варианте в систему отправляется одно событие, но с разными свойствами.

  • Событие: «просмотр страницы завершенной игры».
  • Свойство события: ‘level’ = ‘1’.
  • Событие: «просмотр страницы завершенной игры».
  • Свойство события: ‘level’ = ‘2’.

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

Вариант 2. Независимые события для каждой страницы

  • Событие «просмотр страницы продукта».
  • Событие «просмотр страницы с корзиной».
  • Событие «просмотр страницы оформления заказа».

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

Мы рекомендуем группировать подобные просмотры страниц в события, которые можно объединить в одно целое (например, «загрузка страницы сведений о продукте», «загрузка страницы онбординга»). Этот метод дает вам гибкость обоих подходов и позволяет быстро смотреть и понимать пути пользователя без необходимости углубляться в специфические свойства событий, в то же время имея возможность использовать некоторую форму агрегации при анализе данных.

Примеры

  • Событие «просмотренная главная страница»
  • Событие «просмотренная страница продукта»
  • Свойство события: 'product id' = '129092'
  • Свойство события: 'category' = 'Women's'

Как правильно называть события

Чтобы работать с данными было удобно, нужна понятная и прозрачная таксономия событий. Поэтому когда вы составите список событий и категорий, продумайте их номенклатуру. Хорошие названия событий — описательные. Они обозначают то, что происходит. Хороший синтаксис: глагол в настоящем времени + существительное с пробелами, набранные строчными буквами (всё на английском, конечно).

Примеры названий

  • Событие: 'submit shipping address' (заполнение адреса доставки).
  • Событие: 'submit order' (отправка заказа).
  • Событие: 'land on order success page' (переход на страницу подтверждения успешного заказа).

Элементы названия

Имя события можно начать с категории. Такая структура имён упрощает поиск событий и повышает прозрачность. Если пользователь Amplitude не знает, какие события находятся в процессе с оформлением заказа, он просто введёт «checkout» и быстро просмотрит результаты выдачи.

Используйте последовательную систему имён — во всех событиях должен быть единый синтаксис, единая логика.

Рекомендации по пространству имен от команды Amplitude

  • Используйте только строчные буквы. Это исключит ошибки при измерениях. Amplitude чувствительна к регистру и 'Checkout Submitted Order' и 'Checkout submitted order' для неё — разные события.
  • Используйте глаголы настоящего времени. Это минимизирует путаницу.

Не так важно, какой синтаксис вы выбрали — главное, последовательно придерживаться его во всех именах.

Длина имен событий

Делайте имена событий короткими — тогда данные будет легче читать и понимать. Распространенная ошибка — это излишняя детализация. Из-за неё появляются очень длинные, сложные имена событий. Бороться с ней просто — выносите избыточные элементы в свойства события и в категории. Например, есть событие 'game: completed game: level 1'. Вот как его можно реструктурировать:

  • Категория события: 'game'.
  • Событие: 'completed game'.
  • Свойство события: 'level' = '1'.

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

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

P.S. Большая часть — переведенные, переработанные и перекомпонованные инструкции и гайды самого Amplitude.

{ "author_name": "Тимур Тукаев", "author_type": "self", "tags": [], "comments": 0, "likes": -2, "favorites": 12, "is_advertisement": false, "subsite_label": "services", "id": 128257, "is_wide": false, "is_ugc": true, "date": "Tue, 19 May 2020 18:02:31 +0300", "is_special": false }
Право
Товарные знаки для тех, кто ведёт бизнес в интернете: защищаем домен, управляем отзывами и контролируем конкурентов
Казалось бы, регистрация брендов в Роспатенте — это история про заводы и предприятия: вот наша одежда, еда или…
Объявление на vc.ru
0
Комментариев нет
Популярные
По порядку

Прямой эфир