Powiadomienia web push: jak działają i jak używać ich dobrze

Powiadomienia web push to jedyny kanał marketingowy, w którym jedna zła decyzja projektowa może zamknąć Ci drogę do klienta na stałe. Poprosisz o zgodę w złym momencie, odwiedzający kliknie Blokuj i ta przeglądarka jest dla Ciebie zamknięta na zawsze. Bez ponownego pytania, bez drugiej kampanii, bez emaila odzyskującego. Ta asymetria sprawia, że warto zrozumieć mechanizm, zanim napiszesz choćby jedną wiadomość.

Czym są powiadomienia web push

Powiadomienie web push to wiadomość wysłana z Twojego serwera do przeglądarki subskrybenta, wyświetlana przez centrum powiadomień systemu operacyjnego i dostarczana nawet wtedy, gdy Twoja witryna jest zamknięta. Ta ostatnia część jest tu sednem: w przeciwieństwie do wyskakującego okna na stronie web push dociera do kogoś, kto akurat nie patrzy na Twoją witrynę.

Zbudowany jest z trzech współpracujących API platformy webowej, a podział między nimi wyjaśnia większość zachowań tego kanału: Service Worker API, Push API i Notifications API.

Jak web push działa pod maską

Service worker

Service worker to javascriptowy worker, który działa jak proxy między Twoją aplikacją webową, przeglądarką i siecią. Pracuje we własnym wątku, nie ma dostępu do DOM i istnieje dalej po zamknięciu strony, która go zarejestrowała. Ta trwałość pozwala mu odebrać wiadomość push i wyświetlić powiadomienie, gdy nikt nie ma otwartej Twojej karty. Service workery działają tylko w bezpiecznych kontekstach, czyli po HTTPS, przy czym http://localhost jest traktowany jako bezpieczny na potrzeby rozwoju.

Subskrypcja: endpoint plus dwa klucze

Gdy service worker jest już aktywny, strona wywołuje registration.pushManager.subscribe(). Przeglądarka rozmawia z usługą push swojego producenta i zwraca PushSubscription zawierający:

• endpoint, unikalny adres URL, na którym usługa push przyjmuje wiadomości
• keys.p256dh, klucz publiczny Elliptic Curve Diffie-Hellman na krzywej P-256
• keys.auth, sekret uwierzytelniający

Twój serwer przechowuje wszystkie trzy i traktuje endpoint jak sekret, bo każdy, kto go ma, może wysyłać do tego subskrybenta. Klucze istnieją, bo ładunki są szyfrowane end to end. RFC 8291 opisuje jak: wymiana ECDH na P-256 ustala wspólny sekret, HKDF wyprowadza z niego klucze, a ładunek jest zapieczętowany algorytmem AES-128-GCM w kodowaniu treści aes128gcm. Usługa push przekazuje szyfrogram, którego nie potrafi odczytać.

Usługa push

Nie wysyłasz wiadomości push bezpośrednio na urządzenie. Wysyłasz je do usługi push prowadzonej przez producenta przeglądarki: endpointy FCM Google dla Chrome, autopush Mozilli dla Firefoksa, usługa push Apple dla Safari. RFC 8030, „Generic Event Delivery Using HTTP Push”, definiuje protokół. Twój serwer wysyła POST na endpoint subskrypcji, a usługa push zajmuje się trudnymi elementami dostarczania mobilnego: jednym oszczędnym energetycznie połączeniem z urządzeniem, kolejkowaniem, gdy urządzenie jest offline, i budzeniem przeglądarki, gdy wiadomość dotrze. To także powód, dla którego dostarczenie nie może być gwarantowane. Jeśli urządzenie jest wyłączone wystarczająco długo, wiadomości wygasają zgodnie z ich TTL i są odrzucane.

VAPID: dowód, kto wysyła

Sekretność endpointu to cienkie zabezpieczenie. RFC 8292 dodaje Voluntary Application Server Identification, czyli VAPID, żeby usługa push mogła stwierdzić, z którego serwera aplikacji przyszła wiadomość.

