Spletna potisna obvestila: kako delujejo in kako jih dobro uporabiti

Spletna potisna obvestila so edini trženjski kanal, kjer vas ena sama slaba odločitev pri zasnovi lahko trajno zapre pred stranko. Če dovoljenje zahtevate ob napačnem trenutku, obiskovalec klikne Blokiraj in ta brskalnik je za vas za vedno zaprt. Brez ponovnega poziva, brez druge kampanje, brez e-pošte za vrnitev. Prav zaradi te asimetrije je vredno razumeti mehanizem, preden napišete eno samo sporočilo.

Kaj so spletna potisna obvestila

Spletno potisno obvestilo je sporočilo, ki ga vaš strežnik pošlje v brskalnik naročnika, prikaže ga obvestilno središče operacijskega sistema, dostavi pa se tudi takrat, ko je vaše spletno mesto zaprto. Prav zadnji del je bistvo: za razliko od pojavnega okna na strani spletni potisk doseže nekoga, ki trenutno ne gleda vašega spletnega mesta.

Zgrajen je iz treh vmesnikov spletne platforme, ki delujejo skupaj, in prav delitev med njimi pojasni večino vedenja tega kanala: Service Worker API, Push API in Notifications API.

Kako spletni potisk deluje pod pokrovom

Storitveni delavec

Storitveni delavec (service worker) je delavec JavaScript, ki deluje kot posrednik med vašo spletno aplikacijo, brskalnikom in omrežjem. Teče na svoji niti, nima dostopa do DOM in obstaja naprej tudi po tem, ko se stran, ki ga je registrirala, zapre. Prav ta vztrajnost mu omogoča, da prejme potisno sporočilo in prikaže obvestilo, ko nihče nima odprtega vašega zavihka. Storitveni delavci tečejo samo v varnih kontekstih, kar pomeni HTTPS, pri čemer se http://localhost za razvoj obravnava kot varen.

Naročnina: končna točka in dva ključa

Ko je storitveni delavec dejaven, stran pokliče registration.pushManager.subscribe(). Brskalnik se poveže s potisno storitvijo svojega ponudnika in vrne objekt PushSubscription, ki vsebuje:

• endpoint, edinstven URL zmožnosti, na katerem potisna storitev sprejema sporočila
• keys.p256dh, javni ključ Elliptic Curve Diffie-Hellman na krivulji P-256
• keys.auth, avtentikacijsko skrivnost

Vaš strežnik shrani vse tri in končno točko obravnava kot skrivnost, saj lahko vsakdo, ki jo ima, pošilja temu naročniku. Ključi obstajajo zato, ker je vsebina šifrirana od konca do konca. RFC 8291 določa, kako: izmenjava ECDH na P-256 vzpostavi skupno skrivnost, HKDF iz nje izpelje ključe, vsebina pa je zapečatena z AES-128-GCM pod kodiranjem vsebine aes128gcm. Potisna storitev posreduje šifropis, ki ga ne more prebrati.

Potisna storitev

Potisnih sporočil ne pošiljate neposredno v napravo. Pošiljate jih potisni storitvi, ki jo upravlja ponudnik brskalnika: končne točke Google FCM za Chrome, Mozillin autopush za Firefox, Applova potisna storitev za Safari. Protokol določa RFC 8030, „Generic Event Delivery Using HTTP Push”. Vaš strežnik pošlje POST na končno točko naročnine, potisna storitev pa poskrbi za težke dele mobilne dostave: eno energijsko varčno povezavo do naprave, čakalno vrsto, ko je naprava brez povezave, in bujenje brskalnika ob prispetju sporočila. To je tudi razlog, da dostave ni mogoče zajamčiti. Če je naprava dovolj dolgo izklopljena, sporočilom poteče njihov TTL in se zavržejo.

VAPID: dokaz, kdo pošilja

To, da je končna točka skrivnost, je šibka varnost. RFC 8292 dodaja Voluntary Application Server Identification ali VAPID, da lahko potisna storitev ugotovi, s katerega aplikacijskega strežnika je sporočilo prišlo.

