Настраиваем аналитику приложения для отслеживания пути пользователя

В приложении сервиса доставки продуктов «Смекалка» не были настроены события для отслеживания действий пользователя. Специалисты MediaNation настроили аналитику, выявили шаблоны поведения пользователей, ведущие к отказам, и предложили рекомендации для повышения конверсий и эффективности рекламы приложения. Никита Шамин, руководитель отдела рекламы мобильных приложений, делится наработками в кейсе.

Клиент

«Смекалка» — это сервис доставки полезных продуктов.

Приложение сервиса было опубликовано в Google Play Market и App Store 28 декабря 2021 года и 3 января 2022 года соответственно. Приложение отличается от сайта быстрым доступом в личный кабинет и сохраненными данными адреса доставки и банковской карты. Мобильный продукт лучше вовлекает покупателей в процесс покупки и помогает быстрее следить за изменениями в каталоге онлайн-магазина.

На момент запуска в аналитическом сервисе не были настроены in-app события, что не позволяло отслеживать путь пользователя по воронке и влияние UX / UI на него.

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

Задачи

Маркетинговый отдел компании поставил перед нами задачу построить аналитику так, чтобы она позволяла отслеживать изменения на разных этапах воронки продаж и легко обработать сырые данные для поиска инсайтов по улучшению UX / UI.

Нас также попросили подготовить документацию по работе с аналитической системой для маркетологов. В ее состав должна была войти инструкция для создания трек-ссылок под разные задачи. Все эти работы мы провели в рамках услуги “Консалтинг по аналитике приложений”.

Эту комплексную задачу мы разбили на несколько подзадач:

На основании Customer Journey Map определить ключевые события на каждом этапе воронки.
Вручную пройтись по каждому этапу воронки продаж, изучить функции и поведение различных элементов интерфейса, напрямую или косвенно влияющих на поведение пользователя.
На основании данных, полученных на первых двух этапах, составить набор in-app событий для разметки в SDK аналитических систем. Подготовить удобную и понятную документацию для разработчиков клиента.
Сопровождать разработчиков на этапе разметки in-app событий и корректировать техническое задание в соответствии с особенностями используемого стека и потребностей маркетологов в сборе тех или иных данных.
Разработать методику анализа данных и сбора отчета с результатами за месяц в удобном для клиента формате.

Выбор событий для отслеживания

Процесс разметки in-app событий и подготовки технического задания для разработчиков мы разделили на два основных этапа:

Первый этап — разметка основных событий в воронке, свойственной той или иной категории приложений. Как правило, для каждой категории есть стандартный набор обязательных событий. Воронка Смекалка, как и большинства приложений интернет-магазинов, состоит из следующих основных in-app событий:

Начало сессии
Открытие каталога
Просмотр страницы товара
Добавление товара в корзину
Оформление заказа

Это идеальный набор шагов, который клиент ожидал от пользователя. Если вы не уверены, какой стандартный набор in-app событий есть в вашей категории, то рекомендуем обратиться к статье аналитического сервиса AppsFlyer c несколькими примерами разметки.

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

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

Результатом изучения интерфейса приложения стала таблица в следующем формате:

Каждое in-app событие по смыслу отнесено к каждому из этапов базовой воронки. Так мы отмечаем все промежуточные варианты действий пользователей на том или ином шаге. При дальнейшем анализе это помогает более точечно определять элемент или последовательность действий, которые могли помешать пользователю перейти на следующий этап. Важно понимать, что мы не пытаемся довести до оформления заказа абсолютно всех пользователей. Это невозможно. Но мы стремимся снизить отток пользователей на каждом из этапов воронки продаж, в особенности на финальных.

Про важность корректной разметки

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

Мы применили более целесообразный подход: создали ряд вложенных параметров и сохраняли данные в формате JSON которые помещались в рамках всего одной записи в таблице. Такие параметры необходимы для идентификации товара или заказа с тем списком сопутствующих характеристик, который будет необходим клиенту. Затем их можно извлечь в формате типа данных «словарь» (неупорядоченные коллекции произвольных объектов с доступом по ключу) и преобразовать в несколько отдельных таблиц.

Для каждой команды, будь то разработчики или менеджеры по продукту, такой подробный тип разметки in-app событий полезен. Каждый сможет выгрузить только ту информацию, которая ему нужна.

Использовать эти данные могут и маркетологи. При подготовке к проведению акции они смогут собрать составить списки аудиторий по тем или иным параметрам, а затем уже вести этих пользователей на конкретный товар с применением диплинков в рекламных кампаниях, тем самым сокращая их путь до конверсии. При этом события будут фиксироваться как по органическому, так и по рекламному трафику. Достаточно будет лишь применить ряд фильтров в интерфейсе системы аналитики или при выгрузке сырых данных по API:

Поиск точек роста приложения

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

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

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

Геолокация

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

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

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

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

Был также переработан модуль определения местоположения устройства. Это привело к корректному определению точной геопозиции пользователя и обнаружению возможности доставки по указанному адресу. Так мы помогли устранить лишний шаг в пути пользователя и исключить возможность ввести его в замешательство на этом этапе, а, значит, увеличили шансы на рост конверсий.