Web push умер не от блокировщиков, а от плохой роли в воронке

Web push умер не от блокировщиков, а от плохой роли в воронке

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

Моё мнение простое: **web push нельзя оценивать по открываемости в отрыве от сценария**. Если сообщение не связано с событием в поведении пользователя, оно почти всегда проигрывает email и in-app по качеству контакта. А если связано — может обгонять их по скорости реакции.

На практике у нас лучше всего работают три класса сценариев:

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

Один наблюдение из кампаний: когда мы перестали слать web push по общим сегментам и оставили только поведенческие триггеры, доля переходов выросла почти вдвое, а отписки заметно упали. Причина не в магии канала, а в том, что сообщение стало уместным.

Что я считаю важным в 2026 году:
— web push — это не replacement для email, а быстрый слой поверх lifecycle;
— мобильный push остаётся сильнее по удержанию, но web push полезен там, где пользователь уже в браузере и не требует установки;
— in-app лучше всего работает как объяснение и обучение, а не как дубль пуша.

Если у канала нет своей роли в системе CRM, он превращается в шум. А в эпоху, где retention важнее первой покупки, шум — слишком дорогая ошибка.

—
Хочешь больше marketing? @LifecycleMarketingRoomPro