Всем привет! Мы команда Dev’s Battle. В этом посте расскажем о том, как мы создавали для нашего продукта (MMO RPG игра в телеграм) собственную систему аналитики
Зачем проекту аналитика?
Цифровой продукт без аналитики - это как строитель, работающий в полной темноте. Аналитика позволяет команде понимать, как именно пользователи используют продукт, а также вводить нормальную систему продуктовых тестов. Ведь в конечном итоге - весь бизнес очень просто раскладывается на метрики, конверсии и другие показатели.
Если отойти от лирики, то мы решали одну простую задачу - понять, что происходит с продуктом и куда его дальше развивать. Аналитика должна была помочь нам определить наши слабые места, увидеть что интересно пользователям, а что нет. А главное, понять как нам монетизировать наш проект и насколько мы далеко от сходимости юнит экономики.
Мы пытались реализовать все через стандартную Google Analytics, но очень быстро поняли, что это решение нам не подходит. Дело в том, что у GA есть своя версия для веб-сайтов и для мобильных приложений, а мы со своим телеграм ботом и его архитектурой не пролезали ни под одну из этих категорий.
Поискали и попробовали также пару готовых библиотек аналитики для телеграм ботов, но и они нас не порадовали. Функционал был слишком узкий, а у нас ведь полноценная игра, нам и за игровой экономикой надо смотреть и за онбордингом, да и за кучей других показателей.
В итоге было принято решение делать все самим. Ну мы и начали...
Какие инструменты использовали?
Честно говоря, к моменту когда мы начали всерьез разрабатывать аналитику у нас уже были первые дашборды, накиданные нашим разработчиком. Толку от них было мало, но прирост пользователей показывали и уже было хорошо.
Для системы аналитики мы выбрали Grafana . Данное решение возможно будет победнее, чем дашборды в Tableau, но зато полностью бесплатное, супер гибкое и кастомное (с помощью запросов PostgreSQL и небольших скиллов в визуализации можно сделать очень приемлемые дашборды).
Cтек для аналитики: Grafana, PostgreSQL, Docker
Также нам пришлось немного перекроить базу данных, начать записывать буквально каждое действие наших пользователей и сохранять их для будущего анализа.
Как создавали систему дашбордов?
Первое с чем мы столкнулись набросав нужные нам данные - данных стало слишком много. Аналитика конечно хорошо, но она должна помогать принимать решения, а точно не отвлекать и не запутывать.
Вот так выглядели первые драфты, куча данных и полное непонимание, что с ними делать. Именно тогда мы задумались о том, как выстроить систему дашбордов, чтобы все было просто и понятно. Решение было следующее
Система дашбордов 2.0 (скрины далее)
1. Main stats - сюда мы вынесли основные для нас метрики: количество активных игроков, DAU, WAU, Retention, Рефферальные ссылки и воронку онбординга с конверсиями по этапам
2. Gamenomics - сюда снесли все метрики, касающееся игровой экономики: количество денег в игре, статистика по покупке игровых предметов, распределение пользователей по уровням и компаниям
3. Marketing&Sales - третий дашборд вобрал в себя данные по маркетингу, статистике переходов, продаж и конверсий. Его мы еще дорабатываем по мере развития монетизации продукта.
Какие показателя для нас самые важные?
Этот вопрос очень хороший, и надеемся, что ответ на него поможет многим другим командам разработчиков. Наш набор ключевых метрик вобрал в себя, как исконно игровые метрики, так и стандартные показатели для любых цифровых продуктов.
Кстати если эту статью все таки читают продукты, проджекты и бизнес аналитики, поделитесь своими идеями, что нужно добавить или вынести из этого списка? (Будем супер благодарны, да и надеемся, что аудитория VC это оценит)
Итак, наша заветная семерка:
1-Day Retention. Процент вернувшихся пользователей — ключевой показатель работоспособности мобильных игр. Retention rate в принципе один из фундаментальных показателей в управлении продуктом.
1-Day Retention показывает процент пользователей, которые возвращаются в нашу игру на следующий день после первого запуска. Так, например, если удержание на второй день составляет 50 %, это означает, что 50 % новых пользователей зашли в игру на второй день.
Показатель показывает на сколько игра цепляет пользователя и служит прямым индикатором жизнеспособности продукта
N-Day Retention. Процент вернувшихся пользователей в зависимости от количества дней. Мы считаем для 1, 3, 7, 14 и 28 дня. Отображаемый в виде воронки данный показатель отлично показывает в какой момент пользователю становится скучно.
В нашей случае, показатель удержания снижается от 46% на 1 день до 15% через 28 дней игры, что уже является неплохим показателям для старта, хоть работать конечно есть над чем!
DAU/WAU. Метрики пользовательской активности за определённый период: за день (daily active users — DAU), за неделю (weekly active users — WAU). Эти метрики показывают нам число уникальных игроков, которые в течение конкретного временного промежутка хотя бы раз проявили активность в нашей игре.
Как правило, эти метрики используют разработчики мобильных приложений. Для них это своеобразная мера успешности продукта. На основе DAU/WAU/MAU определяют степень «привязанности» к приложению и планируют стратегию дальнейшего продвижения.
Onbording Funnel (воронка онбординга). Это не совсем метрика, скорее набор конверсий между этапами в процессе онбординга нового пользователя. Тем не менее, для нас данный показатель оказался крайне ценным.
Воронка показывает нам сколько пользователей мы теряем, пока знакомим нового юзера с продуктом. Для расчета мы выделили основные этапы онбрдинга и начали смотреть сколько людей проходит через каждый этап.
Кстати благодаря этой воронке мы увидели, что теряем 60% пользователей на обучении и внеся пару простых правок сумели понизить показатель до 27%
Wealth distribution - показывает нам распределение игровой валюты между игроками. Очень занятная метрика, которая говорит о балансе в игре или об его отсутствии. Распределение мы смотрим по персентилям игроков - % денег который принадлежит топ 1%, 5%, 10% и 20% игрокам.
Кстати сейчас, 1% богатейших игроков принадлежит 26% всех денег. Наверно, это не очень хорошо, но зато цифра очень близка к реальному миру (фан факт 1% жителей США владеют 32% всего богатства в стране. Так что у нас тут симулятор рыночной экономик развивается ))
Conversions / Payments по когортам - классические показатели монетизации. Считаем, как % от новых пользователей за неделю, которые воспользовались платными функциями игры.
Считать по когортам очень удобно, ведь пользователь не всегда совершает покупку в первый день. Таким образом можно свести расходную и доходную часть и понять находишься ли ты в плюсе или наоборот зря тратишься на маркетинг.
REF Count - наша кастомная метрика, которая позволяет отслеживать работу рефферальной системы. Наша игра бесплатная (Freemium) и мы делаем большую ставку на виральность и шеринг, а с помощью UTM-меток можем отслеживать работоспособность всей этой системы.
Для нас такая система была открытием и вот сейчас достойные 3% наших игроков являются условно бесплатными, пришедшими по рекомендации от других пользователей.
Это не все метрики, что мы собираем, но сейчас для развития проекта считаем перечисленные наиболее значимыми.
Как аналитика помогает нам сегодня?
Мы наконец-то перешли от хаотичных тестов и движения по наитию к реальным продуктовым гипотезам и решениям на основе данных. Конечно, не все фишки мы успели реализовать (например, все еще ленимся наладить нормальную систему А/Б тестов), но практика управления проектом уже выросла до новых высот.
Мы начали активнее генерить новые гипотезы, видеть слепые зоны и проблемные места, а также результаты от внесенных измненений.
Сейчас мы активно развиваем проект дальше, и несмотря на то, что еще находимся на ранней стадии, уже считаем что сделали достаточно большой продукт в рамках того, что есть сегодня в Telegram.
А главное, этот продукт работает! И уже помогает сотням начинающих разработчиков развивать свои hard skills в программировании.
P. S.Если захотите попробовать нашу игру сами — вот ссылочка. Будем рады вашим комментам, идеям и предложениям
web3_Venture
Здравствуйте. Подскажите по параметрам где вы считали "оконные" показатели изменения в день / неделю / месяц например ( +45% / +12% / -34% ). У вас получается просто был запрос postgree с lead / lag который выполнялся каждые 5 секунд (ну или сколько у вас стоит в настройках графаны).
Если так , то выглядит как очень сильная нагрузка на DB.
seylanov Автор
Автообновление можно отключить, мы так и сделали
Сейчас запросы выполняются только тогда, когда кто-то из команды хочет посмотреть дашборд