Anti-pattern delle metriche di prodotto

Le metriche di vanità sono metriche che sembrano impressionanti in una presentazione ma sono scollegate dalla reale salute o traiettoria del prodotto. Comuni metriche di vanità nel SaaS: utenti totali registrati (include tutti coloro che si sono mai iscritti, inclusi utenti churned, mai attivati e inattivi da tempo — sembra un numero grande ma è un pessimo indicatore della base utenti attiva); visualizzazioni di pagina (facilmente gonfiate da traffico di bassa qualità, bot o UX confusa che fa cliccare gli utenti più volte per completare un'attività); download totali dell'app (per prodotti mobile); follower su LinkedIn; e menzioni in comunicati stampa. Persistono perché sono facili da far crescere, aumentano sempre (sono conteggi cumulativi che possono solo salire) e producono grafici narrativi soddisfacenti per le presentazioni all-hands. L'antidoto è abbinare ogni metrica di vanità al suo equivalente aggiustato per la qualità: invece di utenti totali, riportare MAU + tasso di attivazione; invece di visualizzazioni di pagina, riportare pagine con > 30 secondi di engagement; invece di download, riportare la retention a 7 giorni. La metrica aggiustata per la qualità rivela se la crescita della metrica di vanità è significativa.

Il bias di sopravvivenza nell'analisi del prodotto si verifica quando i team analizzano solo gli utenti che sono ancora presenti nei dati, ignorando quelli che se ne sono andati — producendo conclusioni sistematicamente ottimistiche. Esempio classico SaaS: un team vuole capire quali azioni di onboarding portano alla retention. Analizzano il comportamento dei loro attuali utenti attivi nella settimana 1 e scoprono che l'85% degli utenti attivi ha aggiunto un membro del team durante l'onboarding. Conclusione: "aggiungere un membro del team presto è il comportamento chiave." Analisi anti-bias di sopravvivenza: analizzare la coorte di tutti gli utenti di 90 giorni fa (non gli attuali utenti attivi) e confrontare il comportamento della settimana 1 di coloro che sono ancora attivi rispetto a quelli che hanno effettuato il churn. Questo rivela se l'aggiunta di un membro del team predice effettivamente la retention o se è semplicemente un comportamento comune per la maggior parte degli utenti indipendentemente dall'esito. L'"analisi di correlazione della retention" senza controllo della coorte è quasi sempre influenzata dal bias di sopravvivenza. Product Ops forma i PM sulla metodologia di analisi controllata per coorte come pratica standard nell'interpretazione della user research.

L'errore analitico più pericoloso e comune nelle operazioni di prodotto: osservare che due cose accadono insieme e concludere che una causa l'altra. Esempio reale: un'azienda SaaS osserva che gli utenti che impostano la notifica email del daily digest hanno una retention a 90 giorni 4 volte superiore rispetto agli utenti che non lo fanno. Concludono: "se forziamo tutti i nuovi utenti a impostare il daily digest, miglioreremo drasticamente la retention." Implementano l'impostazione obbligatoria delle notifiche nell'onboarding. La retention non migliora. La verità: gli utenti che impostano volontariamente le notifiche del daily digest sono già engaged e committed — avrebbero mantenuto la retention comunque. L'impostazione delle notifiche è un sintomo di alto engagement, non la sua causa. Testa prima di concludere: l'unico modo affidabile per stabilire la causalità è un esperimento controllato randomizzato — assegnare casualmente alcuni utenti a un gruppo che viene spinto verso il comportamento "correlato" e confrontare la loro retention con un controllo randomizzato. Se il gruppo spinto casualmente migliora, la causalità è supportata. Product Ops dovrebbe richiedere che ogni "scoperta" dall'analisi del prodotto superi una convalida di causalità di base — sia tramite esperimento che tramite un plausibile meccanismo causale — prima che informi una decisione di prodotto.