Push-уведомления для PWA: как настроить и не раздражать пользователей

Push-уведомления для PWA помогают вернуть пользователя и сообщить о важном событии. Но частые сообщения вызывают раздражение. В статье разберём настройку Web Push, покажем код и расскажем, как использовать уведомления без потери доверия.

Зачем бизнесу push-уведомления для PWA

PWA сочетает возможности сайта и приложения. Пользователь открывает веб-приложение в браузере. При этом PWA может работать офлайн и получать фоновые события.

Push-уведомления расширяют эти возможности. Они позволяют связаться с пользователем после ухода с сайта. Для этого браузер использует Push API и Service Worker. Само приложение при этом может быть закрыто.

Push-уведомления для PWA особенно полезны в таких сценариях:

• интернет-магазин сообщает о снижении цены;
• сервис сообщает о новом заказе;
• банк информирует о транзакции;
• CRM напоминает о задаче;
• медиа отправляет важную новость;
• сервис бронирования сообщает об изменении статуса;
• чат уведомляет о новом сообщении.

Главное правило простое: сообщение должно иметь ценность.

Если пользователь получает уведомление без причины, он отключит разрешение. Иногда он перестанет пользоваться сервисом совсем.

Поэтому push-уведомления для PWA стоит рассматривать не как рекламный канал. Это дополнительный интерфейс продукта.

Как работают push-уведомления для PWA

Механика состоит из нескольких компонентов:

1. Пользователь открывает сайт.
2. Сайт регистрирует Service Worker.
3. Пользователь даёт разрешение на уведомления.
4. Браузер создаёт Push Subscription.
5. Приложение передаёт подписку на сервер.
6. Сервер отправляет push-сообщение.
7. Service Worker получает событие.
8. Service Worker показывает уведомление.

Push API отвечает за доставку сообщения. Notifications API отвечает за отображение уведомления. Service Worker связывает эти механизмы.

Push-уведомления для PWA не отправляются напрямую с сайта на устройство. Между сервером и браузером работает push-сервис.

Это важно учитывать при проектировании архитектуры.

Что нужно для работы

Минимальный набор выглядит так:

• HTTPS;
• PWA с зарегистрированным Service Worker;
• Push API;
• Notifications API;
• серверная часть;
• VAPID-ключи;
• база подписок пользователей.

Современный Push API считается широко доступным стандартом. MDN отмечает его широкую поддержку в браузерах с марта 2023 года.

На iPhone и iPad Web Push работает для веб-приложений, добавленных на экран «Домой». Поддержка появилась в iOS и iPadOS 16.4.

Как настроить push-уведомления для PWA

Настройка начинается не с кнопки «Разрешить уведомления». Сначала нужно подготовить Service Worker.

Шаг 1. Регистрируем Service Worker

В основном JavaScript-файле:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', async () => {
    try {
      const registration =
        await navigator.serviceWorker.register('/sw.js');

      console.log('Service Worker зарегистрирован');
    } catch (error) {
      console.error('Ошибка регистрации:', error);
    }
  });
}

Файл sw.js должен находиться в подходящей области видимости.

Service Worker работает отдельно от страницы. Он может запускаться в фоне и обрабатывать push-события.

Шаг 2. Запрашиваем разрешение

Не показывайте системный запрос сразу после открытия сайта.

Сначала объясните пользу. Затем предложите пользователю включить уведомления.

Например:

const button = document.querySelector('#enable-push');

button.addEventListener('click', async () => {
  const permission = await Notification.requestPermission();

  if (permission === 'granted') {
    console.log('Уведомления разрешены');
  }
});

Такой сценарий лучше воспринимается пользователем.

MDN также рекомендует запрашивать разрешение после действия пользователя. Например, после клика по кнопке.

Шаг 3. Создаём Push Subscription

После получения разрешения создаётся подписка.

Для этого используется PushManager:

const registration =
  await navigator.serviceWorker.ready;

const subscription =
  await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: VAPID_PUBLIC_KEY
  });

await fetch('/api/push/subscribe', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify(subscription)
});

Подписка содержит endpoint и криптографические данные. Сервер использует их для отправки сообщений. Endpoint нужно хранить защищённо.

Как отправлять push с сервера

Для Node.js часто используют пакет web-push.

Установка:

npm install web-push

Пример серверной настройки:

const webpush = require('web-push');

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

Далее сервер отправляет сообщение:

await webpush.sendNotification(
  subscription,
  JSON.stringify({
    title: 'Статус заказа изменён',
    body: 'Заказ №1842 передан в доставку.',
    url: '/orders/1842'
  })
);

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

Также нужно удалять неактуальные подписки. Например, после ответа push-сервиса о том, что endpoint больше недействителен.

Обрабатываем push в Service Worker

Теперь Service Worker должен показать уведомление:

self.addEventListener('push', event => {
  const data = event.data?.json() || {};

  const title = data.title || 'Новое уведомление';

  const options = {
    body: data.body || '',
    icon: '/icons/icon-192.png',
    badge: '/icons/badge.png',
    data: {
      url: data.url || '/'
    }
  };

  event.waitUntil(
    self.registration.showNotification(title, options)
  );
});

При клике можно открыть нужную страницу:

self.addEventListener('notificationclick', event => {
  event.notification.close();

  const url = event.notification.data?.url || '/';

  event.waitUntil(
    clients.openWindow(url)
  );
});

Так push-уведомления для PWA превращаются из простого сообщения в полноценный сценарий взаимодействия.

Пользователь сразу попадает туда, где может выполнить действие.

Как не раздражать пользователей

Технически отправить push несложно. Сложнее выбрать правильный момент.

Представим ситуацию.

