Web push értesítések: hogyan működnek és hogyan használd jól őket

A web push értesítés az egyetlen marketingcsatorna, ahol egyetlen rossz tervezési döntés véglegesen kizárhat egy vásárlódtól. Rossz pillanatban kérsz engedélyt, a látogató a Tiltás gombra kattint, és az a böngésző örökre bezárul előtted. Nincs újrakérdezés, nincs második kampány, nincs visszaszerző e-mail. Ez az aszimmetria az oka annak, hogy érdemes megérteni a mechanizmust, mielőtt egyetlen üzenetet is megírnál.

Mik azok a web push értesítések

A web push értesítés a szerveredről a feliratkozó böngészőjébe küldött üzenet, amelyet az operációs rendszer értesítési felülete jelenít meg, és amely akkor is megérkezik, ha az oldalad zárva van. Ez az utolsó rész a lényeg: az oldalon megjelenő felugró ablakkal szemben a web push elér olyasvalakit is, aki éppen nem nézi a webhelyedet.

Három webplatform-API épül egymásra benne, és a köztük lévő munkamegosztás magyarázza a csatorna viselkedésének nagy részét: a Service Worker API, a Push API és a Notifications API.

Hogyan működik a web push a motorháztető alatt

A service worker

A service worker olyan JavaScript worker, amely proxyként áll a webalkalmazásod, a böngésző és a hálózat között. Saját szálon fut, nincs DOM-hozzáférése, és azután is létezik, hogy bezárul az őt regisztráló oldal. Ez az állandóság teszi lehetővé, hogy push üzenetet fogadjon és értesítést jelenítsen meg akkor is, amikor senkinél sincs nyitva a lapod. A service workerek csak biztonságos kontextusban futnak, ami HTTPS-t jelent, a fejlesztéshez pedig a http://localhost számít biztonságosnak.

A feliratkozás: egy végpont plusz két kulcs

Ha a service worker aktív, az oldal meghívja a registration.pushManager.subscribe() metódust. A böngésző kommunikál a gyártója push szolgáltatásával, és egy PushSubscription objektumot ad vissza, amely a következőket tartalmazza:

• endpoint, egyedi képesség-URL, amelyen a push szolgáltatás elfogadja az üzeneteket
• keys.p256dh, elliptikus görbés Diffie-Hellman nyilvános kulcs a P-256 görbén
• keys.auth, hitelesítési titok

A szervered mindhármat eltárolja, és a végpontot titokként kezeli, mert aki birtokolja, az küldhet annak a feliratkozónak. A kulcsok azért vannak, mert a hasznos terhek végponttól végpontig titkosítottak. Az RFC 8291 írja le, hogyan: egy P-256 görbén végzett ECDH csere közös titkot hoz létre, ebből a HKDF kulcsokat származtat, a hasznos terhet pedig AES-128-GCM zárja le az aes128gcm tartalomkódolás alatt. A push szolgáltatás olyan titkosított szöveget továbbít, amelyet nem tud elolvasni.

A push szolgáltatás

A push üzeneteket nem közvetlenül az eszközre küldöd. A böngészőgyártó által üzemeltetett push szolgáltatásnak küldöd: a Chrome-nál a Google FCM végpontjainak, a Firefoxnál a Mozilla autopush szolgáltatásának, a Safarinál az Apple push szolgáltatásának. A protokollt az RFC 8030, a „Generic Event Delivery Using HTTP Push” definiálja. A szervered POST kérést küld a feliratkozási végpontra, a push szolgáltatás pedig elvégzi a mobilkézbesítés nehéz részét: egyetlen energiatakarékos kapcsolat az eszközhöz, sorbaállítás offline állapotban, a böngésző felébresztése, amikor üzenet érkezik. Ezért sem garantálható a kézbesítés. Ha az eszköz elég hosszú ideig ki van kapcsolva, az üzenetek a TTL-jük szerint lejárnak, és eldobódnak.

VAPID: annak bizonyítása, ki küld

A végpont titkossága vékony védelem. Az RFC 8292 hozzáadja a Voluntary Application Server Identification, azaz VAPID mechanizmust, hogy a push szolgáltatás meg tudja állapítani, melyik alkalmazásszervertől érkezett az üzenet.

