Если вы зачитывались историями про Шерлока Холмса или смотрели многочисленные экранизации, то наверняка помните название метода, который использует герой для раскрытия запутанных дел. На всякий случай напомним: он пользуется индукцией — переходом от частного к общему в противовес дедукции, когда из общих данных делают вывод о частных. Как же использовать метод индукции для изучения поведения пользователей в нашем приложении?.. «Элементарно!»- сказал бы герой сэра Арутра Конан Дойля. «Именно так», – вторит ему ведущий аналитик devtodev Василий Сабиров.
источник картинки www.smartdatacollective.com/sites/smartdatacollective.com/files/Sherlock-Holmes-Big-Data-Analytics-and-BI-Attivio.png
До недавнего времени большинство аналитических систем предлагали работу по дедуктивному методу: проводился анализ всех пользователей сразу, а вывод делался о поведении каждого конкретного пользователя. Нельзя считать это ошибкой, но для более точных выводов всё же стоит применить и индуктивный метод. И теперь сервис devtodev рад представить новый функционал аналитических систем, в основу которого положен на индуктивный метод: анализ профилей пользователей.
Если вы задались целью точнее понять свой проект, то сначала вы встраиваете в него аналитику и начинаете видеть определенные метрики (DAU, ARPU, LTV, и так далее) и отчёты. Означает ли это, что вы до конца понимаете проект, над которым работаете? Не совсем. Да, вы можете делать выводы о поведении большинства, однако взглянуть на проект глазами конкретного пользователя у вас пока не получится.
Чтобы увидеть продукт с этой точки зрения, нужно проследить поведение конкретного пользователя: какие действия он совершает, с какими проблемами сталкивается, понимает ли он суть вашего продукта. Последив за каждым пользователем и узнав, какие действия он совершает внутри продукта, вы, без сомнения, сможете лучше понять его.
Профили пользователей в системе Amplitude
источник картинки amplitude.zendesk.com/hc/en-us/article_attachments/202671468/User_Search_2.png
Проанализировав таким образом N пользователей, вы сможете собрать данные, необходимые для формулировки ряда гипотез об улучшении продукта. И их количество уж точно не будет меньше, чем по итогам анализа метрик по всем пользователям сразу. Практика показывает, что N при этом необязательно должно быть большим: при детальном изучении уже на третьем пользователе вы сформулируете какие-то гипотезы, на пятом — определяете проблемы, на десятом в вашей голове созревают планы на изменение и улучшение продукта.
источник картинки www.ew.com/sites/default/files/1452454622/christian-bale_0_1.jpg
Еще один пример из художественного произведения, на сей раз это фильм “Игра на понижение”. Внимательный зритель помнит, как герой Кристиана Бейла изучает огромную таблицу с ипотечными кредитами, взятыми каждым конкретным заемщиком, а потом опрашивает этих самых людей, находя таким образом предпосылки грядущего финансового кризиса. Банки же, привыкшие оценивать общую ситуацию, а не каждый случай в отдельности, не верят в приближение конца, так как в целом ситуация складывается отличная, и ничего не предвещает краха. Чем не яркий пример ошибочного анализа?
В итоге формируется следующий тренд: многие аналитические системы на рынке запускают свои модули, предоставляющие возможность анализа профилей пользователей. У Localytics это Profiles, у Mixpanel — People, у Amplitude — User Activity.
В devtodev мы создали продвинутый вариант такого модуля и назвали его Users.
Из чего же складывается профиль пользователя?
Во-первых, это информация, которая собирается аналитической системой по умолчанию:
- дата установки;
- язык;
- страна;
- часовой пояс;
- Устройство (девайс);
- версия ОС;
- канал трафика;
- версия приложения;
- и т.д.
С помощью этой информации можно фильтровать пользователей по тем или иным параметрам, создавать сегменты и отслеживать в дальнейшем их поведение. Допустим, можно выбрать всех пользователей с iPad, всех из Франции, всех пришедших с Facebook, всех, кто используюет предыдущую версию приложения, и так далее. Фильтры можно комбинировать, чтобы ориентироваться на точечно выбранную аудиторию: англоговорящие пользователи из Западной Европы, пользующиеся новой версией приложения и зарегистрировавшиеся в сервисе не более двух месяцев назад.
Во-вторых, в профилях хранится информация о платежах пользователя: когда он заплатил, сколько и за что. Вы будто примеряете его профиль на себя и начинаете лучше понимать мотив его действий: почему он купил именно этот IAP, почему между платежами прошло именно столько времени и так далее.
Без профилей пользователей вы можете видеть монетизационные метрики, статистику покупок, и это, безусловно, очень полезная информация. Однако более глубинное понимание достигается именно за счёт перемещения на уровень игрока.
В-третьих, профиль пользователя включает в себя статистику событий (custom events), которые происходили с пользователем в проекте. Вы начинаете видеть их последовательность, вы как бы смотрите видео о том, как конкретный человек пользуется вашим продуктом.
Вот примеры некоторых вопросов, на которые можно ответить, используя такой метод:
- какое событие обычно следует после события A?
- какое событие предшествует событию B?
- все ли пользователи выполняют событие C после события D? или же уходят на событие E?
- какие события предшествуют уходу пользователя из проекта?
Можно выбрать всех пользователей, входивших в магазин приложения (совершавших событие “Вход в магазин”) и оценить, какие события этому входу предшествовали и каким было поведение пользователя после входа в магазин. Так станет яснее, как происходит конверсия пользователя и в интерес к покупке, и непосредственно в переход к покупке, и как итог в успешный совершенный платёж.
Профили пользователей в системе MixPanel
источник картинки cdn.mxpnl.com/cache/81e4c82a27f699ba6153b46064105a1e/images/static/landing/marketing/people2/feature-illus.png
И наконец, профиль пользователя включает в себя User Properties, которые определяете вы сами. Это может быть что угодно: уровень в игре, код группы при проведении A/B-теста, классификация по величине платёжной активности (minnow / dolphin / whale) и так далее.
На все проекты стандартных методов на напасёшься, и наиболее правильной тактикой аналитической системы будет сформировать универсальный набор полезных параметров для отслеживания действий пользователя, оставив при этом возможность клиенту самостоятельно выбрать для анализа любой другой параметр.
Практическая польза наличия профилей пользователей в системе аналитики очевидна, для сомневающихся приведу аргументы:
- С помощью этого модуля можно провести анализ “наоборот”, или индуктивный анализ, если хотите. Вы смотрите поведение конкретных пользователей и начинаете лучше понимать, что они чувствуют, используя ваш продукт
- На основе проведенного анализа можно отправить выбранным пользователям push-уведомления — некоторые системы (и devtodev в том числе) позволяют это сделать.
Случай из практики: разработчики приложения заметили, что пользователь застрял на каком-то уровне, и отправили ему уведомление с подсказкой, как этот уровень пройти. Затем оказалось, что он не один такой, и значительное количество пользователей застревают на одном и том же уровне, а потом уходят из приложения в среднем на семь дней. Пока все дружно писали постановку на упрощение уровня (хотелось же, чтобы пользователи не уходили), всем застрявшим на уровне вы отправили push-уведомление с явной подсказкой. Что же сделали с теми, кто не входил в игру семь дней и больше? Правильно, разослали небольшой, но приятный бонус в виртуальной валюте с помощью тех же push-уведомлений, воспользовавшись передаваемыми параметрами.
- С помощью профилей пользователей легко тестировать интеграцию аналитической системы. Вообще, интеграция аналитики процесс нетрудный, но достаточно кропотливый: сначала надо сформировать набор событий, чётко понимая, что этих событий будет достаточно для последующих выводов (подробнее про это я писал тут). И когда интеграция закончена, не помешало бы её хорошенько протестировать. И здесь профили пользователей и работа аналитики в реальном времени будут хорошим подспорьем: вы самостоятельно открываете приложение, совершаете цепочку событий, затем находите в аналитике свой профиль и просто смотрите, правильно ли передались события с параметрами. Если же аналитику правильно не тестировать, то итерация на исправление может занять более месяца, который можно было б посвятить более нужным вещам.
- И наконец, увеличивается доверие к аналитической системе. Допустим, эта самая система что-то вам посчитала (напрмер, ARPU = $0,2), и вы не знаете, как это значение было получено и можно ли ему вообще доверять. Как представитель аналитического сервиса заявлю, что доверять можно, однако я прекрасно понимаю людей, испытывающих легкое недоверие к системе, считая её чёрным ящиком. Часто людям, работающим с данными, хочется самим выгрузить данные и перепроверить всё руками. Наличие профилей пользователей увеличивает доверие к системе аналитики: вы видите не голые цифры, а данные по каждому пользователю отдельно, а возможность выгрузки данных как раз даёт возможность особенно недоверчивым персонам выгрузить данные и посчитать всё самим. Таким образом, наличие профилей пользователей взаимовыгодно и для клиента, и для самой аналитической системы.
Таким образом, анализ профилей пользователей существенно упрощает жизнь и клиенту аналитической системы, и самой системе, оставляя современного Шерлока Холмса не у дел. У клиента появляется гораздо больше возможностей для оценки действий пользователей, и главная из них — это возможность проведения индуктивного анализа (анализа “наоборот”). Важно, что и сама система остается в выигрыше, заручаясь еще большим доверием со стороны клиента.
Автор: devtodev
