Webbpush: så fungerar push-notiser och så använder du dem rätt

Push-notiser på webben är den enda marknadsföringskanal där ett enda dåligt designbeslut kan låsa dig ute från en kund för alltid. Fråga om behörighet vid fel tillfälle, besökaren klickar på Blockera, och den webbläsaren är stängd för dig för gott. Ingen ny fråga, ingen andra kampanj, inget återvinningsmejl. Den asymmetrin är skälet till att mekaniken är värd att förstå innan du skriver ett enda meddelande.

Vad push-notiser på webben är

En webbpushnotis är ett meddelande som skickas från din server till en prenumerants webbläsare, visas av operativsystemets notiscenter och levereras även när din webbplats är stängd. Den sista delen är hela poängen: till skillnad från en popup på sidan når webbpush någon som just nu inte tittar på din webbplats.

Kanalen är byggd av tre webbplattforms-API:er som samarbetar, och uppdelningen mellan dem förklarar det mesta av kanalens beteende: Service Worker API, Push API och Notifications API.

Så fungerar webbpush under huven

Service workern

En service worker är en JavaScript-worker som agerar proxy mellan din webbapp, webbläsaren och nätverket. Den kör i en egen tråd, har ingen åtkomst till DOM och fortsätter existera efter att sidan som registrerade den har stängts. Den beständigheten är det som gör att den kan ta emot ett pushmeddelande och visa en notis när ingen har din flik öppen. Service workers körs bara i säkra kontexter, vilket betyder HTTPS, med http://localhost behandlat som säkert vid utveckling.

Prenumerationen: en endpoint plus två nycklar

När en service worker är aktiv anropar sidan registration.pushManager.subscribe(). Webbläsaren pratar med leverantörens pushtjänst och returnerar en PushSubscription som innehåller:

• endpoint, en unik URL som pushtjänsten tar emot meddelanden på
• keys.p256dh, en publik Elliptic Curve Diffie-Hellman-nyckel på kurvan P-256
• keys.auth, en autentiseringshemlighet

Din server sparar alla tre och behandlar endpointen som en hemlighet, eftersom var och en som har den kan skicka till den prenumeranten. Nycklarna finns för att nyttolasten krypteras hela vägen. RFC 8291 anger hur: ett ECDH-utbyte på P-256 etablerar en delad hemlighet, HKDF härleder nycklar ur den, och nyttolasten förseglas med AES-128-GCM under innehållskodningen aes128gcm. Pushtjänsten vidarebefordrar chiffertext som den inte kan läsa.

Pushtjänsten

Du skickar inte pushmeddelanden direkt till en enhet. Du skickar dem till en pushtjänst som drivs av webbläsarleverantören: Googles FCM-endpointer för Chrome, Mozillas autopush för Firefox, Apples pushtjänst för Safari. RFC 8030, “Generic Event Delivery Using HTTP Push”, definierar protokollet. Din server gör POST till prenumerationens endpoint, och pushtjänsten sköter de svåra delarna av mobil leverans: en batterisnål uppkoppling till enheten, kö när enheten är offline, väckning av webbläsaren när ett meddelande kommer. Det är också därför leverans inte kan garanteras. Om enheten är avstängd tillräckligt länge går meddelandena ut enligt sin TTL och kastas.

VAPID: att bevisa vem som skickar

Att endpointen är hemlig är tunn säkerhet. RFC 8292 lägger till Voluntary Application Server Identification, VAPID, så att en pushtjänst kan avgöra vilken applikationsserver ett meddelande kom från.

Du genererar ett ECDSA-nyckelpar på NIST-kurvan P-256 en gång. Den publika nyckeln läggs i applicationServerKey när webbläsaren prenumererar, vilket binder prenumerationen till din server. Vid varje push skickar din server en JWT signerad med den matchande privata nyckeln med ES256, med ett aud-anspråk för pushtjänstens ursprung, ett exp-anspråk högst 24 timmar fram i tiden och valfritt ett sub-anspråk med kontaktuppgifter. Pushtjänsten verifierar signaturen, så en stulen endpoint räcker inte längre för att spamma dina prenumeranter.

Leveranskedjan, hela vägen