Generujesz raz parę kluczy ECDSA na krzywej NIST P-256. Klucz publiczny trafia do applicationServerKey, gdy przeglądarka tworzy subskrypcję, wiążąc ją z Twoim serwerem. Przy każdym powiadomieniu Twój serwer wysyła JWT podpisany pasującym kluczem prywatnym algorytmem ES256, niosący roszczenie aud z domeną usługi push, roszczenie exp nie dalsze niż 24 godziny i opcjonalnie roszczenie sub z danymi kontaktowymi. Usługa push weryfikuje podpis, więc sam skradziony endpoint już nie wystarczy do spamowania Twoich subskrybentów.

Ścieżka dostarczenia od początku do końca

1. Strona rejestruje service workera i po udzieleniu zgody wywołuje subscribe() z Twoim publicznym kluczem VAPID.
2. Twój serwer zapisuje zwrócony endpoint i klucze przy rekordzie subskrybenta.
3. Żeby wysłać, Twój serwer szyfruje ładunek kluczami p256dh i auth, podpisuje JWT VAPID i wysyła POST na endpoint.
4. Usługa push uwierzytelnia żądanie i dostarcza zaszyfrowaną wiadomość.
5. Przeglądarka budzi service workera zdarzeniem push, które odszyfrowuje ładunek i wywołuje ServiceWorkerRegistration.showNotification().
6. Kliknięcie uruchamia notificationclick w service workerze, gdzie otwierasz docelowy adres URL.

Dlaczego model zgody jest tak restrykcyjny

Spójrz, co daje subskrypcja: proces w tle działający bez otwartej witryny plus możliwość rysowania po powierzchni powiadomień systemu operacyjnego. Przeglądarki bramkują to więc wyraźną zgodą użytkownika, przyznawaną osobno dla każdej domeny, a większość wymaga, żeby prośba szła po prawdziwym geście użytkownika.

Zaskakuje też drugie ograniczenie. Chrome i Edge wymagają userVisibleOnly: true przy subskrypcji, czyli obietnicy, że każde powiadomienie push wyprodukuje widoczne dla użytkownika powiadomienie, więc ciche pushe w tle nie są wspieranym zastosowaniem tego API. Firefox również nakłada limit na wiadomości push, które nie generują powiadomienia.

Wsparcie przeglądarek i platform

Według MDN Push API jest szeroko dostępne w ramach Baseline od marca 2023, czyli działa w aktualnych wersjach Chrome, Edge, Firefoksa i Safari na komputerach oraz w Chrome i Firefoksie na Androida. Dwa zastrzeżenia mają większe znaczenie niż sam nagłówek.

Po pierwsze, Notifications API nie jest dostępne równomiernie. MDN oznacza je jako ograniczenie dostępności, bo konstruktor Notification() rzuca TypeError w większości przeglądarek mobilnych. Dla wszystkiego, co musi działać na telefonach, używaj trwałych powiadomień przez ServiceWorkerRegistration.showNotification(), czyli tej samej ścieżki service workera, na której i tak jesteś.

Po drugie, opcje powiadomień są nierówno zaimplementowane. Przyciski akcji, plakietki, obrazy i requireInteraction różnią się między przeglądarkami i systemami operacyjnymi, więc projektuj powiadomienia, które nadal czyta się poprawnie przy samym tytule, treści i ikonie.

Wymóg iOS i iPadOS

To zastrzeżenie przesądza, czy web push nadaje się dla odbiorców mocno mobilnych, i prawie wszędzie jest podawane błędnie.

Apple dodał Web Push w iOS i iPadOS 16.4 i działa on tylko dla aplikacji webowych dodanych do ekranu głównego. Jak ujął to WebKit, „dodajemy obsługę Web Push do aplikacji webowych z ekranu głównego” oraz „aplikacja webowa dodana do ekranu głównego może poprosić o zgodę na otrzymywanie powiadomień push”. Użytkownik dodaje ją przez menu Udostępnij i „Dodaj do ekranu głównego”, a o zgodę trzeba potem poprosić w odpowiedzi na bezpośrednią interakcję, na przykład tapnięcie przycisku subskrypcji.

Witryna otwarta w zwykłej karcie Safari na iPhonie nie może utworzyć subskrypcji push. To realna bariera: prosisz o krok instalacji, zanim w ogóle będziesz mógł poprosić o zgodę. Na macOS jest łatwiej, bo Safari 16.1 w macOS Ventura dodało oparty na standardach Web Push dla zwykłych witryn, bez kroku instalacji.

