1. Логирование статистики
использования в мобильных
приложениях

2. Кто пользователь?
Что он делает в приложении?
Какую статистику собирать, на что
смотреть?
Мы залогировали ВСЁ, что теперь
делать со всеми этими цифрами?

3. Кому нужна статистика?
Инвестору Маркетологу Продуктовой Разработчикам
команде
«Где деньги?» «Кто аудитория?» «Что делать?» «Каково качество
приложения?»
• Количество • Как часто • Какова статистика
активных планировать по • Есть ли ошибки и
пользователей коммуникацию и использованию сколько?
• Время в что писать? фичей • Как они влияют на
приложении • Портрет (пол, • Какие фичи пользователей?
• Как часто возраст) делать?
пользуются • Интересы • Как оценивать
• Как быстро уходят фичи?

4. Выбор инструмента сбора статистики
Достоинства Недостатки Как используем
• Очень гибкая, • Тяжело • «Сырые» логи
можно собирать визуализировать (чтобы из них
и считать что результаты можно было
Своя
угодно • Тяжело вытащить ответы
статистика поддерживать на нетривиальные
• Сомнительная вопросы)
надёжность • «Карма»
• Просто внедрять • Ограниченные • Высокоуровневая
• Работает на возможности статистика по
Flurry
уровне сегментов (мало, активности
Analytics пользователя (а негибкие) пользователей
не сессии)
• Очень гибкая • Сложноватая • Основной
Google (можно придумать • Работает только с инструемент сбора
как логировать что сессиями (а не с статистики
Analytics угодно) пользователями)

5. Часть 1
ОТВЕТЫ НА ЧАСТЫЕ ВОПРОСЫ

6. Инвестору Маркетологу Продуктовой Разработчикам
команде
Где деньги?
1. Сколько активных
пользователей?
2. Как часто
пользуются?
3. Как быстро уходят?

7. Инвестору > Сколько активных пользователей?
Источник данных на графике — images.google.com 
В отличие от Google Analytics, который плохо работает на
уровне пользователя (а не сессии) Flurry прекрасно считает
именно пользователей.

8. Инвестору > Как часто пользуются?
Источник данных на графике — images.google.com 

9. Инвестору > Как быстро уходят?
Источник данных на графике — images.google.com 

10. Инвестору Маркетологу Продуктовой Разработчикам
команде
Кто
аудитория?
1. Кто наши пользователи?
2. Какие у них интересы?
3. Как с ними общаться?

11. Маркетологу > Оценка аудитории
Audience Estimations во Flurry
Health & Fitness, Newsstand - News &
Politics, Games - Board, Sports, Books,
Games - Card, Music, Photo & Video,
Lifestyle, Utilities, Business, Games
Casual & Social Gamers, Parenting &
Education, Sports Fans, Bookworms,
Social Influencers, Business Travelers,
News & Magazine Readers, Food &
Dining Lovers, Personal Finance Geeks,
Business Professionals, Auto
Enthusiasts, Home & Garden Pros,
Entertainment Enthusiasts, Catalog
Достоверность — ?? Shopper

12. Маркетологу > Оценка аудитории
Опрос
• Составить вопросы
• Выбрать e-mail’ы активных пользователей
• Отправить письмо со ссылкой на опрос
(угрожая подарками)

13. Маркетологу > Оценка аудитории
Сравнение Flurry estimates с
данными опроса
Возраст Пол
Flurry estimates Опрос Flurry estimates Опрос
Вердикт: годен!

14. Маркетологу > Планирование e-mail рассылок
Карма
• New (первые две недели)
• Casual (от 1 до 5 сессий в неделю)
• Addicted (>5 сессий в неделю)
• Inactive (ни одной сессии за неделю)
• Lost (ни одной сессии больше месяца)
Писать, когда пользователь переходит из одной
группы в другую.

15. Инвестору Маркетологу Продуктовой Разработчикам
команде
Что
делать?
Какую статистику
вообще считать и
как делать из неё
выводы?

16. Продуктовой команде > Какие события логировать?
Чем выше на лестнице находится нужное действие,
тем более сложные методы нужны для того, чтобы
его трекать.
$$ + E-commerce
Sign in
+ Custom Vars
Настройка под себя
Внесение своего вклада
+ Events
Шаринг
Screens
Потребление контента
(Pageviews)

