Зачем вообще нужны push-уведомления

Давайте начнём с простого. Пользователь зашёл на ваш сайт, посмотрел пару страниц и ушёл. Классическая ситуация. Раньше единственным способом вернуть его была email-рассылка — но для этого нужно было сначала получить адрес почты, потом пробиться через спам-фильтры, а потом надеяться, что письмо вообще откроют.

Web push работает иначе. Пользователь нажимает одну кнопку «Разрешить» — и всё, вы можете отправлять ему короткие сообщения прямо в браузер. Даже когда вкладка с вашим сайтом закрыта. Даже когда браузер свёрнут.

Вот несколько сценариев, где пуши реально полезны:

  • Интернет-магазин напоминает о брошенной корзине: «Вы отложили кроссовки, но так и не оформили заказ»
  • Новостной портал присылает дайджест за день или срочную новость
  • SaaS-сервис оповещает о завершении обработки файла или об обновлении тарифа
  • Образовательная платформа напоминает о начале вебинара через 15 минут

Средняя конверсия подписки на пуши — от 3% до 10% в зависимости от ниши. Это заметно выше, чем у формы подписки на email. И логично: нажать «Разрешить» проще, чем вводить почтовый адрес.

Как это работает под капотом

Прежде чем подключать какой-то сервис, полезно понимать, что происходит технически.

Service Worker — невидимый помощник

В основе web push лежит Service Worker — это JavaScript-файл, который браузер запускает в фоне, отдельно от вашей страницы. Он работает даже когда вкладка закрыта. Именно Service Worker «слушает» входящие push-сообщения и решает, как их показать пользователю.

Регистрация выглядит просто:

// Регистрируем Service Worker
navigator.serviceWorker.register('/sw.js');

А в самом файле `sw.js` вы обрабатываете событие `push`:

self.addEventListener('push', (event) => {
  const data = event.data.json();
  event.waitUntil(
    self.registration.showNotification(data.title, {
      body: data.body,
      icon: '/icon-192.png',
      data: { url: data.url }
    })
  );
});

self.addEventListener('notificationclick', (event) => {
  event.notification.close();
  event.waitUntil(clients.openWindow(event.notification.data.url));
});

VAPID-ключи — ваш пропуск в систему

Чтобы отправлять пуши, серверу нужно доказать свою личность. Для этого используются VAPID-ключи — пара из публичного и приватного ключа. Публичный ключ вы передаёте в браузер при подписке, приватный — храните на сервере.

Сгенерировать ключи можно через npm-пакет `web-push`:

npx web-push generate-vapid-keys

Результат — две строки. Публичный ключ пойдёт на фронтенд, приватный — в переменные окружения на сервере. Никакой регистрации в Google или Apple для этого не нужно — VAPID-ключи вы создаёте сами.

Схема взаимодействия

Вся цепочка выглядит так:

  1. Пользователь заходит на сайт, браузер регистрирует Service Worker
  2. Вы показываете запрос на подписку (нативный или кастомный)
  3. Пользователь нажимает «Разрешить»
  4. Браузер создаёт объект подписки (`PushSubscription`) с endpoint и ключами шифрования
  5. Вы отправляете этот объект к себе на сервер и сохраняете
  6. Когда нужно послать уведомление, сервер подписывает запрос VAPID-ключами и отправляет его на endpoint
  7. Push-сервис (Google FCM, Apple APNs и т.д.) доставляет сообщение в браузер
  8. Service Worker получает событие `push` и показывает уведомление

Важный момент: endpoint зависит от браузера. Chrome использует `fcm.googleapis.com`, Safari — `web.push.apple.com`. Но вам не нужно об этом думать, если вы используете библиотеку `web-push` на Node.js — она сама разберётся, куда отправлять.

Что изменилось к 2026 году

Браузеры стали строже

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

Что это значит на практике: нужен предварительный шаг. Покажите сначала свой кастомный баннер или попап с объяснением — «Хотите получать уведомления о скидках?». И только после клика на «Да, хочу» вызывайте `Notification.requestPermission()`. Это называется двухшаговая подписка, и сейчас это фактически стандарт.

iOS наконец-то в игре (но с оговорками)

