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

Webpushr — это платформа web push-уведомлений, которая доставляет уведомления браузера в режиме реального времени пользователям, давшим согласие на их получение, даже когда те полностью покинули ваш сайт. В отличие от электронной почты или SMS, web push не требует личных контактных данных — подписчики получают уведомления напрямую через встроенную систему уведомлений браузера посредством Web Push Protocol и Push API.

Это руководство охватывает полный процесс настройки: от создания аккаунта и конфигурации плагина WordPress до расширенной сегментации, автоматизации на основе триггеров и аналитики подписчиков. Также рассматриваются технические особые случаи — конфликты service worker, требования HTTPS, проблемы совместимости с iOS и вопросы производительности — которые большинство руководств полностью игнорируют.

Предварительные требования

Прежде чем открывать панель управления WordPress, убедитесь, что ваша среда соответствует следующим обязательным требованиям:

• HTTPS обязателен. Push API и service workers ограничены безопасными источниками. Сайт, работающий на обычном HTTP, не может зарегистрировать service worker и, следовательно, не может доставлять web push-уведомления. Если ваш сайт ещё не защищён, вам нужен действующий SSL-сертификат — AlexHost предоставляет SSL-сертификаты, которые закрывают это требование.
• WordPress 5.0 или выше рекомендуется для полной совместимости с блочным редактором Gutenberg и метабоксом Webpushr.
• PHP 7.4 или выше на стороне сервера, чтобы избежать предупреждений об устаревших функциях, которые могут незаметно нарушить инициализацию плагина.
• Осведомлённость о поддержке браузеров: Chrome, Firefox и Edge на настольных компьютерах и Android поддерживают Web Push Protocol. Safari на macOS добавил поддержку в Safari 16 (macOS Ventura). iOS Safari добавил ограниченную поддержку в iOS 16.4 только для PWA, добавленных на главный экран — стандартные web push-уведомления на основе браузера в iOS по-прежнему ненадёжны на момент написания этого руководства.
• Отсутствие конфликтующих service workers. Если вы уже используете PWA-плагин или другой сервис push-уведомлений, их service workers могут конфликтовать с Webpushr. Проверьте активные service workers по адресу chrome://serviceworker-internals/ перед тем, как продолжить.

Шаг 1: Создание и настройка аккаунта Webpushr

Перейдите на webpushr.com и зарегистрируйте новый аккаунт. В процессе регистрации вас попросят указать домен вашего сайта. Введите точный домен в том виде, в котором он отображается в адресной строке браузера, включая префикс www или его отсутствие — это значение используется для определения области действия service worker, и несоответствие приведёт к ошибкам подписки.

После регистрации Webpushr предоставит два важных учётных данных:

• API Key — используется плагином WordPress для аутентификации REST API-вызовов при отправке уведомлений.
• Auth Token — используется для серверных API-запросов, если вы впоследствии создадите пользовательские интеграции.

Найдите оба значения в разделе Account > API Keys в панели управления Webpushr и сохраните их в надёжном месте. API Key не является секретом в традиционном смысле (он встроен в клиентские запросы), однако Auth Token должен оставаться конфиденциальным.

Сравнение бесплатного и платного планов Webpushr

Для большинства небольших сайтов на WordPress бесплатного тарифа достаточно, чтобы оценить канал перед переходом на платный план.

Шаг 2: Установка плагина Webpushr для WordPress

Войдите в панель администратора WordPress и выполните следующие действия:

1. Перейдите в Плагины > Добавить новый.
2. Найдите Webpushr.
3. Найдите официальный плагин, опубликованный Webpushr Inc. — проверьте имя издателя, чтобы не установить плагин с похожим названием.
4. Нажмите Установить, затем Активировать.

Также можно установить через WP-CLI, если вы управляете WordPress из командной строки:

wp plugin install webpushr-web-push-notifications --activate

После активации в левом меню навигации WordPress появится новый пункт Webpushr.

