Nike: как in-app сообщения превратили «пуш-эхо» в сценарий возврата в приложение

Nike: как in-app сообщения превратили «пуш-эхо» в сценарий возврата в приложение

Контекст
В спортивных приложениях человек редко «зависает» в одной сессии: сегодня оформил тренировку, завтра потерял мотивацию, потом вернулся через неделю-две. В 2026 это усиливается — люди меньше реагируют на “просто напоминания”, а алгоритмы (в том числе в браузерах и поиске) всё чаще закрывают частично задачу контентом «снаружи». Поэтому бренд выигрывает там, где может дать ценность внутри приложения: персональный маршрут действий и быстрые шаги к цели.

Задача
Nike (в экосистеме Nike Training/Run и связанных функций) регулярно сталкивался с типовой проблемой lifecycle:
— пользователи после первой активности снижали частоту сессий
— уведомления и сообщения в приложении отправлялись “по факту”, без привязки к следующему логическому действию
— бренд терял часть аудитории на этапе «знаю, но не начинаю»
Цель: увеличить возврат в приложение и долю пользователей, которые доводят начатое до следующего шага (занятие/запуск трека/возврат к плану).

Решение
Команда переработала in-app messaging в сценарий, а не в набор сообщений. Ключевые элементы были такими:

1) Разделили сегменты не по “статусу активности”, а по “намерению на последнем шаге”
Например:
— «посмотрел план, но не начал»
— «начал тренировку, но не завершил»
— «был в ран-режиме, но слетела сессия»
Смысл: сообщение должно продолжать путь, а не просто “напоминать о приложении”.

2) Встроили in-app сообщение в нужную точку пользователя (а не по времени из календаря)
Напоминания показывали не “через 24 часа”, а при открытии ключевого экрана: если человек возвращался в раздел планов, ему показывали продолжение именно этого плана. Если открывал статистику после паузы — предлагали короткий “вход” (короткая тренировка/микро-сессия).

3) Использовали A/B тесты формата: баннер против модалки и разные CTA
Вместо одного текста тестировали:
— размер и приоритет блока в интерфейсе (баннер сверху/в середине/полноэкранный блок)
— формулировку CTA под действие («Продолжить» vs «Запустить сейчас» vs «Выбрать тренировку на сегодня»)
— наличие “микро-обещания” результатом, но без перегруза (например, акцент на длительности занятия и простом старте)

4) Ограничили частоту показа и ввели “порог полезности”
Если пользователь уже выполнил целевое действие, in-app переставал давить. Если игнорировал два сценария подряд — переходили в более мягкий режим: не “запусти тренировку”, а “подборка под текущее состояние/цель” (то есть меняли тип ценности).

Результат
По внутренним метрикам (в формате типовых отчетов по продуктовой аналитике) сценарный подход дал измеримый эффект на поведенческих конверсиях:
— рост доли пользователей, которые возвращаются в приложение и делают следующий шаг по сценарному действию
— снижение доли “пустых” показов in-app сообщений (когда пользователь не совершал продолжение в разумное окно после открытия)
— более стабильное удержание в когортах после паузы: не всплески от разовых пушей, а последовательный возврат
В практическом измерении это выглядело так: пользователи чаще доходили до запуска занятия/трекера именно в момент повторного открытия соответствующего раздела.

Уроки
1) In-app messaging выигрывает, когда он продолжает действие, а не сообщает “о наличии приложения”.
2) Сегментация по “намерению последнего шага” точнее, чем сегментация по времени или общему статусу.
3) A/B стоит проводить не только по тексту, но по формату (баннер/модалка) и CTA, потому что это влияет на пропускную способность интерфейса.
4) Frequency capping и смена типа ценности предотвращают выгорание: иначе рост кликов превращается в падение смысла.

Если вы строите lifecycle и у вас “сообщения есть, а сценариев нет” — начните с одного экрана и одного намерения (например, «посмотрел план, но не начал») и доведите до следующего действия. Именно там обычно прячется лучший прирост.

— @InAppMessagingRu