Напоминание пришло. Практика не началась: как языковому приложению возвращать пользователя к делу
Вечером телефон напоминает: «Пора заниматься». Человек нажимает на уведомление, попадает на главный экран, видит несколько вариантов практики и закрывает приложение. Открытие состоялось. Учебная попытка — нет. Для маркетингового отчёта это может выглядеть как возвращённый пользователь; для человека это ещё одно прерывание, которое не помогло начать.
Нам в KeelAI важно разделить эти два события. Мы строим языковые приложения, поэтому уведомление имеет смысл не само по себе, а рядом с конкретной задачей: ответить собеседнику, разобрать реплику, вспомнить слово. Ниже — разбор нашего утверждённого продуктового стандарта и план его проверки. Это не рассказ об эксперименте с ростом конверсии: таких результатов здесь не заявляем. Иллюстрации показывают проектную логику, а не выдают макеты за уже выпущенные экраны.
1. Человек согласился практиковаться, а не получать всё подряд
В нашем стандарте есть два независимых решения. «Напоминать о практике» относится к учебному расписанию. «Советы по обучению» объединяет сообщения о тестах уровня, новых функциях, языках и приложениях. Советы выключены по умолчанию и не включаются вместе с напоминаниями. Этот выбор кажется мелочью, пока команда не пытается отправить новость о продукте всем, кто однажды попросил напомнить об уроке.
Разница не в длине сообщения. «Завтра потренируем уточняющие вопросы» и «У нас появилось новое приложение» могут занимать одинаковое место на экране, но отвечают на разные ожидания. В первом случае человек попросил поддержать его режим. Во втором продукт приглашает попробовать что-то ещё. Если эти обещания смешать, у пользователя остаётся грубый инструмент: выключить всё, включая полезные напоминания.
Рабочая проверка начинается с вопроса: на какое именно согласие опирается это сообщение? Ответ «он наш пользователь» недостаточен. Для каждого типа доставки нужно понимать категорию, доступную платформу и способ отказа. Мы не делаем из этого юридический разбор: здесь обсуждаем продуктовую границу. Принятый стандарт также требует сохранять ранее данное согласие и прекращать объединённые категории при выключении советов.
Для бизнеса такая граница не обязательно означает меньше возможностей. Она делает понятным, кому действительно интересны новые инструменты, а кто пришёл только заниматься. Эти группы можно изучать отдельно, не приписывая одинаковую мотивацию всем активным аккаунтам.
2. Расписание — договорённость, у которой должна быть пауза
В настройках учебных напоминаний предусмотрены время и пауза на неделю. Дни недели показываются только там, где расписание их поддерживает. Это важное ограничение: интерфейс не должен изображать возможность, которую доставка не умеет выполнять. На одной платформе может работать один механизм, на другой — другой, но пользователю не нужно разбираться в устройстве очередей сообщений.
Пауза отличается от отказа. Человек может уехать, заболеть, сменить рабочую неделю или просто не хотеть вечерних уведомлений несколько дней. Если единственный выход — отключить напоминания полностью, продукт теряет информацию о намерении. Он видит «не хочет получать», хотя реальное решение было «не сейчас». Временное молчание — нормальный пользовательский сценарий, а не поломка вовлечённости.
Проверять здесь стоит не только сохранение переключателя. После включения паузы запланированное сообщение не должно продолжать приходить из старой очереди. После возобновления не нужен накопленный поток пропущенных напоминаний. При смене времени важно сверить видимое расписание с фактической доставкой. Это пункты проверки, а не утверждение, что каждую такую неисправность мы уже нашли у себя.
Наконец, не стоит обещать точную частоту там, где её нельзя гарантировать. В принятом стандарте прямо записано: показывать только работающие настройки платформы. Для человека честное ограничение полезнее красивого меню, которое ведёт себя непредсказуемо.
3. Куда ведёт нажатие: в каталог или к первой реплике
Учебное напоминание должно пройти путь дальше системного экрана. Представим тренировочное задание: на английском уточнить, какую версию презентации коллега ждёт завтра. Это вымышленная учебная ситуация, не клиентский кейс. Если уведомление обещает короткую практику этой задачи, после нажатия пользователь должен узнавать обещанный контекст, а не заново выбирать язык и искать упражнение.
Не во всех приложениях возможен прямой переход к конкретному заданию. Тогда честнее вести к ближайшему понятному действию и не обещать то, чего нет. Плохая связка — точное приглашение с неопределённым продолжением. Хорошая — короткое приглашение и экран, на котором человек сразу понимает, что делать. Между ними нельзя внезапно добавлять ненужный запрос доступа к микрофону, если задание можно начать текстом.
Для тестирования нужен целый маршрут: приложение закрыто; пользователь нажал уведомление; нужный экран появился; первая попытка сохранена. Затем тот же маршрут стоит проверить при открытом приложении и после паузы в занятиях. Сохранённое состояние может влиять на переход: старая незаконченная задача не должна незаметно подменять новую. Само наличие ссылки ещё не доказывает, что этот путь работает.
Первая попытка — более содержательное событие, чем открытие. В диалоге это самостоятельная реплика, в словаре — ответ на задание, в чтении — действие внутри практики. Точное определение зависит от режима, но его нужно записать до измерения, иначе команда будет сравнивать несопоставимые события.
4. Что считать успехом, если CTR недостаточно
Доля открытий полезна для диагностики текста и доставки. Она не отвечает на вопрос, состоялось ли обучение. Сообщение с интригующим обещанием может собрать нажатия и привести к разочарованию. Сдержанное напоминание может привлечь меньше людей, но привести тех, кто действительно готов сделать задание. Без следующего события команда этого различия не увидит.
Минимальная цепочка измерения выглядит так: полученное уведомление, открытие, первая учебная попытка, завершение выбранной задачи. Для каждого перехода нужен собственный знаменатель. Нельзя назвать долю завершений среди открывших сообщением о доле завершений среди всех получивших. Нельзя также складывать нажатия одного человека и считать их разными вернувшимися учениками.
Рядом с этой цепочкой нужны ограничения: выключение напоминаний, использование паузы, жалобы на нерелевантность, повторные открытия без практики. Пауза сама по себе не отрицательная метрика: она может означать, что управление удобно. Но её изменение вместе с жалобами — повод проверить время и содержание доставки. Оптимизировать стоит не только возвращение, но и цену этого возвращения для пользователя.
На этих схемах намеренно нет процентов. Мы не располагаем в этом материале проверенным сравнением вариантов и не будем подменять его убедительной диаграммой. Сначала нужны согласованные определения событий и данные о доставке; затем можно обсуждать эффект.
5. Как проверить гипотезу, не перепутав напоминание с эффектом продукта
Практичный эксперимент начинается не с десятка сообщений, а с одного вопроса. Например: помогает ли возвращение к выбранной задаче чаще совершать первую попытку, чем возвращение на общий экран? Это предложенная схема проверки. Она не означает, что такой эксперимент уже проведён в KeelAI или что один вариант заранее лучше.
Сравнивать нужно людей с сопоставимым намерением: одинаковой категорией согласия, доступной платформой и похожим этапом знакомства с продуктом. Если в один вариант попали новые пользователи, а в другой — давно занимающиеся, результат легко приписать уведомлению по ошибке. Время наблюдения и правило остановки тоже определяют заранее, а не выбирают после появления красивой цифры.
Особенно полезны несколько ручных проходов до запуска измерения. Проверить, что происходит после нажатия, можно раньше, чем накопятся данные. Если участники не находят задание или получают лишний экран, эксперимент будет измерять ошибку маршрута. Это не исследование образовательного эффекта. После устранения проблемы проверку начинают заново с понятной исходной точкой.
Посмотреть доступные варианты языковой практики можно в KeelAI. Для нас этот сценарий связывает продукт и коммуникацию: приглашение должно соответствовать тому действию, которое человек реально сможет выполнить. Сам переход по ссылке не подтверждает ни регистрацию, ни оплату, ни результат обучения.
6. Что команда должна решить до следующей отправки
На обсуждении уведомлений полезно держать рядом три артефакта: карту согласий, маршрут возвращения и определения событий. Маркетинг видит, какую аудиторию можно приглашать. Дизайнер — где человек принимает решение и где начинает задание. Разработчик — какие условия нужно проверить перед отправкой и какое состояние сохранить после нажатия. Аналитик — где заканчивается доставка и начинается практика.
Отдельно стоит фиксировать ограничения выпуска. В нашем стандарте изменение меню для Apple включается в следующий выпуск вместе с другими изменениями, а не отправляется отдельной сборкой только ради этого меню. Для Android и web в отдельных приложениях действуют ограничения рекламных push. Поэтому наличие общего правила не следует выдавать за одновременную доступность каждой возможности во всех сборках.
Хорошее напоминание не требует героического внимания. Пользователь понимает, почему оно пришло, может отложить его без наказания и после нажатия получает обещанное действие. Продуктовая команда, в свою очередь, отличает нажатие от попытки и не называет возвращением к учёбе обычное открытие экрана. Именно эту границу стоит проверить прежде, чем обсуждать более настойчивые тексты и более частую доставку.