In breve
Questi due canali sembrano simili perché entrambi mostrano piccoli messaggi legati al tuo prodotto, ma stanno ai lati opposti di due linee: portata e consenso. Il web push esce dal tuo sito e arriva sul dispositivo dopo che l’utente ha concesso un permesso del browser. I messaggi in-app restano dentro una sessione attiva e non richiedono un permesso separato. Trattali come due strumenti, non come uno.
Come funziona il web push
Il web push si basa su tre componenti del browser che lavorano insieme: un service worker (uno script in background che il browser tiene in esecuzione), la Push API (che iscrive il browser a un servizio push e riceve i messaggi) e la Notifications API (che mostra la notifica di sistema). L’utente deve cliccare esplicitamente Consenti nella richiesta di permesso del browser; finché non lo fa, non puoi inviare nulla. Dopo l’opt-in ottieni un endpoint di iscrizione e delle chiavi di cifratura, e il tuo server invia tramite il servizio push del browser anche quando la scheda è chiusa. Poiché il messaggio arriva fuori dal sito, il web push è il canale di riattivazione del gruppo: per il compito che svolge è più vicino agli SMS o all’email che a qualsiasi cosa viva dentro la tua app. Il limite: dipende dal supporto di browser e sistema operativo, e l’utente può revocare il permesso in qualsiasi momento.
L’eccezione di iOS
Su iPhone e iPad il web push non funziona in una normale scheda di Safari. Apple ha aggiunto il web push solo per le web app che l’utente ha aggiunto alla schermata Home, a partire da Safari 16.4 (marzo 2023). La richiesta di permesso deve arrivare in risposta a un tocco diretto, per esempio su un pulsante Iscriviti, non al caricamento della pagina. Quindi su iOS il pubblico che puoi raggiungere è il sottoinsieme di utenti che hanno installato il tuo sito come web app e poi concesso il permesso. Pianifica tenendo conto di questo divario, invece di dare per scontata la parità con il desktop.
Come funzionano i messaggi in-app
I messaggi in-app compaiono dentro una sessione attiva: un banner, una finestra modale, uno slide-out o un tooltip mostrato dal tuo prodotto mentre l’utente lo sta usando. Non c’è un opt-in separato, perché l’utente è già nel tuo prodotto; il messaggio fa parte dell’esperienza. Il compromesso è la portata: l’in-app raggiunge solo chi è presente in quel momento. Non può far tornare un utente che si è allontanato, e chi ha abbandonato il prodotto non lo vedrà mai.
Quando usare l’uno o l’altro
| Obiettivo | Cosa usare |
|---|---|
| Far tornare un utente che si è allontanato | Web push (o email / SMS) |
| Annunciare una funzione agli utenti attivi | Banner o finestra modale in-app |
| Guidare un nuovo utente nella configurazione | Tooltip o slide-out in-app |
| Avvisare di un evento urgente fuori dal sito | Web push |
| Proporre un upgrade nel mezzo di un’attività | Finestra modale in-app |
La divisione onesta: l’in-app si occupa di chi è già nella stanza, il web push va a cercare chi se n’è andato. La maggior parte dei prodotti usa entrambi, coordinati dentro un customer journey (il percorso del cliente), così la stessa persona non riceve un promemoria in-app e una notifica web push per la stessa cosa a pochi minuti di distanza. Decidere quale canale porta quale messaggio, in che ordine e senza sovrapposizioni è il passaggio dal gestire molti canali al gestirli come uno solo: il tema di multicanale vs omnicanale. Strumenti dedicati come OneSignal o Novu sono specializzati nel recapito di push e notifiche; una piattaforma di engagement integra push e in-app nella stessa logica di percorso degli altri canali.