Come siamo passati da lanciare un A/B test in un anno, a due alla settimana?

A/B testing e sperimentazione sono due termini molto in voga adesso nelle community di Product. Per startup che hanno trovato product-market fit e sono pronte a migliorare i conversion rate, tuttavia, non è facile capire come iniziare. In questo articolo, parlerò di come siamo passati da lanciare un solo A/B test nel 2019, ai due attuali a settimana.

Ecco cosa troverai:

– A quale punto iniziare a lanciare A/B test?
– Come scegliere il primo A/B test?
– Come scegliere il tool per A/B test?
– Conclusione

A quale punto iniziare a lanciare A/B test?

Quando ho iniziato a lavorare come Growth Product Manager, la pressione in azienda per iniziare a lanciare A/B test era molto alta. Fortunatamente, il management era molto interessato all’ A/B testing, perciò le sfida non era convincere il resto dell’azienda a lanciare esperimenti, ma capire come lanciarli.

Problemi da risolvere.

Prima di iniziare a testare, volevo essere sicuro di avere delle risposte definitive ai seguenti punti:

• Infrastruttura: la base di tutto, in termini di tracking e tool per sperimentare. La fiducia nei dati deve essere completa, per non correre il rischio di non poter prendere azioni concrete dopo i risultati di un test. La startup aveva avuto esperienza in passato con A/B test, ma la fiducia nei risultati era compromessa per degli errori nel tracking. Il tool presentava risultati diversi rispetti a ciò che proveniva dal database, e volevo evitare di ripetere gli stessi errori.
  
• Traffico: molte aziende commettono l’errore di investire in A/B testing prima di aver raggiunto una base di utenti sufficiente. Dopo analisi varie, abbiamo compreso che nel nostro caso l’unica piattaforma dove era possibile eseguire con successo A/B test era la mobile app. Per maggiori dettagli sul livello di traffico necessario per iniziare a sperimentare, potete leggere questo articolo.
  
• Processo: lanciare A/B test può diventare in alcune aziende una scorciatoia per testare le idee dei manager, senza concentrarsi su analisi e user research. Ogni A/B test presenta un costo opportunità, poiché  è necessario investire development time e traffico che potrebbe essere utilizzato per altre ipotesi. È quindi necessario stabilire dall’inizio un processo per ridurre al minimo questo rischio, e prioritizzare correttamente le ipotesi su cui lavorare.

Avendo constatato che ancora mancavano risposte chiare a questi punti, io e il mio team abbiamo passato i mesi successivi a risolvere questi problemi.

Il Product Growth team all’inizio era formato solamente da me, una Product Designer e uno sviluppatore. Pur essendo limitati in termini di risorse, questo ci ha dato l’opportunità di essere concentrati esclusivamente su come risolvere i punti descritti in maniera efficiente.

Il mio consiglio è di creare un team simile che agisca come una task force, unicamente concentrato su questo progetto.

Come scegliere il primo A/B test?

L’obiettivo del nostro team è aumentare il numero di utenti registrati, agendo sul conversion rate fra Install e Registration. La nostra app, che si occupa di dichiarazioni delle tasse, prevede una decina di domande prima che l’utente possa creare un account, non potendo supportare tutti i casi. Ad esempio, un utente che svolge come professione il freelancer, ancora non può usare la nostra app per dichiarare le proprie tasse. Il Registration flow è piuttosto lungo, e quindi le possibilità di ottimizzazione sono molteplici.

Quando abbiamo iniziato a pensare a come potessimo migliorare questo rate, avevamo svariate ipotesi, ma nessuna di queste valutata tramite user research. Come primo passo abbiamo quindi organizzato una sessione di user research per capire quali problemi riscontrassero nell’ acquisition funnel della nostra app.

La ricerca ha prodotto risultati concreti e abbiamo potuto individuare trend nelle risposte, utili per creare una prima lista di ipotesi.

Come scrivere le ipotesi per un A/B test?

Come primo passo, abbiamo creato un template su come scrivere le ipotesi su cui lavorare, da condividere con il resto dell’azienda:

• Ipotesi: nel nostro caso, il motivo per cui pensiamo che un utente non completi l’azione desiderata. Ad esempio, “Utente non si registra perché non ha ancora ricevuto un beneficio tale da motivarlo a crearsi un account”.
  
• Soluzione: l’ iniziativa specifica che adottiamo per risolvere il problema descritto nella ipotesi. Ad esempio, “Creare un banner con esempi di deduzioni che l’ utente può sfruttare per aumentare il rimborso”.
  
• KPI: le metriche che misureremo per determinare se l’A/B test è stato un successo o meno. Nel caso le metriche siano molteplici, è importante avere una metrica primaria di successo, per evitare di basarsi su indicatori meno importanti. Nel nostro esempio, il KPI primario sarebbe il Registration rate, ovvero percentuale di utenti che creano un account, e KPI secondario potrebbe essere la percentuale di utenti che completano tutte le domande prima di raggiungere il Registration screen.
  
• Predizione: è una frase che riassume l’esperimento e segue una struttura fissa: “SE implementassimo la soluzione, ALLORA miglioreremo il KPI DI x%”. È importante decretare prima del lancio dell’ A/B test il risultato previsto, poiché questo numero è usato per calcolare la sua durata e priorità. Nel nostro esempio, la predizione sarebbe: “SE mostrassimo agli utenti un banner con esempi di deduzione, ALLORA miglioreremo il Registration rate DEL 3%”.

Come prioritizzare le ipotesi?

Abbiamo documentato le ipotesi seguendo questo template, ma a questo punto ancora non era con chiaro quale A/B test saremmo dovuti partire. Abbiamo deciso di utilizzare una variante del RICE Score model per classificare le ipotesi:

