Notifiche push dal sito: quando servono e come usarle per aggiornare i clienti

Partire da un motivo concreto per ricevere l’avviso

Scrivi una frase che completi questa idea: “Il cliente vuole essere avvisato quando…”. Se non emerge un evento riconoscibile, probabilmente la funzione non è ancora definita. “Torna a visitarci” è meno utile di un aggiornamento relativo a un prodotto che la persona ha scelto di seguire.

Separa avvisi di servizio, disponibilità richieste e messaggi promozionali. La scelta di ricevere un aggiornamento su un ordine non deve essere interpretata come interesse per ogni offerta. Definisci categorie comprensibili e conserva la preferenza relativa al singolo argomento quando il progetto lo richiede.

Gli avvisi urgenti o essenziali richiedono un piano di comunicazione adeguato: non fare dipendere tutto da una push che il cliente potrebbe non vedere.

Capire che cosa richiede una notifica dal sito

Il Web Push permette a un servizio di inviare un messaggio a una sottoscrizione del browser anche quando la pagina non è in primo piano. Nella configurazione standard descritta dalla documentazione della Push API intervengono il sito, un componente in background chiamato service worker e un servizio di invio. Non basta aggiungere una campanella grafica.

Chiedi al fornitore dove vengono conservate le sottoscrizioni, come si aggiornano e come vengono rimosse quelle non più valide. Servono HTTPS, gestione delle credenziali e un collegamento affidabile agli eventi del sito. Un invio ripetuto dopo un errore non dovrebbe produrre più notifiche per lo stesso evento.

La scelta si inserisce nel confronto tra sito web e app: per alcuni progetti è sufficiente una web app, per altri servono funzioni ulteriori. Le push sono un requisito da valutare insieme al resto del servizio.

Controllare i requisiti su iPhone, Android e computer

La disponibilità dipende da sistema operativo, browser, versione e impostazioni. Il sito deve rilevare le funzionalità effettive e proporre il percorso adatto, evitando di mostrare un pulsante inutilizzabile. Anche una prova riuscita sul computer di chi sviluppa non conferma il funzionamento sul telefono dei clienti.

Su iPhone e iPad, WebKit ha introdotto il supporto Web Push da iOS e iPadOS 16.4 per le web app aggiunte alla schermata Home. Il permesso viene richiesto dopo un’interazione diretta, come il tocco su un comando di iscrizione. Non promettere la stessa esperienza da una normale scheda del browser.

Su Android e computer verifica i browser che interessano il tuo pubblico e le rispettive impostazioni di notifica. Prepara una spiegazione breve per installazione o attivazione quando necessarie, e lascia un’alternativa per chi non può o non vuole usare questo canale.

Chiedere il permesso nel momento giusto

Prima della finestra del browser, spiega che cosa verrà inviato. “Avvisami quando torna questa taglia” permette una scelta precisa. Il comando deve seguire un interesse manifestato dal cliente; non interrompere l’arrivo sul sito con una richiesta priva di contesto.

La documentazione sulle notifiche distingue permesso non ancora espresso, concesso e negato. La richiesta deve partire da un gesto dell’utente. Se viene rifiutata, rispetta la scelta e non riproporre continuamente finestre o istruzioni pressanti per aggirarla.

Il permesso tecnico del browser non descrive da solo tutte le finalità di trattamento dei dati. Organizza informative, preferenze ed eventuali consensi in base al servizio concreto. Nel progetto devono essere chiari destinatari, fornitori coinvolti e uso dei dati; le comunicazioni commerciali vanno valutate separatamente dagli avvisi richiesti.

Scrivere messaggi brevi e ancora utili quando arrivano

Ogni notifica deve dire che cosa è cambiato e portare alla pagina pertinente. Non mandare alla homepage se il cliente aspetta una variante specifica. Se l’accesso è scaduto, dopo l’autenticazione deve poter riprendere il percorso previsto.

Prevedi una scadenza del messaggio: l’avviso su una disponibilità limitata può diventare inutile se arriva molto dopo. Deduplica gli eventi, limita la frequenza e concorda fasce orarie appropriate. Le regole devono valere anche quando più campagne o funzioni cercano di contattare lo stesso cliente.

Considera che il testo può comparire sulla schermata bloccata del telefono. Evita dettagli riservati e usa messaggi generici che rimandino all’area protetta. “C’è un aggiornamento nella tua area personale” può essere più adatto di una descrizione che espone informazioni a chi guarda lo schermo.

Rendere semplice la disattivazione

Metti nelle preferenze del sito un comando comprensibile per interrompere gli avvisi e, se previsto, scegliere le categorie. La disiscrizione va registrata nel servizio di invio, non limitata a nascondere l’icona. La Push API prevede la cancellazione della sottoscrizione; il progetto deve collegarla correttamente ai dati conservati.

Spiega anche che i permessi possono essere gestiti nelle impostazioni del browser o del sistema. Un cliente può usare più dispositivi: chiarisci se il comando interrompe gli avvisi soltanto su quello corrente oppure su tutte le sottoscrizioni associate all’account.

Dopo logout, cambio account o revoca, controlla che un dispositivo condiviso non continui a ricevere aggiornamenti personali del precedente utente. Mantieni pulita la lista delle sottoscrizioni scadute o rifiutate dal servizio.

Esempio ipotetico: un articolo temporaneamente esaurito

Un negozio offre l’avviso per una scarpa nella taglia scelta. Il cliente seleziona la taglia, legge lo scopo e abilita le notifiche sul dispositivo compatibile. La preferenza viene collegata a quella variante, senza estendersi automaticamente alle promozioni del negozio.

Quando il sistema rileva un riassortimento confermato, invia un avviso con una durata utile limitata. Il collegamento apre la variante corretta; il messaggio precisa che la disponibilità va verificata al momento dell’acquisto, senza promettere una prenotazione della merce. Se l’articolo termina nuovamente, la pagina mostra lo stato attuale. Il cliente può disattivare l’avviso dalle preferenze.

Misurare il risultato con prove e dati leggibili

Prova iscrizione, rifiuto e disattivazione sui dispositivi scelti. Controlla anche rete assente, permesso revocato, sessione scaduta e pagina aperta da una notifica vecchia. Verifica che ogni evento generi il messaggio previsto una sola volta.

• Permesso richiesto soltanto dopo il comando esplicito.
• Percorso di attivazione comprensibile sui dispositivi supportati.
• Pagina corretta dopo il clic e dopo l’accesso.
• Preferenze rispettate anche su dispositivi condivisi.
• Avvisi scaduti, duplicati e sottoscrizioni invalide gestiti.

Distingui richieste di invio, esiti disponibili dal fornitore, clic e azioni completate. Un invio accettato non prova che la persona abbia visto il messaggio. Confronta utilità, disiscrizioni e assistenza richiesta; per comunicazioni più articolate valuta anche la newsletter del sito aziendale.

Domande frequenti

Posso inviare notifiche senza un’app scaricata dallo store?

In molti casi sì, attraverso il Web Push sui dispositivi compatibili. Su iPhone e iPad il percorso richiede una web app aggiunta alla Home e il permesso dell’utente; va verificata la configurazione concreta.

Le notifiche arrivano sempre subito?

No. Connessione, permessi, impostazioni e condizioni del dispositivo possono incidere sulla visualizzazione. Per messaggi essenziali occorre prevedere un percorso di comunicazione adeguato.

Posso iscrivere tutti quelli che visitano il sito?

No. La visualizzazione delle notifiche richiede il permesso dell’utente e un’iscrizione correttamente gestita. Il progetto deve spiegare lo scopo degli avvisi e rispettare preferenze e rifiuti.