Web push-varsler: slik fungerer de, og slik bruker du dem godt

Web push-varsler er den eneste markedsføringskanalen der én dårlig designbeslutning kan stenge deg permanent ute fra en kunde. Be om tillatelse på feil tidspunkt, den besøkende klikker Blokker, og den nettleseren er lukket for deg for alltid. Ingen ny forespørsel, ingen ny kampanje, ingen tilbakevinnings-e-post. Den skjevheten er grunnen til at mekanismen er verdt å forstå før du skriver en eneste melding.

Hva web push-varsler er

Et web push-varsel er en melding som sendes fra serveren din til en abonnents nettleser, vises av operativsystemets varslingssenter, og leveres selv når nettstedet ditt er lukket. Den siste delen er hele poenget: i motsetning til et sprettoppvindu på siden, når web push noen som ikke akkurat nå ser på nettstedet ditt.

Det er bygget av tre web-API-er som jobber sammen, og delingen mellom dem forklarer mesteparten av oppførselen til kanalen: Service Worker API, Push API og Notifications API.

Slik fungerer web push under panseret

Service workeren

En service worker er en JavaScript-worker som fungerer som en mellomtjener mellom nettappen din, nettleseren og nettverket. Den kjører på sin egen tråd, har ingen DOM-tilgang, og fortsetter å eksistere etter at siden som registrerte den er lukket. Den varigheten er det som lar den ta imot en push-melding og vise et varsel når ingen har fanen din åpen. Service workers kjører bare i sikre kontekster, altså HTTPS, med http://localhost behandlet som sikkert under utvikling.

Abonnementet: et endepunkt pluss to nøkler

Når en service worker er aktiv, kaller siden registration.pushManager.subscribe(). Nettleseren snakker med leverandørens push-tjeneste og returnerer et PushSubscription-objekt som inneholder:

• endpoint, en unik URL som push-tjenesten tar imot meldinger på
• keys.p256dh, en offentlig Elliptic Curve Diffie-Hellman-nøkkel på P-256-kurven
• keys.auth, en autentiseringshemmelighet

Serveren din lagrer alle tre og behandler endepunktet som en hemmelighet, for den som har det, kan sende til den abonnenten. Nøklene finnes fordi innholdet krypteres ende til ende. RFC 8291 spesifiserer hvordan: en ECDH-utveksling på P-256 etablerer en delt hemmelighet, HKDF utleder nøkler fra den, og innholdet forsegles med AES-128-GCM under innholdskodingen aes128gcm. Push-tjenesten videreformidler kryptert tekst den ikke kan lese.

Push-tjenesten

Du sender ikke push-meldinger direkte til en enhet. Du sender dem til en push-tjeneste som drives av nettleserleverandøren: Googles FCM-endepunkter for Chrome, Mozillas autopush for Firefox, Apples push-tjeneste for Safari. RFC 8030, «Generic Event Delivery Using HTTP Push», definerer protokollen. Serveren din poster til abonnementsendepunktet, og push-tjenesten håndterer de vanskelige delene av mobil levering: én batterivennlig tilkobling til enheten, kø mens den er frakoblet, og vekking av nettleseren når en melding kommer. Det er også derfor levering ikke kan garanteres. Er enheten avslått lenge nok, utløper meldingene i tråd med TTL-en sin og forkastes.

VAPID: å bevise hvem som sender

At endepunktet er en hemmelighet, er tynn sikkerhet. RFC 8292 legger til Voluntary Application Server Identification, eller VAPID, slik at en push-tjeneste kan avgjøre hvilken applikasjonsserver en melding kom fra.

Du genererer et ECDSA-nøkkelpar på NIST-kurven P-256 én gang. Den offentlige nøkkelen legges i applicationServerKey når nettleseren abonnerer, og binder abonnementet til serveren din. For hver push sender serveren din en JWT signert med den tilhørende private nøkkelen ved bruk av ES256, med et aud-krav for push-tjenestens domene, et exp-krav som ikke ligger mer enn 24 timer frem, og eventuelt et sub-krav med kontaktopplysninger. Push-tjenesten verifiserer signaturen, så et stjålet endepunkt alene er ikke lenger nok til å spamme abonnentene dine.

Leveringsveien, fra ende til ende