Что плагин делает на уровне сервера

Понимание архитектуры плагина поможет вам грамотно устранять неполадки. При активации плагин:

1. Регистрирует правило перезаписи для обслуживания файла service worker (webpushr-sw.js) из корня сайта. Это критически важно — service workers должны обслуживаться из корневой области, чтобы контролировать весь источник.
2. Внедряет JavaScript-сниппет на каждую страницу фронтенда через wp_enqueue_scripts, который загружает Webpushr SDK и регистрирует service worker.
3. Подключается к действиям WordPress publish_post и publish_page для автоматической отправки push-уведомлений при публикации контента.

Если ваш плагин кэширования агрессивно кэширует файл service worker, подписчики могут получать устаревшие push-данные или вовсе не проходить регистрацию. Исключите webpushr-sw.js из правил кэширования.

Шаг 3: Подключение плагина к аккаунту Webpushr

Перейдите в Webpushr > Настройки в панели управления WordPress. Вы увидите поле с названием API Key. Вставьте API Key, полученный из панели управления Webpushr на шаге 1.

Нажмите Сохранить изменения. Плагин отправит запрос на проверку в Webpushr API. Если ключ действителен, появится подтверждение об успехе. Если вы видите ошибку:

• Убедитесь, что в вставленном ключе нет пробелов в начале или конце.
• Проверьте, может ли ваш сервер выполнять исходящие HTTPS-запросы к api.webpushr.com. Некоторые защищённые конфигурации VPS по умолчанию блокируют исходящие соединения. На Linux-сервере проверьте с помощью:

curl -I https://api.webpushr.com

Ответ 200 OK или 301 подтверждает наличие соединения. Если соединение истекает по таймауту, проверьте правила брандмауэра с помощью iptables -L OUTPUT или сетевого ACL вашего хостинг-провайдера.

Если вы запускаете WordPress в среде VPS-хостинга, у вас есть полный контроль над правилами брандмауэра и вы можете напрямую добавить конечную точку Webpushr API в белый список.

Шаг 4: Настройка запроса на подписку

Запрос на подписку — это диалоговое окно браузера, которое просит пользователей разрешить уведомления. Нативный диалог разрешений браузера нельзя стилизовать — он отображается самим браузером. Однако Webpushr предоставляет предварительный запрос на подписку (пользовательский оверлей, который появляется перед нативным диалогом) и его можно полностью настроить.

Настройте предварительный запрос на подписку в панели управления Webpushr в разделе Settings > Opt-in Prompt:

• Стиль запроса: Выберите между виджетом-колокольчиком, верхней панелью, всплывающим блоком или пользовательским модальным окном.
• Текст запроса: Напишите текст, который чётко передаёт ценность подписки. Расплывчатые запросы вроде «Разрешить уведомления?» неизменно уступают по эффективности запросам, уточняющим, что именно получат подписчики, например: «Получайте мгновенные уведомления о новых советах по безопасности».
• Задержка запроса: Установите задержку (в секундах или просмотрах страниц) перед показом запроса. Немедленный показ при загрузке страницы даёт более низкий процент подписок, чем ожидание, пока пользователь не ознакомится хотя бы с одним материалом.
• Интервал повторного запроса: Определите, сколько дней должно пройти, прежде чем пользователю, закрывшему запрос, он будет показан снова. Агрессивные повторные запросы ухудшают пользовательский опыт и увеличивают показатель отказов.

Показатели подписки по типам запросов

Контекстные запросы — показываемые после того, как пользователь совершил значимое действие, например дочитал статью до конца — неизменно превосходят все остальные подходы.

Шаг 5: Настройка параметров доставки уведомлений

Автоматическая отправка при публикации записи

В разделе Webpushr > Настройки переключатель Auto-Push Notification управляет тем, будет ли push-уведомление отправляться автоматически каждый раз при публикации записи. При включении Webpushr автоматически извлекает заголовок записи, отрывок и URL изображения-обложки и формирует полезную нагрузку уведомления.

