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

• Аналитика
• 03-Фев-2025
• -
• Нет комментариев

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

Клиент

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

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

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

Задача

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

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

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

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

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

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

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

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

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

Результатом изучения интерфейса программы стала таблица в таком формате:

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

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

Дуже важливо правильно розмічати події, оскільки вони можуть не лише повідомляти маркетологів та аналітиків безпосередньо про факт їхнього наступу, а й доносити додаткову інформацію. Наприклад, ми хочемо знати, якими товарами користувачі програми цікавляться найчастіше до покупки. Найневдалішим рішенням було б розмітити для кожного товару окрему подію. Це незручно, оскільки перевантажує інтерфейс аналітичної системи та збільшує тимчасові витрати на роботу програмістів, особливо якщо ми говоримо про інтернет-магазини з тисячами найменувань товарів.

Ми застосували більш доцільний підхід: створили низку вкладених параметрів та зберігали дані у форматі JSON, які містилися в рамках всього одного запису в таблиці. Такі параметри необхідні для ідентифікації товару або замовлення з тим переліком супутніх характеристик, який буде потрібний клієнту. Потім їх можна отримати у форматі типу даних «словник» (неупорядковані колекції довільних об’єктів з доступом по ключу) і перетворити на кілька окремих таблиць.

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

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

Поиск точек роста программы

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

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

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

Геолокация

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

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

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

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