Egyszer generálsz egy ECDSA kulcspárt a NIST P-256 görbén. A nyilvános kulcs az applicationServerKey értékébe kerül, amikor a böngésző feliratkozik, ezzel a szerveredhez kötve a feliratkozást. Minden pushnál a szervered egy JWT-t küld, amelyet a hozzá tartozó privát kulccsal írt alá ES256 algoritmussal, és amely aud állítást hordoz a push szolgáltatás forrására, exp állítást legfeljebb 24 órára előre, opcionálisan pedig sub állítást elérhetőségi adatokkal. A push szolgáltatás ellenőrzi az aláírást, így önmagában egy ellopott végpont már nem elég ahhoz, hogy valaki spamelje a feliratkozóidat.

A kézbesítési útvonal, végponttól végpontig

1. Az oldal regisztrál egy service workert, majd az engedély megadása után meghívja a subscribe() metódust a VAPID nyilvános kulcsoddal.
2. A szervered eltárolja a visszakapott végpontot és kulcsokat a feliratkozó rekordjához.
3. Küldéskor a szervered titkosítja a hasznos terhet a p256dh és auth értékekkel, aláír egy VAPID JWT-t, és POST kérést küld a végpontra.
4. A push szolgáltatás hitelesíti a kérést, és kézbesíti a titkosított üzenetet.
5. A böngésző push eseménnyel felébreszti a service workert, amely dekódolja a hasznos terhet, és meghívja a ServiceWorkerRegistration.showNotification() metódust.
6. A kattintás notificationclick eseményt vált ki a service workerben, ahol megnyitod a cél-URL-t.

Miért ilyen szigorú az engedélymodell

Nézd meg, mit ad egy feliratkozás: háttérfolyamatot, amely az oldalad megnyitása nélkül fut, plusz azt a lehetőséget, hogy rajzolj az operációs rendszer értesítési felületére. A böngészők ezért kifejezett, forrásonkénti, felhasználó által adott engedély mögé zárják, és a legtöbbjük megköveteli, hogy a kérés valódi felhasználói gesztust kövessen.

Egy másik korlát meg szokta lepni az embereket. A Chrome és az Edge megköveteli a userVisibleOnly: true beállítást a feliratkozásnál, ami ígéret arra, hogy minden push a felhasználó számára látható értesítést eredményez, tehát a néma háttérpush nem támogatott használati mód. A Firefox is kvótát alkalmaz azokra a push üzenetekre, amelyek nem generálnak értesítést.

Böngésző- és platformtámogatás

Az MDN szerint a Push API 2023 márciusa óta Baseline széles körben elérhető, vagyis működik a Chrome, az Edge, a Firefox és a Safari aktuális asztali verzióiban, valamint az androidos Chrome-ban és Firefoxban. Két kikötés többet számít a főcímnél.

Először: a Notifications API nem egyformán érhető el. Az MDN korlátozott elérhetőségűként jelöli, mert a Notification() konstruktor TypeError hibát dob a legtöbb mobilböngészőben. Bármihez, aminek telefonon is működnie kell, használj tartós értesítéseket a ServiceWorkerRegistration.showNotification() metóduson keresztül, ami amúgy is a service workeres út.

Másodszor: az értesítési beállítások megvalósítása egyenetlen. A műveletgombok, a jelvények, a képek és a requireInteraction böngészőnként és operációs rendszerenként eltérnek, ezért olyan értesítéseket tervezz, amelyek pusztán egy címmel, egy szövegtörzzsel és egy ikonnal is helyesen olvashatók.

Az iOS és iPadOS követelmény

Ez a kikötés dönti el, hogy a web push életképes-e mobilnehéz közönségnél, és szinte mindenhol rosszul írják le.

Az Apple az iOS és iPadOS 16.4 verziójában vezette be a Web Pusht, és ez csak azoknál a webalkalmazásoknál működik, amelyeket kitettek a kezdőképernyőre. A WebKit megfogalmazása szerint „we are adding support for Web Push to Home Screen web apps”, és „a web app that has been added to the Home Screen can request permission to receive push notifications”. A felhasználó a Megosztás menü és a „Kezdőképernyőhöz adás” lehetőséggel teszi ki, az engedélyt pedig ezután közvetlen felhasználói interakcióra válaszul kell kérni, például egy feliratkozás gomb megérintésekor.

