Notifiche push web: come funzionano e come usarle bene

Le notifiche push web sono l’unico canale di marketing in cui una sola scelta di design sbagliata può escluderti per sempre da un cliente. Chiedi il permesso nel momento sbagliato, la persona clicca Blocca e quel browser ti è chiuso per sempre. Nessun nuovo prompt, nessuna seconda campagna, nessuna email di recupero. È questa asimmetria a rendere il meccanismo degno di essere capito prima di scrivere anche un solo messaggio.

Che cosa sono le notifiche push web

Una notifica push web è un messaggio inviato dal tuo server al browser di un iscritto, mostrato dal centro notifiche del sistema operativo e consegnato anche quando il tuo sito è chiuso. Quest’ultimo punto è tutto il senso della cosa: a differenza di un popup nella pagina, il push web raggiunge chi in quel momento non sta guardando il tuo sito.

È costruito su tre API della piattaforma web che lavorano insieme, e la divisione tra loro spiega quasi tutto il comportamento del canale: la Service Worker API, la Push API e la Notifications API.

Come funziona il push web sotto il cofano

Il service worker

Un service worker è un worker JavaScript che agisce da proxy tra la tua web app, il browser e la rete. Gira su un thread proprio, non ha accesso al DOM e continua a esistere dopo la chiusura della pagina che lo ha registrato. È questa persistenza a permettergli di ricevere un messaggio push e mostrare una notifica quando nessuno ha aperto la tua scheda. I service worker girano solo in contesti sicuri, cioè in HTTPS, con http://localhost trattato come sicuro per lo sviluppo.

L’iscrizione: un endpoint più due chiavi

Una volta che il service worker è attivo, la pagina chiama registration.pushManager.subscribe(). Il browser parla con il push service del proprio fornitore e restituisce un PushSubscription che contiene:

• endpoint, un URL di capability unico su cui il push service accetta messaggi
• keys.p256dh, una chiave pubblica Elliptic Curve Diffie-Hellman sulla curva P-256
• keys.auth, un segreto di autenticazione

Il tuo server conserva tutti e tre e tratta l’endpoint come un segreto, perché chiunque lo possieda può inviare a quell’iscritto. Le chiavi esistono perché i payload sono cifrati end to end. La RFC 8291 specifica come: uno scambio ECDH su P-256 stabilisce un segreto condiviso, HKDF ne deriva le chiavi e il payload viene sigillato con AES-128-GCM sotto la content encoding aes128gcm. Il push service inoltra un testo cifrato che non può leggere.

Il push service

Non invii i messaggi push direttamente a un dispositivo. Li invii a un push service gestito dal fornitore del browser: gli endpoint FCM di Google per Chrome, autopush di Mozilla per Firefox, il push service di Apple per Safari. La RFC 8030, “Generic Event Delivery Using HTTP Push”, definisce il protocollo. Il tuo server fa una POST verso l’endpoint dell’iscrizione, e il push service si occupa delle parti difficili della consegna mobile: una sola connessione efficiente dal punto di vista della batteria verso il dispositivo, l’accodamento mentre è offline, il risveglio del browser all’arrivo di un messaggio. È anche il motivo per cui la consegna non può essere garantita. Se il dispositivo resta spento abbastanza a lungo, i messaggi scadono in base al loro TTL e vengono scartati.

VAPID: dimostrare chi sta inviando

Il fatto che l’endpoint sia un segreto è una sicurezza sottile. La RFC 8292 aggiunge la Voluntary Application Server Identification, cioè VAPID, così un push service può capire da quale application server arriva un messaggio.

Generi una volta sola una coppia di chiavi ECDSA sulla curva NIST P-256. La chiave pubblica finisce in applicationServerKey quando il browser si iscrive, legando l’iscrizione al tuo server. Per ogni invio push, il tuo server manda un JWT firmato con la chiave privata corrispondente usando ES256, con un claim aud per l’origine del push service, un claim exp non oltre 24 ore e, facoltativamente, un claim sub con i dati di contatto. Il push service verifica la firma, quindi un endpoint rubato da solo non basta più a inondare di messaggi i tuoi iscritti.

Il percorso di consegna, dall’inizio alla fine

1. La pagina registra un service worker e, dopo la concessione del permesso, chiama subscribe() con la tua chiave pubblica VAPID.
2. Il tuo server salva endpoint e chiavi restituiti insieme al record dell’iscritto.
3. Per inviare, il tuo server cifra il payload con p256dh e auth, firma un JWT VAPID e fa una POST verso l’endpoint.
4. Il push service autentica la richiesta e consegna il messaggio cifrato.
5. Il browser risveglia il service worker con un evento push, che decifra il payload e chiama ServiceWorkerRegistration.showNotification().
6. Un clic genera notificationclick nel service worker, dove apri l’URL di destinazione.