Особый случай: Если вы используете рабочий процесс переноса со staging на production, где записи импортируются или их статус меняется программно (например, через WP-CLI или скрипт миграции), хук publish_post сработает для каждой импортированной записи, потенциально засыпав подписчиков десятками уведомлений за секунды. Отключите автоматическую отправку перед запуском массового импорта:

wp option update webpushr_auto_push 0

Повторно включите её после завершения импорта.

Ручная отправка из редактора записей

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

• Отправить push-уведомление: Флажок, при установке которого уведомление ставится в очередь при публикации или обновлении.
• Пользовательский заголовок уведомления: Замените заголовок записи более привлекательным заголовком для уведомления.
• Пользовательское сообщение уведомления: Замените автоматически сформированный отрывок.
• Пользовательский URL уведомления: Перенаправьте подписчиков на конкретную целевую страницу вместо постоянной ссылки на запись — полезно для рекламных кампаний.
• Пользовательская иконка уведомления: Замените иконку сайта по умолчанию изображением, специфичным для кампании.

Структура полезной нагрузки уведомления

Полезная нагрузка web push-уведомления состоит из:

• title — отображается жирным шрифтом в верхней части уведомления.
• body — описательный текст под заголовком.
• icon — квадратное изображение (рекомендуется 192×192 пикселя), отображаемое рядом с уведомлением.
• image — большое баннерное изображение, отображаемое под текстом на поддерживаемых платформах (Chrome на Android, Chrome на Windows).
• badge — небольшая монохромная иконка, отображаемая в строке состояния Android.
• url — URL назначения при нажатии пользователем на уведомление.
• actions — до двух кнопок действий с пользовательскими подписями и URL (поддерживается в Chrome и Edge).

Ограничение title до 50 символов и body до 120 символов предотвращает обрезку текста на большинстве платформ.

Шаг 6: Сквозное тестирование push-уведомлений

Тестирование в том же сеансе браузера, где вы вошли в WordPress, не даст точного представления об опыте подписчика. Используйте отдельный профиль браузера или окно в режиме инкогнито:

1. Откройте ваш сайт в приватном окне или окне инкогнито.
2. Предварительный запрос на подписку должен появиться после настроенной вами задержки.
3. Нажмите на кнопку призыва к действию в запросе, затем нажмите Разрешить в нативном диалоге браузера.
4. Вернитесь в панель управления WordPress и опубликуйте тестовую запись, или воспользуйтесь кнопкой Send Test Notification в панели управления Webpushr.
5. Убедитесь, что уведомление появилось с правильным заголовком, текстом, иконкой и что при нажатии на него происходит переход по правильному URL.

Распространённые причины сбоев при тестировании:

