Як налаштувати push-сповіщення Webpushr для WordPress

Webpushr — це платформа для веб-push-сповіщень, яка доставляє сповіщення браузера в реальному часі користувачам, які підписалися, навіть якщо вони повністю покинули ваш сайт. На відміну від електронної пошти або SMS, веб-push не потребує особистої контактної інформації — підписники отримують сповіщення безпосередньо через рідну систему сповіщень браузера за допомогою Web Push Protocol та Push API.

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

Передумови перед початком роботи

Перш ніж торкатися панелі керування WordPress, переконайтеся, що ваше середовище відповідає таким жорстким вимогам:

• HTTPS є обов’язковим. Push API та service workers обмежені безпечними джерелами. Сайт, що працює на звичайному HTTP, не може зареєструвати service worker і тому не може доставляти веб-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 на головному екрані — стандартний веб-push на основі браузера на iOS залишається ненадійним на момент написання цього тексту.
• Відсутність конфліктуючих service workers. Якщо ви вже використовуєте плагін PWA або інший сервіс push-сповіщень, їхні service workers можуть конфліктувати з service worker 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

Після активації новий пункт меню Webpushr з’являється в лівій навігаційній панелі WordPress.

Що плагін насправді робить на рівні сервера

Розуміння архітектури плагіна допомагає вам розумно вирішувати проблеми. При активації плагін:

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: Налаштування параметрів доставки сповіщень

Автоматичний push при публікації запису

У розділі Webpushr > Налаштування перемикач Auto-Push Notification контролює, чи буде автоматично надсилатися push-сповіщення щоразу, коли ви публікуєте запис. Коли увімкнено, Webpushr автоматично отримує заголовок запису, уривок та URL зображення-мініатюри та формує навантаження сповіщення.

Граничний випадок: Якщо ви використовуєте робочий процес зі стейджингу на продакшн, де записи імпортуються або їхній статус змінюється програмно (наприклад, через WP-CLI або скрипт міграції), хук publish_post спрацює для кожного імпортованого запису, потенційно заваливши ваших підписників десятками сповіщень за секунди. Вимкніть auto-push перед запуском масових імпортів:

wp option update webpushr_auto_push 0

Повторно увімкніть його після завершення імпорту.

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

Для детального контролю вимкніть auto-push глобально та використовуйте мета-блок Webpushr для кожного запису в редакторі записів. Цей мета-блок з’являється під основним редактором контенту та надає такі елементи керування:

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

Анатомія навантаження сповіщення

Навантаження веб-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 Focus Assist, macOS Do Not Disturb, канали сповіщень 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 тести, щоб визначити, яке повідомлення забезпечує вищий показник кліків, перш ніж розгортати повну кампанію.

Крок 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 у стандартних сеансах браузера залишаються поза досяжністю веб-push, що є суттєвою прогалиною аудиторії для сайтів з переважно мобільним трафіком.

Міркування щодо хостингової інфраструктури

Доставка веб-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 секунд або одного перегляду сторінки.
• Auto-push вимкнено, якщо ви виконуєте заплановані масові імпорти або міграції контенту.
• Тестове сповіщення було отримано наскрізно в чистому сеансі браузера.
• Розміри іконки сповіщення становлять 192×192 пікселі, а URL є абсолютним HTTPS.
• TTL налаштовано відповідно до чутливості вашого контенту до часу.
• Базові показники аналітики зафіксовано перед першою кампанією, щоб мати значущу точку порівняння.
• Політику конфіденційності/GDPR оновлено для розкриття інформації про збір даних push-сповіщень.

Часті запитання

Чи працює Webpushr без HTTPS?

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

Чому мої push-сповіщення не доставляються деяким підписникам?

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

Чи можу я надсилати push-сповіщення користувачам iOS?

Станом на iOS 16.4, веб-push підтримується лише для Progressive Web Apps (PWA), доданих на головний екран. Користувачі, які переглядають ваш сайт у Safari або будь-якому іншому браузері iOS без додавання на головний екран, не отримуватимуть веб-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, ці підписники будуть доступні знову негайно.