Сквозной поиск

Контекст

• Платформы: iOS, Android, Web.
• Команда: продакт, техлид, аналитик, 3 разработчика, 3 тестировщика.
• Период: декабрь 2025 – июль 2026.

Проблема

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

Моя задача

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

Исследование и бенчмаркинг рынка

Совместно со специалистами клиентского опыта провели исследование текущего сценария и выявили несколько проблем:

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

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

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

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

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

Тестировал точечно — там, где риск ошибки был выше или решение было неочевидным (например, Contact Picker API и его онбординг): для этого использовал коридорные тесты. По менее рискованным гипотезам опирался на данные исследования и практику рынка, а также на self-serve инструменты через Pathway: AB-тесты, тест первого клика, тепловые карты.

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

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

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 — она показывает реальное соотношение вместо фиктивной середины.

46% 1

11% 2–4

43% 5

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

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

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