Caso studio
Zero notifiche consegnate su un flusso attivo: il token era registrato sul profilo anonimo
Un flusso senza condizioni, ogni invio in errore. Escluse in mezz'ora le tre cause più comuni, il token risultava scritto sul profilo anonimo invece che su quello con email.
Un’app consumer di loyalty con meccaniche di gioco, su iOS e Android, con un sistema di analytics già installato e funzionante.
Il vincolo: la piattaforma di analytics esistente andava lasciata al suo posto. Il nuovo strumento di messaggistica doveva convivere accanto, non sostituirla, e la parte di prodotto dentro l’app restava sull’esistente. Ogni intervento sull’app passava da un’agenzia di sviluppo esterna, quindi ogni correzione aveva il costo di un rilascio.
Il risultato: dal primo flusso con zero consegne alle notifiche recapitate, con collegamento diretto alle quattro schermate che contano invece che alla pagina iniziale.
Qui sotto c’è come abbiamo escluso in mezz’ora le tre cause più comuni, dove finiva davvero il token, e il secondo problema emerso dopo la correzione.
Cosa contiene questo caso
- come escludere il comportamento degli utenti quando un invio fallisce al 100%
- come capire su quale profilo un sistema di messaggistica registra un identificativo di dispositivo
- come far funzionare un collegamento diretto all’app anche dentro le email
- come ordinare le verifiche di infrastruttura rispetto alla costruzione dei contenuti
Indice
- Il cliente e il punto di partenza
- Diagnosi del token e correzione
- Collegamenti diretti da push e da email
- Nota di metodo sui numeri
- Cosa non ha funzionato
- Cosa faremmo adesso
- Conclusione
Il cliente e il punto di partenza
App di loyalty con raccolta punti, premi e sezione di gioco, su entrambe le piattaforme mobili. Sviluppo affidato a un’agenzia esterna. Analytics e configurazione remota già attivi e funzionanti, da lasciare intatti.
Il progetto prevedeva l’aggiunta di uno strumento di messaggistica accanto all’esistente, per notifiche push e segmentazione email. Piano concordato in cinque passi: mappatura degli eventi su lavagna condivisa, allineamento con gli sviluppatori, implementazione su entrambe le piattaforme, verifica interna, rilascio.
Lo stato iniziale, con la fonte di ciascun dato:
| Dato | Valore | Fonte |
|---|---|---|
| Durata stimata del progetto | 3 settimane, test inclusi | call di allineamento, 16 febbraio |
| Priorità dichiarata dal cliente | push prima delle email | call di allineamento |
| Analytics preesistente | attivo, da non toccare | call di allineamento |
| Notifiche consegnate al primo flusso | 0 | pannello consegne |
Diagnosi del token e correzione
IN SINTESI
Cosa abbiamo fatto: eseguito un test controllato su account interni per escludere le cause legate al comportamento degli utenti.
Perché: le notifiche falliscono per motivi banali molto più spesso che per motivi tecnici, e quelle cause vanno eliminate per prime.
Cosa abbiamo trovato: il token del dispositivo era registrato sul profilo anonimo invece che su quello con email.
Il numero della sezione: 0 consegne su un flusso senza condizioni, poi consegne attive dal rilascio successivo.
Il primo flusso attivato era volutamente il più semplice possibile: una sola notifica di benvenuto dopo la registrazione, nessuna condizione, nessuna segmentazione. Serviva a verificare che il canale fosse aperto.
Ogni invio è tornato in errore con lo stesso messaggio, riferito a un token mancante.
Le cause più frequenti di fallimento sono tre e riguardano tutte l’utente: applicazione disinstallata, permesso di notifica negato, dispositivo spento da tempo. Sono anche quelle su cui non si può intervenire, quindi vanno escluse prima di guardare l’integrazione.
Le abbiamo escluse tutte insieme con un test controllato su account interni: applicazione installata nella giornata, permesso concesso a mano, dispositivo acceso e in mano mentre si osservava il pannello. Stesso errore, quindi il comportamento degli utenti era fuori discussione.
La causa era nell’ordine delle chiamate dentro l’applicazione.
Lo strumento di messaggistica crea un profilo appena si avvia sul dispositivo. È un profilo anonimo, identificato solo dall’identificativo del dispositivo. Quando l’utente concede il permesso e il sistema operativo rilascia il token, questo viene scritto sul profilo attivo in quel momento.
Se l’utente non si è ancora identificato con la propria email, quel profilo è l’anonimo. Più tardi la persona si registra, l’applicazione comunica l’email, e viene creato il profilo identificato. Ma il token resta dov’era. I due profili convivono, uno con l’email e senza token, l’altro con il token e senza email.
I flussi inviano ai profili che hanno un’email, cercano il token lì, e non lo trovano.
La correzione è nell’ordine: identificare l’utente prima di chiedere il permesso, non dopo. Così quando il token arriva, il profilo attivo ha già un’email associata. Per chi si registra la prima volta, dove il token nasce necessariamente prima dell’email, la regola è ripropagarlo subito dopo la registrazione.
Cosa ha funzionato
Il test su account controllati. È l’unica configurazione in cui le tre cause più comuni si escludono tutte insieme e in mezz’ora, invece che una per volta su ipotesi.
Collegamenti diretti: quello che funziona nelle push non funziona nelle email
IN SINTESI
Cosa abbiamo fatto: mappato quattro schermate come destinazioni dirette, poi impostato la variante compatibile con i client di posta.
Perché: una notifica che apre la pagina iniziale costringe l’utente a cercare da solo ciò di cui parla il messaggio.
Cosa abbiamo trovato: i collegamenti interni all’app funzionano nelle notifiche ma vengono bloccati nelle email.
Il numero della sezione: 4 schermate mappate come destinazioni dirette.
Risolto il token, le notifiche partivano ma portavano tutte alla pagina iniziale.
Abbiamo mappato quattro destinazioni: premi, giochi, caricamento scontrino, saldo punti. La pagina iniziale resta senza collegamento, perché è la destinazione predefinita del tocco.
I collegamenti interni all’applicazione funzionano nelle notifiche push. Nelle email no. I client di posta non aprono indirizzi interni delle applicazioni per una ragione di sicurezza, perché sarebbe un modo semplice per far avviare software da un messaggio ricevuto da uno sconosciuto.
La soluzione compatibile richiede due passaggi in più. Si usano indirizzi web normali e si dichiara al sistema operativo che quel dominio appartiene a quell’applicazione, pubblicando due file di configurazione sul sito, uno per piattaforma. Da quel momento lo stesso indirizzo apre la schermata dentro l’app se l’app è installata, e la pagina web se non lo è.
In mezzo va sistemato anche il tracciamento dei clic dello strumento di messaggistica, che riscrive gli indirizzi e deve lasciarli passare senza interrompere la catena.
Cosa ha funzionato
Aver trattato i due canali separatamente invece di cercare una soluzione unica. Le due destinazioni hanno vincoli diversi e la stessa configurazione non le copre entrambe.
Nota di metodo sui numeri
Fonte di verità dichiarata: il pannello consegne dello strumento di messaggistica, incrociato con la scheda profilo dei singoli utenti di test.
| Numero pubblicato | Fonte | Finestra | Modello |
|---|---|---|---|
| 0 consegne | pannello consegne | primo flusso attivato | invii totali del flusso, non campione |
| 4 schermate | mappatura concordata | progetto | destinazioni con collegamento diretto |
| 3 settimane stimate | call di allineamento 16 febbraio | dichiarazione iniziale | durata prevista test inclusi |
Cosa non siamo in grado di misurare, e con che grado di certezza.
Il tasso di consegna raggiunto dopo la correzione non è quantificato in questo documento. Il fatto verificato è che il canale è passato da nessuna consegna a consegne attive, osservato sul pannello dopo il rilascio della correzione. La percentuale di recapito a regime richiede una finestra di osservazione su volume, che non è stata impostata.
L’effetto dei collegamenti diretti sul tasso di apertura e sulla conversione non è misurato. Servirebbe un confronto fra notifiche con e senza destinazione diretta sullo stesso pubblico.
Segnaliamo un limite di documentazione interna. Le fonti d’archivio su questo progetto coprono la fase di pianificazione ma non la fase di debug. I passaggi tecnici descritti sopra provengono dalla ricostruzione diretta di chi ha eseguito il lavoro, non da note contemporanee. È una lacuna nostra di documentazione, e sul piano del metodo la trattiamo come tale.
Cosa non ha funzionato
Abbiamo costruito i flussi prima di verificare l’infrastruttura. Tre settimane di mappatura eventi, configurazione e test interni sono state completate prima di scoprire che il canale non poteva consegnare. Sullo stesso progetto lo stesso ordine sbagliato si è ripetuto sulle email, dove i record del dominio mittente non erano ancora propagati e la piattaforma bloccava gli invii in silenzio, senza errore visibile nel costruttore dei flussi. Cosa abbiamo fatto invece: l’ordine è invertito. Prima si verificano dominio, permessi e una consegna reale di prova, poi si costruiscono i contenuti. Costruire per primi è più gratificante e lascia settimane di lavoro ferme davanti a un blocco che non si annuncia.
Non abbiamo documentato la fase di debug mentre la eseguivamo. Del lavoro tecnico su questo progetto non restano note contemporanee, solo la ricostruzione a posteriori. Significa che i dettagli non sono verificabili contro una fonte datata, ed è un problema in un tipo di lavoro che vendiamo sulla verificabilità. Cosa abbiamo fatto invece: ogni sessione di debug produce adesso una nota datata con i valori osservati, anche quando dura mezz’ora.
Cosa faremmo adesso
Misurare il tasso di consegna a regime. Il canale funziona, ma non abbiamo un valore di riferimento su volume da confrontare nel tempo.
Confrontare notifiche con e senza destinazione diretta. È l’unico modo per sapere se le quattro schermate mappate valgono il lavoro di mantenerle.
Verificare il comportamento sugli utenti registrati prima dell’integrazione. Per chi si era registrato prima, il token è stato emesso in una sessione in cui l’identificazione non veniva chiamata. La correzione dovrebbe recuperarli al primo accesso successivo, e va confermato sul campo.
Definire il routing fra i due sistemi di notifica. Entrambi gli strumenti possono ricevere il token del dispositivo. Senza una regola esplicita di smistamento, ciascuno può intercettare notifiche non sue.
Conclusione
Un flusso attivo con zero notifiche consegnate, causato da un token registrato sul profilo anonimo invece che su quello identificato. Dopo la correzione dell’ordine delle chiamate, il canale consegna e le notifiche portano direttamente alle quattro schermate mappate.
Quello che questo lavoro lascia, ripreso dai quattro punti iniziali.
Come escludere il comportamento degli utenti: si esegue un test su account controllati, con applicazione installata e permesso concesso a mano. Se fallisce anche quello, il problema è nell’integrazione.
Come capire dove finisce un identificativo di dispositivo: si guarda quale profilo era attivo nel momento in cui è stato rilasciato, non quale profilo lo sta cercando.
Come far funzionare un collegamento all’app dentro le email: si passa da indirizzi web normali dichiarando al sistema operativo la proprietà del dominio, perché gli indirizzi interni vengono bloccati.
Come ordinare le verifiche: infrastruttura prima, contenuti dopo. Un blocco di configurazione non produce errori visibili e può fermare settimane di lavoro senza annunciarsi.
Quando questo lavoro ha senso, e quando no
Ha senso se hai un’applicazione mobile e vuoi aggiungere un canale di messaggistica accanto a un sistema di analytics già in uso, senza sostituirlo.
Non ha senso se il tuo volume di utenti attivi è tale che la segmentazione delle notifiche non cambia nessuna decisione. E non ha senso se non hai accesso al team che sviluppa l’app, perché le correzioni di questo tipo vivono nel codice dell’applicazione e non nella configurazione dello strumento.
Il primo passo è aprire la scheda di un profilo con email di un utente che ha l’app installata e guardare se contiene un token di notifica. Se non c’è, è su un altro profilo.