Krótko mówiąc
Te dwa kanały wyglądają podobnie, bo oba wyświetlają krótkie wiadomości związane z Twoim produktem, ale leżą po przeciwnych stronach dwóch granic: zasięgu i zgody. Web push opuszcza Twoją stronę i trafia na urządzenie, gdy użytkownik przyzna uprawnienie w przeglądarce. Wiadomości in-app zostają w aktywnej sesji i nie wymagają osobnego uprawnienia. Traktuj je jak dwa narzędzia, a nie jedno.
Jak działa web push
Web push opiera się na współpracy trzech elementów przeglądarki: service workera (skryptu, który przeglądarka utrzymuje w działaniu w tle), Push API (które subskrybuje przeglądarkę w usłudze powiadomień push i odbiera wiadomości) oraz Notifications API (które wyświetla powiadomienie systemowe). Użytkownik musi wyraźnie kliknąć Zezwalaj w okienku z prośbą o uprawnienie; dopóki tego nie zrobi, nie możesz niczego wysłać. Po wyrażeniu zgody dostajesz endpoint subskrypcji i klucze szyfrujące, a Twój serwer wysyła wiadomości przez usługę powiadomień push przeglądarki nawet wtedy, gdy karta jest zamknięta. Ponieważ wiadomość dociera poza stroną, web push jest w tej grupie kanałem do ponownego angażowania – zadaniem bliżej mu do SMS-ów czy e-maila niż do czegokolwiek, co żyje w Twojej aplikacji. Haczyk: ogranicza go obsługa przeglądarki i systemu, a użytkownik może w każdej chwili cofnąć uprawnienie.
Zastrzeżenie dotyczące iOS
Na iPhonie i iPadzie web push nie działa w zwykłej karcie Safari. Apple dodało web push tylko dla aplikacji webowych, które użytkownik dodał do ekranu początkowego, począwszy od Safari 16.4 (marzec 2023). Prośba o uprawnienie musi być odpowiedzią na bezpośrednie stuknięcie – np. przycisk Subskrybuj – a nie pojawiać się przy ładowaniu strony. Na iOS do Twojego zasięgu należą więc tylko ci użytkownicy, którzy zainstalowali Twoją stronę jako aplikację webową, a potem przyznali uprawnienie. Zaplanuj tę lukę, zamiast zakładać, że będzie tak samo jak na komputerze.
Jak działają wiadomości in-app
Wiadomości in-app wyświetlają się w aktywnej sesji – baner, okno modalne, panel wysuwany z boku czy podpowiedź przy elemencie, rysowane przez Twój produkt, gdy użytkownik z niego korzysta. Nie ma osobnej zgody, bo użytkownik już jest w Twoim produkcie; wiadomość jest częścią doświadczenia. Ceną jest zasięg: in-app dociera tylko do osób, które są obecne właśnie teraz. Nie sprowadzi z powrotem użytkownika, który przestał korzystać z produktu, a użytkownik, który odszedł, nigdy jej nie zobaczy.
Kiedy czego używać
| Zadanie | Po co sięgnąć |
|---|---|
| Sprowadzić z powrotem nieaktywnego użytkownika | Web push (albo e-mail / SMS) |
| Ogłosić nową funkcję aktywnym użytkownikom | Baner lub okno modalne in-app |
| Przeprowadzić nowego użytkownika przez konfigurację | Podpowiedź lub panel wysuwany in-app |
| Powiadomić poza stroną o pilnym zdarzeniu | Web push |
| Zaproponować przejście na wyższy plan w trakcie zadania | Okno modalne in-app |
Uczciwy podział: in-app obsługuje ludzi, którzy już są w pokoju, a web push szuka tych, którzy wyszli. Większość produktów używa obu kanałów, koordynując je w ramach ścieżki klienta, żeby ta sama osoba nie dostała w ciągu kilku minut przypomnienia in-app i powiadomienia web push o tym samym. Decyzja, który kanał niesie którą wiadomość, w jakiej kolejności i bez nakładania się, to przejście od prowadzenia wielu kanałów do prowadzenia ich jak jednego – o tym jest tekst multichannel vs omnichannel. Samodzielne narzędzia, takie jak OneSignal czy Novu, specjalizują się w dostarczaniu powiadomień push i innych powiadomień; platforma customer engagement włącza web push i in-app w tę samą logikę ścieżek co pozostałe kanały.