Minimalny przykład subskrypcji

To cały przepływ po stronie klienta. Jego miejsce jest w obsłudze kliknięcia, a nie przy ładowaniu strony.

async function subscribeToPush(vapidPublicKey) {
  // Push i service workery wymagają bezpiecznego kontekstu (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

  const registration = await navigator.serviceWorker.register("/sw.js");

  // Musi być wywołane z gestu użytkownika i tylko raz na użytkownika.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // klucz publiczny P-256 w base64url
  });

  // Zapisz endpoint i klucze po stronie serwera; traktuj endpoint jak sekret.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Wewnątrz sw.js obsługujesz zdarzenie push, wywołujesz self.registration.showNotification(title, options) i obsługujesz notificationclick, żeby otworzyć docelowy adres URL.

UX zgody: tu upada większość programów

Nigdy nie pytaj przy ładowaniu strony

Lighthouse ma na to osobny audyt: „jeśli Twoja strona prosi o zgodę na wysyłanie powiadomień przy ładowaniu, te powiadomienia mogą nie być trafne dla Twoich użytkowników ani ich potrzeb”. Zaleca zaproponowanie konkretnego typu powiadomień i poproszenie o zgodę dopiero po tym, jak użytkownik zapisze się na ten typ. Safari 12.1 i inne przeglądarki poszły dalej, wymagając interakcji ze stroną, zanim prośba w ogóle może się pojawić.

Użyj miękkiego pytania wstępnego

Pokaż najpierw własne zaproszenie na stronie. Nazywa ono korzyść, można je zamknąć bez trwałych konsekwencji, a dopiero kliknięcie w nie uruchamia prawdziwe okno przeglądarki. Kogoś, kto zignoruje Twoje miękkie pytanie dzisiaj, można zapytać ponownie za miesiąc. Kogoś, kto kliknie Blokuj, już nie. Sprawiają, że to działa, dwie zasady: opisz, co naprawdę będziesz wysyłać, zamiast pisać „otrzymuj aktualizacje”, i nigdy nie prowokuj przypadkowego kliknięcia, bo przypadkowa zgoda kończy się natychmiastowym wypisaniem.

Pytaj w kontekście

Sam Chrome zaleca, żeby „pozwolić użytkownikom przejąć inicjatywę i włączyć powiadomienia we własnym tempie”, umieszczając przełączniki dyskretnie w istniejących elementach interfejsu, i unikać „pokazywania okien lub nakładek bez kontekstu albo zaraz po wejściu użytkownika na witrynę”.

Momenty, które działają w handlu, są konkretne: przycisk „powiadom mnie, gdy wróci do sprzedaży” przy wyprzedanym produkcie, strona potwierdzenia zamówienia oferująca aktualizacje dostawy, przełącznik obserwowania ceny przy często oglądanym produkcie. Zgoda jest wymieniana za nazwaną korzyść, a nie zbierana na siłę.

Odmowa jest w praktyce trwała

Gdy ktoś zablokuje powiadomienia, przeglądarka zapamiętuje tę decyzję dla Twojej domeny. Późniejsze wywołania Notification.requestPermission() rozstrzygają się na zapisanej wartości denied, nic nie pokazując, i dlatego własny przykład MDN sprawdza Notification.permission, zanim w ogóle wywoła requestPermission(). Cofnięcie blokady oznacza grzebanie w ustawieniach witryny, czego praktycznie nikt nie robi.

Co robią przeglądarki, gdy zrobisz to źle

Konsekwencje to już nie tylko niski wskaźnik zgód.

• Chrome automatycznie włącza domeny z bardzo niskim wskaźnikiem akceptacji do cichszego interfejsu zgody, osobno według typu urządzenia, wygaszając okno dla wszystkich.
• Chrome ogranicza tempo witrynom, które łączą wysoki wolumen push z niskim zaangażowaniem, zwracając HTTP 429. Eskalacja trwa jeden dzień, potem siedem, potem czternaście, a resetuje się dopiero po 42 kolejnych dniach bez zakłóceń.
• Chrome automatycznie odbiera teraz zgodę na powiadomienia witrynom, z którymi użytkownik ostatnio nie wchodził w interakcję, gdy występuje „bardzo niskie zaangażowanie użytkownika i wysoki wolumen wysyłanych powiadomień”. Uzasadnienie Google jest bezlitosne: „Mniej niż 1% wszystkich powiadomień spotyka się z jakąkolwiek interakcją użytkowników.”