Egy iPhone-on, hagyományos Safari lapon nyitott oldal nem tud push feliratkozást létrehozni. Ez valódi akadály: telepítési lépést kérsz, mielőtt egyáltalán engedélyt kérhetnél. macOS-en egyszerűbb a helyzet, mert a macOS Venturán futó Safari 16.1 szabványalapú Web Pusht hozott a hagyományos webhelyekhez, telepítési lépés nélkül.

Minimális feliratkozási példa

Ez a teljes kliensoldali folyamat. Kattintáskezelőbe való, nem az oldal betöltésébe.

async function subscribeToPush(vapidPublicKey) {
  // A push és a service worker biztonságos kontextust igényel (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Felhasználói gesztusból kell hívni, és felhasználónként csak egyszer.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // base64url kódolású P-256 nyilvános kulcs
  });

  // A végpontot és a kulcsokat a szerveren tárold; a végpont titok.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Az sw.js fájlban kezeled a push eseményt, meghívod a self.registration.showNotification(title, options) metódust, és a notificationclick eseményt kezelve nyitod meg a cél-URL-t.

Az engedélykérés UX-e: itt bukik el a legtöbb program

Soha ne kérj oldalbetöltéskor

A Lighthouse-nak külön auditja van erre: „if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs”. Az ajánlása az, hogy kínálj egy konkrét értesítéstípust, és csak akkor kérj engedélyt, miután a felhasználó feliratkozott arra a típusra. A Safari 12.1 és más böngészők tovább mentek, és megkövetelik az oldallal való interakciót, mielőtt egyáltalán kérés indulhatna.

Használj lágy előkérdést

Előbb mutasd meg a saját, oldalon belüli felkérésedet. Ez megnevezi az értékajánlatot, elvethető végleges költség nélkül, és csak a rákattintás váltja ki a valódi böngészőkérdést. Aki ma figyelmen kívül hagyja a lágy kérdésedet, azt jövő hónapban újra megkérdezheted. Aki a Tiltás gombra kattint, azt nem. Két szabály teszi működővé: írd le, mit fogsz ténylegesen küldeni, ne azt, hogy „értesüljön a frissítésekről”, és soha ne tervezz be téves kattintást, mert a véletlen elfogadás azonnali leiratkozást szül.

Kérdezz kontextusban

A Chrome saját ajánlása az, hogy „let your users take the initiative and turn on notifications at their own pace”, vagyis helyezz el diszkrét kapcsolókat a meglévő felületeken, és kerüld a „showing prompts and/or overlays without context or immediately after a user lands on the site” esetét.

A kereskedelemben működő pillanatok konkrétak: egy „szólj, ha újra lesz raktáron” vezérlő egy elfogyott terméknél, egy rendelés-visszaigazoló oldal, amely szállítási frissítéseket kínál, egy árfigyelő kapcsoló egy gyakran nézett terméknél. Az engedélyt megnevezett előnyért cseréled, nem begyűjtöd.

Az elutasítás gyakorlatilag végleges

Ha valaki letiltja az értesítéseket, a böngésző eltárolja ezt a döntést a forrásodhoz. A Notification.requestPermission() későbbi hívásai a tárolt denied értékre oldódnak fel anélkül, hogy bármit megjelenítenének, ezért ellenőrzi az MDN saját példája is a Notification.permission értékét, mielőtt egyáltalán meghívná a requestPermission() metódust. A tiltás visszavonása a webhelybeállításokban való turkálást jelenti, amit gyakorlatilag senki nem tesz meg.

Mit tesznek a böngészők, ha elrontod

A következmény már nem csak alacsony feliratkozási arány.

• A Chrome automatikusan bevonja a nagyon alacsony elfogadási arányú forrásokat egy csendesebb engedélyfelületre, eszköztípusonként külön, elnyomva a kérdést mindenki előtt.
• A Chrome sebességkorlátot alkalmaz azokra az oldalakra, amelyek nagy push volument alacsony elköteleződéssel kombinálnak, és HTTP 429 választ ad. Az eszkaláció egy nap, majd hét, majd tizennégy nap, és csak 42 egymást követő nem zavaró nap után áll vissza.
• A Chrome mostantól automatikusan visszavonja az értesítési engedélyt azoktól az oldalaktól, amelyekkel a felhasználó mostanában nem lépett interakcióba, ahol „very low user engagement and a high volume of notifications being sent” a helyzet. A Google indoklása kíméletlen: „Less than 1% of all notifications receive any interaction from users.”

