Un problema da 100 milioni, risolto elegantemente

Il tasso di abbandono (o churn rate) è una delle metriche che, spesso, vorrete tenere sott’occhio da vicino e ridurre. Può determinare la fine o il successo di un prodotto: acquisire clienti è notoriamente dispendioso, dunque una volta conquistati ve li vorrete tenere stretti.

Qualche mese fa, questo tweet di Matt Lerner è balzato in cima alla mia timeline. Ciò che rende il thread particolarmente interessante non è tanto il fatto che a PayPal abbiano risolto un problema di abbandono da 100 milioni di dollari, quanto che l’eleganza del modo in cui sono giunti alla soluzione (la quale, per inciso, ha richiesto la modifica di zero linee di codice). Si tratta di un ottimo esempio di come spendere sufficiente tempo al pensare al problema possa risultare in soluzioni efficaci e intelligenti.

Il problema: venditori che se ne vanno

Non è mistero che una parte significativa delle entrate di PayPay derivino dalle commissioni pagate dai venditori che usano i loro prodotti. Quanti sono quelli che, per una ragione o per l’altra, abbandonano il servizio? Lerner ci dice che sono circa 1 milione all’anno. Il numero esatto non è importante: la sostanza è che sono tanti, troppi perché sia pensabile di prevenire l’abbandono di ciascuno.

Superficialmente, il problema può essere descritto con: come ridurre il tasso di abbandono? Invece di balzare subito alle conclusioni e pensare a possibili soluzioni, tuttavia, il team ha speso tempo a pensare meglio al problema. Come? Innanzitutto delimitandolo.

Perdere utenti ≠ churn

Partendo dal dato grezzo del milione di abbandoni: sono tutti churn, o sembrano churn ma sono “altro”? E chi può essere considerato, a titolo pieno, un utente che ha abbandonato il servizio?

La prima considerazione del team è che non è sufficiente guardare agli account chiusi: mantenere un account non ha un costo e la maggior parte degli utenti si limita a mantenerlo senza utilizzarlo. Se un utente chiude un account, la decisione è stata probabilmente presa da tempo e si può considerare irreversibile. Piuttosto, occorre guardare a quei venditori le cui transazioni di punto in bianco terminano.

Secondo, si possono escludere quelli che Lerner chiama one-and-dones: si tratta di business che si registrano, eseguono una manciata di transazioni e poi smettono di usare il servizio. Perché escluderli? Perché analizzando i dati il team ha scoperto che si tratta per lo più di piccoli venditori che non necessitano davvero di usare il prodotto su base giornaliera. Dunque, il loro l’impatto sul problema è minimo e la soluzione probabilmente ardua.

Terzo, si possono escludere quei business che hanno una pessima esperienza iniziale e, a causa di quest’ultima, non proseguono con l’utilizzo del servizio. Il problema è serio, eccome – ma non è churn. Spiega Lerner, è un problema di attivazione e onboarding – dunque che va affrontato diversamente.

Quarto, escludere i falsi positivi: merchants le cui transazioni sembrano svanire per un certo periodo, per poi riapparire. Ad esempio, chi ha un business strettamente legato a stagionalità ed eventi (ad esempio l’organizzatore di un grosso festival che si tiene una volta all’anno).

Infine, tutti quegli utenti che sono stati rimossi dalla piattaforma per comportamenti non idonei. Naturalmente non vi è alcun interesse a recuperarli.

80/20

Esclusi dalla lista tutti i casi di cui sopra, Lerner ci dice che si trovavano ancora con qualche decina di migliaia di account. Ancora troppi per poter trovare una soluzione onnicomprensiva.

Come nella maggior parte dei casi, vale la regola dell’80/20 – che in questo caso tuttavia è la regola del 90/10. Infatti, il 90% del fatturato viene generato da circa il 10% dei venditori. Il problema, visto da questa prospettiva, va affrontato come revenue churn invece che come account churn: non più decine di migliaia di account da considerare, ma un paio di centinaia.

“Death by a thousand paper cuts”

Purtroppo, trovare una soluzione per questi merchant non è comunque affare da poco. PayPal ha sistemato tempo addietro tutti i principali difetti del proprio prodotto: questi abbandoni non erano dovuti a un singolo grosso, evidente problema, quanto alla somma di tanti, piccoli incidenti e fastidi. Come scovarli? Scherza Lerner (ma non troppo): con l’aiuto dello stagista estivo.

In breve, una persona ha speso tempo ad esplorare tutti i sistemi rilevanti per ricostruire lo storico di questi utenti e determinare i vari piccoli intoppi che avevano incontrato. Da qui, ha aggregato le varie occorrenze in 20 scenari “killer”. Infine, ha impostato una query settimanale per individuare gli account il cui storico più recente li rendeva candidati per un imminente abbandono.

Gli account vengono segnalati all’assistenza clienti, che li contatta proattivamente per risolvere i problemi in corso. Naturalmente, con grande soddisfazione dei merchant stessi.

Delimita il problema e poi scava nei dettagli

Il thread si conclude spiegando che il problema non poteva essere risolto su scala, dunque andava ridotto. La sintesi delle lezioni imparate, così come elencate da Lerner, è:

  1. Concentrati sugli utenti che smettono di usare il servizio. Chi cancella un account è perso.
  2. Distingui tra ritenzione e attivazione: richiedono soluzioni diverse.
  3. Concentrati solo cui casi che sono solubili e che vale la pena risolvere.
  4. Se le entrate sono concentrate, considera account churn vs revenue churn.
  5. Quando il problema è sufficientemente delimitato, scava nei dettagli.

Quando mi viene presentato un problema, trovo tutt’ora difficile non passare subito alla ricerca di una possibile soluzione. Saper fare un passo indietro e iterare la definizione di un problema è importante, in product management, tanto quanto (se non più di) saper stabilire le giuste priorità, validare le soluzioni prima di implementarle o gestire il ciclo di sviluppo di un prodotto in maniera incrementale.

Questa breve storia è un ottimo esempio da tenere a mente: quell’ora in più spesa ad analizzare il problema potrebbe salvarmi svariate ore spese a progettare una soluzione costosa e approssimativa.

Subscribe
Notify of
guest
0 Commenti
Oldest
Newest Most Voted
Inline Feedbacks
View all comments