Webové push notifikácie: ako fungujú a ako ich používať dobre

Webové push notifikácie sú jediný marketingový kanál, kde Vás jedno zlé rozhodnutie v návrhu môže natrvalo zamknúť pred zákazníkom. Požiadate o povolenie v nesprávnej chvíli, návštevník klikne na Blokovať a ten prehliadač je pre Vás zatvorený navždy. Žiadna opakovaná výzva, žiadna druhá kampaň, žiadny e-mail na získanie späť. Práve táto asymetria je dôvod, prečo sa oplatí pochopiť mechanizmus skôr, než napíšete jedinú správu.

Čo sú webové push notifikácie

Webová push notifikácia je správa odoslaná z Vášho servera do prehliadača odberateľa, zobrazená v notifikačnom centre operačného systému a doručená aj vtedy, keď je Vaša stránka zatvorená. Presne v tomto je celý zmysel: na rozdiel od vyskakovacieho okna na stránke zastihne web push aj niekoho, kto sa práve na Váš web nepozerá.

Skladá sa z troch webových platformových API, ktoré spolupracujú, a rozdelenie medzi nimi vysvetľuje väčšinu správania tohto kanála: Service Worker API, Push API a Notifications API.

Ako web push funguje pod kapotou

Service worker

Service worker je JavaScriptový worker, ktorý funguje ako proxy medzi Vašou webovou aplikáciou, prehliadačom a sieťou. Beží vo vlastnom vlákne, nemá prístup k DOM a existuje ďalej aj po zatvorení stránky, ktorá ho zaregistrovala. Práve táto trvácnosť mu umožňuje prijať push správu a zobraziť notifikáciu, keď nikto nemá otvorenú Vašu kartu. Service workery bežia iba v bezpečných kontextoch, čo znamená HTTPS, pričom http://localhost sa pri vývoji považuje za bezpečný.

Odber: endpoint plus dva kľúče

Keď je service worker aktívny, stránka zavolá registration.pushManager.subscribe(). Prehliadač komunikuje s push službou svojho výrobcu a vráti PushSubscription, ktorý obsahuje:

• endpoint, jedinečnú URL adresu, na ktorej push služba prijíma správy
• keys.p256dh, verejný kľúč Elliptic Curve Diffie-Hellman na krivke P-256
• keys.auth, autentifikačné tajomstvo

Váš server všetky tri uloží a endpoint považuje za tajomstvo, pretože ktokoľvek, kto ho má, môže danému odberateľovi posielať správy. Kľúče existujú preto, lebo payloady sú šifrované od konca po koniec. RFC 8291 určuje ako: výmena ECDH na krivke P-256 vytvorí zdieľané tajomstvo, HKDF z neho odvodí kľúče a payload sa zapečatí pomocou AES-128-GCM pod kódovaním obsahu aes128gcm. Push služba prenáša šifrovaný text, ktorý nedokáže prečítať.

Push služba

Push správy neposielate priamo do zariadenia. Posielate ich do push služby prevádzkovanej výrobcom prehliadača: endpointy FCM od Googlu pre Chrome, autopush od Mozilly pre Firefox, push služba od Apple pre Safari. Protokol definuje RFC 8030 „Generic Event Delivery Using HTTP Push”. Váš server pošle POST na endpoint odberu a push služba zvládne tie ťažké časti mobilného doručovania: jedno pripojenie k zariadeniu šetrné k batérii, radenie do fronty počas offline stavu, zobudenie prehliadača pri príchode správy. To je aj dôvod, prečo sa doručenie nedá garantovať. Ak je zariadenie dostatočne dlho vypnuté, správy podľa svojho TTL vypršia a zahodia sa.

VAPID: dôkaz o tom, kto posiela

To, že endpoint je tajný, je slabá ochrana. RFC 8292 pridáva Voluntary Application Server Identification, čiže VAPID, aby push služba vedela určiť, z ktorého aplikačného servera správa prišla.