Pusztán rossz küldéssel elveszítheted azokat a feliratkozókat, akiket már megszereztél.

A web push az e-maillel és az SMS-sel összevetve

A birtoklásbeli különbség, amely megváltoztatja a stratégiát

A push feliratkozás egy képesség-URL, amely egyetlen eszköz egyetlen böngészőprofiljához kötődik. Nem személy. Ugyanaz a vásárló laptopon Chrome-mal és telefonon Firefoxszal két, egymással kapcsolatban nem álló feliratkozás, és nem tudhatod, hogy ugyanaz az ember, hacsak nem azonosítja magát.

Ráadásul nem is hordozható. Egy e-mail-listát exportálhatsz, és holnap betöltheted egy másik platformra. Push feliratkozásokat nem tudsz szállítók között mozgatni, mert a kulcsok és a VAPID kötés egy konkrét alkalmazásszerver-kulcshoz készültek.

Ezért a web pusht mindig gyorsítóként kezeld egy saját tulajdonú csatorna mellett, sose helyettesítőként. A push pillanatát arra használd, hogy e-mail-címet vagy telefonszámot szerezz, ne fordítva. A marketingautomatizálás teljes útmutatója végigveszi, hogyan köss több csatornát egyetlen ügyfélútba.

Használati esetek, amelyek valóban működnek

A csatorna azokat az üzeneteket jutalmazza, amelyek időérzékenyek, személyesen relevánsak, és egyetlen érintéssel cselekvésre válthatók.

• Kosárelhagyás. Egy push egy órán belül, később e-maillel megerősítve. Az elhagyott kosár e-mail útmutató foglalkozik a sorrendezéssel.
• Készletértesítés. A legerősebb eset, mert a felhasználó kifejezetten kérte, hogy szóljanak neki.
• Árcsökkenés a figyelt termékeknél. Ugyanaz a logika, önként vállalt relevancia.
• Szállítási és rendelési állapot. Magas megnyitási szándék, alacsony panaszkockázat.
• Friss hírek egy feliratkozott témában. Hírek, eredmények, elérhetőségi ablakok.

Az is ugyanilyen világos, mi bukik el: az általános „új bejegyzést publikáltunk” körüzenetek, a differenciálatlan napi ajánlatok, bármi, ami egy címnél és egy sornál többet igényel, az újraaktiváló kampányok azoknak a feliratkozóknak, akik az utolsó húsz értesítést figyelmen kívül hagyták, és az olyan tranzakciós tartalom, amelyhez tartós nyilvántartás kell.

Gyakoriság, időzítés és szegmentálás

Kezdj óvatosan: feliratkozónként heti egy-három értesítés, és csak akkor bővíts, ha a leiratkozási és átkattintási arány tartja magát. A fáradás gyorsabban jelentkezik, mint az e-mailnél, mert a némítás egyetlen érintésbe kerül egy olyan értesítésen, amelyet az operációs rendszer már felhozott.

Az időzítés előny és veszély is egyben. A push azonnal érkezik, tehát a 02:00-kor küldött üzenet 02:00-kor érkezik meg. A feliratkozáskor tárold vagy következtesd ki a feliratkozó időzónáját, és tartsd a küldést egy meghatározott ablakon belül.

A szegmentálást az korlátozza, amit egy feliratkozásról tudsz, nem az, amit egy személyről, ezért a használható dimenziók viselkedésalapúak: megtekintett oldalak, figyelt termékek, kosárállapot, vásárlás frissessége, platform. A vásárlói szegmentálás útmutató mélyebbre megy.

A web push mérése

Négy mérőszám számít, és nem mindegyik ugyanúgy mérhető.

• Kézbesítés. Elfogadta-e a push szolgáltatás a kérést. A 201 azt jelenti, hogy elfogadta, nem azt, hogy kézbesítette. A 404 vagy 410 azt jelenti, hogy a feliratkozás halott.
• Megjelenítés. Megjelent-e az értesítés. Ezt csak akkor tudod, ha a service worker visszajelez, amikor a showNotification() beteljesül.
• Átkattintási arány. Kattintások osztva a megjelenítésekkel. Ezt a számot érdemes optimalizálni.
• Leiratkozási arány. Leiratkozások és engedélyvisszavonások küldésenként. Ezt figyeld szorosabban, mint az átkattintási arányt, mert ez a csatorna halálának előrejelzője.