Вы столкнулись с проблемой: интернет-магазин отправляет пять уведомлений в день. Каждое сообщение рекламирует товар.

Мы решаем её способом: разделяем сообщения по типам. Системные события получают высокий приоритет. Рекламные предложения отправляются только при наличии интереса пользователя.

Результат: уведомления перестают конкурировать друг с другом. Пользователь понимает причину каждого сообщения.

Push-уведомления для PWA должны соответствовать контексту.

Не отправляйте уведомление ради активности

Плохой сценарий:

«Мы давно вас не видели! Откройте сайт прямо сейчас!»

Хороший сценарий:

«Цена на товар из вашего списка снизилась на 15%.»

Во втором случае есть конкретная причина для открытия приложения.

Учитывайте время

Не отправляйте рекламные сообщения ночью.

Для разных регионов используйте локальное время пользователя. Для рабочих сервисов учитывайте рабочие часы.

Особенно важно это для международных проектов.

Дайте пользователю контроль

Хороший интерфейс позволяет настроить категории уведомлений:

• заказы;
• сообщения;
• изменения цены;
• новости;
• акции;
• системные события.

Пользователь сам выбирает нужные категории.

Это лучше одного переключателя «Получать всё».

Частота push-уведомлений: сколько достаточно

Универсального числа нет.

Для одного сервиса нормальным может быть одно сообщение в неделю. Для чата несколько уведомлений в день выглядят естественно.

Ориентируйтесь на частоту событий.

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

Полезное правило:

Нет события — нет уведомления.

Также анализируйте фактическое поведение аудитории.

Смотрите:

• CTR уведомлений;
• открытия PWA;
• отказы от подписки;
• блокировку уведомлений;
• конверсию после перехода;
• частоту взаимодействия;
• долю неактивных подписок.

Одна цифра особенно важна: 100% пользователей должны явно согласиться на получение уведомлений. Без разрешения браузера push-уведомления отправлять нельзя.

Push-уведомления для PWA и сегментация

Одинаковое сообщение для всех пользователей редко даёт хороший результат.

Сегментация делает push полезнее.

Например, интернет-магазин может разделить аудиторию:

Сегмент	Событие	Пример сообщения
Новый клиент	Брошенная корзина	«Товары ждут вас в корзине»
Постоянный клиент	Снижение цены	«Цена на товар из избранного снизилась»
Покупатель	Изменение заказа	«Заказ передан в доставку»
Подписчик	Новая публикация	«Вышел новый материал по вашей теме»

Push-уведомления для PWA становятся полезнее, когда сообщение соответствует конкретному пользователю.

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

Что делать, если пользователь запретил уведомления

Не пытайтесь обходить системные ограничения браузера.

Покажите альтернативный сценарий.

Например:

• email;
• уведомления внутри PWA;
• бейдж на иконке;
• сообщения в личном кабинете;
• SMS для критичных событий.

Для iOS веб-приложения могут использовать системные механизмы уведомлений и Focus. Пользователь сохраняет контроль над тем, когда получать сообщения.

Типичные ошибки при настройке Push

Запрос разрешения сразу

Пользователь ещё не понимает ценность сервиса.

Решение: сначала показать пользу, затем запросить разрешение.

Одинаковый push для всех

Такой подход снижает релевантность сообщений.

Решение: использовать сегменты и события.

Слишком много рекламы

Push превращается в рекламную рассылку.

Решение: отделить транзакционные сообщения от маркетинговых.

Нет ссылки на нужный экран

Пользователь открывает PWA и ищет нужную информацию.

Решение: передавать URL в payload уведомления.

Не удаляются старые подписки

База постепенно накапливает неактуальные endpoint.

Решение: обрабатывать ошибки отправки и удалять недействительные подписки.

Нет аналитики

Команда не знает, работают ли push-уведомления.

Решение: связывать отправку с открытием и целевым действием.

Чек-лист перед запуском

Перед публикацией push-уведомлений для PWA проверьте:

• сайт работает по HTTPS;
• Service Worker корректно регистрируется;
• разрешение запрашивается после действия пользователя;
• подписка сохраняется на сервере;
• VAPID-ключи хранятся безопасно;
• недействительные подписки удаляются;
• уведомление содержит понятный текст;
• клик открывает нужный экран;
• настроены категории сообщений;
• учитывается часовой пояс;
• есть механизм отписки;
• собирается аналитика;
• проверена работа на мобильных устройствах.

Когда стоит заказать настройку PWA у студии

Push — только одна часть PWA.

Нужно правильно связать интерфейс, Service Worker, сервер, базу подписок и аналитику.

Ошибка в одном компоненте может нарушить весь сценарий.

Вы столкнулись с проблемой: PWA уже работает, но уведомления не доставляются стабильно.

Мы решаем её способом: проверяем Service Worker, подписки, HTTPS, VAPID, серверную отправку и сценарии разрешений.

Результат: пользователь получает релевантные уведомления, а бизнес видит действия после перехода.

В студии «Компьюти» мы можем спроектировать PWA с нуля или доработать существующий проект. Это включает технический аудит, разработку интерфейса, Service Worker, интеграцию Web Push и настройку аналитики.

Заключение

Push-уведомления для PWA помогают возвращать пользователей и быстро сообщать о важных событиях. Но эффективность зависит не от количества отправок.

Главное — релевантность, правильный момент и контроль со стороны пользователя.

Настройте push после проектирования сценариев. Разделите сообщения по типам. Анализируйте результат. Не отправляйте уведомления без понятной причины.

Если вашему проекту нужны push-уведомления для PWA, обратитесь в студию «Компьюти». Мы поможем спроектировать механизм, написать код и встроить Web Push в существующую PWA.