Пользовательское событие в мобильной аналитике — индикатор, позволяющий зафиксировать то или иное действие пользователя в приложении.
Стандартные пользовательские события - «регистрация», «авторизация» или «покупка» — используются для расчёта основных метрик (удержания, конверсии, LTV) и обычно не вызывают у владельцев приложений вопросов.
В то же время для каждого приложения можно настроить ряд кастомных событий: «прохождение уровня» (для игры), «появление нового друга» (для соцсети), «просмотр определённой категории товаров» (для e-commerce) и т.п.
Такие события можно сравнить с маячками, расставленными по всему пользовательскому пути. Именно они эффективно подсвечивают проблемы, помогают выявить точки роста и увидеть реакцию аудитории на изменения в продукте.
В этой статье мы дадим вам 5 полезных советов, как настроить кастомную разметку так, чтобы собирать наиболее полную и полезную информацию о взаимодействии аудитории с продуктом.
Помните, что отслеживание пользовательских событий — всего лишь инструмент. Поэтому, при планировании разметки, всегда отталкивайтесь от вопросов, ответы на которые хотите получить.
Это могут быть, например, вопросы про закономерности в пользовательском поведении:
Или вопросы про обновления продукта:
После формулировки пула вопросов, вы сможете подобрать для каждого из них соответствующие пользовательские события. Например, чтобы вычислить наименее популярные разделы приложения, нужно будет настроить несколько событий «посещение раздела X».
В процессе сбора данных о действиях пользователей надо не только думать о целях дальнейшей аналитики, но и учитывать логику работы приложения. Невозможно разметить события, не заданные на этапе разработки.
Например, вы хотите отследить связь между количеством покупок и игровым прогрессом пользователей. Эта задача подразумевает, что в логике приложения предусмотрен как минимум:
Если всё это у вас уже есть, можно настроить разметку и попытаться найти закономерность. В противном случае можно попросить разработчиков настроить нужные события внутри приложения и получить более полную картину.
Не стремитесь отслеживать абсолютно всё. Избыток информации не всегда идёт на пользу аналитике, поскольку с большими объёмами данных иногда просто неудобно работать.
Чтобы не запутаться в миллиарде событий, мы рекомендуем начинать разметку с формулировки вопросов. Это помогает сконцентрироваться на данных, важных для достижения ваших конкретных целей.
События внутри приложения уже создали разработчики. Ваша задача — сопоставить каждый из целевых вопросов с этими событиями и решить, какую информацию отправлять через SDK в аналитическую систему.
Не всегда достаточно знать, что то или иное событие произошло. Зачастую важно понимать при каких именно обстоятельствах. Для этого к любому событию можно добавить параметры — особые переменные, позволяющие передавать необходимую информацию.
Например: событие «завершение уровня» — параметр «количество заработанных очков»; событие «отмена заказа на этапе оформления» — параметр «стоимость доставки».
Более того, некоторые события без параметров просто теряют смысл. Так, например, «просмотр категории товаров» вряд ли может привнести вклад в аналитику без уточнения названия категории.
При этом использование параметров позволяет сократить число необходимых событий. Благодаря параметру «количество заработанных очков», вам не нужно настраивать отдельные события «завершение уровня со счётом 0», «завершение уровня со счётом 1» и т.д.
У каждой аналитической системы есть свои сильные и слабые стороны, преимущества, ограничения и просто особенности, которые нужно иметь в виду при проектировании разметки.
Когда вы выбираете аналитическую систему, не забудьте сначала ответить на такие вопросы:
Всегда лучше подробно ознакомиться с инструментом и его возможностями заранее, чем тратить время на исправление ошибок в процессе работы.
Не менее важно, чтобы вы говорили на одном языке с представителями аналитической платформы.
Нередки ситуации, когда владелец приложения использует один термин, а система аналитики — другой. Например, один специалист может относить к событию «установка» только установку, а другой — установку и первый запуск приложения.
Большинство аналитических систем имеют собственную документацию и техническую поддержку, которые помогут вам разобраться в терминологии и метриках и убедиться, что вы говорите об одном и том же.
Некоторые системы аналитики предоставляют возможность трекинга событий на разных платформах: например, если пользователь совершает одно и то же событие с разных платформ (iOS, Android, Web).
Если вы выбрали мультиплатформенную систему аналитики, убедитесь, что при разметке событий в системе названия одних и тех же событий для разных платформ совпадают: это важно для анализа продуктовой воронки.
Например, если прохождение 5-ого уровня игры для платформы iOS помечено как “прохождение уровня 5”, а для Android - “завершение 5-ого уровня”, то при построении автоматизированной воронки вам придется выбирать два разных события или строить две разные воронки.
Подробнее о построении продуктовой воронки можно прочитать здесь.
Представим, что у нас есть приложение, для которого мы хотим отследить пользовательский путь и выявить проблемы с функциональностью.
Пусть это будет игра, в которой предусмотрены функции регистрации и авторизации, уровни с разной игровой механикой и несколько вариантов in-app транзакций.
Пройдём по всем пяти шагам, описанным выше.
В первую очередь нам необходимо сформулировать конкретные вопросы, на которые мы, в итоге, собираемся получить ответы:
Ещё раз критически посмотрим на получившиеся вопросы и убедимся, что логика работы приложения позволяет на них ответить.
События установки, регистрации и авторизации наверняка уже заданы разработчиками. А вот техническую возможность отслеживания покупок и трекинга прохождения уровней нужно проверить и, при необходимости, доработать.
Мы будем отслеживать только те события, которые помогут ответить на поставленные вопросы, то есть, в итоге, улучшить пользовательский опыт.
Чтобы ничего не упустить, сопоставим каждый вопрос с релевантными событиями:
Параметры событий однозначно понадобятся нам как минимум в двух случаях:
Прежде чем приступать к разметке, мы должны выбрать аналитическую систему, особенности которой отвечают нашим задачам.
Главное требование к платформе — внутри неё должен быть предусмотрен трекинг событий. Всё остальное зависит от специфики продукта. Для нашего примера принципиальны широкие возможности для работы с параметрами (возможность передавать параметры, лимит на количество параметров, допустимые форматы параметров), но другие приложения могут обходиться и без них.
После этого мы внимательно ознакомимся с документацией выбранной аналитической системы и выясним, как называются и реализуются все интересующие нас события.
Например, для «in-app покупки товара» может использоваться термин «платёж» или «транзакция». Или такого встроенного события может вообще не быть в системе. Тогда его можно сделать кастомным и назвать на своё усмотрение.
Трекинг пользовательских событий — важная для мобильной аналитики технология, реализованная в большинстве современных аналитических систем.
Чтобы собранные данные приносили вашему приложению как можно больше пользы, действуйте последовательно и помните о следующем:
Ищете подходящую систему аналитики для трекинга пользовательских событий?
В MyTracker количество кастомных событий и параметров не ограничено. Размечайте и анализируйте каждый шаг — от регистрации и просмотра конкретного экрана до добавления в корзину и совершения заказа. Подробнее о возможностях трекинга в MyTracker можно прочитать в нашей статье.