Attribúciós buktatók

A push attribúció hízeleg magának. Az értesítés olyan eszközre érkezik, amelyet a feliratkozó már a kezében tart, így gyakran olyan munkamenetet ír a saját javára, amely amúgy is megtörtént volna. Használj kontrollcsoportokat ahelyett, hogy feltételeznéd az inkrementalitást. A megjelenítéseket alulszámoljuk, miközben minden kattintás rögzül, tehát a küldésekre vetített átkattintási arány felülbecsli a teljesítményt. És mivel a feliratkozás böngésző, nem személy, a telefonon kattintott, majd asztali gépen vásárlással záruló push két, egymással kapcsolatban nem álló eseménynek látszik. Az e-mail marketing mérőszámok útmutatója foglalkozik a csatornákon átívelő mérési higiéniával.

Hozzájárulás, GDPR és leiratkozás

A böngésző engedélykérése technikai kapu. Nem automatikusan teljes jogalap a marketinghez.

Ha EU-ban vagy Egyesült Királyságban élő embereknek küldesz marketinget, kezeld a pusht úgy, ahogy az e-mailt. Magyarázd el a kérdés megjelenése előtt, mit fogsz küldeni, hogy a hozzájárulás tájékozott és konkrét legyen. Rögzítsd, mikor és hol jött létre a feliratkozás, és soha ne csomagold a push hozzájárulást egy nem kapcsolódó művelethez. Ha a feliratkozásokat azonosított vásárlókhoz kötöd, azok az adatok a személyesadat-kötelezettségeid alá esnek, a törlési kérésekkel együtt.

A leiratkozási higiénia ugyanennyire számít. Kínálj oldalon belüli beállításvezérlőt, hogy az emberek tiltás helyett csökkenthessék a gyakoriságot, hívd meg a PushSubscription.unsubscribe() metódust, és töröld a rekordot a szerveren, amikor ezt teszik, a 404 vagy 410 válasznál pedig tisztítsd ki a feliratkozásokat. Az MDN iránymutatása rövid és helytálló: a felhasználóknak „offered an easy way to opt out of getting more in the future” kell lennie.

Hol a helye a web pushnak a csatornakészletben

A web push jó harmadik csatorna és rossz első: gyors, a határon ingyenes, és verhetetlen az időkritikus riasztásoknál, ugyanakkor eszközhöz kötött, nem exportálható, és egyetlen kattintásra van a végleges elvesztéstől.

Ettől lesz az orkesztráció az igazi feladat. Melyik üzenet melyik csatornára megy, hogyan nyomod el az e-mailt, ha a push már konvertált, és hogyan tartasz fenn egyetlen vásárlói képet olyan felületeken át, amelyek eltérően azonosítják az embereket. A Brevo web és mobil pusht is kínál az e-mail és az SMS mellett, a Tajo pedig a Brevo tetején ül, és Shopify áruházak számára koordinálja ezt a csatornákon átívelő logikát. Az SMS oldalához nézd meg az SMS automatizálási útmutatót.

Legfontosabb tanulságok

• A web push három együttműködő API: a service worker a háttérfuttatáshoz, a Push API a feliratkozáshoz és a szállításhoz, a Notifications API a megjelenítéshez. A feliratkozás egy végpont plusz egy p256dh kulcs és egy auth titok, a hasznos terhek végponttól végpontig titkosítottak, a VAPID pedig bizonyítja a küldőt.
• A push 2023 márciusa óta Baseline széles körben elérhető, de iOS-en és iPadOS-en csak a kezdőképernyőre kitett webalkalmazásoknál működik.
• Soha ne kérj engedélyt oldalbetöltéskor. Használj lágy előkérdést, kérdezz kontextusban, és ne feledd, hogy a tiltás végleges az adott forrásra.
• A Chrome mostantól csendesebb kérdéseket, sebességkorlátot és automatikus engedélyvisszavonást érvényesít, tehát a rossz küldés azokba a feliratkozókba kerül, akiket már megszereztél.
• A feliratkozás böngésző, nem személy, és nem exportálható. Előbb az e-mail-listát építsd fel, a pusht pedig annak gyorsítására használd.