Enkrat ustvarite par ključev ECDSA na krivulji NIST P-256. Javni ključ gre v applicationServerKey, ko se brskalnik naroči, s čimer naročnino veže na vaš strežnik. Za vsak potisk vaš strežnik pošlje žeton JWT, podpisan z ustreznim zasebnim ključem po ES256, ki nosi zahtevek aud za izvor potisne storitve, zahtevek exp z veljavnostjo največ 24 ur in po želji zahtevek sub s kontaktnimi podatki. Potisna storitev preveri podpis, zato ukradena končna točka sama po sebi ne zadošča več za pošiljanje neželene pošte vašim naročnikom.

Pot dostave od konca do konca

1. Stran registrira storitvenega delavca in po odobrenem dovoljenju pokliče subscribe() z vašim javnim ključem VAPID.
2. Vaš strežnik vrnjeno končno točko in ključe shrani ob zapis naročnika.
3. Za pošiljanje vaš strežnik vsebino šifrira s p256dh in auth, podpiše žeton JWT za VAPID in pošlje POST na končno točko.
4. Potisna storitev preveri zahtevo in dostavi šifrirano sporočilo.
5. Brskalnik prebudi storitvenega delavca z dogodkom push, ta pa vsebino dešifrira in pokliče ServiceWorkerRegistration.showNotification().
6. Klik v storitvenem delavcu sproži notificationclick, kjer odprete ciljni URL.

Zakaj je model dovoljenj tako strog

Poglejte, kaj naročnina omogoča: proces v ozadju, ki teče, ne da bi bilo vaše spletno mesto odprto, poleg tega pa zmožnost izrisovanja na obvestilni površini operacijskega sistema. Brskalniki zato to zavarujejo z izrecnim dovoljenjem na izvor, ki ga podeli uporabnik, večina pa zahteva, da zahtevi sledi resnična uporabnikova gesta.

Druga omejitev ljudi preseneti. Chrome in Edge pri naročanju zahtevata userVisibleOnly: true, torej obljubo, da bo vsak potisk ustvaril uporabniku vidno obvestilo, zato tihi potiski v ozadju niso podprta raba tega vmesnika. Tudi Firefox uporablja kvoto za potisna sporočila, ki ne ustvarijo obvestila.

Podpora brskalnikov in platform

Po podatkih MDN je Push API na široko dostopen v okviru Baseline od marca 2023, kar pomeni, da deluje v trenutnih različicah brskalnikov Chrome, Edge, Firefox in Safari na namizju ter v brskalnikih Chrome in Firefox za Android. Dve opozorili sta pomembnejši od tega naslova.

Prvič, Notifications API ni enakomerno na voljo. MDN ga označuje kot omejeno dostopnega, ker konstruktor Notification() v večini mobilnih brskalnikov sproži TypeError. Za vse, kar mora delovati na telefonih, uporabite vztrajna obvestila prek ServiceWorkerRegistration.showNotification(), kar je pot prek storitvenega delavca, na kateri ste tako ali tako.

Drugič, možnosti obvestil so neenakomerno implementirane. Gumbi za dejanja, značke, slike in requireInteraction se med brskalniki in operacijskimi sistemi razlikujejo, zato zasnujte obvestila, ki so razumljiva že samo z naslovom, telesom in ikono.

Zahteva pri iOS in iPadOS

To opozorilo odloči, ali je spletni potisk sploh smiseln za občinstvo, ki uporablja predvsem mobilne naprave, in skoraj povsod je navedeno napačno.

Apple je Web Push dodal v iOS in iPadOS 16.4, deluje pa samo za spletne aplikacije, ki so dodane na začetni zaslon. Kot je zapisal WebKit, „we are adding support for Web Push to Home Screen web apps” in „a web app that has been added to the Home Screen can request permission to receive push notifications”. Uporabnik jo doda prek menija za deljenje in ukaza „Add to Home Screen”, nato pa je treba dovoljenje zahtevati kot odziv na neposredno dejanje uporabnika, na primer na dotik gumba za naročilo.