Raz si vygenerujete pár kľúčov ECDSA na krivke NIST P-256. Verejný kľúč ide do applicationServerKey pri prihlásení v prehliadači a viaže odber na Váš server. Pri každom pushi Váš server posiela JWT podpísané zodpovedajúcim privátnym kľúčom pomocou ES256, ktoré nesie claim aud s doménou push služby, claim exp s platnosťou najviac 24 hodín a voliteľne claim sub s kontaktnými údajmi. Push služba podpis overí, takže samotný ukradnutý endpoint už na spamovanie Vašich odberateľov nestačí.

Cesta doručenia od začiatku do konca

1. Stránka zaregistruje service worker a po udelení povolenia zavolá subscribe() s Vaším verejným kľúčom VAPID.
2. Váš server uloží vrátený endpoint a kľúče k záznamu odberateľa.
3. Pri odosielaní server zašifruje payload pomocou p256dh a auth, podpíše VAPID JWT a pošle POST na endpoint.
4. Push služba požiadavku overí a doručí zašifrovanú správu.
5. Prehliadač zobudí service worker udalosťou push, ktorá payload dešifruje a zavolá ServiceWorkerRegistration.showNotification().
6. Kliknutie spustí notificationclick v service workeri, kde otvoríte cieľovú URL.

Prečo je model povolení taký prísny

Pozrite sa, čo odber udeľuje: proces na pozadí, ktorý beží bez toho, aby bola Vaša stránka otvorená, plus možnosť kresliť na notifikačnú plochu operačného systému. Prehliadače to preto zamykajú za výslovné povolenie udelené používateľom pre každú doménu zvlášť a väčšina vyžaduje, aby žiadosť nasledovala po skutočnom geste používateľa.

Druhé obmedzenie ľudí prekvapuje. Chrome a Edge vyžadujú pri prihlásení userVisibleOnly: true, čo je prísľub, že každý push vytvorí používateľovi viditeľnú notifikáciu, takže tiché pushe na pozadí nie sú podporovaným použitím tohto API. Firefox navyše uplatňuje kvótu na push správy, ktoré notifikáciu nevygenerujú.

Podpora v prehliadačoch a na platformách

Podľa MDN je Push API v stave Baseline widely available od marca 2023, čo znamená, že funguje naprieč aktuálnymi verziami Chrome, Edge, Firefoxu a Safari na počítačoch a v Chrome a Firefoxe pre Android. Dve výhrady sú dôležitejšie než tento titulok.

Po prvé, Notifications API nie je dostupné rovnomerne. MDN ho označuje ako obmedzene dostupné, pretože konštruktor Notification() na väčšine mobilných prehliadačov vyhodí TypeError. Pri čomkoľvek, čo musí fungovať na telefónoch, použite radšej trvalé notifikácie cez ServiceWorkerRegistration.showNotification(), čo je aj tak tá cesta cez service worker, na ktorej ste.

Po druhé, možnosti notifikácií sú implementované nerovnomerne. Tlačidlá akcií, odznaky, obrázky a requireInteraction sa medzi prehliadačmi a operačnými systémami líšia, takže navrhujte notifikácie tak, aby dávali zmysel aj len s nadpisom, textom a ikonou.

Požiadavka na iOS a iPadOS

Táto výhrada rozhoduje o tom, či je web push použiteľný pre publikum s prevahou mobilov, a takmer všade sa uvádza nesprávne.

Apple pridal Web Push v iOS a iPadOS 16.4 a funguje iba pre webové aplikácie, ktoré boli pridané na plochu. Ako to formuloval WebKit, „we are adding support for Web Push to Home Screen web apps” a „a web app that has been added to the Home Screen can request permission to receive push notifications”. Používateľ ju pridá cez ponuku Zdieľať a „Pridať na plochu” a povolenie sa potom musí vyžiadať ako reakcia na priamu interakciu používateľa, napríklad na ťuknutie na tlačidlo odberu.

Stránka otvorená v bežnej karte Safari na iPhone nedokáže vytvoriť push odber. To je skutočná bariéra: pýtate si inštalačný krok skôr, než sa vôbec môžete opýtať na povolenie. Na macOS je to jednoduchšie, pretože Safari 16.1 na macOS Ventura pridalo Web Push podľa štandardov pre bežné webové stránky bez inštalačného kroku.