• Reach: numero di utenti che raggiungono una determinata parte del flow e che determinano il campione dell’ A/B test. Nel nostro esempio, il numero di utenti che potrebbero vedere il banner, assumiamo il 70 percento della user base.
  
• Impact: l’incremento previsto nel caso l’A/B test sia un successo, il medesimo incluso nella Predizione. Nel nostro esempio, abbiamo scelto 3%.
  
• Confidence: il livello di fiducia nel successo dell’A/B test. Questo dato è soggettivo, e cresce nel caso ci siano chiari insights a favore dell’ esperimento durante la user research. Solitamente, per questo criterio usiamo un scala di valori da 1 a 5. Per il nostro esempio, assumiamo che abbiamo formulato questa ipotesi a seguito di feedback ricevuto da utenti, perciò il livello di confidence e’ alto e pari a 4.
  
• Effort: l’investimento in termini di development e design per implementare la soluzione richiesta dall’ A/B test. Anche in questo caso, utilizziamo una scala di valori da 1 a 5. Nel nostro esempio, sviluppare un banner richiede un livello di effort basso, perciò assegnamo 1 come valore.

A questi, per la natura frammentata del nostro prodotto che ha diversi drop prima della registrazione, abbiamo deciso di aggiungere un ulteriore criterio:

• % of Drop: quanti utenti perdiamo in un determinato punto del flow, utile per capire quanto grande effettivamente sia il drop che vogliamo risolvere. Nel nostro esempio, assumiamo una perdita del 30% di utenti tra il punto in cui mostriamo il banner, e il momento della creazione dell’ account.

E utilizziamo questa formula per prioritizzare:

Nel nostro esempio, il punteggio ottenuto dalla ipotesi sarebbe 2,52. Il risultato finale è stato il seguente documento, con una lista di ipotesi ordinate per punteggio:

Dopo aver definito la lista delle ipotesi su cui concentrarci, abbiamo lavorato su dei prototipi da testare con degli utenti per ricevere feedback e attuare miglioramenti.

Dopo settimane di lavoro preliminare per decidere su cosa concentrarci, il design del primo A/B test era finalmente pronto ad essere testato. A questo punto, purtroppo, l’infrastruttura su cui stavamo lavorando in parallelo ancora non era pronta e ciò ha causato un ritardo.

Come scegliere il tool per A/B test?

In parallelo, abbiamo iniziato stilato una serie di criteri per classificare le varie opzioni che il mercato offre per lanciare A/B test:

• Piattaforma: la maggioranza dei nostri utenti usa la mobile app, perciò abbiamo deciso di concentrarci su un tool orientato su questa piattaforma. Abbiamo deciso di non estendere la ricerca a tool che permettessero di lanciare A/B test su sito web e web app.
  
• Facilità di esecuzione: l’intenzione era di iniziare a sperimentare il prima possibile, e avendo un solo sviluppatore a disposizione, era importante scegliere un tool facile da implementare.
  
• Integrazione con Database: la mobile app è complessa e contiene centinaia di eventi, utilizzati per formulare i KPI. Abbiamo ritenuto necessario scegliere un tool che ci permettesse di utilizzare questi eventi per decretare il successo di un A/B test. 
  
• Costo: il range di prezzo dei tool sul mercato è molto ampio, da poche centinaia di euro al mese fino ad arrivare a svariate migliaia. Per le nostre esigenze, abbiamo deciso di concentrarsi sulla fascia bassa del mercato, e nel caso cercare successivamente una soluzione più avanzata.

Dopo aver classificato le varie opzioni seguendo questi criteri, abbiamo deciso di utilizzare Firebase. Firebase è una piattaforma sviluppata da Google che offre numerosi servizi per lo sviluppo di mobile applications. Tra i tanti, semplifica l’hosting, la gestione dei dati provenienti dall’app e l’autenticazione degli utenti. Inoltre, negli ultimi anni hanno lavorato allo sviluppo di una piattaforma di A/B testing, il tool che abbiamo deciso di adottare.

Abbiamo passato le settimane successive ad implementare Firebase e a testare se funzionasse tramite A/A test, ovvero un esperimento in cui le varianti sono identiche. L’obiettivo di un A/A test è certificare l’ accuratezza dei risultati prodotti dal tool. Poiché le due varianti sono identiche, alla fine dell’esperimento la differenza tra i due conversion rate non dovrebbe essere significativa.

Questa fase è stata più complicata del previsto, per vari problemi durante la fase di A/A testing che hanno ritardato il lancio del primo esperimento. Finalmente, dopo mesi di user research e lavoro sull’infrastruttura, abbiamo iniziato il primo A/B test.

Conclusione

Il primo A/B test ha prodotto i risultati sperati, migliorando il Registration rate in modo significativo. 

Nelle prime settimane del 2020, il team si è ingrandito a seguito dell’assunzione di due sviluppatori. Grazie all’ aggiunta di nuove risorse e al lavoro svolto in precedenza, siamo passati da lanciare un solo A/B test durante il 2019, a due alla settimana. È stato importante investire più risorse nel team, poiché la task force iniziale non sarebbe stata capace di supportare questo carico di lavoro.

Le sfide che abbiamo adesso sono molto diverse rispetto a quella di dieci mesi fa. Stiamo lavorando su creare un processo per cui diversi team possono lanciare A/B test in parallelo, e prioritizzare correttamente. Il nostro obbiettivo di lungo termine è avere l’ infrastruttura e le abilità per lanciare contemporaneamente multipli A/B test.

Spero che l’ articolo sia interessante e utile per startup e Product Manager interessati a iniziare a lanciare A/B test. Sono curioso di sapere quali sono state le vostre esperienze, lasciate un commento!