Contare gli accessi o i clic può indicare che qualcuno interagisce con un prodotto, ma non dimostra che una funzionalità risolva un problema. Per definire le priorità dei miglioramenti, le metriche di utilizzo nel SaaS devono collegare comportamenti osservabili a domande di prodotto: chi usa una funzionalità, con quale frequenza, in quale contesto e in quale punto abbandona un flusso.
Una raccolta degli eventi utile inizia prima di scrivere codice. Se un evento non può orientare una decisione, probabilmente è rumore. L’obiettivo non è registrare ogni azione disponibile, ma costruire segnali coerenti che permettano di comprendere l’adozione, rilevare gli attriti e verificare se un intervento modifica il comportamento previsto.
Partire dalla decisione, non dall’evento
Formulate prima la domanda a cui volete rispondere. Per esempio: “Quale percentuale di account configura un’integrazione nei primi 14 giorni?” è più utile per prendere decisioni di “Quante volte è stato premuto il pulsante dell’integrazione?”. La prima definisce una popolazione, un’azione e una finestra temporale; la seconda descrive soltanto un’attività.
Per ogni metrica, documentate:
- Decisione: cosa potrebbe cambiare il team se il segnale aumenta, diminuisce o rimane stabile.
- Popolazione: quali utenti, account o piani sono inclusi e quali esclusi.
- Comportamento: quale azione osservabile viene considerata un utilizzo significativo.
- Periodo: quando inizia e termina la finestra di osservazione.
- Limiti: quali conclusioni non è possibile trarre dalla metrica.
Se la risposta non cambierebbe una priorità, un’ipotesi o un’indagine, non è necessario raccogliere l’evento subito. Una domanda sull’abbandono, invece, può richiedere eventi di inizio e completamento di un flusso, non un contatore generale di attività.
Definire gli eventi con uno schema stabile
Un evento deve avere un nome comprensibile e una definizione condivisa tra prodotto e sviluppo. Una struttura pratica comprende il nome, l’attore, l’account associato, il momento di emissione e un contesto minimo. Per esempio, report_export_completed dovrebbe indicare che l’esportazione è terminata correttamente, non che è stato mostrato il pulsante o che è iniziata una richiesta.
Documentate anche le proprietà ammesse e i relativi tipi: identificativo interno dell’account, tipo di esportazione o risultato. Evitate nomi ambigui come action e valori liberi che mescolano concetti diversi. Se il significato di un evento cambia, registrate la modifica o introducete una versione dello schema; in caso contrario, una serie storica potrebbe combinare comportamenti diversi senza che i report lo segnalino.
Definite con precisione il momento di emissione. Per misurare il completamento, inviate l’evento dopo aver confermato il risultato, non prima di eseguire l’operazione. Nei processi asincroni, separate inizio, successo e fallimento se queste fasi rispondono a domande diverse. Non definite “completato” un processo che è stato soltanto accodato.
Distinguere utenti, account e flussi
Nel SaaS B2B, una persona e un account aziendale non sono la stessa unità di analisi. Un utente può appartenere a un’organizzazione; più utenti possono utilizzare una funzionalità dallo stesso account. L’adozione per account risponde alla domanda su quante organizzazioni hanno adottato una funzionalità. L’attività individuale mostra chi la usa e con quale regolarità. Entrambe le prospettive sono valide, ma non devono essere mescolate nello stesso denominatore.
Per esempio, per valutare una funzionalità collaborativa, potete misurare la percentuale di account idonei con almeno un’azione valida e, separatamente, quanti utenti distinti partecipano in ciascun account. Definite cosa significa “idoneo”: un account senza accesso alla funzionalità non dovrebbe risultare come non adottante. Concordate anche come trattare un account con più spazi di lavoro o utenti che cambiano organizzazione.
Per comprendere un flusso, stabilite passaggi osservabili, come inizio, convalida e completamento. Confrontate il numero di entità che raggiungono ciascuna fase usando un’identità coerente. Il tasso di abbandono è interpretabile solo se si conoscono la popolazione che ha avviato il flusso, il tempo previsto per completarlo e il modo in cui vengono gestiti i tentativi ripetuti o i processi ancora aperti.
Prevenire duplicati e attività che non rappresentano un utilizzo
Lo stesso comportamento può essere registrato due volte se il browser ripete una richiesta, una coda elabora nuovamente un messaggio o una chiamata termina senza che il client riceva una conferma. Quando opportuno, usate una chiave di idempotenza o un identificativo univoco dell’operazione e definite nel sistema di analisi quale evento rappresenta l’azione di business da conteggiare.
Separate le azioni delle persone dalle attività automatiche. Una sincronizzazione pianificata, un’attività di manutenzione o una chiamata interna non dovrebbe aumentare l’utilizzo attribuito a un utente. Se è utile misurare l’attività automatica, contrassegnatela con un attore o un tipo di origine distinto ed escludetela dagli indicatori di adozione umana.
È inoltre necessario gestire i cambiamenti di identità: inviti, cancellazioni di utenti, utenti accorpati e account trasferiti. Stabilite una regola coerente per l’identità analitica, evitando di usare l’indirizzo e-mail come identificativo permanente. Un identificativo interno pseudonimo tende a essere più stabile e riduce l’esposizione dei dati personali.
Raccogliere eventi in PHP senza accoppiare l’analisi al business
La logica di business deve determinare se un’operazione è consentita e quale risultato produce. L’analisi registra quel risultato, ma non dovrebbe determinarlo. Se una chiamata al provider di analisi fallisce, in genere non dovrebbe impedire all’utente di completare un’esportazione o salvare una modifica.
In un’applicazione PHP, potete generare eventi da un servizio applicativo dopo aver confermato l’operazione rilevante e inviarli tramite una coda o un meccanismo disaccoppiato quando l’affidabilità lo richiede. Se la coerenza tra la transazione di business e la registrazione è fondamentale, valutate il pattern outbox: salvare l’evento in sospeso insieme alla modifica e pubblicarlo in seguito. La scelta dipende dal rischio di perdita, dal volume e dall’architettura; non tutti i prodotti hanno bisogno dello stesso livello di complessità.
Centralizzate lo schema e le convenzioni, invece di creare eventi sparsi con proprietà diverse in ogni controller. Applicate limiti e convalide, registrate gli errori di consegna senza riversare payload sensibili ed evitate che le regole di business dipendano da una risposta del sistema di analisi.
Ridurre al minimo i dati e convalidare la raccolta degli eventi
Raccogliete solo i dati necessari per rispondere alla domanda definita. Non inviate al sistema di analisi password, contenuti di documenti, token, dati di pagamento o testo libero. Esaminate gli identificativi e le proprietà che potrebbero rivelare informazioni personali, limitate l’accesso in base al ruolo e definite una policy di conservazione coerente con le finalità e gli obblighi applicabili.
Prima di fare affidamento su un indicatore, provate gli eventi con scenari concreti: operazione riuscita, errore di convalida, nuovo tentativo, doppio invio, utente senza autorizzazioni e processo automatico. Verificate che l’evento compaia una sola volta, contenga l’attore e l’account previsti e venga emesso al momento corretto. Aggiungete controlli operativi per rilevare cali improvvisi dei volumi, proprietà mancanti o variazioni nella percentuale di errori.
La convalida non termina con il deploy del codice. Confrontate registrazioni di esempio con l’azione effettiva, verificate filtri e denominatori dei report ed esaminate le modifiche allo schema. Un aumento improvviso può dipendere da una nuova integrazione, da un errore di duplicazione o da una modifica dell’identità, non da un miglioramento dell’adozione.
Interpretare i segnali e trasformarli in test
Trend e coorti aiutano a confrontare gruppi definiti da una condizione comune, come la data di registrazione o l’utilizzo iniziale di una funzionalità. Indicate sempre il periodo, la dimensione del gruppo e i criteri di inclusione. Un miglioramento della conversione dopo una modifica è un segnale da approfondire, non la prova automatica che la modifica lo abbia causato: potrebbero aver influito la stagionalità, la composizione dei clienti, le campagne o modifiche simultanee.
Trasformate l’osservazione in un’ipotesi verificabile. Per esempio: “Gli account che non completano la connessione si fermano durante l’autorizzazione; mostrare istruzioni specifiche dovrebbe aumentare le connessioni valide”. Definite in anticipo la metrica principale, le metriche di salvaguardia — come gli errori o le richieste di supporto — e il periodo di valutazione. Quando possibile, utilizzate un confronto controllato; altrimenti, affiancate al trend interviste, revisione delle sessioni o analisi degli incidenti, senza presentare prove correlazionali come causali.
Una metrica utile permette di decidere cosa fare dopo, non solo di riferire ciò che è accaduto. Verificate periodicamente che ogni evento mantenga una definizione chiara e continui a rispondere a una decisione reale. In questo modo, l’analisi accompagna il prodotto: offre segnali affidabili, rende visibili i propri limiti e orienta test in grado di confermare o confutare un’ipotesi.
