Времени заняло:
14 недель
Моя роль:
UX-исследователь
Мой скоуп:
Usability-testing, Audit
Контекст:
Продукт вышел на рынок в 2023 году. Меня пригласили отдельным контрактом разобраться, что происходит с онбордингом после релиза.
Инструменты:
Google Analytics 4, Google Tag Manager, Hotjar
Задача
Регистрации шли, клиенты появлялись, но между этими двумя точками у команды не было данных. Никто не знал, сколько людей доходит до поданной заявки и где именно теряются остальные.
Задача была измерить путь, найти причины отвала, внести изменения и подтвердить результат повторным замером.
Что пришлось починить в аналитике до начала
Путь пользователя разрезан на два домена: сайт omg.one и приложение app.omg.one. В GA4 они считались как два разных визита, сквозной воронки не существовало.
Настроил cross-domain tracking, через GTM разметил шаги онбординга отдельными событиями с параметрами шага, ветки и ошибки. Hotjar поставил на оба домена: записи сессий, тепловые карты, опрос на выходе.
Онбординг состоит из трёх веток
После подтверждения телефона и почты пользователь попадает на автоматический роутинг, который определяет его случай: новая британская компания, существующая британская компания или иностранная компания.
Большая часть трафика шла в третью ветку: предприниматель с компанией за пределами UK. Её я и взял за основу исследования.
Путь в ней такой: данные компании, юридический адрес, личные данные, виды деятельности, оплата адреса, описание бизнеса на пяти экранах, структура бизнеса, декларация, верификация личности через Sumsub, обработка заявки.
Базовый замер
Четыре недели без изменений в продукте. Меньший период не показал бы недельную сезонность: в B2B активность по дням недели различается в разы.
Половина ветки теряется на одном экране
Type of Activities просит выбрать SIC-коды, британский классификатор видов деятельности. В списке варианты вроде добычи урановых руд и производства пестицидов.
Предприниматель из Франции, регистрирующий компанию в Британии, видит этот классификатор впервые и должен в нём себя опознать.
Медианное время на экране 6 минут 40 секунд, вдвое больше любого другого шага.
Что показали данные по этому экрану
Поисковые запросы я логировал отдельным событием. Люди искали обычными словами: consulting, software, marketing, trading, import. Классификатор отвечает формальными названиями, и по этим запросам выдача была пустой.
Медианное время на экране 6 минут 40 секунд, вдвое больше любого другого шага.
В записях Hotjar повторяется один паттерн: человек открывает вторую вкладку, уходит искать, что такое SIC-код, и не возвращается.
Оплата стоит слишком рано
Checkout идёт сразу после SIC-кодов. К этому моменту человек прошёл семь экранов, застрял на восьмом, и у него просят деньги за юридический адрес.
При этом впереди ещё пять экранов описания бизнеса, структура, декларация и верификация личности. Объём оставшейся работы нигде не показан.
В записях видно возврат назад с экрана оплаты и уход на сайт, к разделу с тарифами.
Остальные потери
Пять экранов описания бизнеса дают суммарно −34% к моменту Business Structure. Нумерация «1 из 5» появляется только на первом экране, дальше пользователь не знает, сколько осталось. Медианная длина ответа 40 знаков при ожидаемых нескольких предложениях.
Верификация личности уходит на домен Sumsub. Оттуда не возвращаются 27%. На мобильных переход открывается в новой вкладке, и возврат в приложение неочевиден.
Гипотезы
Собрал 14 гипотез, оценил по влиянию, охвату и трудоёмкости. В работу взял пять.
1. SIC-коды: словарь синонимов, чтобы обычные слова находили формальные коды. Подсказка из трёх популярных кодов по стране и виду деятельности. Объяснение на экране, что это такое и зачем. Возможность пропустить и вернуться.
2. Перенести Checkout после декларации, когда объём работы уже виден.
3. Свести пять экранов описания в один с прогрессивным раскрытием и сквозным индикатором шага.
4. Сохранение прогресса и письмо со ссылкой на незаконченную заявку.
5. Верификацию открывать в том же окне с явным возвратом, на мобильных добавить подсказку.
Проверка до разработки
Спроектировал изменения и проверил их на 8 пользователях кликабельным прототипом, отдельно на десктопе и на телефоне. Разметку событий сохранил без изменений, чтобы данные до и после были сопоставимы.
Повторный замер
Те же четыре недели, те же события, та же сегментация.
Разрыв на неделях внедрения показан намеренно: в этот период данные несопоставимы, и сплошная линия создавала бы ложное впечатление плавного роста.
Итоги
Самое результативное изменение не было интерфейсным. Британский классификатор видов деятельности остался тем же, изменился способ в нём искать: обычными словами вместо официальных названий.
Разметка событий осталась в продукте, команда отслеживает эти показатели после окончания моего контракта.
Следующий кейс:
Концепт
Web
Талоны для банка без отделений
N26 · 2024
У N26 нет отделений, и от этого задача только интереснее. Собрал прототип, где талон живёт внутри приложения: занимаешь место до выхода из дома и следишь за очередью по дороге.
Кейса пока нет, но я работаю над этим