1. Siden registrerer en service worker og kaller, etter at tillatelse er gitt, subscribe() med din offentlige VAPID-nøkkel.
2. Serveren din lagrer endepunktet og nøklene som kommer tilbake, mot abonnentoppføringen.
3. For å sende krypterer serveren din innholdet med p256dh og auth, signerer en VAPID-JWT og poster til endepunktet.
4. Push-tjenesten autentiserer forespørselen og leverer den krypterte meldingen.
5. Nettleseren vekker service workeren med en push-hendelse, som dekrypterer innholdet og kaller ServiceWorkerRegistration.showNotification().
6. Et klikk utløser notificationclick i service workeren, der du åpner mål-URL-en.

Hvorfor tillatelsesmodellen er så streng

Se på hva et abonnement gir: en bakgrunnsprosess som kjører uten at nettstedet ditt er åpent, pluss muligheten til å tegne på operativsystemets varslingsflate. Nettlesere sperrer derfor for det bak en uttrykkelig tillatelse per domene, gitt av brukeren, og de fleste krever at forespørselen kommer etter en ekte brukerhandling.

En annen begrensning overrasker folk. Chrome og Edge krever userVisibleOnly: true ved abonnering, et løfte om at hver push skal gi et varsel brukeren ser, så stille bakgrunns-push er ikke en støttet bruk av API-et. Firefox bruker også en kvote på push-meldinger som ikke gir et varsel.

Nettleser- og plattformstøtte

Ifølge MDN har Push API vært Baseline widely available siden mars 2023, noe som betyr at det fungerer på tvers av gjeldende versjoner av Chrome, Edge, Firefox og Safari på skrivebordet, og på Chrome og Firefox for Android. To forbehold betyr mer enn overskriften.

For det første er Notifications API ikke jevnt tilgjengelig. MDN merker det som begrenset tilgjengelig fordi konstruktøren Notification() kaster en TypeError i de fleste mobilnettlesere. For alt som må fungere på telefon, bruker du vedvarende varsler via ServiceWorkerRegistration.showNotification() i stedet, som uansett er service worker-veien du allerede er på.

For det andre er varselalternativene ujevnt implementert. Handlingsknapper, merker, bilder og requireInteraction varierer mellom nettlesere og operativsystemer, så design varsler som fortsatt leses riktig med bare en tittel, en brødtekst og et ikon.

Kravet på iOS og iPadOS

Dette forbeholdet avgjør om web push er levedyktig for en mobiltung målgruppe, og det gjengis feil nesten overalt.

Apple la til Web Push i iOS og iPadOS 16.4, og det fungerer bare for nettapper som er lagt til på Hjem-skjermen. Som WebKit formulerte det: «we are adding support for Web Push to Home Screen web apps», og «a web app that has been added to the Home Screen can request permission to receive push notifications». Brukeren legger den til via Del-menyen og «Legg til på Hjem-skjerm», og tillatelsen må deretter bes om som svar på direkte brukerhandling, for eksempel et trykk på en abonnementsknapp.

Et nettsted som er åpent i en vanlig Safari-fane på iPhone, kan ikke opprette et push-abonnement. Det er en reell barriere: du ber om et installasjonssteg før du i det hele tatt får spurt om tillatelse. På macOS er det enklere, fordi Safari 16.1 på macOS Ventura la til standardbasert Web Push for vanlige nettsteder uten installasjonssteg.

Et minimalt eksempel på abonnering

Dette er hele flyten på klientsiden. Den hører hjemme i en klikkhåndterer, ikke ved sidelast.

async function subscribeToPush(vapidPublicKey) {
  // Push og service workers krever en sikker kontekst (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Må kalles fra en brukerhandling, og bare én gang per bruker.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // base64url-kodet offentlig P-256-nøkkel
  });

  // Lagre endepunkt + nøkler på serversiden, og behandle endepunktet som en hemmelighet.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Inne i sw.js håndterer du push-hendelsen, kaller self.registration.showNotification(title, options), og håndterer notificationclick for å åpne mål-URL-en.

Samtykkeflyten: der de fleste programmer feiler

Aldri spør ved sidelast

Lighthouse har en egen sjekk for nettopp dette: «if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs». Anbefalingen er å tilby en bestemt type varsel og først be om tillatelse etter at brukeren har valgt den typen. Safari 12.1 og andre nettlesere gikk lenger og krever samhandling med siden før en forespørsel i det hele tatt kan sendes.

Bruk en myk forhåndsdialog

Vis din egen invitasjon på siden først. Den navngir nytten, den kan avvises uten permanent kostnad, og bare et klikk på den utløser den ekte nettleserdialogen. Den som ignorerer din myke dialog i dag, kan spørres igjen neste måned. Den som klikker Blokker, kan ikke det. To regler får det til å virke: beskriv hva du faktisk kommer til å sende i stedet for «få oppdateringer», og konstruer aldri et feilklikk, for en tilfeldig aksept gir en umiddelbar avmelding.