Spletno mesto, odprto v običajnem zavihku Safari na iPhonu, ne more ustvariti naročnine na potiske. To je resnična ovira: za namestitveni korak prosite, še preden lahko sploh vprašate za dovoljenje. Na macOS je lažje, ker je Safari 16.1 na macOS Ventura dodal standardiziran Web Push za običajna spletna mesta brez namestitvenega koraka.

Minimalen primer naročnine

To je celoten tok na strani odjemalca. Sodi v obravnavo klika, ne v nalaganje strani.

async function subscribeToPush(vapidPublicKey) {
  // Potisk in storitveni delavci zahtevajo varen kontekst (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Klicati je treba iz uporabnikove geste in samo enkrat na uporabnika.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // javni ključ P-256, kodiran v base64url
  });

  // Končno točko in ključe shranite na strežniku; končno točko obravnavajte kot skrivnost.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Znotraj sw.js obravnavate dogodek push, pokličete self.registration.showNotification(title, options) in obravnavate notificationclick, da odprete ciljni URL.

Uporabniška izkušnja dovoljenj: tam večina programov pade

Nikoli ne sprašujte ob nalaganju strani

Lighthouse ima za to poseben pregled: „if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs”. Priporoča, da ponudite določeno vrsto obvestil in dovoljenje zahtevate šele potem, ko uporabnik privoli v to vrsto. Safari 12.1 in drugi brskalniki so šli še dlje in zahtevajo interakcijo s stranjo, preden je zahtevo sploh mogoče poslati.

Uporabite mehki predpoziv

Najprej pokažite svoje lastno povabilo na strani. Poimenuje ponujeno vrednost, mogoče ga je zavrniti brez trajne cene, pravi poziv brskalnika pa sproži šele klik nanj. Nekoga, ki vaš mehki poziv danes prezre, lahko čez mesec dni vprašate znova. Nekoga, ki klikne Blokiraj, ne morete. Delovanje zagotovita dve pravili: opišite, kaj boste dejansko pošiljali, in ne „prejemajte novosti”, ter nikoli ne zasnujte pomotnega klika, saj nenamerna privolitev pripelje do takojšnje odjave.

Vprašajte v kontekstu

Chromovo priporočilo je, da „let your users take the initiative and turn on notifications at their own pace”, torej da stikala diskretno umestite v obstoječe površine vmesnika in se izogibate „showing prompts and/or overlays without context or immediately after a user lands on the site”.

Trenutki, ki v trgovini delujejo, so specifični: možnost „obvestite me, ko bo spet na zalogi” pri razprodanem izdelku, stran s potrditvijo naročila, ki ponudi obvestila o dostavi, stikalo za spremljanje cene pri pogosto ogledanem izdelku. Dovoljenje se zamenja za poimenovano korist, ne pa pobere mimogrede.

Zavrnitev je dejansko trajna

Ko nekdo blokira obvestila, brskalnik to odločitev shrani za vaš izvor. Poznejši klici Notification.requestPermission() se razrešijo v shranjeno vrednost denied, ne da bi karkoli prikazali, zato tudi lasten primer na MDN preveri Notification.permission, preden sploh pokliče requestPermission(). Razveljavitev blokade pomeni brskanje po nastavitvah spletnega mesta, česar dejansko ne počne nihče.

Kaj naredijo brskalniki, ko se zmotite

Posledice niso več le nizka stopnja privolitve.

• Chrome izvore z zelo nizkimi stopnjami sprejemanja samodejno uvrsti v tišji vmesnik za dovoljenja, ločeno po vrsti naprave, s čimer poziv zatre za vse.
• Chrome omejuje zahteve spletnim mestom, ki združujejo velik obseg potiskov z nizko angažiranostjo, in vrača HTTP 429. Stopnjevanje traja en dan, nato sedem, nato štirinajst, ponastavi pa se šele po 42 zaporednih dneh brez motenj.
• Chrome zdaj samodejno prekliče dovoljenje za obvestila pri spletnih mestih, s katerimi uporabnik v zadnjem času ni bil v stiku in kjer gre za „very low user engagement and a high volume of notifications being sent”. Googlova utemeljitev je neizprosna: „Less than 1% of all notifications receive any interaction from users.”