Minimálny príklad odberu

Toto je celý tok na strane klienta. Patrí do obsluhy kliknutia, nie na načítanie stránky.

async function subscribeToPush(vapidPublicKey) {
  // Push a service workery vyžadujú bezpečný kontext (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Musí sa volať z gesta používateľa a iba raz na používateľa.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // verejný kľúč P-256 kódovaný v base64url
  });

  // Endpoint a kľúče uložte na serveri, endpoint považujte za tajomstvo.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Vnútri sw.js obslúžite udalosť push, zavoláte self.registration.showNotification(title, options) a obslúžite notificationclick, aby ste otvorili cieľovú URL.

UX povolení: tu väčšina programov zlyhá

Nikdy sa nepýtajte pri načítaní stránky

Lighthouse na to má samostatný audit: „ak Vaša stránka žiada o povolenie posielať notifikácie pri načítaní, tieto notifikácie nemusia byť pre Vašich používateľov ani ich potreby relevantné”. Odporúča ponúknuť konkrétny typ notifikácie a o povolenie požiadať až potom, ako sa používateľ pre ten typ rozhodne. Safari 12.1 a ďalšie prehliadače išli ešte ďalej a vyžadujú interakciu so stránkou skôr, než sa žiadosť vôbec dá podať.

Použite mäkkú prípravnú výzvu

Najprv ukážte vlastnú pozvánku priamo na stránke. Pomenuje hodnotu, dá sa zavrieť bez trvalých následkov a skutočnú výzvu prehliadača spustí až kliknutie na ňu. Toho, kto Vašu mäkkú výzvu dnes ignoruje, sa môžete opýtať znova o mesiac. Toho, kto klikne na Blokovať, už nie. Fungovať to bude vďaka dvom pravidlám: popíšte, čo naozaj budete posielať, namiesto „získajte novinky”, a nikdy nezariaďte omylné kliknutie, pretože náhodné prijatie vedie k okamžitému odhláseniu.

Pýtajte sa v kontexte

Samotný Chrome odporúča „nechať používateľov prevziať iniciatívu a zapnúť si notifikácie vlastným tempom” tým, že prepínače umiestnite decentne do existujúcich častí rozhrania, a vyhnúť sa „zobrazovaniu výziev alebo prekryvov bez kontextu či hneď po tom, ako používateľ pristane na stránke”.

Momenty, ktoré v e-commerce fungujú, sú konkrétne: ovládací prvok „upozorniť ma, keď bude tovar opäť skladom” pri vypredanom produkte, stránka potvrdenia objednávky ponúkajúca aktualizácie o doručení, prepínač sledovania ceny pri často prezeranom produkte. Povolenie sa vymieňa za pomenovaný prínos, nie zbiera.

Zamietnutie je prakticky trvalé

Keď niekto notifikácie zablokuje, prehliadač si toto rozhodnutie pre Vašu doménu uloží. Neskoršie volania Notification.requestPermission() sa vyhodnotia na uloženú hodnotu denied bez toho, aby sa čokoľvek zobrazilo, a preto vlastný príklad na MDN kontroluje Notification.permission skôr, než vôbec zavolá requestPermission(). Zrušenie blokovania znamená hrabať sa v nastaveniach stránky, čo v podstate nikto nerobí.

Čo urobia prehliadače, keď to pokazíte

Následkom už nie je len nízka miera prihlásení.

• Chrome automaticky zaraďuje domény s veľmi nízkou mierou prijatí do tichšieho rozhrania povolení, samostatne podľa typu zariadenia, a výzvu tak potlačí pre všetkých.
• Chrome obmedzuje frekvenciu stránkam, ktoré spájajú vysoký objem pushov s nízkym zapojením, a vracia HTTP 429. Eskalácia trvá jeden deň, potom sedem, potom štrnásť a resetuje sa až po 42 po sebe idúcich dňoch bez rušivého správania.
• Chrome dnes automaticky odoberá povolenie notifikácií stránkam, s ktorými používateľ v poslednom čase nekomunikoval a kde je „veľmi nízke zapojenie používateľa a vysoký objem odosielaných notifikácií”. Zdôvodnenie od Googlu je strohé: „Menej ako 1 % všetkých notifikácií dostane od používateľov akúkoľvek interakciu.”

