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