Jak skonfigurować powiadomienia push Webpushr dla WordPress

Webpushr to platforma powiadomień push, która dostarcza powiadomienia przeglądarkowe w czasie rzeczywistym do użytkowników, którzy wyrazili na to zgodę — nawet jeśli całkowicie opuścili Twoją witrynę. W przeciwieństwie do poczty e-mail czy SMS, web push nie wymaga żadnych danych kontaktowych — subskrybenci otrzymują powiadomienia bezpośrednio przez natywny system powiadomień przeglądarki za pośrednictwem Web Push Protocol i Push API.

Ten przewodnik przeprowadza przez cały proces konfiguracji: od założenia konta i konfiguracji wtyczki WordPress, przez zaawansowaną segmentację, automatyzację opartą na wyzwalaczach, aż po analizę subskrybentów. Obejmuje również techniczne przypadki brzegowe — konflikty service workerów, wymagania HTTPS, luki w kompatybilności z iOS i kwestie wydajnościowe — które większość poradników całkowicie pomija.

Wymagania wstępne

Przed przejściem do panelu WordPress upewnij się, że Twoje środowisko spełnia następujące wymagania:

• HTTPS jest obowiązkowe. Push API i service workery są ograniczone do bezpiecznych źródeł. Witryna działająca na zwykłym HTTP nie może zarejestrować service workera, a tym samym nie może dostarczać powiadomień web push. Jeśli Twoja witryna nie jest jeszcze zabezpieczona, potrzebujesz ważnego certyfikatu SSL — AlexHost oferuje Certyfikaty SSL, które spełniają to wymaganie.
• WordPress 5.0 lub nowszy jest zalecany dla pełnej kompatybilności edytora bloków Gutenberg z meta boxem Webpushr.
• PHP 7.4 lub nowszy po stronie serwera, aby uniknąć ostrzeżeń o przestarzałych funkcjach, które mogą po cichu przerywać inicjalizację wtyczki.
• Świadomość obsługi przeglądarek: Chrome, Firefox i Edge na komputerach stacjonarnych i Androidzie obsługują Web Push Protocol. Safari na macOS dodało obsługę w Safari 16 (macOS Ventura). iOS Safari dodało ograniczoną obsługę w iOS 16.4 wyłącznie dla PWA dodanych do ekranu głównego — standardowe powiadomienia web push oparte na przeglądarce na iOS pozostają zawodne w chwili pisania tego tekstu.
• Brak konfliktujących service workerów. Jeśli korzystasz już z wtyczki PWA lub innej usługi powiadomień push, ich service workery mogą kolidować z service workerem Webpushr. Sprawdź aktywne service workery pod adresem chrome://serviceworker-internals/ przed kontynuowaniem.

Krok 1: Utwórz i skonfiguruj konto Webpushr

Przejdź na stronę webpushr.com i zarejestruj nowe konto. Podczas wdrożenia zostaniesz poproszony o podanie domeny swojej witryny. Wprowadź dokładną domenę tak, jak pojawia się w pasku adresu przeglądarki, łącznie z prefiksem www lub jego brakiem — ta wartość służy do określenia zakresu service workera, a niezgodności spowodują błędy subskrypcji.

Po rejestracji Webpushr udostępnia dwa kluczowe dane uwierzytelniające:

• API Key — używany przez wtyczkę WordPress do uwierzytelniania wywołań REST API przy wysyłaniu powiadomień.
• Auth Token — używany do żądań API po stronie serwera, jeśli później zbudujesz niestandardowe integracje.

Znajdź obie wartości w sekcji Account > API Keys w panelu Webpushr i przechowuj je bezpiecznie. API Key nie jest sekretem w tradycyjnym sensie (jest osadzony w żądaniach po stronie klienta), ale Auth Token musi pozostać prywatny.

Limity planu bezpłatnego i płatnego Webpushr

Dla większości małych witryn WordPress bezpłatny poziom jest wystarczający do weryfikacji kanału przed przejściem na plan płatny.

Krok 2: Zainstaluj wtyczkę Webpushr dla WordPress

