Фундаментом аналитики является сбор данных. Настройка аналитики мобильного приложения включает в себя интеграцию SDK системы аналитики в мобильное приложение, проектирование структуры ивентов и их расстановку внутри приложения. Неправильно настроенный сбор данных для аналитики оставит вас без приборов в работе с вашим продуктом, либо же обеспечит неверными данными, что, с моей точки зрения, еще хуже, чем отсутствие данных.
В этой статье я расскажу о том:
- Какие ошибки часто допускают при настройке аналитики мобильных приложений;
- Как я обычно подхожу к процессу встраивания аналитики в мобильное приложение;
- Какие хаки помогают мне эффективнее использовать данные.
Обратите внимание: материал опубликован в июне 2014 года.
Внутренняя аналитика мобильных приложений, или зачем нужны ивенты
Аналитика мобильных приложений обычно строится на ивентах. Вы шлете в систему аналитики ивенты (события), а система предоставляет интерфейс для работы с этими данными.
Ивент — любое действие, которое совершает пользователь, например клик на кнопку, открытие определенного экрана, добавление комментария, трата или покупка внутренней валюты. Когда происходит это событие, то приложение отправляет ивент на сервера системы аналитики. Вместе с ивентами обычно передаются ряд обязательных параметров (идентификатор пользователя, версия приложения, модель девайса, прочие служебные параметры), а также ряд дополнительных кастомных параметров, которые вы определяете сами (например, количество дней с момента начала использования приложения, кол-во запусков приложения и тд).
По сравнению со стандартными для веба системами аналитики («Яндекс Метрика» или Google Analytics) описанный подход оказывается более затратным на этапе встраивания и настройки системы аналитики, но зато позволяет отвечать на существенно большее количество вопросов.
Почитать про разные системы аналитики для мобильных приложений можно в сравнительном обзоре Mixpanel, Flurry, Google Analytics, Localytics и в обзоре системы аналитики Kontagent (теперь Upsight). Подробнее о том, какие вообще бывают системы аналитики, можно прочитать в обзоре существующих аналитических решений для мобильных приложений.
Ошибки при настройке аналитики в мобильном приложении
Обычно проектированию структуры ивентов и настройке аналитики уделяется мало времени и внимания при разработке мобильных приложений. Неправильно или некачественно настроенная аналитика сильно осложняет последующую работу с продуктом, а порой оставляет полет вашего продукта без каких-либо навигационных приборов.
Чтобы глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в GoPractice.
→ Программа «Профессия: продакт-менеджер» поможет вам перейти в продакт-менеджмент из смежной роли или индустрии.
→ В «Симуляторе управления продуктом на основе данных» вы научитесь принимать решения с помощью данных и исследований при создании продукта.
→ В «Симуляторе управления ростом продукта» найдете пути управляемого роста и масштабирования продукта.
→ В «Симуляторе SQL для продуктовой аналитики» поймете, как применять SQL для решения продуктовых и маркетинговых задач.
→ В мини-симуляторе «Генеративный AI для продакт-менеджеров» вы научитесь применять генеративный AI для создания продуктов, решив практический бизнес-кейс.
→ В «Симуляторе управления ML/AI-проектами» научитесь применять технологии машинного обучения с пользой для бизнеса.
→ Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.
→ Еще больше ценных материалов и инсайтов — в телеграм-канале .
Я заметил следующие распространенные ошибки при настройке аналитики:
1) Настройка аналитики откладывается до последнего момента. Но перед релизом и помимо аналитики, которая в этот момент не кажется особо важной частью, образуется большой стек всевозможных задач. В итоге времени на продумывание того, какие данные следует собирать и зачем, не остается.
2) Иногда ивентами завешивают каждый элемент и каждое действие в приложении, безотносительно полезности и применимости этой информации. Такой подход тоже опасен, так как появляется куча ненужных данных, а их структура далеко не всегда подходит для последующей работы с ними.
3) Случается и другая крайность. Ивенты вешают только на наиболее важные места в приложении (по мнению команды на момент релиза), а потом оказывается, что собираемые данные не позволяют получить ответы на ключевые вопросы.
4) Еще одна распространенная ошибка. При настройке аналитики не учитывают ограничения, накладываемые функциональными возможностями используемой системы аналитики, что опять же делает сложным или вовсе невозможным получение ответов на интересующие вопросы после запуска продукта.
Все описанные ошибки произрастают из неправильного подхода к настройке аналитики. Аналитика призвана отвечать на вопросы, поэтому логично сначала сформулировать набор интересующих вопросов, а потом на их основе сформировать структуру ивентов, которые позволят на эти вопросы ответить, а не наоборот.
Настройка аналитики мобильного приложения. Алгоритм.
Шаг 1. Что хотим знать
Сначала необходимо определиться с тем, на какие вопросы вы хотите найти ответы с помощью собираемых данных, какие гипотезы вы хотите доказать или опровергнуть. Представьте, что приложение уже запущено, и пришло время провести анализ. Что вы захотите узнать, что проверить?
Чтобы не потерять важные вопросы, я рекомендую использовать следующий подход. Выпишите основные сценарии использования вашего приложения, а затем задавайте интересующие вопросы, представляя, как пользователь проходит через эти сценарии.
Финальный список вопросов обычно состоит из стандартной части, которая подходит почти для любого приложения, а также из вопросов, специфичных для каждого конкретного приложения.
Стандартная часть обычно выглядит примерно так:
- Где люди отваливаются на туториале?
- Насколько туториал эффективен (какая часть пользователей обучились по его итогам, а не просто прокликали его)?
- Сколько людей продолжают использовать приложение спустя 1, 7, 14 дней?
- Какая доля новых пользователей заходит в магазин или видит продающий экран?
- Какова конверсия в покупку? В повторную покупку?
- Сколько стоит привлеченный пользователь?
- Сколько мы зарабатываем с пользователя на 1, 7, 14, 30 день?
- Как отличаются ответы на предыдущие вопросы в зависимости от платформы, страны, источника трафика, типа девайса?
После самостоятельного составления списка вопросов имеет смысл спросить других участников команды о том, что им интересно узнать о взаимодействии пользователей с продуктом. Если пропустить эту часть, то может получиться, например, что вы включили в список ключевые вопросы по геймдизайну, но вопросы про интерфейсные решения остались вне вашего внимания.
Итогом этого шага является список вопросов, который представляет собой структуру исследования приложения.
Шаг 2. Какие ивенты и с какими параметрами нужны, чтобы ответить на вопросы из шага 1
Теперь у вас есть понимание того, что конкретно вы хотите знать, поэтому можно переходить к проектированию структуры ивентов и их параметров. Подойдите к этому процессу итеративно. Быстро составьте первую версию списка ивентов и переходите к следующему пункту. К этому пункту вы еще вернетесь.
Шаг 3. Позволит ли используемая система аналитики ответить на вопросы из шага 1 со структурой ивентов из шага 2?
Дело в том, что разные системы аналитики обладают разным функционалом, разными возможностями и разными ограничениями, и все эти особенности надо учитывать еще на этапе встраивания аналитики в приложение. Особенности вашей системы аналитики вам, скорее всего, хорошо знакомы, но я все-таки приведу несколько примеров, чтобы было понятнее, о чем идет речь.
Пример 1
Во Flurry есть ограничение на количество параметров, которые можно передавать с ивентом (не более 10 параметров у конкретного ивента). Поэтому при создании структуры ивентов и параметров вам надо держать эту особенность в голове. В Kontagent параметров ивентов по сути нет (подробнее тут), поэтому всю содержательную информацию придется поместить в название ивента.
Пример 2
Во Flurry при составлении воронок нельзя указывать параметры ивентов. Поэтому если вы захотите построить воронку движения пользователя по уровням в вашей игре, то придется для каждого уровня заводить отдельный ивент. Несмотря на то что удобным и логичными кажется заведение специального ивента, отправляемого при прохождении уровня с параметром level_number, если вы хотите иметь воронку прохождения игры по уровням и при этом используете Flurry, это решение вам не подойдет.
Пример 3
Если вы используете Mixpanel и хотите интегрировать его с AppsFlyer (система для определения источников трафика), чтобы знать, откуда пришел пользователь, то вам надо будет делать параметр источника трафика глобальным (то есть передавать его со всеми ивентами). В противном случае вы, например, не будете знать о том, пользователю из какого источника трафика принадлежит покупка, а значит, не сможете посчитать LTV для разных каналов трафика.
Таких особенностей систем аналитики много, и думать о них следует на этапе настройки аналитики приложения. Если оказалось, что текущая структура ивентов и параметров не закрывает ваши вопросы с помощью используемой у вас системы аналитики, то вернитесь к шагу 2 и переделайте структуру ивентов.
Шаг 4. Еще раз пройдитесь по предыдущим пунктам
Спустя некоторое время имеет смысл еще раз пройтись по получившемуся списку вопросов и структуре ивентов, чтобы добавить туда то, что было упущено (а такое есть почти всегда), и чтобы оптимизировать структуру ивентов для упрощения последующей работы с данными.
Шаг 5. Встройте аналитику в приложение
На этом этапе максимально детально объясните разработчикам суть каждого ивента и параметра. Расскажите, когда и при каких условиях каждый конкретный ивент должен отправляться, для чего он нужен, и что с его помощью вы хотите понять/узнать/проверить.
Осмысленное встраивание аналитики окупается экономией времени на следующем шаге.
Шаг 6. Протестируйте статистику перед релизом
Тестировать можно поверхностно — просто проверить факт того, что ивенты и их параметры приходят в систему аналитики.
Но чтобы быть до конца уверенным в том, что все работает правильно, я рекомендую использовать следующий подход. Выгрузите собственную сессию использования приложения в виде последовательности ивентов во времени. Затем проверьте, что все ивенты приходят в нужный момент, и что все параметры изменяются в соответствии с заложенной вами логикой.
В системе аналитики Mixpanel это делать очень удобно благодаря инструменту Live view, который позволяет видеть и фильтровать приходящие ивенты в режиме реального времени.
Я рекомендую очень внимательно проверять мобильную аналитику, как минимум по двум причинам:
- Обновить аналитику в мобильном приложении — это накладно (временные затраты на проверку приложения в сторе, а также временные затраты на обновление пользователей на новую версию);
- Неправильные данные — это еще хуже, с моей точки зрения, чем их отсутствие.
Описанный выше алгоритм настройки аналитики мобильного приложения из шести шагов может показаться достаточно сложным, но в реальности он несложный. Если все описанное выше поместить в одно предложение, то получится следующее:
заранее подумайте о том, что вы хотите узнать из собираемых данных, и заранее убедитесь, что ваша система аналитики способна дать вам это знание при имеющейся структуре ивентов.
Полезные хаки при настройке аналитики в мобильном приложении
Глобальные параметры
Есть такой полезный хак — отправлять определенные параметры со всеми ивентами. Я называю такие параметры глобальными.
Глобальные параметры обычно характеризуют пользователя, а не само действие, к которому прикреплен ивент. В список глобальных параметров я почти всегда вношу следующие параметры:
1) номер недели или дня, когда пользователь пришел в игру (для последующего выделения когорт);
2) источник трафика;
3) уровень игрока;
4) количество покупок;
5) кол-во пройденных уровней в игре.
Пишите статистику как минимум в две системы аналитики
Даже при внимательной проверке статистики на этапе тестирования все равно случаются ошибки, поэтому лучше писать данные как минимум в две системы, чтобы иметь возможность проверять их достоверность. В качестве запасной системы аналитики удобно использовать Flurry.
Проверяйте покупки на сервере перед тем, как писать их в статистику
Если вы хотите использовать вашу систему аналитики для работы с финансовыми данными, то обязательно делайте серверную валидацию платежей перед тем, как писать ивенты покупки в статистику. В противном случае читеры испортят все ваши данные.
Как хранить структуру ивентов
Для хранения и ведения структуры ивентов хорошо подходит Excel-файл. Заводите новую вкладку на каждую версию приложения и отмечайте цветом ивенты, которые добавились в соответствующей версии приложения. Так вы всегда будете знать, когда и какие изменения вносились в структуру ивентов.
Как называть ивенты
Чтобы не путаться в названиях ивентов, их удобно называть по принципу ЭКРАН_ЭЛЕМЕНТ_ДЕЙСТВИЕ. Например, старт уровня будет называться LEVSCR_LEVEL_STARTED, а покупка в магазине SHOP_ITEM_PURCHASED.
Для некоторых сущностей такая структура не подходит. В таком случае можно вводить сквозные ивенты, которые не привязаны ни к какому экрану, а отвечают, например, за трекинг внутренней экономики. Такие ивенты можно назвать ECONOMICS_CURRENCY_SPENT и ECONOMICS_CURRENCY_GAINED, а в качестве параметров передавать method (на что потратил) и value (сколько потратил).
В заключение
В качестве заключения еще раз повторю ключевую мысль: заранее подумайте о том, что вы хотите узнать из собираемых данных, и заранее убедитесь, что ваша система аналитики способна дать вам это знание при имеющейся структуре ивентов.