Spør i kontekst

Chromes egen anbefaling er å «let your users take the initiative and turn on notifications at their own pace» ved å plassere brytere diskré i eksisterende grensesnittflater, og å unngå «showing prompts and/or overlays without context or immediately after a user lands on the site».

Øyeblikkene som fungerer i netthandel, er konkrete: en «gi meg beskjed når varen er tilbake»-knapp på et utsolgt produkt, en ordrebekreftelsesside som tilbyr leveringsoppdateringer, en prisvarsling på et produkt som ofte blir sett på. Tillatelsen byttes mot en navngitt fordel i stedet for å høstes.

Et avslag er i praksis permanent

Når noen blokkerer varsler, lagrer nettleseren den avgjørelsen for domenet ditt. Senere kall til Notification.requestPermission() løses mot den lagrede verdien denied uten at noe vises, og det er derfor MDNs eget eksempel sjekker Notification.permission før det i det hele tatt kaller requestPermission(). Å reversere en blokkering betyr å grave seg ned i nettstedsinnstillingene, noe i praksis ingen gjør.

Hva nettlesere gjør når du bommer

Konsekvensene er ikke lenger bare en lav påmeldingsrate.

• Chrome melder automatisk domener med svært lav akseptrate inn i et stillere tillatelsesgrensesnitt, separat per enhetstype, og undertrykker dialogen for alle.
• Chrome rategrenser nettsteder som kombinerer høyt push-volum med lavt engasjement, og returnerer HTTP 429. Eskaleringen løper én dag, så sju, så fjorten, og nullstilles først etter 42 sammenhengende dager uten forstyrrende sending.
• Chrome trekker nå automatisk tilbake varseltillatelsen for nettsteder en bruker ikke har samhandlet med i det siste, der det er «very low user engagement and a high volume of notifications being sent». Googles begrunnelse er nokså kontant: «Less than 1% of all notifications receive any interaction from users.»

Du kan miste abonnenter du allerede har vunnet, rett og slett ved å sende dårlig.

Web push sammenlignet med e-post og SMS

Eierskapsforskjellen som endrer strategien

Et push-abonnement er en URL knyttet til én nettleserprofil på én enhet. Det er ikke en person. Den samme kunden som bruker Chrome på en laptop og Firefox på telefonen, er to urelaterte abonnementer, og du kan ikke vite at de er samme menneske med mindre de identifiserer seg.

Det er heller ikke flyttbart. Du kan eksportere en e-postliste og laste den inn i en annen plattform i morgen. Du kan ikke flytte push-abonnementer mellom leverandører, fordi nøklene og VAPID-bindingen ble opprettet mot en bestemt applikasjonsservernøkkel.

Behandle derfor web push som en forsterker på en kanal du eier, aldri som en erstatning. Bruk push-øyeblikket til å tjene en e-postadresse eller et telefonnummer, ikke omvendt. Den komplette guiden til markedsautomatisering dekker hvordan du kobler flere kanaler inn i én reise.

Bruksområder som faktisk fungerer

Kanalen belønner meldinger som er tidskritiske, personlig relevante og mulige å handle på med ett trykk.

• Forlatt handlekurv. En push innen en time, forsterket av en e-post senere. Guiden til e-post for forlatt handlekurv dekker rekkefølgen.
• Varsel om at varen er tilbake på lager. Det sterkeste tilfellet, fordi brukeren uttrykkelig ba om beskjed.
• Prisfall på varer man følger. Samme logikk, selvvalgt relevans.
• Leverings- og ordrestatus. Høy åpningsintensjon, lav klagerisiko.
• Ferske oppdateringer i et tema man abonnerer på. Nyheter, resultater, tilgjengelighetsvinduer.

Det som feiler, er like tydelig: generiske «vi har publisert et nytt innlegg»-utsendelser, udifferensierte dagstilbud, alt som trenger mer enn en tittel og én linje, reaktiveringsblast til abonnenter som ignorerte de tjue siste varslene, og transaksjonelt innhold som trenger et varig spor.

Frekvens, tidspunkt og segmentering

Start forsiktig: ett til tre varsler per abonnent per uke, og øk bare hvis avmeldings- og klikkratene holder seg. Trettheten viser seg raskere enn i e-post, fordi det koster ett trykk å dempe et varsel operativsystemet allerede har løftet frem.