Zaloguj się do panelu administracyjnego WordPress i wykonaj następujące kroki:

1. Przejdź do Wtyczki > Dodaj nową.
2. Wyszukaj Webpushr.
3. Znajdź oficjalną wtyczkę opublikowaną przez Webpushr Inc. — zweryfikuj nazwę wydawcy, aby uniknąć instalacji wtyczki o podobnej nazwie.
4. Kliknij Zainstaluj teraz, a następnie Aktywuj.

Alternatywnie zainstaluj za pomocą WP-CLI, jeśli zarządzasz WordPress z wiersza poleceń:

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

Po aktywacji w lewym menu nawigacyjnym WordPress pojawi się nowa pozycja Webpushr.

Co wtyczka faktycznie robi na poziomie serwera

Zrozumienie architektury wtyczki pomaga w inteligentnym rozwiązywaniu problemów. Po aktywacji wtyczka:

1. Rejestruje regułę przepisywania, aby serwować plik service workera (webpushr-sw.js) z katalogu głównego witryny. Jest to kluczowe — service workery muszą być serwowane z zakresu głównego, aby kontrolować całe źródło.
2. Wstrzykuje fragment kodu JavaScript na każdą stronę front-endu za pomocą wp_enqueue_scripts, który ładuje SDK Webpushr i rejestruje service workera.
3. Podpina się pod akcje WordPress publish_post i publish_page, aby wyzwalać automatyczne powiadomienia push przy publikowaniu treści.

Jeśli Twoja wtyczka do buforowania agresywnie buforuje plik service workera, subskrybenci mogą otrzymywać nieaktualne ładunki push lub w ogóle nie rejestrować się. Wyklucz webpushr-sw.js z reguł buforowania.

Krok 3: Połącz wtyczkę z kontem Webpushr

Przejdź do Webpushr > Ustawienia w panelu WordPress. Zobaczysz pole oznaczone jako API Key. Wklej API Key pobrany z panelu Webpushr w Kroku 1.

Kliknij Zapisz zmiany. Wtyczka wyśle żądanie weryfikacyjne do API Webpushr. Jeśli klucz jest prawidłowy, pojawi się potwierdzenie sukcesu. Jeśli zobaczysz błąd:

• Upewnij się, że wklejony klucz nie zawiera wiodących ani końcowych spacji.
• Sprawdź, czy Twój serwer może wykonywać wychodzące żądania HTTPS do api.webpushr.com. Niektóre zabezpieczone konfiguracje VPS domyślnie blokują połączenia wychodzące. Na serwerze Linux przetestuj za pomocą:

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

Odpowiedź 200 OK lub 301 potwierdza łączność. Jeśli połączenie przekroczy limit czasu, sprawdź reguły zapory za pomocą iptables -L OUTPUT lub listy ACL sieci swojego dostawcy hostingu.

Jeśli korzystasz z WordPress w środowisku Hostingu VPS, masz pełną kontrolę nad regułami zapory i możesz bezpośrednio dodać punkt końcowy API Webpushr do białej listy.

Krok 4: Skonfiguruj monit o zgodę

Monit o zgodę to okno dialogowe uprawnień przeglądarki, które prosi użytkowników o zezwolenie na powiadomienia. Natywnego okna dialogowego przeglądarki nie można stylizować — jest renderowane przez samą przeglądarkę. Jednak Webpushr oferuje wstępny monit o zgodę (niestandardową nakładkę pojawiającą się przed natywnym oknem dialogowym), którą możesz w pełni dostosować.

Skonfiguruj wstępny monit o zgodę w panelu Webpushr w sekcji Settings > Opt-in Prompt:

• Styl monitu: Wybierz między widżetem dzwonka, górnym paskiem, wysuwanym polem lub niestandardowym modalem.
• Tekst monitu: Napisz treść, która jasno komunikuje korzyści z subskrypcji. Niejasne monity, takie jak „Zezwolić na powiadomienia?”, konsekwentnie osiągają gorsze wyniki niż monity określające, co subskrybenci będą otrzymywać, np. „Otrzymuj natychmiastowe powiadomienia, gdy opublikujemy nowe porady dotyczące bezpieczeństwa.”
• Opóźnienie monitu: Ustaw opóźnienie (w sekundach lub odsłonach strony) przed wyświetleniem monitu. Wyświetlanie go natychmiast po załadowaniu strony daje niższe wskaźniki zgody niż oczekiwanie, aż użytkownik zaangażuje się w co najmniej jedną treść.
• Interwał ponownego monitu: Określ, ile dni musi minąć przed ponownym wyświetleniem monitu użytkownikowi, który go odrzucił. Agresywne ponowne monity szkodzą doświadczeniu użytkownika i zwiększają współczynnik odrzuceń.

Wskaźniki zgody według typu monitu

Kontekstowe monity — wyświetlane po wykonaniu przez użytkownika znaczącej akcji, np. przeczytaniu artykułu do końca — konsekwentnie przewyższają wszystkie inne podejścia.

Krok 5: Skonfiguruj ustawienia dostarczania powiadomień

Automatyczny push przy publikowaniu wpisu

W sekcji Webpushr > Ustawienia przełącznik Auto-Push Notification kontroluje, czy powiadomienie push jest wysyłane automatycznie za każdym razem, gdy publikujesz wpis. Po włączeniu Webpushr pobiera tytuł wpisu, fragment i URL obrazu wyróżniającego, a następnie automatycznie konstruuje ładunek powiadomienia.

Przypadek brzegowy: Jeśli korzystasz z przepływu pracy staging-do-produkcji, w którym wpisy są importowane lub ich status jest zmieniany programowo (np. za pomocą WP-CLI lub skryptu migracyjnego), hook publish_post uruchomi się dla każdego importowanego wpisu, potencjalnie zalewając subskrybentów dziesiątkami powiadomień w ciągu sekund. Wyłącz auto-push przed uruchomieniem masowych importów:

wp option update webpushr_auto_push 0

Włącz go ponownie po zakończeniu importu.

Ręczny push z edytora wpisów

Aby uzyskać szczegółową kontrolę, wyłącz auto-push globalnie i używaj meta boxa Webpushr dla poszczególnych wpisów w edytorze wpisów. Ten meta box pojawia się poniżej głównego edytora treści i udostępnia następujące opcje:

• Wyślij powiadomienie push: Pole wyboru, które po zaznaczeniu kolejkuje powiadomienie przy publikowaniu lub aktualizacji.
• Niestandardowy tytuł powiadomienia: Zastąp tytuł wpisu bardziej przyciągającym uwagę nagłówkiem dla powiadomienia.
• Niestandardowa wiadomość powiadomienia: Zastąp automatycznie wygenerowany fragment.
• Niestandardowy URL powiadomienia: Przekieruj subskrybentów na konkretną stronę docelową zamiast na permalink wpisu — przydatne w kampaniach promocyjnych.
• Niestandardowa ikona powiadomienia: Zastąp domyślną ikonę witryny obrazem specyficznym dla kampanii.

Anatomia ładunku powiadomienia

Ładunek powiadomienia web push składa się z:

• title — wyświetlany pogrubioną czcionką na górze powiadomienia.
• body — tekst opisowy poniżej tytułu.
• icon — kwadratowy obraz (zalecane 192×192 px) wyświetlany obok powiadomienia.
• image — duży obraz banerowy wyświetlany poniżej treści na obsługiwanych platformach (Chrome na Androidzie, Chrome na Windows).
• badge — mała monochromatyczna ikona wyświetlana na pasku stanu Androida.
• url — docelowy URL po kliknięciu powiadomienia przez użytkownika.
• actions — do dwóch przycisków akcji z niestandardowymi etykietami i URL (obsługiwane w Chrome i Edge).

Utrzymanie title poniżej 50 znaków i body poniżej 120 znaków zapobiega obcinaniu tekstu na większości platform.

Krok 6: Przetestuj powiadomienia push od początku do końca