Perché il modello dei permessi è così rigido

Guarda che cosa concede un’iscrizione: un processo in background che gira senza che il tuo sito sia aperto, più la possibilità di disegnare sulla superficie di notifica del sistema operativo. Per questo i browser lo proteggono dietro un permesso esplicito, per origine, concesso dall’utente, e quasi tutti richiedono che la richiesta segua un gesto reale dell’utente.

Un secondo vincolo sorprende molti. Chrome ed Edge richiedono userVisibleOnly: true alla subscribe, cioè la promessa che ogni push produrrà una notifica visibile all’utente, quindi i push silenziosi in background non sono un uso supportato dell’API. Anche Firefox applica una quota ai messaggi push che non generano una notifica.

Supporto di browser e piattaforme

Secondo MDN, la Push API è Baseline widely available da marzo 2023, il che significa che funziona nelle versioni correnti di Chrome, Edge, Firefox e Safari su desktop, e su Chrome e Firefox per Android. Due avvertenze contano più del titolo.

Primo, la Notifications API non è disponibile in modo uniforme. MDN la segnala come a disponibilità limitata perché il costruttore Notification() lancia un TypeError sulla maggior parte dei browser mobile. Per qualsiasi cosa debba funzionare sugli smartphone, usa le notifiche persistenti tramite ServiceWorkerRegistration.showNotification(), che è comunque il percorso del service worker su cui ti trovi.

Secondo, le opzioni di notifica sono implementate in modo disomogeneo. Pulsanti di azione, badge, immagini e requireInteraction variano tra browser e sistemi operativi, quindi progetta notifiche che si leggano correttamente anche solo con un titolo, un corpo e un’icona.

Il requisito su iOS e iPadOS

Questa avvertenza decide se il push web è praticabile per un pubblico prevalentemente mobile, e quasi ovunque viene riportata male.

Apple ha introdotto Web Push in iOS e iPadOS 16.4, e funziona solo per le web app aggiunte alla schermata Home. Come ha scritto WebKit, “stiamo aggiungendo il supporto al Web Push per le web app della schermata Home” e “una web app aggiunta alla schermata Home può chiedere il permesso di ricevere notifiche push”. L’utente la aggiunge dal menu Condividi con “Aggiungi a Home”, e il permesso va poi richiesto in risposta a un’interazione diretta, per esempio il tocco su un pulsante di iscrizione.

Un sito aperto in una normale scheda di Safari su iPhone non può creare un’iscrizione push. È una barriera reale: stai chiedendo un passaggio di installazione prima ancora di poter chiedere il permesso. Su macOS è più semplice, perché Safari 16.1 su macOS Ventura ha introdotto il Web Push conforme agli standard per i siti web normali, senza passaggi di installazione.

Un esempio minimo di iscrizione

Questo è tutto il flusso lato client. Va dentro un gestore di clic, non al caricamento della pagina.