Долгое время web push не работал на iPhone — и это была главная боль. Начиная с iOS 16.4, Apple добавила поддержку Web Push для PWA. Но есть нюанс: уведомления приходят только в веб-приложения, добавленные на домашний экран. Просто открыть сайт в Safari и получать пуши — не получится.

Для разработчика это значит вот что:

  • У сайта должен быть корректный `manifest.json` с иконками
  • Пользователь должен вручную добавить сайт на Home Screen
  • Только после этого можно запрашивать разрешение на уведомления

Это ограничение довольно существенное, но для лояльной аудитории — вполне рабочий вариант. Если у вас, например, образовательная платформа или сервис доставки, пользователи готовы добавить вас на экран.

Legacy FCM API больше не работает

Если вы настраивали пуши пару лет назад через Firebase Cloud Messaging, проверьте — не используете ли вы устаревший Legacy API. В 2026 году актуален HTTP v1 API. Старые endpoint'ы могут перестать работать в любой момент, если ещё не перестали. Это тот случай, когда «работает — не трогай» может дорого обойтись.

Два пути: свой код или готовый сервис

У вас есть два варианта подключения push-уведомлений, и выбор зависит от задачи.

Вариант 1: Написать всё самому

Если вы разработчик и вам нужен полный контроль — это ваш путь. По сути, нужно сделать три вещи:

  1. Service Worker — файл в корне сайта, обрабатывающий события `push` и `notificationclick`
  2. Клиентский скрипт — регистрация SW, запрос разрешения, получение `PushSubscription` и отправка на сервер
  3. Серверная часть — хранение подписок и отправка уведомлений через библиотеку `web-push`

На Node.js серверная часть выглядит примерно так:

import webpush from 'web-push';

webpush.setVapidDetails(
  'mailto:you@example.com',
  process.env.VAPID_PUBLIC_KEY,
  process.env.VAPID_PRIVATE_KEY
);

// Отправка уведомления конкретному подписчику
async function sendPush(subscription, payload) {
  try {
    await webpush.sendNotification(
      subscription,
      JSON.stringify(payload)
    );
  } catch (err) {
    if (err.statusCode === 410) {
      // Подписка протухла — удаляем из базы
      await removeSubscription(subscription.endpoint);
    }
  }
}

Плюсы: бесплатно (за исключением серверных расходов), полный контроль, никаких зависимостей от сторонних сервисов.

Минусы: нет готовой аналитики, сегментации, A/B-тестов. Всё это придётся строить самому.

Этот путь подходит для проектов, где нужна глубокая интеграция с бэкендом — транзакционные уведомления, персонализированные триггеры.

Вариант 2: Использовать специализированный сервис

Если нужно быстро запуститься и не хочется возиться с инфраструктурой — берите готовый сервис. Вот проверенные варианты на 2025–2026 год:

OneSignal — наверное, самая популярная платформа для web push и мобильных пушей. Есть бесплатный тариф, сегментация, автоматизация, A/B-тесты. Документация хорошая, интеграция занимает минут 20.

Pushwoosh — сильная сторона — омниканальные сценарии. Можно выстроить цепочку: сначала push, если не открыл — email, если не открыл — SMS. Подходит для средних и крупных проектов.

SendPulse — маркетинговая платформа с push-каналом. Удобна тем, что здесь же можно делать email-рассылки и чат-ботов. Для быстрого старта — нормальный выбор.

Push4site — сервис проще, чем предыдущие, но если нужно просто собирать базу и отправлять уведомления — его вполне хватит.

DashaMail — российский сервис, совмещающий email и push. Русскоязычная поддержка, понятный интерфейс. Если проект ориентирован на Россию — стоит посмотреть.

Подключение через сервис обычно сводится к трём шагам: зарегистрироваться, вставить JS-код на сайт, скачать файл Service Worker и положить его в корень. На HTTPS-сайтах обычно всё. Для HTTP может потребоваться промежуточный поддомен — но честно говоря, в 2026 году сайт без HTTPS — это уже экзотика.

Практические советы, которые экономят нервы

Не показывайте запрос сразу

Пользователь зашёл на сайт впервые и ещё не понимает, что вы ему предлагаете. А тут выскакивает системное окно «Разрешить уведомления?». Естественная реакция — нажать «Блокировать». И всё: отменить это решение пользователь может только через настройки браузера, а туда он никогда не полезет.

