Почему web push умирает не из-за блокировок, а из-за плохого повода

Почему web push умирает не из-за блокировок, а из-за плохого повода

Я часто вижу одну и ту же ошибку: команды запускают web push как «дешёвый канал дожима», а потом удивляются, что CTR падает, отписки растут, а возврат в приложение или на сайт почти не меняется. Проблема не в самом канале. Проблема в том, что его используют без причины, которую пользователь действительно считает значимой.

Для мобильного маркетинг-менеджера web push, mobile push и in-app — это не три независимых инструмента, а одна система частоты, контекста и права на внимание. И в 2026 году это особенно заметно: когда растёт роль retention и LTV, а цена первого касания уже не окупает грубую коммуникацию, выигрывают не те, кто шлёт больше, а те, кто шлёт точнее.

У меня в практике был типичный сценарий: ecommerce-команда отправляла web push на все сегменты с одним и тем же оффером. Охват был нормальный, клики тоже, но вклад в повторные покупки почти не рос. Когда мы разделили сценарии на три уровня — поведенческий триггер, ценностный повод и сервисное сообщение — частота отправок снизилась почти на треть, а доля возвратов из пушей выросла примерно на 18%. Не потому что текст стал «красивее». А потому что сообщение стало уместным.

Мой вывод простой: **пуш — это не про канал, а про момент**.

Если смотреть на это как на систему, я бы держал такой порядок:
— web push — для возвращения в моменте, когда пользователь ещё «тёплый»;
— mobile push — для регулярного удержания и сценариев привычки;
— in-app — для объяснения, обучения и мягкого дожима внутри опыта.

И ещё одна вещь, которую многие недооценивают: в эпоху AI-генерации креативов конкуренция идёт не в количестве вариантов, а в логике триггера. Текст может написать модель. А вот понять, почему человек должен увидеть его именно сейчас, всё ещё должен маркетолог.

Если в вашей системе пуши «работают в целом», но не двигают LTV, я бы начинал не с частоты, а с ревизии поводов.