После установки: почему возврат в AI-приложение начинается не с пуша
Мобильное приложение может успешно открываться и при этом каждый раз заставлять человека начинать сначала. Снова выбрать язык, вспомнить материал, найти нужное слово, понять, какое упражнение осталось незаконченным. Для продукта это несколько обычных экранов. Для пользователя это работа, которую приходится выполнить до самой практики.
После выпуска KeelAI в Google Play и App Store вопрос о возвращении особенно важен для нас как продуктовый критерий. Релиз в магазине завершает один процесс, но не отвечает на другой вопрос: что увидит человек, который установил приложение, попробовал его и вернулся после перерыва?
Ниже не отчёт о росте удержания и не история успешного A/B-теста. Это разбор трёх собственных продуктовых экранов и проект проверки сценария возвращения. Показываем, какие выводы допустимы по интерфейсу, а какие требуют наблюдений и событийной аналитики. Числа на скриншотах относятся к конкретным демонстрационным состояниям, не к результатам пользователей.
1. Возвращение начинается с незавершённой задачи
Представим рабочую ситуацию: сотрудник международной команды читает короткий текст на изучаемом языке, получает рабочий звонок и закрывает приложение. Вечером он открывает его снова. Его задача не обязательно звучит как «пройти следующий урок». Возможно, он хочет закончить именно тот текст или проверить слово, которое не успел разобрать.
Это проектный сценарий, а не описание конкретного клиента. Он полезен тем, что связывает возврат с наблюдаемым действием. Можно проверить, нашёл ли человек предыдущий материал, сколько лишних переходов сделал и продолжил ли работу. Формулировка «повысить вовлечённость» таких проверок сама по себе не задаёт.
Здесь стоит разделить три разных обещания интерфейса: помнить выбор, показывать предыдущую задачу и восстанавливать её состояние. Выбранный язык ещё не означает сохранённую позицию в тексте. Карточка последнего диалога ещё не доказывает, что после открытия начнётся нужная реплика. Каждое обещание проверяется отдельно.
Для команды это удобная единица планирования: не абстрактное «удержание», а конкретная цепочка от повторного открытия до продолжения. У такой цепочки есть начало, ожидаемый результат и понятные места поломки. Кроме того, её можно обсуждать совместно с разработчиком, дизайнером и автором учебного материала, не подменяя учебную задачу маркетинговым показателем.
И важно оставить альтернативу: после перерыва человек может передумать. Продолжить должно быть легко, но не обязательно. Переход к другому материалу не следует автоматически записывать в неудачу возвращения, особенно если пользователь осознанно сменил тему или язык.
2. Библиотека: короткий путь должен вести в правильное место
На нашем скриншоте библиотеки есть блок «Продолжить чтение». Он расположен выше каталога и показывает начатый материал, уровень и состояние чтения. Ниже находятся другие тексты. Уже по этой структуре видно различие между двумя задачами: продолжить начатое и выбрать новое.
Следующая проверка должна происходить не на картинке, а в работающем продукте. Открываем текст, читаем часть, выходим, возвращаемся. Сверяем название, язык, позицию и доступность действия. Затем повторяем сценарий после полного закрытия приложения. Если результаты различаются, это уже две разные пользовательские ситуации, даже при одинаковом внешнем виде карточки.
Отдельный случай: материал обновился или стал недоступен. Здесь нельзя бесконечно показывать привлекательную кнопку, которая ведёт в ошибку. Нужен понятный исход: открыть доступную версию, предложить начать заново или объяснить отсутствие материала. Честное объяснение лучше обещания продолжения, которое не выполняется.
Продуктовый вывод простой: оценивать стоит не наличие блока, а завершённость маршрута. На ревью полезно задавать вопрос не «у нас есть продолжение?», а «куда именно попадёт человек после перерыва и откуда интерфейс это знает?».
3. Аудиодиалог: восстановить место не значит восстановить понимание
С аудио задача сложнее. На скриншоте диалога видны тема, уровень, текущая реплика, управление воспроизведением и кнопки «Текст» и «Перевод». Это разные способы вернуться в содержание. Послушать предыдущую реплику, прочитать её и посмотреть перевод не одно и то же учебное действие.
Если человек остановился посреди диалога, механическое продолжение со следующей реплики может оказаться неудобным: ситуация уже забыта. Но автоматический показ перевода тоже меняет упражнение. Поэтому в проектируемом сценарии стоит различать возврат к месту и добровольное восстановление контекста. Например, предложить повторить предыдущую реплику, сохранив возможность двигаться дальше.
Это предложение для проверки, а не утверждение о реализованной функции. На наблюдении важно записать, что человек выбрал сам: продолжил, повторил, открыл текст или вернулся к началу. И спросить почему. Одинаковое нажатие может означать забытый контекст, непонятную кнопку или желание ещё раз потренировать произношение.
В аналитике нельзя безоговорочно считать повторное прослушивание потерей времени. Для обучения повтор может быть осмысленным действием. Плохим признаком будет другой сценарий: человек ищет нужную реплику, несколько раз перезапускает всё упражнение и так и не возвращается к собственной задаче.
4. Словарь: история поиска и избранное решают разные задачи
Третий экран показывает словарь с областями History и Favorites. В представленном состоянии обе пустые. Это важная оговорка: скриншот подтверждает наличие элементов интерфейса, но не позволяет утверждать, что история заполнена, синхронизируется между устройствами или действительно помогает возвращению.
История отвечает на вопрос «что я открывал?». Избранное отвечает на вопрос «что я решил сохранить?». Если смешать эти сущности, пользователь получит список, смысл которого придётся угадывать. Случайно найденное слово не равно слову, которое человек хочет повторить перед рабочим созвоном.
Для проверки нужен короткий маршрут: найти слово, открыть карточку, сохранить её, уйти и вернуться. Затем проверить отдельно поиск недавнего слова и доступ к сохранённому. Полезно повторить сценарий после смены языка: человеку должно быть понятно, к какому языку относится найденная запись, а не только как она переводится.
Пустое состояние тоже часть возвращения. Если история исчезла, нельзя маскировать это приветствием новичку. Но и обещать синхронизацию, которой нет, нельзя. Требование к интерфейсу должно следовать из реального способа хранения данных и поведения приложения, а не из привлекательности текста на экране.
5. Как проверить гипотезу без красивых, но пустых цифр
Для такого разбора мы используем собственные экраны KeelAI: чтение, аудиодиалог и словарь дают три разных сценария возвращения. Но наличие этих экранов ещё не доказывает бизнес-эффект. Для выводов нужен заранее определённый план наблюдения.
Начать можно с модерируемой проверки. Дать человеку конкретную задачу, прервать её в известной точке и затем попросить продолжить. Не подсказывать расположение кнопки. Записывать не только успех, но и ошибочные переходы, восстановление контекста и объяснение самого участника. Условия перерыва должны быть одинаковыми для сравниваемых вариантов.
- Основной результат: смог ли человек продолжить выбранную задачу, а не просто открыть нужный раздел.
- Диагностика: сколько действий потребовалось до продолжения и где возникла необходимость искать материал заново.
- Защитная проверка: не потерялись ли язык, позиция, сохранённое слово или доступ к материалу.
- Обратная связь: понял ли человек, что восстановилось автоматически, а что ему пришлось выбрать самостоятельно.
Для событийной аналитики понадобятся согласованные определения. Например, повторное открытие после перерыва, показ действия продолжения, его выбор и фактическое открытие прежней задачи. Повторные доставки одного события нужно исключать. Количество нажатий без числа людей, которым действие вообще показывалось, не даёт интерпретируемой доли.
Это проект измерения, не описание уже внедрённой схемы событий. До запуска следует зафиксировать длину перерыва, окно наблюдения, единицу сравнения и правила учёта повторных сессий. Иначе удобный результат легко получить простым изменением определения «вернувшегося пользователя».
6. Что это меняет для продукта и бизнеса
Переход из статьи, установка приложения, возвращение к материалу и оплата отвечают на разные вопросы. Первый показывает интерес к предложению, второй готовность попробовать формат. Продолжение практики говорит о конкретном поведении. Оплата отражает отдельное решение, зависящее в том числе от доступного предложения и условий использования.
Поэтому нельзя объявлять улучшение маршрута причиной роста выручки только потому, что показатели выросли одновременно. Мог измениться источник аудитории, состав языков, версия приложения или платёжный сценарий. Для причинного вывода нужны подходящий дизайн сравнения и достаточные наблюдения, а не удачный график за несколько дней.
Практический порядок работы такой: сначала проверить восстановление состояния, затем понятность выбора, после этого сравнивать поведение пользователей. Разработчик получает воспроизводимые сценарии, дизайнер видит точки неопределённости, а маркетинг понимает, какое обещание можно честно выносить в коммуникацию. Это небольшая, но общая задача нескольких функций команды.
После выхода в магазины легко переключиться на следующие установки и напоминания. Но перед новым приглашением вернуться полезно пройти путь уже пришедшего человека. Приложение должно не только напомнить о себе, но и помочь вспомнить собственную задачу. Именно это обещание стоит сначала проверить на реальном экране.