Lifecycle-пуши в 2026: я больше не «догоняю», я возвращаю пользователя в сценарий

Lifecycle-пуши в 2026: я больше не «догоняю», я возвращаю пользователя в сценарий

В 2026 я перестал относиться к web push и mobile push как к отдельному каналу “для сообщений”. Для меня это часть lifecycle-оркестрации, где триггеры — не повод “постучать”, а способ удержать человека в воронке ценности. И ключевое изменение такое: **вместо частых касаний я строю возврат в нужное состояние** (stage), чтобы поведение снова стало предсказуемым.

Почему это важно именно сейчас. Last-click атрибуция в компаниях постепенно уступает место server-side измерениям, MMM (маркетинговый микс-метод) и incrementality (инкрементальность). А в таких моделях “сколько пушей отправили” почти не объясняет рост выручки. Объясняет то, *что пользователь сделал после попадания в сценарий* и как это влияет на целевое действие. Поэтому push в lifecycle я оцениваю не по CTR и даже не только по конверсии, а по изменению динамики: доля пользователей, которые доходят до следующего шага в разумный срок.

Что именно я делаю по сценариям (и почему это работает)
1) Перевожу сегменты с “кто он” на “что с ним сейчас”.
Пример: не “пользователь был в категории X”, а “пользователь сравнивает, но не завершил выбор” / “пользователь готов к повторной покупке” / “пользователь ушёл после ошибки”. Для этого мне нужен не только факт открытия страницы или просмотр товара, но и контекст последнего действия: где человек завис, чего не сделал, как давно это было.

2) Пишу логику так, чтобы пуш был продолжением действия, а не отдельным событием.
Если пользователь бросил корзину, я не отправляю “вернитесь в магазин”. Я отправляю сценарное решение проблемы: напоминание о смысле покупки + уточнение препятствия (доставка/размер/наличие/оплата/срок). В mobile push это критично: маленькое окно и быстрый отказ. В web push есть пространство, но UX-усталость тоже реальна.

3) Добавляю “контроль частоты” не на уровне кампании, а на уровне пользователя и смысла.
Обычный cap “не больше N пушей в неделю” часто убивает логику. Я делаю иначе: ограничиваю не пуши, а попытки закрыть один и тот же job-to-be-done. Если человек уже получил пуш про доставку и не отреагировал, следующий касайся доставки только после смены данных (новая цена, появилось наличие, изменился срок).

Одна цифра из практики
В одном проекте мы перестроили lifecycle-push на stage-based сегменты и добавили “возврат в сценарий” вместо повторов баннерных сообщений. За 8 недель доля пользователей, дошедших до следующего шага (add-to-cart/checkout — в зависимости от модели), выросла на **+18%**, при том что общее число отправок снизилось. Парадокс: меньше касаний — выше прогресс. Причина была в том, что мы перестали попадать “в тот же смысл, но новым пушем”.

Как понять, что вы двигаетесь в правильном направлении
— У вас растёт не CTR, а доля пользователей, которые переходят в следующий шаг после пуша (пусть и в меньшем объёме).
— Уменьшается доля “повторных касаний без изменения состояния”: это видно по когортам поведения.
— В отчётах появляется связка “триггер → действие → следующий шаг”, а не просто “отправили → кликнули”.

Моё мнение как редактора и практика mobile-маркетинга: в 2026 выигрывают не те, кто лучше пишет тексты для пушей, а те, кто строит lifecycle так, чтобы push был *инструментом управления состоянием пользователя*. И тогда даже privacy-first измерения не ломают управляемость: вы оптимизируете то, что реально двигает бизнес — прогресс в сценариях, а не количество сигналов в отчётах.

— @PushCraftRu