async function subscribeToPush(vapidPublicKey) {
  // Push e service worker richiedono un contesto sicuro (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Va chiamato da un gesto dell'utente, e una sola volta per utente.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

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

  // Salva endpoint + chiavi lato server; tratta l'endpoint come un segreto.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Dentro sw.js gestisci l’evento push, chiami self.registration.showNotification(title, options) e gestisci notificationclick per aprire l’URL di destinazione.

UX del permesso: dove fallisce la maggior parte dei programmi

Non chiedere mai al caricamento della pagina

Lighthouse ha un audit dedicato proprio a questo: “se la tua pagina chiede il permesso di inviare notifiche al caricamento, quelle notifiche potrebbero non essere pertinenti per i tuoi utenti o per i loro bisogni”. La raccomandazione è offrire un tipo specifico di notifica e chiedere il permesso solo dopo che l’utente ha scelto quel tipo. Safari 12.1 e altri browser sono andati oltre, richiedendo un’interazione con la pagina prima che una richiesta possa essere fatta.

Usa un pre-prompt morbido

Mostra prima un tuo invito dentro la pagina. Dichiara la proposta di valore, può essere chiuso senza costi permanenti e solo un clic su di esso attiva il vero prompt del browser. A chi ignora il tuo prompt morbido oggi puoi chiedere di nuovo il mese prossimo. A chi clicca Blocca no. Due regole lo rendono efficace: descrivi che cosa invierai davvero invece di “ricevi aggiornamenti”, e non progettare mai il clic per errore, perché un consenso accidentale produce una disiscrizione immediata.

Chiedi nel contesto

La raccomandazione di Chrome è “lascia che siano gli utenti a prendere l’iniziativa e ad attivare le notifiche con i loro tempi”, inserendo gli interruttori con discrezione dentro le superfici di interfaccia esistenti, ed evitando di “mostrare prompt o overlay senza contesto o subito dopo che un utente è arrivato sul sito”.

Nel commercio i momenti che funzionano sono specifici: un controllo “avvisami quando torna disponibile” su un prodotto esaurito, una pagina di conferma ordine che offre aggiornamenti sulla consegna, un interruttore di monitoraggio prezzo su un prodotto visitato spesso. Il permesso viene scambiato con un beneficio dichiarato invece di essere raccolto di nascosto.

Un rifiuto è di fatto permanente

Quando qualcuno blocca le notifiche, il browser memorizza quella decisione per la tua origine. Le chiamate successive a Notification.requestPermission() si risolvono con il valore denied memorizzato senza mostrare nulla, ed è il motivo per cui l’esempio di MDN controlla Notification.permission prima ancora di chiamare requestPermission(). Invertire un blocco significa scavare nelle impostazioni del sito, cosa che di fatto nessuno fa.

Che cosa fanno i browser quando sbagli

Le conseguenze non sono più solo un tasso di opt-in basso.

• Chrome iscrive automaticamente le origini con tassi di accettazione molto bassi a una UI dei permessi più silenziosa, separatamente per tipo di dispositivo, sopprimendo il prompt per tutti.
• Chrome applica limiti di frequenza ai siti che combinano volumi push alti con engagement basso, restituendo HTTP 429. L’escalation dura un giorno, poi sette, poi quattordici, e si azzera solo dopo 42 giorni consecutivi senza comportamenti disturbanti.
• Chrome ora revoca automaticamente il permesso di notifica per i siti con cui l’utente non ha interagito di recente, dove c’è “un engagement degli utenti molto basso e un volume elevato di notifiche inviate”. La motivazione di Google è netta: “Meno dell’1% di tutte le notifiche riceve una qualsiasi interazione da parte degli utenti.”

Puoi perdere iscritti già conquistati semplicemente inviando male.

Il push web a confronto con email e SMS

La differenza di proprietà che cambia la strategia

Un’iscrizione push è un URL di capability legato a un profilo browser su un dispositivo. Non è una persona. Lo stesso cliente che usa Chrome sul portatile e Firefox sul telefono sono due iscrizioni scollegate, e non puoi sapere che sono lo stesso essere umano a meno che non si identifichi.

Non è nemmeno portabile. Una lista email la esporti e la carichi in un’altra piattaforma domani. Le iscrizioni push non le puoi spostare tra fornitori, perché le chiavi e il legame VAPID sono stati creati contro una specifica application server key.

Quindi tratta il push web come un acceleratore su un canale di proprietà, mai come un sostituto. Usa il momento push per guadagnarti un indirizzo email o un numero di telefono, non il contrario. La guida completa alla marketing automation spiega come cablare più canali in un unico percorso.

Casi d’uso che funzionano davvero

Il canale premia i messaggi urgenti, personalmente rilevanti e attuabili con un tocco.

• Carrello abbandonato. Un push entro un’ora, rinforzato più tardi da un’email. La guida alle email per il carrello abbandonato spiega la sequenza.
• Avvisi di ritorno in stock. Il caso più forte, perché l’utente ha chiesto esplicitamente di essere avvisato.
• Cali di prezzo sugli articoli monitorati. Stessa logica, rilevanza auto-selezionata.
• Consegna e stato dell’ordine. Alta intenzione di apertura, basso rischio di lamentele.
• Aggiornamenti urgenti su un argomento a cui l’utente si è iscritto. Notizie, risultati, finestre di disponibilità.

Ciò che fallisce è altrettanto chiaro: i broadcast generici “abbiamo pubblicato un nuovo articolo”, le offerte quotidiane indifferenziate, qualsiasi cosa richieda più di un titolo e una riga, le raffiche di riattivazione verso iscritti che hanno ignorato le ultime venti notifiche e i contenuti transazionali che richiedono una traccia duratura.

Frequenza, tempistiche e segmentazione

Parti prudente: una o tre notifiche per iscritto a settimana, allargando solo se i tassi di disiscrizione e di clic reggono. La stanchezza si manifesta più in fretta che nell’email, perché silenziare costa un tocco su una notifica che il sistema operativo ha già mostrato.

Il tempismo è insieme un vantaggio e un pericolo. Il push arriva subito, quindi un messaggio inviato alle 02:00 arriva alle 02:00. Salva o deduci il fuso orario dell’iscritto al momento dell’iscrizione e tieni gli invii dentro una finestra definita.

La segmentazione è vincolata da ciò che sai di un’iscrizione più che di una persona, quindi le dimensioni utilizzabili sono comportamentali: pagine viste, prodotti monitorati, stato del carrello, recenza d’acquisto, piattaforma. La guida alla segmentazione dei clienti approfondisce.

Misurare il push web

Contano quattro metriche, e non sono tutte misurabili allo stesso modo.

• Consegna. Se il push service ha accettato la richiesta. Un 201 significa accettato, non consegnato. Un 404 o un 410 significa che l’iscrizione è morta.
• Visualizzazione. Se la notifica è stata mostrata. Lo sai solo se il service worker lo segnala quando showNotification() si risolve.
• Tasso di clic. Clic diviso visualizzazioni. È il numero da ottimizzare.
• Tasso di disiscrizione. Disiscrizioni e revoche di permesso per invio. Guardalo più da vicino del tasso di clic, perché è l’indicatore anticipatore della morte del canale.

Trappole dell’attribuzione

L’attribuzione del push si fa dei complimenti da sola. La notifica arriva su un dispositivo che l’iscritto ha già in mano, quindi spesso si prende il merito di una sessione che sarebbe comunque avvenuta. Usa gruppi di controllo invece di dare per scontata l’incrementalità. Le visualizzazioni sono sottocontate mentre ogni clic viene registrato, quindi un tasso di clic calcolato sugli invii sovrastima le prestazioni. E poiché un’iscrizione è un browser e non una persona, un push cliccato sul telefono che finisce in un acquisto da desktop sembra due eventi scollegati. La guida alle metriche dell’email marketing copre l’igiene della misurazione tra i canali.

Consenso, GDPR e opt-out

Il prompt di permesso del browser è un cancello tecnico. Non è automaticamente una base giuridica completa per il marketing.

Quando fai marketing verso persone nell’Unione Europea o nel Regno Unito, tratta il push come tratti l’email. Spiega che cosa invierai prima che compaia il prompt, così il consenso è informato e specifico. Registra quando e dove è stata creata l’iscrizione, e non accorpare mai il consenso push a un’azione non correlata. Se leghi le iscrizioni a clienti identificati, quei dati rientrano nei tuoi obblighi sui dati personali, richieste di cancellazione comprese.

L’igiene dell’opt-out conta altrettanto. Offri un controllo delle preferenze dentro il sito così le persone possono ridurre la frequenza invece di bloccare, chiama PushSubscription.unsubscribe() ed elimina il record lato server quando lo fanno, e ripulisci le iscrizioni su un 404 o un 410. L’indicazione di MDN è breve e corretta: agli utenti va “offerto un modo semplice per rinunciare a riceverne altre in futuro”.

Dove si colloca il push web in uno stack di canali

Il push web è un buon terzo canale e un pessimo primo canale: rapido, gratuito al margine e imbattibile per gli avvisi urgenti, ma legato al dispositivo, non esportabile e a un clic dalla perdita permanente.

Questo rende l’orchestrazione il vero problema. Quale messaggio va su quale canale, come sopprimi l’email quando il push ha già convertito e come mantieni una visione unica del cliente su superfici che identificano le persone in modo diverso. Brevo offre push web e mobile accanto a email e SMS, e Tajo si appoggia su Brevo per coordinare questa logica cross-canale per i negozi Shopify. Per il lato SMS, guarda la guida all’automazione SMS.

Punti chiave

• Il push web sono tre API che cooperano: un service worker per l’esecuzione in background, la Push API per iscrizione e trasporto, la Notifications API per la visualizzazione. Un’iscrizione è un endpoint più una chiave p256dh e un segreto auth, i payload sono cifrati end to end e VAPID dimostra chi invia.
• Il push è Baseline widely available da marzo 2023, ma su iOS e iPadOS funziona solo per le web app aggiunte alla schermata Home.
• Non chiedere mai il permesso al caricamento della pagina. Usa un pre-prompt morbido, chiedi nel contesto e ricorda che un blocco è permanente per quell’origine.
• Chrome ora applica prompt silenziosi, limiti di frequenza e revoca automatica del permesso, quindi inviare male ti costa iscritti che hai già.
• Un’iscrizione è un browser, non una persona, e non può essere esportata. Costruisci prima la lista email e usa il push per accelerarla.