Настройка аналитики мобильного приложения. Создание структуры ивентов для аналитики приложения.

Фундаментом аналитики является сбор данных. Настройка аналитики мобильного приложения включает в себя интеграцию SDK системы аналитики в мобильное приложение, проектирование структуры ивентов и их расстановку внутри приложения. Неправильно настроенный сбор данных для аналитики оставит вас без приборов в работе с вашим продуктом, либо же обеспечит неверными данными, что, с моей точки зрения, еще хуже, чем отсутствие данных.

В этой статье я расскажу о том:

  • Какие ошибки часто допускают при настройке аналитики мобильных приложений
  • Как я обычно подхожу к процессу встраивания аналитики в мобильное приложение
  • Также я поделюсь некоторыми хаками и секретами, которые позволят вам эффективнее использовать ваши данные

Настройка аналитики мобильного приложения

Внутренняя аналитика мобильных приложений или зачем нужны ивенты

Аналитика мобильных приложений обычно строится на ивентах. Вы шлете в систему аналитики ивенты (события), а система предоставляет интерфейс для работы с этими данными.

Ивент – любое действие, которое совершает пользователь (клик на кнопку, открытие определенного экрана, добавление комментария, трата или покупка внутренней валюты).  Когда происходит это событие, то приложение отправляет ивент на сервера системы аналитики. Вместе с ивентами обычно передаются ряд обязательных параметров (индификатор пользователя, версия приложения, модель девайса, прочие служебные параметры), а также ряд дополнительных кастомных параметров, которые вы определяете сами (например, количество дней с момента начала использования приложения, кол-во запусков приложения и тд).

По сравнению с стандартными для веба системами аналитики (Яндекс Метрика или Google Analytics) описанный подход оказывается более затратным на этапе встраивания и настройки системы аналитики, но зато позволяет отвечать на существенно большее количество вопросов.

Почитать про разные системы аналитики для мобильных приложений можно в сравнительном обзоре Mixpanel, Flurry, Google Analytics, Localytics и в обзоре системы аналитики Kontagent (теперь Upsight). Подробнее о том, какие вообще бывают системы аналитики можно прочитать в обзоре существующих аналитических решений для мобильных приложений.

 

Ошибки при настройке аналитики в мобильном приложении

Обычно проектированию структуры ивентов и настройке аналитики уделяется мало времени и внимания при разработке мобильных приложений. Неправильно или некачественно настроенная аналитика сильно осложняет последующую работу с продуктом, а порой оставляет полет вашего продукта без каких-либо навигационных приборов.

Я заметил следующие распространенные ошибки при настройке аналитики:

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 (система для определения источников трафика), чтобы в Mixpanel знать, откуда пришел пользователь, то вам надо будет делать параметр источника трафика глобальным (то есть передавать его со всеми ивентами). В противном случае вы, например, не будете знать о том, пользователю из какого источника трафика принадлежит покупка, а значит не сможете посчитать 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 (сколько потратил).

В заключении

И еще раз суть статьи в одном предложении. Заранее подумайте о том, что вы хотите узнать из собираемых данных, и заранее убедитесь, что ваша система аналитики способна дать вам это знание при имеющейся структуре ивентов.

Если у вас есть свои хаки встраивания аналитики в приложения, то поделитесь ими в комментариях. Спасибо.

 



Подписка на рассылку новых материалов

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



Запись опубликована в рубрике Аналитика, Без рубрики, Маркетинг, Мобильная разработка с метками , . Добавьте в закладки постоянную ссылку.
  • Mihail Yurov

    Все разложено по полочкам, спасибо. Примерно также происходит весь процесс. Про live view – не знал о таком, интересно.

  • Maria Paskevich

    Я бы еще добавила одну ошибку, которая часто встречается: путаница с валютами платежа. Стоимость покупки отправляется в той
    валюте, в которой платит пользователь, а в статистической системе все доходы
    отображаются в долларах (или в других валютах, если доступна такая
    возможность). Каждая транзакция передается с несколькими параметрами: это id самой транзакции, стоимость покупки, название купленного
    товара и валюта, в которой была совершена покупка. А затем на сервере стоимость приводится к одной валюте в соответствии с кодом валюты.
    Бывает разработчики забывают про эти коды, и в итоге получают
    сумму долларов, йен, рублей и любых других валют, в которых покупали
    пользователи.

    • Mihail Yurov

      Помимо путаницы в валюте, часто разработчики упускают такой момент, как комиссия AppStore и Google Play. В части проектов значения приходят с учетом комиссии, а в части – без.

    • Олег Якубенков

      Согласен, об этом тоже полезно помнить

  • Олег, добрый день.
    Могли бы вы немного подробнее рассказать про то, как вы замеряете эффективность туториалов?
    Какие события, помимо стандартных “прокликал или просмотрел” вы могли бы посоветовать отслеживать?

    На примере: у нас есть последовательное обучение механикам А и Б.
    А – используется регулярно, Б – один-два раза в процессе прохождения уровня.
    Можем ли мы сделать вывод о плохом обучении механике Б, если пользователи используют её значительно реже, чем один раз за уровень?

    • Олег Якубенков

      Добрый день
      Цифры сами по себе обычно мало чего говорят, кроме их крайних значений. Если вы обучили пользователей делать А, а потом 0% из них это сделали, то тут проблема на лицо.
      Вообще надо пробовать другую версию туториала и сравнивать использование механики Б с текущим туториалом.

      • А по первым двум вопросам можете рассказать, хотя бы вкратце?

        Могли бы вы немного подробнее рассказать про то, как вы замеряете эффективность туториалов?
        Какие события, помимо стандартных “прокликал или просмотрел” вы могли бы посоветовать отслеживать?

        • Олег Якубенков

          Туториал обычно состоит из последовательности конкретных шагов. Для оценки самого туториала имеет смысл посчитать следующую воронку “новые – > шаг1 -> шаг 2 -> шаг 3 …”. Так вы сможете найти проблемные места, где пользователи отваливаются. Именно найти проблемные места, а не оценить эффективность туториала.

          Эффективность туториала лучше оценивать на более длинных метриках, например, retention, ltv, доля платящих (вы должны сами определить, какие метрики для вас являются значимыми).
          Вот интересный пример компании Yammer, как короткий туториал с более высокой конверсией проиграл на долгосрочных показателях длинному туториалу с худшей конверсией – http://habrahabr.ru/post/192008/

  • Andrew Kovzel

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

  • Анатолий Ларин

    Мы создаем два проекта в аналитике для тестирования и релиза. Релизный ключ подсовывается только при отправке в AppStore/Play.

    Так тестовые события и версии не попадают в статистику. И релизные не попадают в тестовую статистику, удобнее тестировать.

  • Alexander Brovko

    А какую системы вы используете как основную? MIxpanel?

    • Олег Якубенков

      Добрый день
      Да, Mixpanel

  • Олег, что скажете на счет Amplitude? Странно, что она не вошла в ваш шортлист.

    • Олег Якубенков

      Когда я писал тот старый пост со сравнением систем аналитики Amplitude только появились- сервис был достаточно сырым
      А сейчас это одна из лучших систем аналитики, я сам на нее перешел с Mixpanel
      В ближайшее время напишу про них пост подробный