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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

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

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