Możesz stracić subskrybentów, których już zdobyłeś, po prostu wysyłając źle.

Web push w porównaniu z emailem i SMS

Różnica we własności, która zmienia strategię

Subskrypcja push to adres URL powiązany z jednym profilem przeglądarki na jednym urządzeniu. To nie jest osoba. Ten sam klient używający Chrome na laptopie i Firefoksa na telefonie to dwie niepowiązane subskrypcje i nie wiesz, że to ten sam człowiek, dopóki sam się nie zidentyfikuje.

Nie jest też przenośna. Listę emailową możesz wyeksportować i jutro wgrać do innej platformy. Subskrypcji push nie przeniesiesz między dostawcami, bo klucze i powiązanie VAPID powstały wobec konkretnego klucza serwera aplikacji.

Traktuj więc web push jako przyspieszacz kanału, który posiadasz, nigdy jako jego zamiennik. Wykorzystaj moment push, żeby zdobyć adres email albo numer telefonu, a nie odwrotnie. Kompletny przewodnik po marketing automation omawia wpinanie kilku kanałów w jedną ścieżkę.

Zastosowania, które naprawdę działają

Kanał nagradza wiadomości wrażliwe na czas, osobiście trafne i możliwe do wykonania jednym tapnięciem.

• Porzucone koszyki. Push w ciągu godziny, wzmocniony emailem później. Przewodnik po emailach o porzuconym koszyku omawia kolejność wiadomości.
• Alerty o powrocie do sprzedaży. Najmocniejszy przypadek, bo użytkownik sam poprosił o informację.
• Spadki cen obserwowanych produktów. Ta sama logika, samodzielnie wybrana trafność.
• Status dostawy i zamówienia. Wysoka intencja otwarcia, niskie ryzyko skarg.
• Pilne aktualizacje w zasubskrybowanym temacie. Wiadomości, wyniki, okna dostępności.

Równie jasne jest to, co zawodzi: ogólne komunikaty „opublikowaliśmy nowy wpis”, niezróżnicowane codzienne promocje, wszystko, co potrzebuje więcej niż tytułu i jednej linijki, masowe próby odzyskania subskrybentów, którzy zignorowali ostatnie dwadzieścia powiadomień, oraz treści transakcyjne wymagające trwałego zapisu.

Częstotliwość, czas i segmentacja

Zacznij ostrożnie: od jednego do trzech powiadomień na subskrybenta tygodniowo, zwiększając tylko wtedy, gdy wskaźniki rezygnacji i kliknięć się utrzymują. Zmęczenie pojawia się szybciej niż w emailu, bo wyciszenie kosztuje jedno tapnięcie na powiadomieniu, które system i tak już pokazał.

Czas jest jednocześnie przewagą i zagrożeniem. Push dociera natychmiast, więc wiadomość wysłana o 02:00 dociera o 02:00. Zapisuj albo wywnioskuj strefę czasową subskrybenta przy subskrypcji i trzymaj wysyłki w zdefiniowanym oknie.

Segmentacja jest ograniczona tym, co wiesz o subskrypcji, a nie o osobie, więc działające wymiary są behawioralne: oglądane strony, obserwowane produkty, stan koszyka, świeżość zakupu, platforma. Przewodnik po segmentacji klientów wchodzi w to głębiej.

Mierzenie web push

Liczą się cztery metryki i nie wszystkie mierzy się tak samo.

• Dostarczenie. Czy usługa push przyjęła żądanie. Kod 201 oznacza przyjęcie, a nie dostarczenie. Kod 404 albo 410 oznacza martwą subskrypcję.
• Wyświetlenie. Czy powiadomienie zostało pokazane. Wiesz to tylko wtedy, gdy service worker raportuje z powrotem po rozstrzygnięciu showNotification().
• Współczynnik kliknięć. Kliknięcia podzielone przez wyświetlenia. To liczba, którą warto optymalizować.
• Wskaźnik rezygnacji. Wypisania i cofnięcia zgody na wysyłkę. Obserwuj go uważniej niż CTR, bo to wskaźnik wyprzedzający śmierć kanału.