1. Sidan registrerar en service worker och anropar, efter att behörighet getts, subscribe() med din publika VAPID-nyckel.
2. Din server sparar den returnerade endpointen och nycklarna på prenumerantens post.
3. För att skicka krypterar din server nyttolasten med p256dh och auth, signerar en VAPID-JWT och gör POST till endpointen.
4. Pushtjänsten autentiserar begäran och levererar det krypterade meddelandet.
5. Webbläsaren väcker service workern med en push-händelse, som dekrypterar nyttolasten och anropar ServiceWorkerRegistration.showNotification().
6. Ett klick utlöser notificationclick i service workern, där du öppnar mål-URL:en.

Varför behörighetsmodellen är så strikt

Titta på vad en prenumeration ger: en bakgrundsprocess som kör utan att din webbplats är öppen, plus möjligheten att rita på operativsystemets notisyta. Webbläsare grindar därför funktionen bakom en uttrycklig behörighet per ursprung som användaren måste ge, och de flesta kräver att förfrågan följer på en genuin användarhandling.

En andra begränsning överraskar många. Chrome och Edge kräver userVisibleOnly: true vid prenumeration, ett löfte om att varje push kommer att producera en notis som användaren ser, så tysta bakgrundspushar är inte en stödd användning av API:et. Firefox tillämpar också en kvot på pushmeddelanden som inte genererar en notis.

Stöd i webbläsare och plattformar

Enligt MDN har Push API varit Baseline widely available sedan mars 2023, vilket betyder att det fungerar i aktuella versioner av Chrome, Edge, Firefox och Safari på dator, samt i Chrome och Firefox för Android. Två förbehåll spelar större roll än rubriken.

För det första är Notifications API inte enhetligt tillgängligt. MDN flaggar det som begränsat tillgängligt eftersom konstruktorn Notification() kastar ett TypeError i de flesta mobila webbläsare. För allt som måste fungera i telefoner, använd beständiga notiser via ServiceWorkerRegistration.showNotification() i stället, vilket är den service worker-väg du ändå är på.

För det andra är notisernas alternativ ojämnt implementerade. Åtgärdsknappar, märken, bilder och requireInteraction varierar mellan webbläsare och operativsystem, så designa notiser som fortfarande läses rätt med bara en rubrik, en brödtext och en ikon.

Kravet på iOS och iPadOS

Det här förbehållet avgör om webbpush är gångbart för en mobiltung målgrupp, och det återges fel nästan överallt.

Apple lade till webbpush i iOS och iPadOS 16.4, och det fungerar bara för webbappar som lagts till på hemskärmen. Som WebKit uttryckte det: “we are adding support for Web Push to Home Screen web apps”, och “a web app that has been added to the Home Screen can request permission to receive push notifications”. Användaren lägger till den via delningsmenyn och “Lägg till på hemskärmen”, och behörigheten måste sedan begäras som svar på en direkt användarhandling, till exempel en tryckning på en prenumerationsknapp.

En sida som är öppen i en vanlig Safari-flik på iPhone kan inte skapa en pushprenumeration. Det är ett verkligt hinder: du ber om ett installationssteg innan du ens får fråga om behörighet. På macOS är det enklare, eftersom Safari 16.1 på macOS Ventura lade till standardbaserad webbpush för vanliga webbplatser utan installationssteg.

Ett minimalt exempel på prenumeration

Det här är hela flödet på klientsidan. Det hör hemma i en klickhanterare, inte vid sidladdning.

async function subscribeToPush(vapidPublicKey) {
  // Push och service workers kräver en säker kontext (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Måste anropas från en användarhandling, och bara en gång per användare.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // base64url-kodad publik P-256-nyckel
  });

  // Spara endpoint + nycklar på servern, behandla endpointen som en hemlighet.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Inne i sw.js hanterar du push-händelsen, anropar self.registration.showNotification(title, options) och hanterar notificationclick för att öppna mål-URL:en.

Behörighetsupplevelsen: där de flesta program går fel

Fråga aldrig vid sidladdning

Lighthouse har en egen granskning för just det här: “if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs”. Rekommendationen är att erbjuda en specifik typ av notis och begära behörighet först efter att användaren valt just den typen. Safari 12.1 och andra webbläsare gick längre och kräver interaktion med sidan innan en förfrågan över huvud taget får göras.

Använd en mjuk förfråga

Visa din egen inbjudan på sidan först. Den namnger nyttan, den kan avfärdas utan permanent kostnad, och bara ett klick på den utlöser webbläsarens riktiga ruta. Den som ignorerar din mjuka fråga i dag kan tillfrågas igen nästa månad. Den som klickar på Blockera kan det inte. Två regler får det att fungera: beskriv vad du faktiskt kommer att skicka i stället för “få uppdateringar”, och konstruera aldrig ett felklick, eftersom ett oavsiktligt ja ger en omedelbar avanmälan.