17. Продуктовой команде > Какие события логировать?
Screens (Pageviews)
Достоинства Недостатки
• Дешевизна • Дают мало данных (как правило,
Просто внедряются (автоматически нужны параметры).
— почти бесплатно); защищают от
ситуаций, когда сделали новую
фичу, а трекинг повесить забыли;
• легко считать тайминги экранов
(«сколько времени пользователи
читают статьи» итд);
• можно смотреть классические веб-
метрики (%exits итд).

18. Продуктовой команде > Какие события логировать?
Screens (Pageviews)
Когда использовать:
• Отслеживать потребления контента.
Как использовать:
• По возможности использовать автоматический трекинг
экранов.

19. Продуктовой команде > Какие события логировать?
Events
Достоинства Недостатки
• Содержат параметры; можно гибко • Не тайминговые;
настроить отслеживание важных
вещей. • Нужно программировать и следить,
что они работают правильно.

20. Продуктовой команде > Какие события логировать?
Events
Когда использовать:
• Для трекинга важных событий: шаринга, создания
контента, настройки приложения, создания
аккаунта/логина.
Как использовать:
• Для каждого действия трекать параметры (actions, labels,
values).

21. Продуктовой команде > Какие события логировать?
Events: пример
использования
Event category: Sharing
Event action: Media
Event label:
• Article text
• Article web
Event action: Author
Event label:
• simply miu
Event action: Service
Event label:
• Twitter
• Facebook
• Pocket

22. Продуктовой команде > Какие события логировать?
Custom variables
Когда использовать:
• Для трекинга разных типов пользователей:
залогиненных/не залогиненных, настроивших
приложение или нет, платных/бесплатных итд.
• Для трекинга разных режимов использования
приложения: portrait/landscape, grid/list итд.

23. Продуктовой команде > Какие события логировать?
Источник данных на графике — images.google.com 

24. Продуктовой команде > Какие события логировать?
E-commerce tracking
Когда использовать:
• Для трекинга продаж внутри приложения.

25. Продуктовой команде > Какие события логировать?
Тонкости: сессии
Использовать ли автоматические сессии?
• Автоматически: GA начинает новую сессию если
приложение находилось в фоновом режиме > 30 секунд
(этот таймаут можно изменить).
• Вручную: например, после того, как пользователь
залогинился или разлогинился.

26. Инвестору Маркетологу Продуктовой Разработчикам
команде
Ошибки
есть?
Каково качество
приложения?

27. Разработчикам > Логирование ошибок
Релиз с фиксами
Начало логирования
Апдейт
ошибок
Логировать ошибки можно как Flurry, так и Google Analytics.
(Осторожно, логи ошибок неполные)

28. Часть 2
КЕЙС-СТАДИ: ОЦЕНКА
СУЩЕСТВУЮЩИХ ФИЧ

29. Способ 1: АБ-тестирование

30. Что нужно сделать
– Научиться управлять каким-то параметром
(например, контентом, страницей, экраном).
Удобнее всего, если управлять получается с
сервера.
– Присваивать посетителям сегмент А или
сегмент Б в зависимости от того, какую версию
контента они увидят.
– Логировать название сегмента в кастомную
переменную в Google Analytics.
– Смотреть на разницу в поведении между
сегментом А и сегментом Б.

31. Способ 2: сравнение «до» и «после»

32. Способ 2: сравнение «до» и «после»
Когда нужно сравнить поведение пользователей до и
после определённого события (прошли уровень,
набрали 100 очков итп).
Что нужно:
– Придумать, какие показатели должны меняться в
поведении пользователя «после» по сравнению с «до».
– Разбить пользователей на классы активности
относительно этого показателя.
– Проверить, мигрируют ли они из одного класса
активности в другой.

33. Что нужно сделать
– Придумать, за какими действиями будем
следить (открытия приложения, лайки, новые
заметки итд).
– Разделить активность пользователя по
каждому действию на интервалы (1..5 событий,
6..10, 11..20 итд).
– Для каждого пользователя посчитать, в какой
интервал он попадал “до” и “после”.

34. Визуализация результатов
Для каждого действия строим таблицу
1-3 4-10 11-25 … Сколько действий
совершали после
порогового
1-3 значения
4-10
Количество
пользователей,
11-25 перешедших из
одной категории
активности в другую
… (1-3 -> 11-25)
— увеличили активность
— не изменили активность
Сколько действий
совершали до — уменьшили активность
порогового значения

35. Всё :)
Ольга Алексеева
olga.v.alekseeva@gmail.com