Po raz pierwszy zetknąłem się z powiadomieniami push podczas tworzenia aplikacji mobilnych. Później ta sama zasada rozszerzyła się na internet: odwiedzający zezwala na wiadomości, a przeglądarka może je wyświetlać nawet wtedy, gdy dana osoba nie ma aktualnie otwartej strony.
Od strony technicznej jest to interesujące. Z punktu widzenia marketingu ważniejsze jest inne pytanie: czy mamy coś tak użytecznego i zależnego od czasu, że mamy prawo przerwać komuś zajęcie, aby o tym powiadomić? Jeśli nie, nie potrzebujemy kolejnego kanału.
Czym właściwie jest web push
Aplikacja webowa zwykle korzysta ze zgody na powiadomienia, service workera i usługi push przeglądarki. Subskrypcja jest powiązana z konkretną przeglądarką i urządzeniem, a nie automatycznie z osobą w CRM. MDN Push API opisuje techniczne podstawy oraz rolę service workera.
Ma to praktyczną konsekwencję: liczba subskrypcji nie jest liczbą klientów. Jedna osoba może mieć kilka urządzeń, ponownie zainstalować przeglądarkę albo w dowolnym momencie wycofać zgodę. Bez zalogowanego konta i starannego powiązania zwykle nie wiadomo, do kogo należy urządzenie. Nie próbowałbym ukrywać tej niepewności za pomocą przesadnie precyzyjnej persony.
Proś o zgodę tylko w odpowiednim kontekście
Najgorszą opcją jest systemowy komunikat wyświetlany natychmiast po wejściu na stronę. Osoba nie wie jeszcze, co oferujesz, a przeglądarka prosi ją o długoterminową zgodę. Jeśli wybierze blokadę, często nie dostaniesz drugiej szansy, dopóki ręcznie nie zmieni ustawień.
Dlatego najpierw wyjaśniam konkretną korzyść: powiadomienie o zmianie statusu zamówienia, dostępnym terminie, rozpoczęciu transmisji albo powrocie obserwowanego produktu. Dopiero po świadomym działaniu użytkownika otwieram właściwą prośbę przeglądarki. Dokumentacja Notifications API na MDN również zaleca powiązanie prośby z działaniem użytkownika.
Kiedy push ma sens
- Status i dostępność: zmieniło się zamówienie, rezerwacja, wizyta lub produkt.
- Treści zależne od czasu: rozpoczyna się transmisja, kończy się aukcja albo odbyło się wydarzenie, które dana osoba sama wybrała.
- Powtarzalne narzędzie pracy: użytkownik oczekuje alertów operacyjnych jako części usługi.
- Świadome śledzenie: osoba aktywnie włączyła konkretny temat, a nie ogólne „wiadomości”.
Im bliżej wiadomości do zachowania, które użytkownik wyraźnie skonfigurował, tym łatwiej uzasadnić przerwanie. Ogólny rabat dla wszystkich jest słabszym powodem niż alert, o który ktoś poprosił.
Kiedy wybrałbym e-mail
E-mail lepiej nadaje się do dłuższego wyjaśnienia, dokumentu, podsumowania i komunikacji, do której można wrócić później. Push ma niewiele miejsca, szybko znika i po kliknięciu nie powinien prowadzić do strony, na której użytkownik musi ponownie szukać znaczenia wiadomości.
Jeśli firma nie potrafi obsługiwać trafnych wiadomości e-mail, kolejny kanał często tylko zwielokrotnia problem. Najpierw uporządkowałbym bazę, ofertę i proces, korzystając z artykułu o e-mail marketingu. Następnie wybrałbym narzędzia zgodnie z konkretnym scenariuszem, a nie na podstawie liczby ikon w cenniku.
Co musi zawierać każda wiadomość
- jasny powód, dla którego dotarła właśnie teraz;
- rozpoznawalnego nadawcę;
- zwięzły komunikat bez fałszywej pilności;
- stronę docelową dokładnie odpowiadającą wiadomości;
- możliwość zmiany tematów lub zakończenia subskrypcji;
- limit częstotliwości i okres ciszy zależne od sytuacji użytkownika.
Nie wysyłałbym tej samej wiadomości jednocześnie przez push, e-mail, SMS i czat tylko dlatego, że integracja jest dostępna. Orkiestracja oznacza wybór odpowiedniego kanału, a nie korzystanie ze wszystkich.
Jak mierzyć push
Dostarczenia i kliknięcia są sygnałami operacyjnymi. Wartość biznesowa pojawia się dopiero przy kolejnym kroku: dokończeniu rezerwacji, powrocie do aplikacji, zakupie obserwowanego produktu albo zmniejszeniu liczby zapytań do wsparcia.
Śledzę również sygnały negatywne: wycofanie zgody, rezygnację z tematów, szybki powrót bez działania i skargi. Wysoki współczynnik klikalności może wynikać z agresywnego języka, który w dłuższej perspektywie niszczy kanał.
Oznaczam linki spójnymi parametrami UTM, ale uwzględniam fakt, że część pomiaru będzie ograniczona przez przeglądarkę, zgodę i cykl życia urządzenia. Dokładność dashboardu nie jest powodem do rozszerzania zbierania danych bez korzyści dla danej osoby.
Mały pilotaż zamiast uruchomienia w całym serwisie
- Wybieram jeden scenariusz zdarzenia o jasnej wartości.
- Opisuję, kto i w którym momencie może włączyć subskrypcję.
- Ustalam limit częstotliwości, termin wygaśnięcia wiadomości i możliwość wyłączenia.
- Testuję różne przeglądarki, urządzenia i sytuację bez udzielonej zgody.
- Mierzę zarówno wykonanie zadania, jak i negatywne reakcje.
- Po kilku cyklach decyduję, czy rozszerzyć, dostosować czy wyłączyć kanał.
Mój wniosek
Powiadomienia push nie są tańszym newsletterem. Są krótkimi, uzasadnionymi zakłóceniami uwagi. Dobrze sprawdzają się w przypadku wydarzenia, które dana osoba sama wybrała i o którym musi wiedzieć na czas. Słabo sprawdzają się jako kolejna powierzchnia do ogólnej promocji.
Jeśli chcesz zdecydować, czy push powinien należeć do całej ścieżki klienta, zacznij od przeglądu systemu marketingowego. Swoją konkretną sytuację możesz opisać przez kontakt.