Налаштовуємо аналітику програми для відстеження шляху користувача

У програмі сервісу доставки продуктів «Смекалка» не були налаштовані події для відстеження дій користувача. Фахівці 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 подія за змістом віднесена до кожного з етапів базової вирви. Так ми відзначаємо всі проміжні варіанти дій користувачів на тому чи іншому етапі. При подальшому аналізі це допомагає точніше визначати елемент або послідовність дій, які могли перешкодити користувачеві перейти на наступний етап. Важливо розуміти, що ми не намагаємося довести до оформлення замовлення всіх користувачів. Це неможливо. Але ми прагнемо знизити відтік користувачів на кожному з етапів вирви продажів, особливо на фінальних.

Про важливість коректної розмітки

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

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

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

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

Пошук точок зростання програми

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

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

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

Геолокація

За три місяці роботи з клієнтом ми знайшли цікаві інсайти, гіпотези та точки зростання. Найбільше точок зростання ми виявили на такому ключовому етапі роботи з програмою, як визначення розташування користувача.

При вивченні траєкторій користувачів ми помітили, що на момент вибору адреси доставки клієнти часто звертали додаток, ніби вони забували свою адресу. Але, швидше за все, у користувачів неправильно спрацьовувало визначення геопозиції на пристрої. У цьому й полягала наша гіпотеза. Для її перевірки ми повторно провели ручне тестування та виявили, що при виборі розташування користувачам за замовчуванням відкривалася карта міста.

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

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

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