Fråga i rätt sammanhang

Chromes egen rekommendation är att “let your users take the initiative and turn on notifications at their own pace” genom att placera reglage diskret i befintliga gränssnittsytor, och att undvika “showing prompts and/or overlays without context or immediately after a user lands on the site”.

Ögonblicken som fungerar i handel är specifika: en “meddela mig när varan är tillbaka”-knapp på en slutsåld produkt, en orderbekräftelsesida som erbjuder leveransuppdateringar, ett prisbevakningsreglage på en produkt som ofta visas. Behörigheten byts mot en namngiven nytta i stället för att skördas.

Ett nej är i praktiken permanent

När någon blockerar notiser sparar webbläsaren det beslutet för ditt ursprung. Senare anrop till Notification.requestPermission() löser ut till det sparade värdet denied utan att något visas, vilket är skälet till att MDN:s eget exempel kontrollerar Notification.permission innan requestPermission() ens anropas. Att ångra en blockering betyder att gräva i webbplatsinställningar, vilket i praktiken ingen gör.

Vad webbläsarna gör när du gör fel

Konsekvenserna är inte längre bara en låg andel som tackar ja.

• Chrome placerar automatiskt ursprung med mycket låg andel ja i ett tystare behörighetsgränssnitt, separat per enhetstyp, vilket dämpar rutan för alla.
• Chrome volymbegränsar webbplatser som kombinerar hög pushvolym med lågt engagemang och svarar med HTTP 429. Upptrappningen löper en dag, sedan sju, sedan fjorton, och nollställs först efter 42 sammanhängande dygn utan störande beteende.
• Chrome drar nu automatiskt tillbaka notisbehörigheten för webbplatser en användare inte interagerat med på sistone, där det finns “very low user engagement and a high volume of notifications being sent”. Googles motivering är kärv: “Less than 1% of all notifications receive any interaction from users.”

Du kan förlora prenumeranter du redan förtjänat helt enkelt genom att skicka dåligt.

Webbpush jämfört med e-post och SMS

Ägarskillnaden som ändrar strategin

En pushprenumeration är en URL bunden till en webbläsarprofil på en enhet. Den är inte en person. Samma kund som använder Chrome på en laptop och Firefox på en telefon är två orelaterade prenumerationer, och du kan inte veta att det är samma människa om de inte identifierar sig.

Den är inte heller flyttbar. Du kan exportera en e-postlista och läsa in den i en annan plattform i morgon. Du kan inte flytta pushprenumerationer mellan leverantörer, eftersom nycklarna och VAPID-bindningen skapades mot en specifik applikationsservernyckel.

Behandla därför webbpush som en accelerator på en kanal du äger, aldrig som en ersättning. Använd pushögonblicket till att förtjäna en e-postadress eller ett telefonnummer, inte tvärtom. Den kompletta guiden till marknadsautomatisering går igenom hur du kopplar flera kanaler till en och samma resa.

Användningsfall som faktiskt fungerar

Kanalen belönar meddelanden som är tidskänsliga, personligt relevanta och möjliga att agera på med en tryckning.

• Övergiven varukorg. En push inom en timme, förstärkt av ett mejl senare. Guiden till mejl vid övergiven varukorg går igenom ordningsföljden.
• Aviseringar när varan är tillbaka i lager. Det starkaste fallet, eftersom användaren uttryckligen bad om att få veta.
• Prissänkningar på bevakade varor. Samma logik, självvald relevans.
• Leverans- och orderstatus. Hög avsikt att öppna, låg risk för klagomål.
• Snabba uppdateringar inom ett bevakat ämne. Nyheter, resultat, tillgänglighetsfönster.

Det som misslyckas är lika tydligt: generella utskick om att “vi har publicerat ett nytt inlägg”, odifferentierade dagliga erbjudanden, allt som behöver mer än en rubrik och en rad, återaktiveringsutskick till prenumeranter som ignorerat de senaste tjugo notiserna, och transaktionsinnehåll som behöver ett varaktigt spår.

Frekvens, timing och segmentering

Börja försiktigt: en till tre notiser per prenumerant och vecka, och öka bara om avanmälningar och klickfrekvens håller. Trötthet syns snabbare än i e-post, eftersom det kostar en tryckning att tysta en notis som operativsystemet redan lyft fram.

