Web push умер не от плохой доставки, а от плохого повода

Web push умер не от плохой доставки, а от плохого повода

Я всё чаще вижу одну и ту же ошибку в CRM-командах: web push запускают как «ещё один бесплатный канал», а не как часть сценария удержания. В итоге сообщения получаются шумными, частота растёт, а вклад в выручку — нет.

Моё мнение простое: в 2026 году web push, mobile push и in-app нельзя мерить только по кликам. В эпоху privacy-first атрибуции и размытого last-click канал должен доказывать не трафик, а **изменение поведения**. Вернулся ли пользователь? Дошёл ли до ключевого действия? Ускорил ли повторную покупку или реактивацию? Если ответа нет, канал обслуживает видимость, а не LTV.

Из практики: в одном e-com-проекте мы убрали 38% push-рассылок, потому что они дублировали email и in-app, и оставили только три типа касаний: брошенная корзина, падение интереса и постпокупочный триггер. Открытий стало меньше, зато выручка на одного подписчика выросла. Не потому что сообщения стали «красивее», а потому что исчез мусор.

Я бы вообще смотрел на push как на **слой оркестрации** между каналами, а не как на самостоятельный инструмент.
— web push хорош для быстрых напоминаний в сессии
— mobile push — для возврата в приложение и привычки
— in-app — для объяснения следующего шага внутри продукта

Если у вас есть сегментация, но нет логики следующего лучшего действия, push превращается в календарь уведомлений. А если есть сценарии, контекст и частотный контроль, он начинает работать как retention-механика, а не как раздражитель.

Мой ориентир простой: каждое уведомление должно отвечать на вопрос «зачем пользователь должен увидеть это именно сейчас?». Если ответа нет — лучше не отправлять.