strona nie wysyła powiadomień push – i nagle kampanie, które zwykle przynosiły szybkie wejścia i sprzedaże, milkną. Jeśli to znasz, nie panikuj. W 9 na 10 przypadków problem da się szybko zdiagnozować i naprawić, zwłaszcza gdy podejdziesz do tematu metodycznie: od ustawień użytkownika i przeglądarki, przez service worker i HTTPS, aż po integrację z dostawcą (FCM/OneSignal/Web Push z VAPID). Poniżej znajdziesz praktyczny przegląd kroków, które pozwolą Ci ustalić, gdzie „ucieka” powiadomienie, oraz jak sprawić, by znów regularnie dochodziło do odbiorców.

Strona nie wysyła powiadomień push – pierwsze kroki diagnostyczne

Zacznij od najprostszych przyczyn: uprawnienia, blokady i segmentacja.

• Upewnij się, że użytkownik w ogóle jest zapisany na powiadomienia. W witrynie z dzwonkiem/ikoną subskrypcji sprawdź, czy status to „subskrybowany”, a nie „wypisany” lub „oczekujący”.
• Sprawdź stan uprawnień w przeglądarce: czy dla Twojej domeny powiadomienia są dozwolone, zablokowane czy ustawione jako „pytaj”. Nawet pojedyncze kliknięcie „Zablokuj” potrafi uciszyć wszystko.
• Zweryfikuj ustawienia systemowe: tryb „Nie przeszkadzać” (macOS/iOS) lub Focus Assist/Asystent skupienia (Windows) może tymczasowo wygaszać alerty.
• Wykonaj test na innym urządzeniu/konto użytkownika. Jeśli na jednym dociera, a na innym nie – problem leży po stronie przeglądarki lub systemu, a nie po stronie serwera.
• Sprawdź segmentację i harmonogram. Być może kampania jest ograniczona do zbyt małej grupy, ma restrykcyjne warunki (np. tylko użytkownicy z określonego tagu) albo ustawione godziny ciszy.

Weryfikacja po stronie przeglądarki i urządzenia

Najwięcej problemów bierze się z prostych blokad – usuń je w pierwszej kolejności.

• W Chrome: Ustawienia > Prywatność i bezpieczeństwo > Ustawienia witryn > Powiadomienia > znajdź swoją domenę i przełącz na „Dozwolone”.
• W Firefox: Preferencje > Prywatność i bezpieczeństwo > Uprawnienia > Powiadomienia > Ustawienia. Usuń blokadę lub dodaj witrynę jako dozwoloną.
• W Edge: Ustawienia > Pliki cookie i uprawnienia witryny > Powiadomienia.
• Sprawdź, czy nie używasz okna incognito – niektóre rozszerzenia lub ustawienia prywatności ograniczają działanie powiadomień.
• Wyłącz tryb „Nie przeszkadzać”/Focus na czas testów. Na macOS: Ustawienia systemowe > Skupienie; na Windows: Ustawienia > System > Skupienie.

iOS, iPadOS i Safari – co musisz wiedzieć

Na urządzeniach Apple wsparcie web push ma specyficzne wymagania.

• iOS/iPadOS obsługują web push od wersji 16.4, ale w praktyce powiadomienia działają najlepiej, gdy użytkownik doda Twoją stronę jako PWA do ekranu początkowego.
• Na macOS Safari wspiera Web Push, ale użytkownik musi wyrazić zgodę, a systemowe ustawienia powiadomień dla Safari muszą być włączone.
• Jeśli celujesz w użytkowników iOS, jasno komunikuj instrukcję subskrypcji PWA i zgody – inaczej współczynnik „niedostarczonych” będzie wysoki.

Service worker i HTTPS – fundamenty działania

Bez poprawnego service workera i HTTPS web push nie zadziała.