Правильный подход: показывать кастомный баннер через 30–60 секунд или после конкретного действия (добавление в корзину, просмотр 3 страниц, скролл до середины статьи). И в баннере — конкретное предложение: «Подпишитесь, чтобы узнавать о скидках первым» лучше, чем абстрактное «Получайте наши уведомления».

Сегментируйте базу

Отправлять одно и то же сообщение всей базе — путь к массовым отпискам. Если человек интересовался кроссовками — ему не нужны уведомления о скидках на шторы. На уровне подписки можно сохранять теги, страницу подписки, utm-метки — и использовать это для сегментации.

Следите за частотой отправки

Оптимальная частота — 2–4 пуша в неделю для коммерческих проектов. Информационные порталы могут отправлять чаще, но не больше 1–2 в день. Если переборщить — пользователи начнут отключать уведомления, а браузер может вообще снизить приоритет доставки ваших сообщений.

Обрабатывайте протухшие подписки

Подписка может «умереть» — пользователь переустановил браузер, очистил cookies, поменял устройство. При попытке отправить пуш на такой endpoint вы получите ошибку 410 (Gone). Это нормально. Главное — обрабатывать эту ошибку и удалять невалидные подписки из базы, чтобы не засорять её.

Тестируйте на разных устройствах

Push-уведомления выглядят по-разному в Chrome на Windows, в Firefox на macOS, в Safari на iPhone. Где-то показывается картинка, где-то нет. Где-то кнопки действий работают, где-то — нет. Перед запуском обязательно проверьте отображение на основных платформах вашей аудитории.

Что нельзя делать: частые ошибки

Спамить. Если пользователь подписался на уведомления о скидках, а вы шлёте ему новости компании каждый день — он отпишется. Или хуже — заблокирует.

Отправлять пуши без ценности. «Посмотрите наш новый каталог» — это не ценность. «−30% на кроссовки Nike сегодня до полуночи» — это ценность. Пуш должен давать причину кликнуть.

Игнорировать аналитику. Отслеживайте CTR (клики), delivery rate (доставку) и unsubscribe rate (отписки). Если CTR упал ниже 2% — пора менять стратегию: заголовки, время отправки, сегменты.

Забывать про HTTPS. Web Push работает только на сайтах с SSL-сертификатом. Это базовое требование, и оно не изменится.

Пуши как канал для бизнеса: реальные цифры

Вот цифры с реального проекта — интернет-магазин товаров для дома, средний трафик около 15 000 визитов в месяц.

За 4 месяца после подключения push-уведомлений:

  • Собрали базу в ~1 200 подписчиков (конверсия в подписку — около 6%)
  • Средний CTR по рассылкам — 7,2%
  • Пуши про скидки и акции давали CTR до 12%
  • Информационные пуши (новинки, статьи) — около 3–4%
  • Отток подписчиков — примерно 8% в месяц (часть очищает куки, часть отписывается)

Для сравнения: email-рассылка у того же проекта показывала open rate около 18% и CTR около 2,5%. То есть пуши как канал возвращения пользователей работали заметно лучше — при минимальных затратах на настройку.

Пошаговый чеклист: подключаем web push с нуля

Если вы дочитали до этого места — вот конкретный план действий.

Шаг 1. Убедитесь, что сайт работает по HTTPS.

Шаг 2. Определитесь с подходом: свой код или сервис. Для быстрого старта — сервис (OneSignal, Pushwoosh). Для полного контроля — свой код с `web-push`.

Шаг 3. Сгенерируйте VAPID-ключи (если пишете сами).

Шаг 4. Создайте файл Service Worker и положите его в корень сайта.

Шаг 5. Реализуйте двухшаговую подписку: сначала кастомный баннер, потом — нативный запрос.

Шаг 6. Настройте серверную часть для хранения подписок и отправки уведомлений.

Шаг 7. Если вам важен охват iOS-пользователей — добавьте `manifest.json` и позаботьтесь о том, чтобы сайт можно было установить как PWA.

Шаг 8. Подключите аналитику — хотя бы базовый подсчёт отправленных, доставленных и кликнутых уведомлений.

Шаг 9. Запустите тестовую рассылку и проверьте на разных браузерах и устройствах.

Шаг 10. Начните с 1–2 рассылок в неделю, отслеживайте метрики и корректируйте стратегию.

Вместо итога

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

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