9 советов по настройке аналитики приложения

Современные аналитические системы в большинстве своём работают на основе событий (или ивентов). Событие – это любое действие пользователя в приложении, зафиксированное аналитической системой. Чаще всего аналитики выбирают такие события:

• регистрация пользователя или его первый визит;
• вход в приложение;
• платёж (будь то за виртуальную или за реальную валюту).

Этих трёх событий достаточно, чтобы рассчитать метрики удержания пользователей, их активности и монетизации, – то есть ответить на 80% вопросов к аналитике. Но достаточно ли вам этих 80%?

Большинство проектов отвечает “нет”, и это правильно. Для детального изучения пользователей необходима информация о других событиях: клик по кнопке, бой в игре, прохождение туториала и так далее. Такие события называются кастомными, и они настраиваются отдельно для каждого приложения.
Настройка кастомных событий – очень важная задача, потому что правильно настроенные события упрощают работу с продуктом и демонстрируют проблемы, которые испытывает пользователь. Система событий помогает найти узкие места и точки роста в приложении, поэтому мы решили поделиться несколькими советами о том, как же настроить сбор данных для аналитики.

Совет 1. Не откладывайте настройку событий на потом.

Часто получается так: сначала мы выложим приложение в магазин, посмотрим, как пойдёт, а затем, если что, добавим отслеживание событий. Не надо так! Итерация добавления событий в приложение – это небыстрый процесс, учитывая обновление в сторе, и лучше запустить его еще на этапе разработки. Иначе, если показатели после запуска будут так себе, вы не сможете сделать правильные выводы и вовремя внести изменения в приложение.

Во время разработки вы заранее знаете ключевые точки, через которые пройдет пользователь, – так зачем же оттягивать добавление ивентов на потом?

Совет 2. Используйте параметры события.

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

Настройка параметров позволяет сократить количество передаваемых событий. Например, вместо событий Battle_Win и Battle_Lost можно передать событие Battle_Finish и параметр Result (0/1) как его итог. Такой подход сильно упростит дальнейший анализ.

Совет 3. Используйте глобальные параметры.

В ивенте можно передавать параметры не только события, но и пользователя. Например:

• Дата регистрации. Впоследствии вы сможете делать когортный анализ: сравнивать поведение пользователей, зарегистрированных в разное время;
• Уровень. Это поможет сбалансировать сложность уровней, количество выдаваемой валюты и т.д.;
• Источник трафика. Можно создавать воронки по пользователям из разных источников. Например, сравните воронку активации для пользователей, пришедших из Facebook и Google;
• Метка платящий / неплатящий. Вы сможете разделить анализ поведения платящих и неплатящих пользователей, и это ответит на вопрос, почему одни платят, а другие нет. Может быть, валюты слишком много? Может быть, техническая ошибка на этапе совершения платежа?

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

Совет 4. Заранее нарисуйте воронки.

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

Совет 5. Анализируйте первую сессию максимально детально.

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

Скриншот взят из системы devtodev ^[1].

Совет 6. Только подтверждённые покупки.

Очень распространённая ошибка: если пользователь нажимает Buy, приложение отсылает в систему информацию о покупке. Но ведь он может затем отменить платёж, у него может не оказаться средств на карте и т.д. В итоге, данные с сервера и из системы отличаются, а неправильные данные – это ещё хуже, чем их отсутствие.

Совет 7. Дублируйте информацию в две системы.

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

Совет 8. Тестировать, тестировать и ещё раз тестировать.

Как мы уже говорили, добавление событий в приложение – дело небыстрое, к нему стоит подойти основательно. Забыли передать один параметр – придётся ждать месяц, пока он будет добавлен. И ещё один месяц, пока все пользователи обновят приложение.

Лучше сделать всё заранее. Запишите хотя бы собственную сессию и посмотрите, правильно ли передаются все события, не забыли ли вы какие-нибудь параметры, нет ли каких-то очевидных ошибок.

Совет 9. Подойдите к системе событий структурно.

Часто бывает, что событиями обвешивают буквально каждый управляющий элемент на каждой форме. В итоге в аналитике существуют сотни наименований событий, из которых в отчёты реально попадут лишь 5-10. К тому же, большинство систем аналитики строят свой прайсинг на основании data points. Каждая строчка, которая передаётся в систему аналитики, – это data point. Событие – это data point. И такой бездумный подход может обойтись вам достаточно дорого.

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

Настройка событий – это серьезная задача при управлении проектом, потому что именно трекинг кастомных событий позволяет находить проблемные места и зоны роста. Есть хорошие алгоритмы для определения структуры событий, и мы поговорим о них на вебинаре “События и воронки: как не упустить самое важное” ^[2], который пройдет 16 марта в 18:00 Мск. Мы разберём реальные кейсы построения структуры событий проекта, научимся правильно формировать и трактовать воронки, чтобы не упускать пользователей из рук. Присоединяйтесь!

Автор: devtodev

Источник ^[3]