Как да настроите Webpushr Push известия за 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 може да влязат в конфликт с тези на 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: Инсталирайте WordPress плъгина на Webpushr

Влезте в административния панел на WordPress и следвайте този път:

1. Отидете на Plugins > Add New.
2. Потърсете Webpushr.
3. Намерете официалния плъгин, публикуван от Webpushr Inc. — проверете името на издателя, за да избегнете инсталирането на плъгин с подобно наименование.
4. Кликнете Install Now, след това Activate.

Алтернативно, инсталирайте чрез 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 > Settings в таблото за управление на WordPress. Ще видите поле с надпис API Key. Поставете API Key, който сте извлекли от таблото за управление на Webpushr в Стъпка 1.

Кликнете Save Changes. Плъгинът ще направи заявка за валидиране към 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 > Settings превключвателят 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 px), показвано до известието.
• image — голямо банерно изображение, показвано под тялото на поддържаните платформи (Chrome на Android, Chrome на Windows).
• badge — малка монохромна икона, показвана в лентата за статус на Android.
• url — URL адресът на дестинацията, когато потребителят кликне върху известието.
• actions — до два бутона за действие с персонализирани надписи и URL адреси (поддържани в Chrome и Edge).

Поддържането на title под 50 знака и body под 120 знака предотвратява съкращаването на повечето платформи.

Стъпка 6: Тествайте push известията от край до край

Тестването в същата сесия на браузъра, в която сте влезли в WordPress, няма да ви даде точна представа за преживяването на абоната. Използвайте отделен профил на браузъра или прозорец в режим „инкогнито”:

1. Отворете уебсайта си в частен/инкогнито прозорец.
2. Предварителната подкана за абониране трябва да се появи след конфигурираното от вас закъснение.
3. Кликнете върху призива за действие на подканата, след това кликнете Allow в родния диалог за разрешение на браузъра.
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 е посочен като активен. Ако показва „waiting”, друг service worker блокира активирането.
• Иконата не се зарежда: URL адресът на иконата трябва да е абсолютен (започващ с https://) и изображението трябва да се обслужва с разрешителни CORS заглавки, ако е хоствано в CDN.

Стъпка 7: Разширени функции — сегментация, планиране и тригери

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

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

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

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

Планирани известия

Планирането ви позволява да съставите известие сега и да го доставите на бъдеща дата и час с поддръжка на часови зони. Това е особено ценно за:

• Чувствителни към времето промоции с твърд краен срок.
• Съдържание, публикувано извън пиковите часове на трафик, което искате да бъде доставено по време на прозорци с висока ангажираност.
• Повтарящи се дайджест известия (например седмични обобщения).

Персонализирани известия, базирани на тригери

Персонализираните тригери задействат известия въз основа на JavaScript събития на вашия сайт. Например можете да задействате известие 24 часа след като потребител изостави количка за пазаруване, или когато потребителят достигне определена дълбочина на превъртане. Тригерите се конфигурират чрез JavaScript SDK на Webpushr и изискват персонализирана разработка извън стандартните възможности на 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. При споделен хостинг с ограничителни лимити за изходящи връзки, тази заявка може да изтече и безшумно да се провали.
• Надеждност на webhook: Ако конфигурирате webhooks на Webpushr да уведомяват вашия сървър за събития на абониране, вашият сървър трябва надеждно да приема входящи POST заявки.

Използването на WordPress на VPS с cPanel ви дава контрол за настройка на времеизчакванията за изпълнение на PHP, конфигуриране на правила за изходяща защитна стена и наблюдение на доставката на service worker без ограниченията на споделените среди. За сайтове с голям трафик, при които кампаниите за push известия водят до значителни пикове на едновременен трафик, Dedicated сървър гарантира, че вашият произход може да поеме получения трафик от кликвания без ограничаване. За екипи, управляващи множество WordPress сайтове, Email хостинг в комбинация с 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 px и 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 ще се постави в опашка в състояние „waiting” и никога няма да се активира. Решението е да се използва service worker, който импортира и двата скрипта, или да се избере един доставчик на push и да се деактивират останалите. Проверете chrome://serviceworker-internals/, за да проверите всички регистрирани workers на вашия домейн.

Деактивирането на плъгина Webpushr ще отпише ли съществуващите ми абонати?

Не. Деактивирането на плъгина премахва JavaScript SDK от предния ви край, което предотвратява нови абонаменти и спира автоматичните известия. Въпреки това съществуващите регистрации на крайни точки за push остават валидни в браузъра, докато потребителят изрично не отмени разрешението или крайната точка не изтече. Ако активирате отново плъгина със същия API Key, тези абонати ще бъдат достъпни отново незабавно.