Odberateľov, ktorých ste si už získali, môžete stratiť jednoducho tým, že posielate zle.

Web push v porovnaní s e-mailom a SMS

Rozdiel vo vlastníctve, ktorý mení stratégiu

Push odber je URL adresa s oprávnením, viazaná na jeden profil prehliadača na jednom zariadení. Nie je to osoba. Ten istý zákazník používajúci Chrome na notebooku a Firefox na telefóne sú dva nesúvisiace odbery a nemôžete vedieť, že ide o toho istého človeka, pokiaľ sa sám neidentifikuje.

Nie je to ani prenosné. E-mailový zoznam môžete exportovať a zajtra nahrať do inej platformy. Push odbery medzi dodávateľmi presunúť nemôžete, pretože kľúče a naviazanie cez VAPID vznikli voči konkrétnemu kľúču aplikačného servera.

Preto sa k web pushu správajte ako k urýchľovaču vlastneného kanála, nikdy ako k jeho náhrade. Moment pushu použite na získanie e-mailovej adresy alebo telefónneho čísla, nie naopak. Kompletný sprievodca marketingovou automatizáciou pokrýva zapojenie viacerých kanálov do jednej cesty zákazníka.

Prípady použitia, ktoré naozaj fungujú

Tento kanál odmeňuje správy, ktoré sú časovo citlivé, osobne relevantné a vybaviteľné jedným ťuknutím.

• Opustený košík. Push do hodiny, neskôr podporený e-mailom. Sprievodca e-mailmi pri opustenom košíku pokrýva postupnosť.
• Upozornenia na návrat tovaru na sklad. Najsilnejší prípad, pretože používateľ o upozornenie výslovne požiadal.
• Zníženie ceny pri sledovaných položkách. Rovnaká logika, relevancia zvolená samotným používateľom.
• Stav doručenia a objednávky. Vysoký zámer otvoriť, nízke riziko sťažností.
• Aktuality v odoberanej téme. Novinky, výsledky, okná dostupnosti.

Rovnako jasné je, čo zlyháva: všeobecné rozosielky typu „zverejnili sme nový článok”, nediferencované denné zľavy, čokoľvek, čo potrebuje viac než nadpis a jeden riadok, reaktivačné rozosielky odberateľom, ktorí ignorovali posledných dvadsať notifikácií, a transakčný obsah, ktorý potrebuje trvalý záznam.

Frekvencia, načasovanie a segmentácia

Začnite konzervatívne: jedna až tri notifikácie na odberateľa za týždeň a rozširujte, len ak miera odhlásení a preklikov vydrží. Únava sa prejaví rýchlejšie než pri e-maile, pretože stlmenie stojí jedno ťuknutie na notifikáciu, ktorú operačný systém už aj tak zobrazil.

Načasovanie je zároveň výhoda aj riziko. Push prichádza okamžite, takže správa odoslaná o 02:00 dorazí o 02:00. Pri vytvorení odberu si uložte alebo odvoďte časové pásmo odberateľa a odosielanie držte v definovanom okne.

Segmentáciu obmedzuje to, že viete niečo o odbere, nie o osobe, takže použiteľné rozmery sú behaviorálne: prezerané stránky, sledované produkty, stav košíka, čerstvosť nákupu, platforma. Sprievodca segmentáciou zákazníkov ide hlbšie.

Meranie web pushu

Dôležité sú štyri metriky a nie všetky sa merajú rovnako.

• Doručenie. Či push služba požiadavku prijala. Stav 201 znamená prijaté, nie doručené. Stav 404 alebo 410 znamená, že odber je mŕtvy.
• Zobrazenie. Či sa notifikácia ukázala. Viete to iba vtedy, keď to service worker nahlási späť po tom, ako sa showNotification() dokončí.
• Miera preklikov. Kliknutia delené zobrazeniami. Toto je číslo, ktoré sa oplatí optimalizovať.
• Miera odhlásení. Odhlásenia a odobratia povolenia na jedno odoslanie. Sledujte ju pozornejšie než mieru preklikov, pretože je predstihovým ukazovateľom smrti kanála.

