Come funziona un messaggio in-app?
Il lavoro lo fa l’SDK del tuo prodotto. I messaggi sono associati a condizioni di attivazione (un evento specifico, la visualizzazione di una pagina, l’appartenenza a un segmento) e vengono mostrati direttamente nell’interfaccia quando quelle condizioni si verificano. Poiché la consegna passa da codice che esegui già, non c’è alcuna richiesta di autorizzazione né alcuna iscrizione: chiunque sia attivo nel prodotto può vederne uno. Strumenti come Braze sincronizzano i messaggi idonei sul dispositivo all’inizio della sessione, poi lasciano decidere alle regole di consegna e ai limiti di frequenza cosa compare davvero.
Messaggio in-app o web push: che differenza c’è?
Una notifica web push raggiunge gli utenti fuori dal sito, tramite il sistema di notifiche del browser, ma solo dopo un’autorizzazione esplicita, che molti utenti negano. Un messaggio in-app è l’immagine speculare: nessuna autorizzazione necessaria, ma nessuna portata una volta che l’utente se n’è andato. I due canali coprono ciascuno il punto cieco dell’altro: il push fa tornare le persone, l’in-app le guida una volta arrivate. La guida a web push e messaggi in-app spiega come gestirli come un unico programma.
Quando usare un messaggio in-app?
Ogni volta che la persona che vuoi raggiungere è già nel prodotto: checklist di onboarding, annunci di funzionalità, inviti all’upgrade, suggerimenti contestuali, brevi sondaggi. I messaggi in-app funzionano bene anche come step di un customer journey più ampio: per esempio un tooltip che compare solo agli utenti arrivati alla dashboard ma che non hanno mai creato un progetto. Il punto è il targeting; un messaggio che vedono tutti è solo interfaccia.
Quali sono i limiti dei messaggi in-app?
- Portata legata alla sessione: un utente perso o inattivo non ne vedrà mai uno; la riconquista spetta a email, SMS o push.
- Costo in attenzione: una modale al momento sbagliato interrompe il lavoro vero; parti da banner e tooltip, e alza il livello solo quando il messaggio lo giustifica.
- Rischio di rendering: il contenuto viene inserito in una pagina attiva, quindi la piattaforma deve sanificare l’HTML del messaggio; un rendering sicuro contro gli XSS è un requisito, non una funzionalità.
- Nessun archivio: una volta chiuso, il messaggio sparisce; tutto ciò che può servire all’utente più avanti va anche in un’email o nella documentazione.