Naročnike, ki ste jih že pridobili, lahko izgubite preprosto s slabim pošiljanjem.

Spletni potisk v primerjavi z e-pošto in SMS

Razlika v lastništvu, ki spremeni strategijo

Naročnina na potiske je URL zmožnosti, vezan na en profil brskalnika na eni napravi. Ni oseba. Ista stranka, ki uporablja Chrome na prenosniku in Firefox na telefonu, sta dve nepovezani naročnini, in ne morete vedeti, da gre za istega človeka, razen če se sam predstavi.

Prav tako ni prenosljiva. Seznam e-pošte lahko izvozite in ga jutri naložite v drugo platformo. Naročnin na potiske med ponudniki ne morete prenesti, ker so bili ključi in vezava VAPID ustvarjeni za določen aplikacijski strežniški ključ.

Spletni potisk zato obravnavajte kot pospeševalnik lastnega kanala, nikoli kot nadomestilo. Trenutek potiska uporabite za pridobitev e-poštnega naslova ali telefonske številke, ne obratno. Popoln vodnik po avtomatizaciji trženja pokriva povezovanje več kanalov v eno pot.

Primeri uporabe, ki resnično delujejo

Kanal nagrajuje sporočila, ki so časovno občutljiva, osebno relevantna in izvedljiva z enim dotikom.

• Opuščena košarica. Potisk v eni uri, pozneje podprt z e-pošto. Vodnik po e-pošti za opuščene košarice pokriva zaporedje.
• Obvestila o vrnitvi na zalogo. Najmočnejši primer, ker je uporabnik izrecno prosil, da se mu sporoči.
• Znižanja cen pri spremljanih izdelkih. Ista logika, samoizbrana ustreznost.
• Stanje dostave in naročila. Visoka namera za odpiranje, majhno tveganje pritožb.
• Pomembne novosti pri naročeni temi. Novice, rezultati, okna razpoložljivosti.

Kaj odpove, je enako jasno: splošne objave v slogu „objavili smo nov prispevek”, nediferencirane dnevne ponudbe, vse, kar potrebuje več kot naslov in eno vrstico, množično pošiljanje za ponovno aktivacijo naročnikom, ki so prezrli zadnjih dvajset obvestil, in transakcijska vsebina, ki potrebuje trajen zapis.

Pogostost, čas in segmentacija

Začnite zadržano: eno do tri obvestila na naročnika na teden, širite pa le, če stopnji odjave in klikov zdržita. Utrujenost se pokaže hitreje kot pri e-pošti, ker utišanje stane en dotik na obvestilu, ki ga je operacijski sistem že prikazal.

Čas je hkrati prednost in nevarnost. Potisk prispe takoj, zato sporočilo, poslano ob 2.00, prispe ob 2.00. Ob naročanju shranite ali sklepajte časovni pas naročnika in pošiljanje zadržite znotraj določenega okna.

Segmentacija je omejena s tem, kar veste o naročnini in ne o osebi, zato so uporabne dimenzije vedenjske: ogledane strani, spremljani izdelki, stanje košarice, čas od zadnjega nakupa, platforma. Vodnik po segmentaciji strank gre globlje.

Merjenje spletnega potiska

Štiri metrike so pomembne in vseh ni mogoče meriti na enak način.

• Dostava. Ali je potisna storitev zahtevo sprejela. Koda 201 pomeni sprejeto, ne dostavljeno. Koda 404 ali 410 pomeni, da je naročnina mrtva.
• Prikaz. Ali je bilo obvestilo prikazano. To veste le, če storitveni delavec poroča nazaj, ko se showNotification() razreši.
• Stopnja klikov. Kliki, deljeni s prikazi. To je številka, ki jo je vredno optimizirati.
• Stopnja odjav. Odjave in preklici dovoljenj na pošiljanje. Spremljajte jo bolj pozorno kot stopnjo klikov, saj je vodilni pokazatelj propada kanala.

