Push-уведомления

Web push работает так: посетитель один раз разрешает уведомления, и дальше вы можете слать ему анонсы, акции, новые статьи. Подписка не требует ни email, ни телефона — отсюда быстрый сбор базы. Это дешёвый канал возврата: новый пост вышел, нажали кнопку — часть аудитории вернулась на сайт в тот же час.

Обратная сторона — лёгкость скатиться в спам. Три уведомления в день про скидки, и человек отпишется или вовсе заблокирует push на уровне браузера. Работает мера: слать по делу, сегментировать базу, не дёргать людей по ночам. Push хорошо дополняет email-маркетинг и удержание, но сам по себе чудес не делает.

Под капотом web push держится на трёх элементах: Service Worker (фоновый скрипт, который ловит сообщение, даже когда вкладка закрыта), Push API браузера и сервере-отправителе, подписанном ключом VAPID. Важное ограничение: на iOS web push до недавнего времени просто не работал — Safari принимает их только начиная с iOS 16.4 и лишь для сайтов, добавленных на домашний экран как PWA. Поэтому база подписчиков почти всегда перекошена в сторону Android и десктопа, и оценивать охват надо с поправкой на это.

Ключевые метрики канала — Opt-in Rate (доля согласившихся из тех, кому показали запрос; здоровые 5-10%) и CTR пуша (часто 4-12%, в разы выше email). Главная техническая ошибка — вызывать системный запрос на разрешение в первую же секунду визита: браузер запоминает отказ, и второй раз спросить уже нельзя, человек потерян навсегда. Правильно показывать сначала свой мягкий «пред-запрос» (например, после прочтения статьи или добавления товара в корзину) и только согласившимся отдавать системное окно. На органический трафик push влияет косвенно — через возвраты и удержание, дополняя email-маркетинг, а не заменяя его.