Testowanie w tej samej sesji przeglądarki, w której jesteś zalogowany do WordPress, nie da Ci dokładnego obrazu doświadczenia subskrybenta. Użyj oddzielnego profilu przeglądarki lub okna incognito:

1. Otwórz swoją witrynę w oknie prywatnym/incognito.
2. Wstępny monit o zgodę powinien pojawić się po skonfigurowanym opóźnieniu.
3. Kliknij wezwanie do działania w monicie, a następnie kliknij Zezwól w natywnym oknie dialogowym uprawnień przeglądarki.
4. Wróć do panelu WordPress i opublikuj testowy wpis lub użyj przycisku Send Test Notification w panelu Webpushr.
5. Sprawdź, czy powiadomienie pojawia się z prawidłowym tytułem, treścią, ikoną i czy kliknięcie go prowadzi do właściwego URL.

Typowe błędy podczas testowania:

• Powiadomienie nie pojawia się: Sprawdź, czy powiadomienia przeglądarki nie są zablokowane na poziomie systemu operacyjnego (Windows Focus Assist, macOS Nie przeszkadzać, kanały powiadomień Androida).
• Service worker nie rejestruje się: Otwórz DevTools > Application > Service Workers i potwierdź, że webpushr-sw.js jest wymieniony jako aktywny. Jeśli wyświetla się jako „oczekujący”, inny service worker blokuje aktywację.
• Ikona nie ładuje się: URL ikony musi być bezwzględny (zaczynający się od https://), a obraz musi być serwowany z odpowiednimi nagłówkami CORS, jeśli jest hostowany na CDN.

Krok 7: Zaawansowane funkcje — segmentacja, planowanie i wyzwalacze

Segmentacja odbiorców

Silnik segmentacji Webpushr pozwala tagować subskrybentów na podstawie:

• Segmenty oparte na URL: Automatycznie taguj subskrybentów odwiedzających określone URL lub wzorce URL (np. wszyscy użytkownicy odwiedzający /category/security/ są tagowani security-readers).
• Niestandardowe atrybuty: Przekazuj dowolne pary klucz-wartość za pomocą SDK JavaScript, aby budować segmenty na podstawie właściwości użytkownika, które Twoja aplikacja już śledzi.
• Segmenty zaangażowania: Webpushr automatycznie śledzi znaczniki czasu ostatniej aktywności, umożliwiając tworzenie kampanii ponownego zaangażowania skierowanych do subskrybentów, którzy nie otrzymali powiadomienia od ponad 30 dni.

Segmentacja wymaga płatnego planu i jest konfigurowana w panelu Webpushr w sekcji Segments.

Zaplanowane powiadomienia

Planowanie pozwala skomponować powiadomienie teraz i dostarczyć je w przyszłej dacie i godzinie, z obsługą stref czasowych. Jest to szczególnie wartościowe dla:

• Promocji wrażliwych na czas z twardym terminem.
• Treści publikowanych poza godzinami szczytu ruchu, które chcesz dostarczyć w oknach wysokiego zaangażowania.
• Cyklicznych powiadomień zbiorczych (np. tygodniowe podsumowania).

Niestandardowe powiadomienia oparte na wyzwalaczach

Niestandardowe wyzwalacze uruchamiają powiadomienia na podstawie zdarzeń JavaScript na Twojej witrynie. Na przykład możesz wysłać powiadomienie 24 godziny po tym, jak użytkownik porzuci koszyk zakupowy, lub gdy użytkownik osiągnie określoną głębokość przewijania. Wyzwalacze są konfigurowane za pomocą SDK JavaScript Webpushr i wymagają niestandardowych prac deweloperskich wykraczających poza domyślne możliwości wtyczki WordPress.

Testy A/B treści powiadomień

W planach płatnych Webpushr obsługuje testy podziału tytułów powiadomień i treści wśród segmentów subskrybentów. Przeprowadzaj testy A/B, aby określić, które komunikaty generują wyższe współczynniki klikalności przed uruchomieniem pełnej kampanii.

Krok 8: Monitoruj analitykę subskrybentów

Panel Webpushr dostarcza następujące metryki:

• Łączna liczba subskrybentów: Liczba aktywnych, wypisanych i wygasłych punktów końcowych.
• Wskaźnik dostarczenia: Procent wysłanych powiadomień, które zostały pomyślnie dostarczone do usługi push przeglądarki (FCM dla Chrome/Edge, Mozilla Autopush dla Firefox).
• Współczynnik klikalności (CTR): Procent dostarczonych powiadomień, które skutkowały kliknięciem.
• Wzrost subskrypcji w czasie: Dzienne i tygodniowe trendy pozyskiwania subskrybentów.

Ważna uwaga techniczna dotycząca „dostarczonych” vs. „odebranych”: Powiadomienie jest oznaczane jako dostarczone, gdy usługa push przeglądarki (np. FCM Google) akceptuje ładunek. Jeśli urządzenie użytkownika jest offline, FCM kolejkuje powiadomienie i dostarcza je po ponownym połączeniu urządzenia — ale tylko w oknie TTL (Time to Live), które konfigurujesz. Domyślny TTL wynosi 28 dni. W przypadku powiadomień wrażliwych na czas ustaw krótszy TTL, aby uniknąć dostarczania nieaktualnych treści.

Macierz kompatybilności platform i przeglądarek

„Pełna obsługa” oznacza, że Web Push Protocol, service workery i akcje powiadomień są w pełni obsługiwane. Użytkownicy iOS w standardowych sesjach przeglądarki pozostają poza zasięgiem web push, co stanowi istotną lukę w grupie odbiorców dla witryn z dużym ruchem mobilnym.

Kwestie dotyczące infrastruktury hostingowej

Dostarczanie powiadomień web push jest w dużej mierze obsługiwane przez zewnętrzne usługi push (FCM, Mozilla Autopush), więc surowa przepustowość serwera nie jest wąskim gardłem dla dostarczania. Jednak środowisko hostingowe wpływa na:

• Szybkość serwowania service workera: Plik webpushr-sw.js musi być pobierany szybko przy każdym załadowaniu strony, aby przeglądarki mogły sprawdzić aktualność service workera. Wolny serwer zwiększa czas do pierwszego bajtu (TTFB) dla tego pliku.
• Czas odpowiedzi API: Gdy nowy wpis jest publikowany, wtyczka wykonuje synchroniczne wywołanie API do Webpushr. Na hostingu współdzielonym z restrykcyjnymi limitami połączeń wychodzących to wywołanie może przekroczyć limit czasu i po cichu zakończyć się niepowodzeniem.
• Niezawodność webhooków: Jeśli skonfigurujesz webhooki Webpushr do powiadamiania serwera o zdarzeniach subskrypcji, serwer musi niezawodnie akceptować przychodzące żądania POST.

Uruchomienie WordPress na VPS z cPanel daje Ci kontrolę nad dostosowaniem limitów czasu wykonania PHP, konfigurowaniem reguł zapory wychodzących i monitorowaniem dostarczania service workerów bez ograniczeń środowisk współdzielonych. W przypadku witryn o dużym ruchu, gdzie kampanie powiadomień push generują znaczące skoki jednoczesnego ruchu, Serwer dedykowany zapewnia, że Twoje źródło może wchłonąć wynikające z tego obciążenie klikalności bez throttlingu.

Dla zespołów zarządzających wieloma witrynami WordPress, Hosting poczty e-mail w połączeniu z Webpushr tworzy dwukanałową strategię ponownego zaangażowania — push dla natychmiastowości, e-mail dla głębi.

Macierz decyzji technicznych: kiedy używać Webpushr zamiast alternatyw

Bezpłatny poziom Webpushr jest bardziej ograniczony niż OneSignal, ale jego implementacja service workera jest znacznie czystsza i mniej podatna na konflikty z innymi wtyczkami WordPress — praktyczna zaleta w złożonych instalacjach WordPress.

Praktyczna lista kontrolna przed uruchomieniem

• HTTPS jest aktywny, a certyfikat SSL jest ważny i nie jest samopodpisany.
• Service worker webpushr-sw.js jest dostępny pod adresem https://yourdomain.com/webpushr-sw.js i zwraca status 200.
• Plik service workera jest wykluczony z reguł buforowania Twojej wtyczki do buforowania.
• Opóźnienie monitu o zgodę jest ustawione na co najmniej 5 sekund lub jedną odsłonę strony.
• Auto-push jest wyłączony, jeśli uruchamiasz zaplanowane masowe importy lub migracje treści.
• Testowe powiadomienie zostało odebrane od początku do końca w czystej sesji przeglądarki.
• Wymiary ikony powiadomienia wynoszą 192×192 px, a URL jest bezwzględnym HTTPS.
• TTL jest odpowiednio skonfigurowany dla wrażliwości czasowej Twoich treści.
• Punkt odniesienia analityki jest zapisany przed pierwszą kampanią, aby mieć sensowny punkt porównawczy.
• Polityka prywatności/RODO zaktualizowana o ujawnienie zbierania danych powiadomień push.

FAQ

Czy Webpushr działa bez HTTPS?

Nie. Web Push API i service workery są ograniczone do bezpiecznych źródeł zgodnie ze specyfikacją przeglądarki. Żadna witryna działająca na HTTP nie może zarejestrować service workera, a tym samym nie może wysyłać ani odbierać powiadomień web push. Certyfikat SSL jest twardym wymaganiem technicznym, a nie opcjonalną dobrą praktyką.

Dlaczego moje powiadomienia push nie są dostarczane do niektórych subskrybentów?

Najczęstsze przyczyny to: urządzenie subskrybenta było offline dłużej niż okno TTL powiadomienia; użytkownik cofnął uprawnienia do powiadomień na poziomie przeglądarki lub systemu operacyjnego; lub punkt końcowy usługi push przeglądarki (FCM, Mozilla Autopush) zwrócił wygasłą lub nieprawidłową rejestrację. Panel Webpushr oznacza te przypadki jako „nieudane” dostarczenia i automatycznie usuwa punkty końcowe, które zwracają odpowiedź 410 Gone, co jest prawidłowym zachowaniem zgodnie ze specyfikacją Web Push Protocol.

Czy mogę wysyłać powiadomienia push do użytkowników iOS?

Od iOS 16.4 web push jest obsługiwany tylko dla Progressive Web Apps (PWA) dodanych do ekranu głównego. Użytkownicy przeglądający Twoją witrynę w Safari lub innej przeglądarce iOS bez dodawania jej do ekranu głównego nie będą otrzymywać powiadomień web push. Jest to ograniczenie na poziomie platformy narzucone przez Apple, a nie ograniczenie Webpushr.

Czy service worker Webpushr będzie kolidować z moją istniejącą wtyczką PWA lub do buforowania?

Może. Tylko jeden service worker może kontrolować dany zakres w danym momencie. Jeśli wtyczka PWA (np. Super PWA) lub inna usługa push zarejestrowała już service workera w zakresie głównym, service worker Webpushr będzie kolejkował się w stanie „oczekiwania” i nigdy się nie aktywuje. Rozwiązaniem jest użycie service workera importującego oba skrypty lub wybór jednego dostawcy push i wyłączenie pozostałych. Sprawdź chrome://serviceworker-internals/, aby przeprowadzić audyt wszystkich zarejestrowanych workerów w Twojej domenie.

Czy wyłączenie wtyczki Webpushr wypisuje moich istniejących subskrybentów?

Nie. Dezaktywacja wtyczki usuwa SDK JavaScript z front-endu, co uniemożliwia nowe subskrypcje i zatrzymuje automatyczne powiadomienia. Jednak istniejące rejestracje punktów końcowych push pozostają ważne w przeglądarce, dopóki użytkownik jawnie nie cofnie uprawnień lub punkt końcowy nie wygaśnie. Jeśli ponownie aktywujesz wtyczkę z tym samym API Key, ci subskrybenci będą natychmiast dostępni.