Pasti pripisovanja

Pripisovanje pri potiskih si laska. Obvestilo prispe na napravo, ki jo naročnik že drži v roki, zato si pogosto pripiše zasluge za sejo, ki bi se zgodila tako ali tako. Namesto predpostavljanja prirastka poganjajte kontrolne skupine. Prikazi so podcenjeni, medtem ko je vsak klik zabeležen, zato stopnja klikov, izračunana glede na poslana sporočila, precenjuje uspešnost. In ker je naročnina brskalnik in ne oseba, potisk, kliknjen na telefonu, ki se konča z nakupom na namizju, izgleda kot dva nepovezana dogodka. Vodnik po metrikah e-poštnega trženja pokriva higieno merjenja po kanalih.

Privolitev, GDPR in odjava

Poziv brskalnika za dovoljenje je tehnična ovira. Sam po sebi ni popolna pravna podlaga za trženje.

Kadar tržite ljudem v EU ali Združenem kraljestvu, potisk obravnavajte tako kot e-pošto. Pred prikazom poziva pojasnite, kaj boste pošiljali, da je privolitev informirana in specifična. Zabeležite, kdaj in kje je naročnina nastala, in privolitve za potisk nikoli ne združujte z nepovezanim dejanjem. Če naročnine vežete na prepoznane stranke, ti podatki sodijo v vaše obveznosti glede osebnih podatkov, vključno z zahtevami za izbris.

Enako pomembna je higiena odjave. Ponudite nadzor nastavitev na spletnem mestu, da lahko ljudje zmanjšajo pogostost, namesto da blokirajo, ob tem pokličite PushSubscription.unsubscribe() in izbrišite zapis na strežniku, naročnine pa počistite ob odgovoru 404 ali 410. Navodilo MDN je kratko in pravilno: uporabnikom je treba ponuditi „offered an easy way to opt out of getting more in the future”.

Kam spletni potisk sodi v naboru kanalov

Spletni potisk je dober tretji kanal in slab prvi: hiter, mejno brezplačen in neprekosljiv za časovno kritična opozorila, a vezan na napravo, neizvozljiv in en klik od trajne izgube.

Zato je pravi izziv usklajevanje. Katero sporočilo gre v kateri kanal, kako zatrete e-pošto, ko je potisk že pretvoril, in kako ohranite en pogled na stranko po površinah, ki ljudi prepoznavajo različno. Brevo ob e-pošti in SMS ponuja spletne in mobilne potiske, Tajo pa sedi nad platformo Brevo in za trgovine Shopify usklajuje to logiko med kanali. Za stran SMS si oglejte vodnik po avtomatizaciji SMS.

Ključne ugotovitve

• Spletni potisk so trije vmesniki, ki sodelujejo: storitveni delavec za izvajanje v ozadju, Push API za naročnino in prenos, Notifications API za prikaz. Naročnina je končna točka ter ključ p256dh in skrivnost auth, vsebina je šifrirana od konca do konca, VAPID pa dokazuje pošiljatelja.
• Potisk je v okviru Baseline na široko dostopen od marca 2023, na iOS in iPadOS pa deluje samo za spletne aplikacije, dodane na začetni zaslon.
• Nikoli ne zahtevajte dovoljenja ob nalaganju strani. Uporabite mehki predpoziv, vprašajte v kontekstu in ne pozabite, da je blokada za tisti izvor trajna.
• Chrome zdaj uveljavlja tišje pozive, omejitve zahtev in samodejni preklic dovoljenj, zato vas slabo pošiljanje stane naročnike, ki jih že imate.
• Naročnina je brskalnik in ne oseba ter je ni mogoče izvoziti. Najprej zgradite seznam e-pošte in potisk uporabite za njegovo pospešitev.