Pułapki atrybucji

Atrybucja push sama sobie pochlebia. Powiadomienie dociera na urządzenie, które subskrybent i tak trzyma w ręku, więc często bierze zasługę za sesję, która i tak by się wydarzyła. Uruchamiaj grupy kontrolne zamiast zakładać przyrostowość. Wyświetlenia są niedoliczane, a każde kliknięcie jest zapisane, więc CTR liczony wobec wysyłek zawyża wyniki. A ponieważ subskrypcja to przeglądarka, a nie osoba, push kliknięty na telefonie, który kończy się zakupem na komputerze, wygląda jak dwa niepowiązane zdarzenia. Przewodnik po metrykach email marketingu omawia higienę pomiaru w różnych kanałach.

Zgoda, GDPR i rezygnacja

Okno zgody w przeglądarce to bramka techniczna. Nie jest automatycznie kompletną podstawą prawną dla marketingu.

Jeśli kierujesz marketing do osób w UE albo Wielkiej Brytanii, traktuj push tak, jak traktujesz email. Wyjaśnij, co będziesz wysyłać, zanim pojawi się okno, żeby zgoda była świadoma i konkretna. Zapisuj, kiedy i gdzie powstała subskrypcja, i nigdy nie doklejaj zgody na push do niepowiązanej czynności. Jeśli wiążesz subskrypcje z zidentyfikowanymi klientami, te dane wchodzą w zakres Twoich obowiązków wobec danych osobowych, łącznie z żądaniami usunięcia.

Higiena rezygnacji ma równie duże znaczenie. Zaoferuj panel preferencji na stronie, żeby ludzie mogli zmniejszyć częstotliwość zamiast blokować, wywołuj PushSubscription.unsubscribe() i usuwaj rekord po stronie serwera, gdy to zrobią, oraz czyść subskrypcje przy kodzie 404 albo 410. Wskazówka MDN jest krótka i trafna: użytkownikom należy „zaoferować łatwy sposób rezygnacji z otrzymywania kolejnych w przyszłości”.

Gdzie web push wpisuje się w zestaw kanałów

Web push to dobry trzeci kanał i zły pierwszy: szybki, praktycznie darmowy na marginesie i niezrównany przy alertach wrażliwych na czas, ale przywiązany do urządzenia, nieeksportowalny i o jedno kliknięcie od trwałej utraty.

To sprawia, że prawdziwym problemem jest orkiestracja. Która wiadomość idzie którym kanałem, jak wygasić email, gdy push już skonwertował, i jak utrzymać jeden widok klienta na powierzchniach, które identyfikują ludzi inaczej. Brevo oferuje push webowy i mobilny obok emaila i SMS, a Tajo siedzi na Brevo i koordynuje tę logikę międzykanałową dla sklepów Shopify. Po stronę SMS zajrzyj do przewodnika po automatyzacji SMS.

Najważniejsze wnioski

• Web push to trzy współpracujące API: service worker do działania w tle, Push API do subskrypcji i transportu, Notifications API do wyświetlania. Subskrypcja to endpoint plus klucz p256dh i sekret auth, ładunki są szyfrowane end to end, a VAPID potwierdza nadawcę.
• Push jest szeroko dostępny w ramach Baseline od marca 2023, ale na iOS i iPadOS działa tylko dla aplikacji webowych dodanych do ekranu głównego.
• Nigdy nie proś o zgodę przy ładowaniu strony. Użyj miękkiego pytania wstępnego, pytaj w kontekście i pamiętaj, że blokada jest trwała dla tej domeny.
• Chrome egzekwuje teraz cichsze okna, limity tempa i automatyczne odbieranie zgody, więc złe wysyłanie kosztuje Cię subskrybentów, których już masz.
• Subskrypcja to przeglądarka, a nie osoba, i nie da się jej wyeksportować. Zbuduj najpierw listę emailową i użyj push, żeby ją przyspieszyć.