Tidspunkt er både en fordel og en fare. Push kommer umiddelbart, så en melding sendt kl. 02.00 kommer frem kl. 02.00. Lagre eller utled abonnentens tidssone ved abonnering, og hold sendingene innenfor et definert vindu.

Segmentering er begrenset av hva du vet om et abonnement snarere enn om en person, så de brukbare dimensjonene er atferdsbaserte: sider som er sett, produkter som følges, handlekurvstatus, hvor nylig et kjøp skjedde, plattform. Guiden til kundesegmentering går dypere.

Å måle web push

Fire målinger betyr noe, og de kan ikke måles på samme måte.

• Levering. Om push-tjenesten godtok forespørselen. En 201 betyr godtatt, ikke levert. En 404 eller 410 betyr at abonnementet er dødt.
• Visning. Om varselet faktisk ble vist. Det vet du bare hvis service workeren melder tilbake når showNotification() fullfører.
• Klikkrate. Klikk delt på visninger. Det er tallet det er verdt å optimalisere.
• Avmeldingsrate. Avmeldinger og tilbaketrukne tillatelser per sending. Følg den tettere enn klikkraten, for den er den ledende indikatoren på at kanalen er i ferd med å dø.

Fallgruver i attribusjon

Push-attribusjon smigrer seg selv. Varselet kommer på en enhet abonnenten allerede holder i hånden, så det tar ofte æren for en økt som ville skjedd uansett. Kjør kontrollgrupper i stedet for å anta inkrementell effekt. Visninger telles for lavt mens hvert klikk registreres, så en klikkrate regnet mot antall sendinger overdriver resultatet. Og fordi et abonnement er en nettleser og ikke en person, ser en push som klikkes på telefonen og ender i et kjøp på skrivebordet ut som to urelaterte hendelser. Guiden til måling i e-postmarkedsføring dekker målehygiene på tvers av kanaler.

Samtykke, GDPR og avmelding

Nettleserens tillatelsesdialog er en teknisk sperre. Den er ikke automatisk et fullstendig rettslig grunnlag for markedsføring.

Markedsfører du mot folk i EU eller Storbritannia, behandler du push som du behandler e-post. Forklar hva du kommer til å sende før dialogen dukker opp, slik at samtykket er informert og spesifikt. Registrer når og hvor abonnementet ble opprettet, og pakk aldri push-samtykke sammen med en urelatert handling. Knytter du abonnementer til identifiserte kunder, faller de dataene inn under pliktene dine for personopplysninger, inkludert sletteforespørsler.

Avmeldingshygiene betyr like mye. Tilby en innstillingsside på nettstedet slik at folk kan senke frekvensen i stedet for å blokkere, kall PushSubscription.unsubscribe() og slett oppføringen på serversiden når de gjør det, og rydd bort abonnementer ved 404 eller 410. MDNs veiledning er kort og riktig: brukere bør «offered an easy way to opt out of getting more in the future».

Hvor web push hører hjemme i kanalmiksen

Web push er en god tredjekanal og en dårlig førstekanal: rask, gratis på marginen og uslåelig for tidskritiske varsler, men bundet til enheten, umulig å eksportere og ett klikk unna permanent tap.

Det gjør orkestrering til det egentlige problemet. Hvilken melding som går til hvilken kanal, hvordan du undertrykker e-posten når pushen allerede konverterte, og hvordan du holder ett bilde av kunden på tvers av flater som identifiserer folk ulikt. Brevo tilbyr web push og mobil push ved siden av e-post og SMS, og Tajo ligger oppå Brevo og koordinerer den logikken på tvers av kanaler for Shopify-butikker. For SMS-siden, se guiden til SMS-automatisering.

Viktigste punkter

• Web push er tre API-er som samarbeider: en service worker for bakgrunnskjøring, Push API for abonnement og transport, Notifications API for visning. Et abonnement er et endepunkt pluss en p256dh-nøkkel og en auth-hemmelighet, innholdet krypteres ende til ende, og VAPID beviser hvem som sender.
• Push har vært Baseline widely available siden mars 2023, men på iOS og iPadOS fungerer det bare for nettapper som er lagt til på Hjem-skjermen.
• Be aldri om tillatelse ved sidelast. Bruk en myk forhåndsdialog, spør i kontekst, og husk at en blokkering er permanent for det domenet.
• Chrome håndhever nå stillere dialoger, rategrenser og automatisk tilbaketrekking av tillatelse, så dårlig sending koster deg abonnenter du allerede har.
• Et abonnement er en nettleser, ikke en person, og kan ikke eksporteres. Bygg e-postlisten først, og bruk push til å akselerere den.