Come trasformare i dati di utilizzo del prodotto in un report sull'adozione delle funzionalità (2026)
Un'esportazione dei dati di utilizzo è un lungo elenco di eventi: ID utente, nome dell'evento, timestamp e forse una proprietà o due. Un report sull'adozione delle funzionalità è una singola percentuale. La distanza tra i due è fatta di tre decisioni, non di una formula.
Quali utenti appartengono al denominatore. Cosa si intende per aver utilizzato la funzionalità. E in quale intervallo temporale si effettua la misurazione.
Modificando anche solo uno di questi elementi, il numero varia di decine di punti percentuali. Il report sembrerà comunque corretto, ed è proprio questo il problema.
Questa guida spiega cosa stabilire prima di iniziare, i tre percorsi manuali e i punti deboli di ciascuno.
Cosa serve prima di iniziare
Sono necessarie righe a livello di evento, non un riepilogo pre-aggregato. Una riga per evento, con un identificativo utente e un timestamp.
È necessario il nome dell'evento che rappresenta effettivamente la funzionalità. Questo passaggio è raramente così semplice come sembra, perché la maggior parte delle funzionalità attiva diversi eventi. Un dato sull'adozione di una funzionalità è valido solo quanto lo è questa mappatura.
Bisogna anche sapere chi avrebbe potuto utilizzarla. Se la funzionalità è stata rilasciata tramite un flag a un sottoinsieme di account, tutti gli altri non devono essere inclusi nel denominatore.
Un rapido controllo di coerenza fa risparmiare un'ora di lavoro in seguito. Conta gli utenti unici nell'esportazione e confrontali con il numero di utenti attivi noto. Se differiscono di molto, l'esportazione è filtrata in un modo che non hai notato.
Le tre decisioni che cambiano il numero
Il denominatore. Tutti gli utenti registrati, gli utenti attivi mensili o solo gli utenti idonei per la funzionalità. Questi producono tre percentuali diverse a partire dagli stessi eventi. Ogni dato sull'adozione di una funzionalità è una frazione, quindi definisci entrambe le metà prima di calcolare qualsiasi cosa.
"Idonei" è di solito la scelta più onesta per una funzionalità appena rilasciata. "Tutti gli utenti registrati" è il numero che appare peggiore ed è il più facile da difendere come prudente.
Cosa significa "utilizzato". Aver attivato l'evento una volta, due volte o in due sessioni distinte. Un singolo clic durante un tour guidato non è adozione, e la maggior parte dei team lo impara a proprie spese.
Scegli una soglia e indicala nel report. Due utilizzi in due giorni diversi è una regola comune e difendibile.
L'intervallo temporale. L'adozione non è un singolo istante nel tempo. È la quota di utenti idonei che hanno compiuto l'azione entro un periodo, quindi il periodo fa parte della definizione.
Ecco una sottigliezza documentata che vale la pena conoscere prima di copiare la metodologia di uno strumento. La documentazione sulla retention di Amplitude spiega come funziona il suo calcolo. "Calcola i dati di retention confrontando la data dell'evento iniziale con la data dell'evento di ritorno specificato".
L'intervallo di date si applica solo al primo evento. Amplitude dichiara chiaramente che "gli utenti non devono necessariamente attivare l'evento di ritorno durante quel periodo per apparire nell'analisi".
Si tratta di un comportamento sensato che spesso sorprende le persone. Un foglio di calcolo che filtra entrambi gli eventi nello stesso intervallo temporale non corrisponderà allo strumento, e nessuno dei due è errato.
Come farlo manualmente
Opzione 1: Contare gli utenti unici, poi dividere
Inizia con la deduplicazione, perché i conteggi grezzi degli eventi non rappresentano gli utenti che hanno adottato la funzionalità. Estrai l'elenco degli utenti unici con UNIQUE.
Poi conta quanti di quegli utenti hanno attivato l'evento della funzionalità, utilizzando COUNTIFS con il nome dell'evento e i limiti di data. Dividi per il numero di utenti idonei.
Mantieni i due conteggi in celle visibili anziché annidarli in un'unica formula. Qualcuno chiederà quale fosse il denominatore, e vorrai poterlo indicare chiaramente.
Il limite principale è che questo metodo fornisce un singolo numero senza contesto. Saprai che il 18% ha adottato la funzionalità, ma nulla su chi siano questi utenti.
Opzione 2: Creare una tabella di flag a livello di utente
Una riga per ogni utente idoneo, una colonna per ogni domanda. Hanno attivato l'evento? Quante volte? E in quanti giorni distinti?
Ora puoi segmentare i dati. Adozione per piano, per coorte di registrazione, per dimensione dell'account, o in base al completamento dell'onboarding.
È qui che l'adozione delle funzionalità diventa azionabile e non solo un dato da riportare. Un 18% complessivo nasconde il fatto che i nuovi utenti sono al 40% e gli utenti dello scorso anno sono al 4%.
Quel divario è la vera scoperta. La nostra guida alla analisi di coorte spiega perché il dato complessivo varia ogni volta che cambia il volume delle registrazioni, anche a parità di comportamento.
Il limite è rappresentato dal volume e dalle unioni (join). Un'esportazione da un milione di righe unita a una tabella di account supera il limite oltre il quale le formule rimangono gestibili.
Opzione 3: Tenere una scheda delle definizioni accanto ai numeri
Scrivi il nome dell'evento, la soglia, l'intervallo temporale, il denominatore e chi era idoneo.
Questo è ciò che rende il report confrontabile il mese successivo. È anche la scheda che viene saltata quando qualcuno ha bisogno del numero in dieci minuti.
Il limite è che documentare una definizione non equivale ad applicarla. Qualcuno finirà comunque per ricreare gli stessi cinque filtri a ogni ciclo.
Il limite comune. Tutte e tre le opzioni presuppongono che i nomi degli eventi siano puliti. Quando la stessa azione viene attivata con tre nomi diversi dopo un refactoring, il vero lavoro consiste nel riconciliarli prima ancora di iniziare a contare.
Dove il percorso manuale rallenta
Il primo report richiede una mattinata. Il quarto richiede più tempo, perché nel frattempo la definizione ha subito lievi variazioni senza che nessuno se ne accorgesse.
I nomi degli eventi cambiano quando cambia il prodotto. Una ridenominazione nel codice sorgente si trasforma in un crollo verticale nel grafico, che sembra esattamente un abbandono della funzionalità da parte degli utenti. È così che un grafico sull'adozione delle funzionalità finisce per segnalare una modifica al codice anziché una decisione del cliente.
Le modifiche al rollout compromettono il denominatore. La funzionalità raggiunge il 100% degli account e l'adozione sembra calare, semplicemente perché la popolazione idonea è triplicata.
Poi c'è l'errore di conteggio che persiste più a lungo. Sommare il numero di eventi anziché gli utenti unici gonfia l'adozione ogni volta che una manciata di power user utilizza intensamente la funzionalità.
C'è un ulteriore costo che emerge solo quando si è vicini a una scadenza. Quando qualcuno chiede "è un buon risultato?", una singola percentuale non può rispondere, e creare un confronto diventa un secondo progetto a sé stante.
Come creare il report con Powerdrill Bloom
Step 1: Carica l'esportazione dei dati di utilizzo
Carica l'esportazione degli eventi, o i file degli eventi e degli account insieme. Powerdrill Bloom analizza le colonne al momento del caricamento, così i nomi degli eventi incoerenti e gli ID utente mancanti emergono prima ancora di calcolare qualsiasi percentuale.
Step 2: Descrivi la definizione in linguaggio naturale
Definisci le regole a parole anziché costruirle manualmente. Indica il nome dell'evento, la soglia, l'intervallo temporale e quali utenti sono idonei.
Poi poni le domande che svelano le trappole. Chiedi se ci sono nomi di eventi che sembrano quasi duplicati. Chiedi quanti utenti unici hanno attivato l'evento rispetto al numero totale di eventi attivati, e come varia il tasso di adozione della funzionalità in base al mese di registrazione.
Step 3: Esporta il grafico, il report o la presentazione
Estrai il trend di adozione, una tabella per segmento o una slide che contenga sia il numero che la definizione.
Perché questo metodo è migliore rispetto a ricostruire tutto a ogni ciclo
| Percorso manuale | Powerdrill Bloom | |
|---|---|---|
| Deduplicare gli utenti dagli eventi | Colonne di supporto per file | Richiedere gli utenti unici |
| Suddividere per coorte o piano | Unire e ricostruire la tabella | Richiedere la scomposizione |
| Eventi rinominati dopo un rilascio | Individuarlo nel grafico in un secondo momento | Rilevato al momento del caricamento |
| Modificare la popolazione idonea | Rielaborare il denominatore | Definire la nuova regola |
La terza riga è quella in cui si decide l'accuratezza dei dati. Un evento rinominato e un calo reale appaiono identici in un grafico a linee, ma solo uno dei due richiede un intervento sul prodotto.
Errori comuni
Contare gli eventi anziché gli utenti. Diecimila eventi generati da duecento persone non significano adozione. Deduplica sempre prima di iniziare.
Usare tutti gli utenti registrati come denominatore per una funzionalità limitata da flag. Se solo un terzo degli account può vederla, gli altri due terzi non sono utenti che non l'hanno adottata. Semplicemente non sono idonei.
Considerare un singolo clic come adozione. Un singolo evento durante l'onboarding è solo esposizione. Richiedi un utilizzo ripetuto in giorni diversi se vuoi che il numero abbia un significato reale.
Confrontare un tasso complessivo nel corso dei mesi. I nuovi utenti e quelli esistenti adottano le funzionalità a ritmi diversi, quindi la composizione del pubblico sposta il numero da sola. Suddividi per coorte prima di trarre conclusioni.
Ignorare la ridenominazione di un evento. Un refactoring produce un crollo verticale che sembra abbandono (churn). Controlla il dizionario degli eventi prima di analizzare il comportamento degli utenti.
Copiare l'intervallo temporale di uno strumento senza capire come funziona. Gli intervalli di retention documentati spesso filtrano solo il primo evento, quindi un foglio di calcolo che li filtra entrambi mostrerà dati diversi.
Riportare la percentuale senza allegare la definizione. Il numero non ha senso senza il denominatore e la soglia. Inserisci entrambi nel grafico, nello stesso modo in cui una buona dashboard KPI etichetta le sue metriche.
Conclusione
Definisci la popolazione idonea, stabilisci una soglia di utilizzo, fissa l'intervallo temporale e deduplica gli utenti prima di dividere. Questi quattro passaggi trasformano una percentuale di adozione delle funzionalità in un dato su cui il team di prodotto può effettivamente agire.
Ciò che rende costoso questo processo è che la definizione deve sopravvivere ai cambiamenti del prodotto. Gli eventi rinominati e l'estensione dei rollout modificano entrambi il numero senza che nessuno tocchi il report.
Se è qui che si arena il tuo ciclo di reporting, prova Powerdrill Bloom sulla tua esportazione dei dati di utilizzo. Vedi anche la nostra guida su come creare un grafico di retention delle coorti, la rassegna dei migliori strumenti IA per la product analytics e la pagina dell'assistente CSV AI assistant.
Domande frequenti
Cos'è l'adozione delle funzionalità?
È la quota di utenti idonei che hanno utilizzato una funzionalità entro un intervallo temporale definito, misurata in utenti unici anziché in eventi. La definizione è valida solo se vengono dichiarati il denominatore e la soglia di utilizzo.
Come si calcola a partire da un'esportazione di eventi?
Conta gli utenti unici che hanno attivato l'evento della funzionalità all'interno dell'intervallo temporale, quindi dividi per il numero di utenti idonei. Effettua prima la deduplicazione, poiché un singolo utente può generare centinaia di eventi.
Il denominatore dovrebbe essere costituito da tutti gli utenti o solo dagli utenti attivi?
Utilizza la popolazione idonea, ovvero gli utenti che potevano effettivamente accedere alla funzionalità. Considerare tutti gli utenti registrati produce un dato prudente e sottostima l'adozione se la funzionalità è limitata da un flag di rollout.
Quanto dovrebbe durare l'intervallo temporale di misurazione?
Abbastanza a lungo da coprire un normale ciclo di utilizzo, quindi settimanale per i prodotti ad uso quotidiano e mensile per quelli periodici. Mantienilo fisso nei vari report, poiché modificarlo cambia il risultato finale.
Perché il mio numero differisce da quello dello strumento di analytics?
Di solito dipende dall'intervallo temporale o dalla regola di deduplicazione. I calcoli di retention documentati spesso applicano il filtro della data solo al primo evento, cosa che un foglio di calcolo basato su entrambi gli eventi non riprodurrà.