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.

0
16 комментариев
Написать комментарий...
Татьяна Путинцева

спасибо за статьи. прочитала все 3 части.
а будет ли статья как технически настраивать события в Amplitude?

Ответить
Развернуть ветку
Тимур Тукаев
Автор

Надеюсь за сентябрь закончить

Ответить
Развернуть ветку
DM Foundation

Сентябрь закончился😇

Ответить
Развернуть ветку
Ксения Синякова

Тимур, огромное спасибо за статьи! Я тоже очень жду следующую часть, особенно интересно про подбор событий для отслеживания.

Ответить
Развернуть ветку
Тимур Тукаев
Автор

попробую на выходных доделать

Ответить
Развернуть ветку
Pavel

Ждём)

Ответить
Развернуть ветку
Olha Pekarska

Очень сильно жду 4ю часть! Даже подписалась на ТГ канал!!!))))

Ответить
Развернуть ветку
Artem Prokopenko

Спасибо за статью. Ждемс 4 часть

Ответить
Развернуть ветку
Савелий Прасолов

Очень ждал эту статью. Возможно она уже готова?)

Ответить
Развернуть ветку
Kovtun Dmitry

Ждём 4ю часть

Ответить
Развернуть ветку
sergiu ursu

все 3 части очень важны и интересны
хотелось бы еще побольше про логику сбора информации из разных источников

Ответить
Развернуть ветку
Султан Мухтаров

Приветствую! 

Спасибо за статьи!

А  подскажите, пожалуйста, есть вопрос по поводу стандартного события New User.

Как я понимаю, это событие инициируется, когда в амплитуду попадает юзер, у которого user_id или хеш не совпадает ни с одним, что есть до этого. В этот момент ему присваивается новый user_id и инициируется событие New User. Тогда по логике, Uniques и Events Totals должны быть одинаковыми (так как один юзер не может быть создан два раза).
Но у меня эти значения отличаются. Events Totals в 10 раз больше Uniques. В чем может быть проблема? Сможет мне кто-нибудь помочь?)

Пример уникальных и всего ивентов приложил.

Ответить
Развернуть ветку
Тимур Тукаев
Автор

Удобнее всего задать вопрос в русскоязычном чате по Amplitude: https://t.me/amplitudeweek. Там много экспертов и удобно общаться.

Ответить
Развернуть ветку
Султан Мухтаров

спасибо!

Ответить
Развернуть ветку
Kirill Gugaev

Благодарю за цикл статей. Очень полезно и по-полочкам. 
Взяли Amplitude в стек благодаря вам)

Ответить
Развернуть ветку
Тимур Тукаев
Автор

спасибо за теплые слова)

Ответить
Развернуть ветку
13 комментариев
Раскрывать всегда