• Sprawdź rejestrację SW: w Chrome DevTools > Application > Service Workers zobacz, czy service worker jest „Active” i czy rejestruje się bez błędów.
• Zweryfikuj zakres (scope) SW – powinien obejmować te ścieżki, dla których chcesz obsługiwać subskrypcje.
• Upewnij się, że Twoja strona działa na pełnym HTTPS (bez mieszanej zawartości). Web push wymaga HTTPS, inaczej przeglądarka zablokuje uprawnienia.
• Zajrzyj w konsolę (DevTools > Console) pod kątem błędów związanych z wydarzeniem „push” i „notificationclick”. Brak listenera push w SW = brak powiadomień na froncie.
• Pamiętaj o odświeżeniu SW po zmianach. Zmiana w pliku service worker wymaga bumpu wersji lub innego mechanizmu aktualizacji, by klienci pobrali nową wersję.

Integracja z dostawcą: FCM, OneSignal, VAPID i konfiguracja serwera

Najlepsze kampanie nie dojdą, jeśli klucze i endpointy są niepoprawne.

• W przypadku własnej implementacji Web Push skonfiguruj poprawnie VAPID (public/private key) i nagłówki Authorization.
• Dla Firebase Cloud Messaging (FCM) sprawdź Server key, Sender ID i to, czy projekt, z którego wysyłasz, odpowiada temu, który używa aplikacja w przeglądarce.
• W OneSignal czy innym SaaS zweryfikuj App ID, REST API key oraz środowiska (test/produkcja).
• Monitoruj statusy dostaw: błędy 400/401 (autoryzacja), 404 (zły endpoint), 410 Gone (wygasła subskrypcja) wymagają usunięcia tokenu z bazy i ponownej subskrypcji.
• Ustaw TTL (time-to-live). Krótkie TTL sprawi, że uśpione urządzenia nie odbiorą powiadomienia. Dla pilnych alertów TTL może być krótki, ale dla standardowych wiadomości ustaw rozsądne wartości (np. kilka godzin).

Payload, format i timing – niewidoczne pułapki

Nawet poprawne klucze nie pomogą, jeśli ładunek jest zły albo wysyłasz o złej porze.

• Upewnij się, że payload JSON jest poprawny i nieprzerośnięty. Nie wszystkie przeglądarki lubią bardzo duże ładunki; lepiej wysyłać krótką treść i dociągać dane po kliknięciu.
• Sprawdź ikony i obrazy: linki muszą być publicznie dostępne po HTTPS. Brak ikony zwykle nie blokuje dostawy, ale może powodować ostrzeżenia lub inny wygląd powiadomienia.
• Uwzględnij strefy czasowe. Jeśli targetujesz globalnie, niedostarczone powiadomienia mogą wynikać z harmonogramu ustawionego pod jedną strefę.

Testy end-to-end: jak sprawdzić, czy komunikat dociera

Zredukuj zmienne – testuj na jednej subskrypcji i jednym urządzeniu.

• Wygeneruj lub pobierz bieżący endpoint subskrypcji (pushSubscription) z przeglądarki testowej i wyślij pojedynczy test.
• Obserwuj DevTools > Application > Push messages (w Chrome) i konsolę SW, aby zobaczyć, czy zdarzenie „push” się uruchamia.
• Wyślij drugi test z innym TTL i prostym payloadem (np. tytuł + treść), by wykluczyć problemy z formatem.
• Jeśli komunikat pojawia się tylko, gdy przeglądarka jest otwarta, możliwe że SW nie działa w tle (sprawdź rejestrację, uprawnienia i blokady systemowe).

Najczęstsze przyczyny braku powiadomień i szybkie rozwiązania

Top błędy i konkretne fixy, które oszczędzą Ci godziny:

• Zablokowane uprawnienia w przeglądarce – poproś użytkownika o zmianę statusu lub pokaż instrukcję odblokowania.
• Wygasłe subskrypcje (410 Gone) – regularnie czyść bazę i automatycznie próbuj re-subskrybować.
• Brak HTTPS lub mixed content – wymuś pełny HTTPS i popraw zasoby.
• Nieaktualny service worker – wdróż wersjonowanie i ensure-update.
• Zła konfiguracja FCM/OneSignal/VAPID – zweryfikuj klucze, app ID i środowiska.
• Zbyt restrykcyjna segmentacja – poszerz warunki lub zrób test na jednej subskrypcji.
• Krótkie TTL – zwiększ czas życia wiadomości dla urządzeń offline.
• Blokady systemowe (Nie przeszkadzać/Focus Assist) – poinformuj użytkowników w FAQ i komunikatach w aplikacji.
• iOS bez PWA – dodaj jasny onboarding PWA i wyjaśnij, jak włączyć powiadomienia.

Dobre praktyki, by ograniczyć problemy w przyszłości

Prewencja zmniejsza liczbę zgłoszeń i podnosi deliverability.

• Proś o zgodę kontekstowo, po mikroakcji użytkownika (np. zapis na listę cenową, alert dostępności). Nie wyświetlaj natywnego promptu przy pierwszym wejściu.
• Stosuj pre-prompt (własny baner z wyjaśnieniem korzyści), a dopiero potem natywny prompt przeglądarki.
• Segmentuj rozsądnie i testuj A/B TTL, tytuły i godziny wysyłki.
• Loguj i monitoruj statusy dostaw po stronie serwera; ustaw alerty dla nagłych spadków deliverability.
• Sprzątaj bazę subskrypcji: usuwaj wygasłe endpointy, próbuj re-subskrybować użytkowników po błędach.
• Zapewnij fallback: e-mail lub SMS dla krytycznych komunikatów, jeśli push nie został dostarczony w X minut.
• Komunikuj instrukcję odblokowania powiadomień w Centrum pomocy/FAQ, najlepiej z krótkimi zrzutami ekranu.

Checklist do szybkiej diagnostyki

Przejdź punkt po punkcie i odhaczaj:

• Czy użytkownik jest subskrybowany i ma „Dozwolone” w przeglądarce?
• Czy system nie ma aktywnego trybu „Nie przeszkadzać”/Focus?
• Czy strona i zasoby działają w pełnym HTTPS?
• Czy service worker jest aktywny, aktualny i nasłuchuje zdarzenia „push”?
• Czy klucze VAPID/FCM/OneSignal są poprawne i środowisko to produkcja?
• Czy nie filtrujesz za mocno (segmenty, warunki, harmonogram)?
• Czy TTL nie jest zbyt krótki?
• Czy payload nie zawiera błędów i jest lekki?
• Czy test na pojedynczej subskrypcji dochodzi?

Kiedy skontaktować się z supportem dostawcy

Daj zespołowi wsparcia komplet danych – szybciej znajdą źródło problemu.

• Czas i ID kampanii/testu, środowisko (prod/test), liczba planowanych odbiorców i realnych dostaw.
• Logi błędów z serwera (kody odpowiedzi, np. 410, 401) i fragmenty żądań bez wrażliwych danych.
• Informacja o przeglądarce, systemie i urządzeniach, na których testujesz.
• Zrzuty z DevTools (Application > Service Workers, Notifications, błędy w Console).
• Opis ostatnich zmian w SW/konfiguracji (np. nowy certyfikat, aktualizacja biblioteki).

Na koniec: nawet jeśli dziś masz przestój, to jedna z tych awarii, które najczęściej kończą się szybkim zwycięstwem. Połączenie prostych kroków (uprawnienia, HTTPS, SW) z twardą weryfikacją integracji (klucze, TTL, logi) przywraca ruch z pushy w ciągu godzin, nie dni. A gdy już wszystko działa – zainwestuj w monitoring i porządek w bazie subskrypcji. Dzięki temu kolejne „cisze” będą rzadkie, a Twoje powiadomienia znów zrobią to, co potrafią najlepiej: przyciągać ludzi we właściwym momencie.