UX инсайты, или как строить и читать графы пользовательских путей
Data-driven подход обретает значительную распространенность последние годы, все больше компаний стараются принимать решения, основываясь на данных. Крупная часть аналитики, особенно, касающаяся бизнес метрик, строится без проблем. Аналитика же пользовательского поведения часто вызывает вопросы, особенно в продуктах, которые уже устоялись и имеют некоторое наследие в данных, с которым нужно работать ретроспективно.
Введение
Иногда анализ поведения пользователей не вызывает проблем – путь в продукте линеен и не имеет особых ответвлений и десятков разных сценариев. А бывает, что это не так просто – продукт может быть сложным, с рядом "но" и отклонений от линейной воронки.
Продукт, частью команды которого я являюсь, как раз из вторых. Мы представляем собой e-commerce площадку, но, как я люблю говорить, with benefits. Наш товар – это мероприятия. Концерты, события и аттракционы. Каждый по своему уникален – где-то шоу происходит один раз, а где-то повторяется в разные даты. У какого-то концерта есть карта мест для зрителей, а у другого – нажать кнопку "купить" это уже 70% пользовательского пути. Каждый из этих шагов влияет на конверсии, усложняет или облегчает воронку.
Как узнать, какая часть сервиса пугает пользователя больше всего? Какие шаги на пути пользователя являются "узкими горлышками", а какие – драйверами? Я давно убедился, что на ряд этих вопросов в сложном продукте помогают ответить графы пользовательских путей, про которые пойдет речь в этой статье.
Кто такие Celonis и Retentioneering
Перед тем, как рассказать об инструментах, нужно выяснить, чем являются графы пользовательских путей.
Давайте вспомним стандартные события пользователей в базе данных – если сильно упростить, обычно это некоторое название действия (event_action) и время, когда это действие было совершено (timestamp):
Те или иные события могут происходить несколько раз за одну сессию пользователя. Он может несколько раз возвращаться назад, чтобы посмотреть на товар, или вообще уйти на какие-то смежные страницы/экраны:
И это только за одну сессию одного пользователя, а только представьте, как выглядит таблица, если таких сессий и пользователей хотя бы тысяча.
Что же такое графы пользовательских путей и как Celonis и Retentioneering помогают их построить.
Давайте заберем из нашей таблицы все точки, указывающие на тот или иной шаг/место в интерфейсе. Нарисуем их на плоскости и свяжем между собой последовательности действий одно за другим по времени, как это написано в таблице:
Остался один шаг усложнения! Давайте сделаем следующее:
- добавим условные точки start и end, которые значат, что пользователь "родился", и "ушел";
- отобразим на плоскости все возможные места, куда могут попасть пользователи;
- сделаем размер точек пропорциональным объему пользователей, дошедших до этого места;
- нарисуем стрелочки откуда и куда ходят пользователи;
- а толщина стрелочек будет указывать на объем пользователей, прошедших по этой тропинке.
После этого упражнения получаем следующую картину:
Для построения подобных карт используются такие инструменты как Celonis и Retentioneering. Как правило, немного подготовив данные заранее, их достаточно просто загрузить в один из этих сервисов (Celonis – сервис, Retentioneering – библиотека), графы построятся сами, а в Celonis даже будет ряд дополнительных фичей, упрощающих чтение и анализ.
Как правильно читать подобную карту и находить в ней инсайты я опишу чуть ниже.
Как подготовить данные
Чтобы в графе, который будет построен с помощью одного из вышеупомянутых инструментов, не было ошибок, нужно правильно подготовить данные.
Структура данных для каждого инструмента предельно проста, сервисам нужно иметь лишь три основные параметра:
- id сессии – чтобы понимать путь пользователя. Здесь нужен именно идентификатор сессии, а не пользователя. Потому что, логично, что путь пользователя не заканчивается покупкой. Он может возвращаться, покупать снова или посещать другие страницы сайта вне рамках основного пути;
- идентификатор события – название действия, экрана или другой единицы пути пользователя;
- timestamp – точная дата с секундами (а часто с миллисекундами), когда событие произошло.
Важные замечания по данным:
- Событие должно являться частью интерфейса/пути всех пользователей, а не одного конкретного.
Например, сильно персонализированные события по типу "посещение товара id12345" будут ошибкой и создадут на карте огромную непонятную паутину, вместо читаемого графа. Если ваши события пишутся подобным образом, то их лучше сгруппировать и использовать более общий вариант – "посещение страницы товара".
Это особенно актуально для событий типа pageview в Google Аналитике, где каждая страница отдельного товара воспринимается уникальной. - Данных нужно очень много! Так как это по своей сути сырые логи, смело загружайте в инструмент миллионы строк – от этого отчет станет только точнее.
Основные знания о графе
Перед тем как начать читать карту, я предлагаю ознакомится с рядом базовых знаний о подобных инструментах. Заметки ниже будут приведены через призму Celonis, но они так же актуальны для Retentioneering.
- Process start (start, beginning) – это условная точка начала сессии пользователя. Это не какое-то место на вашем сайте или в вашем приложении. Это некоторое условное "рождение" пользователя. А вот куда пользователь попадает после "рождения" это и есть landing page или start screen в вашем продукте.
Пользователи могут приземляться на разные части вашего продукта, о которых вы ранее не догадывались. Проследить это легко по стрелочкам, исходящим из Process start.
- Process end (end, finish, way-out) – соотвественно, это условная точка завершения сессии пользователя. Аналогично, это не конкретное место в вашем продукте, а условный выход пользователя. Это момент (именно момент, а не событие аналитики), когда пользователь закрыл сайт или выключил телефон и его сессия закончилась.
События до Process end будут помогать определить, была ли сессия успешной или нет. Если до выхода было подтверждение успешного заказа – значит пользователь ушел не с пустыми руками.
- Activities (ползунок, настройка диапазона) – помогает увеличить или уменьшить количество отображаемых на карте событий. По умолчанию на карте не показаны все события из ваших аналитических данных, но двигая этот ползунок, можно увеличивать их число.
При настройке количества событий, приоритет их отображения формируется из объема сессий, в которых это событие было. Чем меньше событий указано отображать на карте – тем более "сильные" или частые события отображаются.
- Connections (ползунок, настройка диапазона) – помогает управлять количеством отображаемых "тропинок" или путей на карте. Аналогично, по умолчанию ряд незначительных и непопулярных путей на карте не отображен, но вы можете настроить порог отображения, чтобы увидеть даже самые редкие пути пользователей.
Приоритет формируется аналогично – чем больше людей ходило этой тропинкой, тем быстрее читатель карты эту тропинку увидит.
Как находить инсайты
После всех подготовок и окончательной загрузки данных в Celonis мы получаем красивый и непонятный график, на котором можно даже запустить визуализацию движения пользователей:
Можно поиграться с ползунками, попробовать разные функции и ознакомится с инструментом подробнее. В интернете много статей про сценарии использования этого инструмента, я же хочу сконцентрироваться на одной задаче – поиск проблемных точек, которые являются причинами выхода пользователей и, соотвественно, починка таких точек может хорошо стимулировать рост продукта.
Если мы ищем причины отказа, в первую очередь нужно смотреть те события, которые привели к выходу пользователя. Для этого достаточно кликнуть на точку Process end и увидеть, какие события предшествовали выходу:
На моем примере есть очевидный отток на страницах товаров, который может говорить о достаточно органическом оттоке – не подошло, не нашел то, что искал. Но помимо этого органического оттока можно обратить внимание на ряд проблемных точек, требующих дальнейших тестов и разбирательств.
Например, некоторый поп-ап, который является причиной оттока. На скрине выше отток происходит после поп-апа, который ведет на установку приложения. Чтобы понять, проблема это, или нормальное поведение, которое не отпугивает пользователей, достаточно посмотреть, дошли ли пользователи до приложения в итоге и совершили ли последующие действия в нем.
Второй же пример, это некие страницы hall-map и select-tickets (в нашем случае это часть сложного чекаута), требуют более детального рассмотрения на карте. Давайте найдем их и приблизим:
На скриншоте выше видно второй распространенный нежелательный кейс в пользовательском пути, который сильно влияет на конверсии – цикл.
Такое паттерн поведения свидетельствует о том, что несколько шагов в пути нужно объединять. Пример того, как подобный цикл видит пользователь, бронируя билет на самолет:
- выбор класса и доступных дат полета разнесены на разные шаги и зависят друг от друга;
- пользователь выбирает класс "бизнес" и попадает на следующую страницу;
- оказывается, что в классе "бизнес" нет нужной ему даты, он возвращается назад, чтобы поменять класс (если он вообще догадается, что это зависит от класса билета);
- выбирает класс "эконом" и попадает снова на страницу с датами, а нужной даты снова нет;
- и так далее
Скорее всего, после второго цикла такой пользователь разочаруется и уйдет, а на самом деле, совсем рядом был класс "бизнес+", который всего на 5% дороже, но нужные пользователю даты и места были свободны.
Заключение
Подобных паттернов поведения и проблемных точек может быть множество, я привел лишь несколько возможных вариантов чтения подобных карт. Более глубокое погружения в подобный подход должно производиться в контексте вашего продукта и ваших пользователей.
Использовать подобные инструменты можно как для ежемесячных сверок или ситуативных гроу-хакинг сессий, так и для регулярной аналитики, которую не сложно настроить путем интеграции сервиса с вашим хранилищем данных.
Несколько дополнительных замечаний, которые стоит учитывать при чтении этой статьи:
- Ваш продукт может быть сложнее или проще, данные могут иметь разную степень подготовки, а неэффективные пользовательские пути иметь другие паттерны. Вероятно вам придется адаптировать и подкручивать модель данных и метод чтения карты под ваш конкретный случай.
- Автор статьи менеджер продукта, а не аналитик. Статья в частности написана для аудитории без сильного аналитического опыта, что может отражаться в стиле и глубине языка, термины могут быть упрощены для легкости восприятия. :)