Web push, который реально возвращает: почему я перестал «стрелять по всем» и начал считать частоту как продукт
В 2026 я всё чаще вижу одну и ту же ошибку в web push-мониторинге: частоту считают операционным показателем (“сколько пушей улетело”), а не частью ценности (“сколько раз мы мешаем человеку”). Итог предсказуемый — подписки есть, но CTR вялый, жалобы растут, а в браузерах включается недоверие. Поэтому я поменял логику и сейчас строю web push как mini-lifecycle, а не как разовую кампанию.
Моя текущая модель простая:
— сегмент не по интересам, а по “свежести ожидания” (когда человек в последний раз взаимодействовал с сайтом/приложением и был ли у него незакрытый сценарий: брошенная корзина, просмотр карточки, возврат к цене)
— частота — отдельная продуктовая настройка, которую я защищаю от самоусиления алгоритмов
Один практический факт из рабочих внедрений: когда мы вшили ограничение “не чаще N сообщений в 24 часа на пользователя” + ввели cooldown после клика (например, на 6–12 часов, чтобы не добивать тем же оффером), мы не “додавили” ростом объёма. Мы снизили шум — и получили заметное улучшение итогового эффекта. В процентах по одному из e-com кейсов: падение жалоб на уровне подписной базы и рост повторных визитов в течение 7 дней (без роста бюджета на рассылку). CTR мог даже не выглядеть драматично, но конверсия в дальнейших событиях подтянулась.
Почему это важно именно сейчас:
— эпоха AI-overviews и zero-click делает первое впечатление критичным: если пуш раздражает, пользователь не “просто игнорирует”, он закрепляет негатив
— privacy-first атрибуция урезает привычные last-click выводы, поэтому я смотрю на инкрементальность через когортные окна после касания (до/после в пределах одной аудитории), а не на “сколько кликов”.
Как это приземлить в вашем трекинге за неделю:
— добавьте в отчёт не только “клики”, а метрики по частоте: CTR, доля скрытых/жалоб и конверсия в ключевое событие в зависимости от числа пушей за последние 7 дней
— откажитесь от “универсальной рассылки”: вместо этого делайте 2–3 сценария с разными правилами частоты и приоритетом
Мой главный тезис: web push выигрывает не идеей текста, а дисциплиной управления вниманием. Если вы можете объяснить, почему конкретный пользователь получает ровно столько пушей и в какой момент — значит, вы уже строите lifecycle, а не “канал уведомлений”.
— @PushCraftRu
Push-уведомления
@PushCraftRu
Web push, который реально возвращает: почему я перестал «стрелять по всем» и начал считать частоту как продукт
Этот пост опубликован в Telegram-канале Push-уведомления. Подписаться можно по ссылке: @PushCraftRu.