Nástrahy atribúcie

Atribúcia pushu si sama sebe lichotí. Notifikácia dorazí na zariadenie, ktoré odberateľ už drží v ruke, takže si často pripíše zásluhy za návštevu, ktorá by sa aj tak stala. Namiesto predpokladu prírastkovosti spúšťajte kontrolné skupiny. Zobrazenia sa podpočítavajú, kým každé kliknutie sa zaznamená, takže miera preklikov počítaná voči odoslaniam výkon nadhodnocuje. A keďže odber je prehliadač, nie osoba, push kliknutý na telefóne, ktorý skončí nákupom na počítači, vyzerá ako dve nesúvisiace udalosti. Sprievodca metrikami e-mailového marketingu pokrýva hygienu merania naprieč kanálmi.

Súhlas, GDPR a odhlásenie

Výzva na povolenie v prehliadači je technická brána. Nie je automaticky úplným právnym základom pre marketing.

Ak robíte marketing voči ľuďom v EÚ alebo Spojenom kráľovstve, správajte sa k pushu tak, ako sa správate k e-mailu. Skôr než sa výzva objaví, vysvetlite, čo budete posielať, aby bol súhlas informovaný a konkrétny. Zaznamenajte, kedy a kde odber vznikol, a nikdy nezabaľujte súhlas s pushom do nesúvisiacej akcie. Ak odbery viažete na identifikovaných zákazníkov, tieto dáta spadajú pod Vaše povinnosti pri osobných údajoch vrátane žiadostí o vymazanie.

Rovnako dôležitá je hygiena odhlasovania. Ponúknite na stránke ovládanie predvolieb, aby si ľudia mohli znížiť frekvenciu namiesto blokovania, pri odhlásení zavolajte PushSubscription.unsubscribe() a zmažte záznam na serveri, a odbery čistite pri stave 404 alebo 410. Odporúčanie MDN je krátke a správne: používateľom má byť „ponúknutý jednoduchý spôsob, ako sa odhlásiť od ďalších správ v budúcnosti”.

Kam web push patrí v skladbe kanálov

Web push je dobrý tretí kanál a zlý prvý: rýchly, na okraji bezplatný a bezkonkurenčný pri časovo kritických upozorneniach, ale viazaný na zariadenie, neexportovateľný a jedno kliknutie od trvalej straty.

Skutočným problémom sa tak stáva orchestrácia. Ktorá správa ide do ktorého kanála, ako potlačíte e-mail, keď push už konvertoval, a ako si udržíte jeden pohľad na zákazníka naprieč plochami, ktoré ľudí identifikujú odlišne. Brevo ponúka webový aj mobilný push popri e-maile a SMS a Tajo sedí nad Brevo a koordinuje túto medzikanálovú logiku pre obchody na Shopify. K SMS strane si pozrite sprievodcu automatizáciou SMS.

Kľúčové poznatky

• Web push sú tri spolupracujúce API: service worker pre beh na pozadí, Push API pre odber a prenos, Notifications API pre zobrazenie. Odber je endpoint plus kľúč p256dh a tajomstvo auth, payloady sú šifrované od konca po koniec a VAPID dokazuje odosielateľa.
• Push je v stave Baseline widely available od marca 2023, ale na iOS a iPadOS funguje iba pre webové aplikácie pridané na plochu.
• Nikdy nežiadajte o povolenie pri načítaní stránky. Použite mäkkú prípravnú výzvu, pýtajte sa v kontexte a pamätajte, že blokovanie je pre danú doménu trvalé.
• Chrome dnes vynucuje tichšie výzvy, limity frekvencie a automatické odoberanie povolení, takže zlé posielanie Vás stojí odberateľov, ktorých už máte.
• Odber je prehliadač, nie osoba, a nedá sa exportovať. Najprv budujte e-mailový zoznam a push použite na jeho zrýchlenie.