Timing är både en fördel och en fara. Push kommer fram direkt, så ett meddelande som skickas 02.00 kommer fram 02.00. Spara eller härled prenumerantens tidszon vid prenumerationstillfället och håll utskicken inom ett bestämt fönster.

Segmenteringen begränsas av vad du vet om en prenumeration snarare än om en person, så de dimensioner som fungerar är beteendemässiga: visade sidor, bevakade produkter, varukorgsstatus, hur nyligen kunden köpt, plattform. Guiden till kundsegmentering går djupare.

Att mäta webbpush

Fyra mätvärden spelar roll, och de går inte att mäta på samma sätt.

• Leverans. Om pushtjänsten accepterade begäran. En 201 betyder accepterad, inte levererad. En 404 eller 410 betyder att prenumerationen är död.
• Visning. Om notisen visades. Det vet du bara om service workern rapporterar tillbaka när showNotification() löser ut.
• Klickfrekvens. Klick delat med visningar. Det är siffran som är värd att optimera.
• Avanmälningsgrad. Avanmälningar och återkallade behörigheter per utskick. Håll ögonen på den hårdare än på klickfrekvensen, eftersom den är den ledande indikatorn på att kanalen håller på att dö.

Fallgropar i attributionen

Push smickrar sig själv i attributionen. Notisen kommer till en enhet prenumeranten redan håller i, så den tar ofta åt sig äran för ett besök som ändå skulle ha skett. Kör kontrollgrupper i stället för att anta inkrementalitet. Visningar underskattas medan varje klick registreras, så en klickfrekvens räknad mot antal skickade överdriver resultatet. Och eftersom en prenumeration är en webbläsare snarare än en person ser en push som klickas på en telefon och slutar i ett köp på datorn ut som två orelaterade händelser. Guiden till mätvärden för e-postmarknadsföring går igenom mäthygien över kanalerna.

Samtycke, GDPR och avanmälan

Webbläsarens behörighetsruta är en teknisk grind. Den är inte automatiskt en fullständig rättslig grund för marknadsföring.

När du marknadsför till personer i EU eller Storbritannien, behandla push som du behandlar e-post. Förklara vad du kommer att skicka innan rutan visas, så att samtycket blir informerat och specifikt. Registrera när och var prenumerationen skapades, och bunta aldrig ihop pushsamtycke med en orelaterad handling. Om du kopplar prenumerationer till identifierade kunder omfattas de uppgifterna av dina skyldigheter kring personuppgifter, inklusive raderingsbegäranden.

Avanmälningshygien spelar lika stor roll. Erbjud en inställning på webbplatsen så att människor kan minska frekvensen i stället för att blockera, anropa PushSubscription.unsubscribe() och radera posten på servern när de gör det, och rensa bort prenumerationer vid 404 eller 410. MDN:s vägledning är kort och riktig: användare ska “offered an easy way to opt out of getting more in the future”.

Var webbpush hör hemma i en kanalmix

Webbpush är en bra tredje kanal och en dålig första: snabb, gratis på marginalen och oöverträffad för tidskritiska varningar, men bunden till enheten, omöjlig att exportera och ett klick från permanent förlust.

Det gör orkestreringen till det verkliga problemet. Vilket meddelande som går till vilken kanal, hur du undertrycker mejlet när pushen redan konverterat, och hur du håller en enda bild av kunden över ytor som identifierar människor på olika sätt. Brevo erbjuder push på webb och mobil vid sidan av e-post och SMS, och Tajo ligger ovanpå Brevo och samordnar den logiken över kanaler för Shopify-butiker. För SMS-sidan, se guiden till SMS-automatisering.

Viktigaste slutsatserna

• Webbpush är tre API:er som samarbetar: en service worker för bakgrundskörning, Push API för prenumeration och transport, Notifications API för visning. En prenumeration är en endpoint plus en p256dh-nyckel och en auth-hemlighet, nyttolaster krypteras hela vägen, och VAPID bevisar vem som skickar.
• Push har varit Baseline widely available sedan mars 2023, men på iOS och iPadOS fungerar det bara för webbappar som lagts till på hemskärmen.
• Begär aldrig behörighet vid sidladdning. Använd en mjuk förfråga, fråga i rätt sammanhang, och kom ihåg att en blockering är permanent för det ursprunget.
• Chrome tillämpar nu tystare rutor, volymgränser och automatiskt återkallade behörigheter, så dåliga utskick kostar dig prenumeranter du redan har.
• En prenumeration är en webbläsare, inte en person, och går inte att exportera. Bygg e-postlistan först och använd push för att snabba på den.