Упростил поиск в банке: успешных сессий на 85% больше

Контекст

Поиск в интернет-банке работает на iOS, Android и в веб-версии. До редизайна все пользователи видели одинаковый стартовый экран с блоками «Недавно искали», «Переводы по телефону» и «Финансовые подсказки». Поисковик находил сервисы и контент банка, но на вопросы вроде «Как...» и «Сколько...» отвечал ошибкой

Проблема

Только 40% поисковых сессий завершались успехом, а удовлетворённость поиском держалась на оценке 2,6 из 5. Успешной мы считали сессию, где пользователь кликал по результату и не возвращался в поиск в течение 10 секунд — то есть находил, а не переформулировал запрос ещё раз

Моя задача

Работал в команде: продакт, техлид, аналитик, 3 разработчика, 3 тестировщика

1. Найти слабые места в сценарии поиска, определить точки роста
2. Сформулировать гипотезы на основе находок
3. Проверить гипотезы коридорными тестами и A/B-тестами
4. Собрать концепт редизайна и утвердить у руководства
5. Довести решение до релиза

Аудит текущего сценария

Вместе со специалистами по клиентскому опыту разобрали текущий сценарий и нашли несколько проблем:

• Стартовый экран одинаковый для всех. Из персонального только «Недавно искали» и «Переводы по телефону»: первый блок просто копирует текст в строку поиска, второй занимает много места
• «Финансовые подсказки» нужны не всем. Блок полезен, только если есть счёт или платёж, а места на экране занимает много
• Вопросы падали в ошибку. Запросы вида «Как...» и «Сколько...» поисковик не обрабатывал
• В веб-версии на iOS нет доступа к контактам. Номер приходилось вбивать вручную или искать перевод в истории, и конверсия переводов проседала

Бенчмаркинг рынка

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

Гипотезы на проверку

• Если убрать неэффективные статичные блоки («Финансовые подсказки», «Недавно искали») и заменить их персонализированными элементами — вырастет релевантность стартового экрана и скорость выполнения целевого действия
• Если сократить блок «Переводы по номеру» — освободится место под более приоритетный контент без потери конверсии в сам перевод
• Если добавить ассистента с ИИ в поиск — пользователи смогут закрывать сложные/развёрнутые запросы (которые раньше падали в ошибку), и поиск станет полноценной точкой входа для операций
• Если составить онбординг по включению Contact Picker API (экспериментальная функция Safari, дающая доступ к системным контактам в браузере) — конверсия переводов в веб-версии iOS вырастет за счёт того, что пользователю не придётся вводить номер вручную или искать перевод в истории

Валидация гипотез

Онбординг Contact Picker API проверял коридорными тестами: 8 из 10 респондентов дошли до меню и включили функцию. Менее рискованные гипотезы проверял через self-serve инструменты Pathway: A/B-тесты, тест первого клика, тепловые карты, а ещё опирался на данные аудита и практику рынка

Сборка концепта

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

1Стартовый экран поиска стал персонализированным

До ввода запроса пользователь видел одинаковые для всех статичные подсказки. Я заменил их персональными чипсами — напоминание оплатить кредит, погасить задолженность, выбрать кэшбэк — действиями, которые актуальны клиенту именно сейчас. Если платежей в категории несколько, открывается шторка с деталями

А ещё избавился от блоков «Финансовые подсказки» и «Недавно искали», уменьшил блок «Переводы по номеру» и назвал его «Делали переводы». На конверсию перевода это не повлияло, зато освободило заметное место на экране

2Пользователи интернет-банка на iOS получили привычный сценарий из мобильного приложения

Перевод по номеру телефона — частый сценарий, но у веб-версии не было доступа к контактам пользователя, в отличие от приложений. Я спроектировал онбординг подключения контактной книги через экспериментальную фичу Safari под названием Contact Picker API: она вызывает адресную книгу в нативном интерфейсе iOS и позволяет подставить номер контакта в нужное поле

Сценарий раскатан недавно, накопленных данных по конверсии пока нет

3Полноценное внедрение ИИ-ассистента

Двигался поэтапно: сначала на странице поиска появился анимированный Газик — пользователям нужно было время привыкнуть к маскоту, прежде чем он начнёт отвечать на вопросы

Позже команда сделала ML-классификатор: он определяет намерение пользователя и понимает, когда достаточно обычной поисковой выдачи, а когда нужен развёрнутый ответ. Для запросов вроде «какой лимит на переводы?», где нужен прямой ответ на месте, я спроектировал ответ ассистента с постепенным появлением текста, по аналогии с ChatGPT, — прямо поверх привычной выдачи. Рядом с ответом всегда висит дисклеймер, а если ассистент не уверен — сценарий сваливается в обычную поисковую выдачу

4Тиражирование точки входа на другие экраны 1 и 2 уровня

В качестве эксперимента продакт-оунер предложил разместить точку входа в поиск на всех экранах 1 и 2 уровней в веб-версии банка: согласно гипотезе, получится увеличить penetration поиска. Я согласовал размещение плавающей кнопки с владельцами экранов, при этом текст на ней учитывает контекст экрана. А если перейти по ней в поиск, то Газик будет предлагать релевантные запросы

Результат

Команда выкатывала изменения в течение нескольких релизов, и самый большой сдвиг произошёл в доле успешных сессий: удалось поднять метрику на 85% — с 40% до 74%. Большую часть этого прироста дали запросы с намерением на вопрос — раньше они просто падали в ошибку поиска, а с ассистентом стали доходить до ответа. А ещё у новых персональных кнопок-чипсов увеличился CTR на 50% по сравнению с обычными — сыграла ставка на персонализацию. Увеличилось и количество ежемесячных пользователей поиска — на 20%, а средняя оценка удовлетворённости выросла с 2,6 до 3,5. Но именно в оценке скрывалась неожиданная находка

40% → 74%

успешные поисковые сессии

2,6 → 3,5

удовлетворённость поиском

+50%

CTR персональных подсказок к статичным

+20%

MAU поиска в интернет-банке

Главный инсайт: 9 из 10 оценок — либо единица, либо пятёрка

Разбирая рост удовлетворённости, я посмотрел на распределение оценок за средним баллом: 46% — единицы, 43% — пятёрки,и только ~11% — всё, что между ними. Средний балл 3,5 описывал пользователя, которого не существовало: у поиска не было «средних» пользователей, были довольные и недовольные, и звёздная шкала прятала их друг за другом. Я инициировал переход на бинарную оценку like/dislike — она показывает реальное соотношение вместо фиктивной середины

Итоги работы и выводы

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

Следующий кейс — «Рабочий стол» →