• Уведомление не появляется: Проверьте, не заблокированы ли уведомления браузера на уровне ОС (режим фокусировки Windows, режим «Не беспокоить» macOS, каналы уведомлений Android).
• Service worker не регистрируется: Откройте DevTools > Application > Service Workers и убедитесь, что webpushr-sw.js отображается как активный. Если он показывает статус «ожидание», другой service worker блокирует активацию.
• Иконка не загружается: URL иконки должен быть абсолютным (начинаться с https://), а изображение должно обслуживаться с разрешающими CORS-заголовками, если оно размещено на CDN.

Шаг 7: Расширенные функции — сегментация, планирование и триггеры

Сегментация аудитории

Механизм сегментации Webpushr позволяет помечать подписчиков на основе:

• Сегменты по URL: Автоматически помечайте подписчиков, посещающих определённые URL или шаблоны URL (например, все пользователи, посещающие /category/security/, получают метку security-readers).
• Пользовательские атрибуты: Передавайте произвольные пары ключ-значение через JavaScript SDK для создания сегментов на основе свойств пользователей, которые уже отслеживает ваше приложение.
• Сегменты по вовлечённости: Webpushr автоматически отслеживает временны́е метки последней активности, что позволяет создавать кампании повторного вовлечения для подписчиков, не получавших уведомлений более 30 дней.

Сегментация требует платного плана и настраивается в панели управления Webpushr в разделе Segments.

Запланированные уведомления

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

• Срочных акций с жёстким дедлайном.
• Контента, опубликованного в часы низкого трафика, который вы хотите доставить в периоды высокой вовлечённости.
• Регулярных дайджест-уведомлений (например, еженедельных обзоров).

Пользовательские уведомления на основе триггеров

Пользовательские триггеры отправляют уведомления на основе JavaScript-событий на вашем сайте. Например, можно отправить уведомление через 24 часа после того, как пользователь бросил корзину, или когда пользователь достигает определённой глубины прокрутки. Триггеры настраиваются через Webpushr JavaScript SDK и требуют пользовательской разработки, выходящей за рамки стандартных возможностей плагина WordPress.

A/B-тестирование текста уведомлений

На платных планах Webpushr поддерживает сплит-тестирование заголовков и текста уведомлений в сегментах подписчиков. Проводите A/B-тесты, чтобы определить, какие формулировки обеспечивают более высокий CTR, прежде чем запускать полноценную кампанию.

Шаг 8: Мониторинг аналитики подписчиков

Панель управления Webpushr предоставляет следующие метрики:

• Общее количество подписчиков: Количество активных, отписавшихся и устаревших конечных точек.
• Процент доставки: Доля отправленных уведомлений, успешно доставленных в сервис push-уведомлений браузера (FCM для Chrome/Edge, Mozilla Autopush для Firefox).
• Кликабельность (CTR): Доля доставленных уведомлений, по которым был выполнен переход.
• Рост подписчиков со временем: Ежедневные и еженедельные тенденции привлечения подписчиков.

Важное техническое замечание о «доставлено» и «получено»: Уведомление считается доставленным, когда сервис push-уведомлений браузера (например, FCM от Google) принимает полезную нагрузку. Если устройство пользователя находится в офлайне, FCM ставит уведомление в очередь и доставляет его при восстановлении соединения — но только в пределах настроенного вами окна TTL (Time to Live). TTL по умолчанию составляет 28 дней. Для срочных уведомлений установите более короткий TTL, чтобы избежать доставки устаревшего контента.

Матрица совместимости платформ и браузеров

«Полная поддержка» означает, что Web Push Protocol, service workers и действия уведомлений полностью поддерживаются. Пользователи iOS в стандартных сеансах браузера остаются недоступны для web push, что является существенным пробелом в охвате аудитории для сайтов с преобладанием мобильного трафика.

Соображения об инфраструктуре хостинга

Доставка web push-уведомлений в основном осуществляется сторонними сервисами push-уведомлений (FCM, Mozilla Autopush), поэтому пропускная способность вашего сервера не является узким местом для доставки. Однако ваша хостинговая среда влияет на:

• Скорость обслуживания service worker: Файл webpushr-sw.js должен быстро загружаться при каждой загрузке страницы, чтобы браузеры могли проверить актуальность service worker. Медленный сервер увеличивает время до первого байта (TTFB) для этого файла.
• Время ответа API: При публикации новой записи плагин выполняет синхронный API-вызов к Webpushr. На общем хостинге с ограничениями исходящих соединений этот вызов может завершиться по таймауту и незаметно завершиться неудачей.
• Надёжность вебхуков: Если вы настраиваете вебхуки Webpushr для уведомления вашего сервера о событиях подписки, ваш сервер должен надёжно принимать входящие POST-запросы.

Запуск WordPress на VPS с cPanel даёт вам возможность настраивать таймауты выполнения PHP, конфигурировать правила исходящего брандмауэра и отслеживать доставку service worker без ограничений общего хостинга. Для высоконагруженных сайтов, где push-кампании вызывают значительные всплески одновременного трафика, выделенный сервер гарантирует, что ваш источник сможет справиться с возникающей нагрузкой переходов без ограничения скорости.

Для команд, управляющих несколькими WordPress-ресурсами, почтовый хостинг в сочетании с Webpushr создаёт двухканальную стратегию повторного вовлечения — push для оперативности, электронная почта для глубины.

Матрица технических решений: когда использовать Webpushr вместо альтернатив

Бесплатный тариф Webpushr более ограничен, чем у OneSignal, однако реализация service worker заметно чище и менее подвержена конфликтам с другими плагинами WordPress — практическое преимущество при сложных установках WordPress.

Практический чеклист перед запуском

• HTTPS активен, SSL-сертификат действителен и не является самоподписанным.
• Service worker webpushr-sw.js доступен по адресу https://yourdomain.com/webpushr-sw.js и возвращает статус 200.
• Файл service worker исключён из правил кэширования вашего плагина кэширования.
• Задержка запроса на подписку установлена не менее 5 секунд или одного просмотра страницы.
• Автоматическая отправка отключена, если вы выполняете плановый массовый импорт или миграцию контента.
• Тестовое уведомление было получено сквозным образом в чистом сеансе браузера.
• Размеры иконки уведомления — 192×192 пикселя, URL является абсолютным HTTPS.
• TTL настроен соответствующим образом с учётом временно́й чувствительности вашего контента.
• Базовые показатели аналитики зафиксированы до запуска первой кампании, чтобы иметь точку сравнения.
• Политика конфиденциальности/GDPR обновлена с указанием на сбор данных push-уведомлений.

Часто задаваемые вопросы

Работает ли Webpushr без HTTPS?

Нет. Web Push API и service workers ограничены безопасными источниками согласно спецификации браузера. Любой сайт, работающий на HTTP, не может зарегистрировать service worker и, следовательно, не может отправлять или получать web push-уведомления. SSL-сертификат является жёстким техническим требованием, а не необязательной рекомендацией.

Почему мои push-уведомления не доставляются некоторым подписчикам?

Наиболее распространённые причины: устройство подписчика находилось в офлайне дольше, чем TTL уведомления; пользователь отозвал разрешения на уведомления на уровне браузера или ОС; или сервис push-уведомлений браузера (FCM, Mozilla Autopush) вернул устаревшую или недействительную регистрацию. Панель управления Webpushr помечает их как «неудачные» доставки и автоматически удаляет конечные точки, возвращающие ответ 410 Gone, что является корректным поведением согласно спецификации Web Push Protocol.

Можно ли отправлять push-уведомления пользователям iOS?

Начиная с iOS 16.4, web push поддерживается только для прогрессивных веб-приложений (PWA), добавленных на главный экран. Пользователи, просматривающие ваш сайт в Safari или любом другом браузере iOS без добавления на главный экран, не будут получать web push-уведомления. Это ограничение на уровне платформы, введённое Apple, а не ограничение Webpushr.

Будет ли service worker Webpushr конфликтовать с моим существующим PWA или плагином кэширования?

Возможно. Только один service worker может управлять заданной областью в один момент времени. Если PWA-плагин (например, Super PWA) или другой сервис push-уведомлений уже зарегистрировал service worker в корневой области, service worker Webpushr встанет в очередь в состоянии «ожидание» и никогда не активируется. Решение — использовать service worker, импортирующий оба скрипта, или выбрать единственного провайдера push-уведомлений и отключить остальные. Проверьте chrome://serviceworker-internals/ для аудита всех зарегистрированных workers на вашем домене.

Отписывает ли отключение плагина Webpushr существующих подписчиков?

Нет. Деактивация плагина удаляет JavaScript SDK с вашего фронтенда, что предотвращает новые подписки и останавливает автоматические уведомления. Однако существующие регистрации push-конечных точек остаются действительными в браузере до тех пор, пока пользователь явно не отзовёт разрешение или конечная точка не истечёт. Если вы повторно активируете плагин с тем же API Key, эти подписчики снова станут доступны немедленно.