Правильно расставляем события во Flurry

Правильно расставляем события во Flurry


Внедрение аналитики в приложение -- важная и не простая задача. Часто про нее забывают, еще чаще делают неверно. Недостаточно встроить библиотеку в приложение. Нужно правильно расставить события. События это метки, сообщающие Flurry, какие действия пользователя нужно записывать. Как показывает практика, программисты не справляются с этой задачей. Менеджеру приложения придется тщательно проследить за процессом.

   Читайте в айСоветах почему я рекомендую Flurry.

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


1. Выделите общие для всех событий параметры

Обычно это данные о пользователе, зарегистрирован он или нет, зашел по WiFi или 3G. Выпишите эти параметры в список с пометкой «добавлять к каждому событию».

Для логина пользователя есть специальный метод setUserID, проследите, чтобы он вызывался в приложении.


2. Расставьте событие на каждый экран приложения

Если у вас есть навигационная схема, пробегитесь по ней и составьте таблицу для программистов «Название экрана» -- «Название события». Если схемы нет -- пробегитесь по приложению или макетам.

К сожалению, Flurry не понимает русские буквы при создании сегмента, поэтому лучше называть события и параметры латиницей. Рекомендую формат названий p<название экрана>, например, pRegister, pLogin, pFilm.



Flurry поддерживает TimedEvents -- события с замеренной продолжительностью во времени. Например, с их помощью можно узнать, сколько времени пользователь читал статью или описание товара. Пометьте события, для которых это актуально в таблице как Timed.

Пробегитесь еще раз по всем экранам и подумайте, какие параметры добавить к событиям. Единственный пример, который приходит в голову, это когда на одном экране могут отображаться разные сущности: экран статьи, фильма или товара. ID этого объекта добавьте в параметры.

  Кстати,  Flurry поддерживает до 300 событий на приложение и до 10 параметров на каждое событие.


3. Расставьте события взаимодействия с элементами экранов

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

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

Берем экран в приложении или макет и смотрим, какие взаимодействия нам интересны: тапы по кнопкам, заполнение полей, события вроде покупки или регистрации в приложении.

Для примера экран фильма в приложении Stream:


События на экране:
  • bFavourite. Фильм добавили или убрали из избранного, параметры ID фильма, убрали/добавили
  • gSwipeFilm. Пролистнули фильм влево или вправо. Сразу после этого события стоит запустить трекинг перехода на экран фильма.
  • bBuyPopup. Нажали кнопку, отрывающую попап с выбором подписки/покупки. Параметры: цена подписки, цена покупки, ID фильма.
  • bBuyFilm. Нажали кнопку покупки, параметры ID фильма, цена.
  • bBuySubscription. Нажали покупку подписки.
После нажатия на кнопку покупки, покупка может и не состояться (Apple спрашивает пароль от аккаунта), поэтому обязательно добавляем событие eBuyFilm с параметрами iD фильма  и цена.

И так по всем основным экранам. Все события добавляем в таблицу для программистов под событием соответствующего экрана.

Примеры событий по отраслям в документации Flurry: mCommerce, новостные приложения, игры.


4. Протестируйте ДО отправки в магазин

Важно! Тестируйте приложение до отправки в магазин, цена ошибки после аппрува высока, да и догло ждать результата.

Для теста заведите отдельное тестовое приложение во Flurry (myApp, myAppTest). Заодно это обеспечит чистоту пользовательских данных от событий нагенерированных вашими тестировщиками.

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

Подождите час и проверьте корректность интеграции. Посмотрите отчет Events → Events Log, что все события работают, параметры и названия корректны, значения верные. В Events → User Path раскройте дерево до 4-5 уровня, проверьте, что все названо понятно и считывается удобно.

 


5. Может ли аналитика ответить на вопросы бизнеса

Самый важный этап тестирования. Сформулируйте вопросы, на которые вы хотите получить ответы от аналитики после запуска приложения. Например:
  • Какой фильм покупают чаще всего.
  • Какой метод оплаты популярнее: подписка или покупка фильмов по одному.
  • Сколько пользователей завершает покупку после нажатия на «Купить фильм».
  • Какими функциями приложения пользуются реже всего, какими не пользуются вообще.
И попытайтесь найти ответы на все эти вопросы во Flurry. Если не получилось, думайте, как дополнить таблицу событий, отдавайте программистам, тестировщикам, проверяйте заново и так, пока не сможете ответить на все вопросы.

После этого можно отправлять приложение в магазин.

От редактора

Чуть шире тему аналитики раскрывает наша статья на Хабре.

Для следующего выпуска рассылки мне нужны добровольцы. Хочу сделать пример таблицы по алгоритму этого выпуска на реальном приложении, у кого есть желание дать свое приложение для примера -- пишите на al@touchin.ru

И хорошая новость, мы запустили айСоветы. Можно задать любой вопрос про мобильные приложения и мы поделимся своим опытом. Если пока нечего спросить, просто подпишитесь на RSS или Twitter.

До встречи через неделю!


ООО «Тач Инстинкт» 18 линия В.О. 29 Санкт-Петербург 199034 Russia 

Дополнения к письму

«Настройка аналитики мобильного приложения» подход к расстановке событий Олега Якубенкова, аналитика ZeptoLab.

App Events Best Practice от Facebook

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

×