Come fare un A/B Test, prioritizzare le ipotesi, e scegliere il tool giusto

A/B test e sperimentazione sono due termini molto in voga nelle community di Product.

Tuttavia, per le startup che sono pronte a migliorare il conversion rate, perché hanno trovato il proprio product-market fit, non è facile capire come iniziare.

In questo articolo, racconterò di come siamo passati da lanciare un solo A/B test (nel 2019) agli attuali due a settimana.

Eccoti una panoramica di cosa leggerai:

• Quando lanciare un A/B test?
• Come scegliere il primo A/B test?
  • Come scrivere le ipotesi per un A/B test?
  • Come prioritizzare le ipotesi?
• Come scegliere i tool per fare A/B testing?
•  Conclusione

Quando lanciare un 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ò la sfida non era convincere il resto dell’azienda a lanciare esperimenti, ma capire come attuarli.

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 rispetto 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 dov’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 questa guida all’A/B testing);
  
• 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.

All’inizio, il Product Growth Team 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 concentrarci 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 la professione di freelance, non può ancora usare la nostra app per dichiarare le proprie tasse.

Il Registration flow è piuttosto lungo, e quindi le possibilità di  sono molteplici.

Quando abbiamo cominciato a pensare a come avremmo potuto migliorare questo rate, avevamo svariate ipotesi, ma nessuna di queste era stata valutata tramite user research.

Come primo passo, quindi, abbiamo organizzato una sessione di user research per capire quali problemi si 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?

Il primo passo che abbiamo compiuto è stato creare un template, su come scrivere le ipotesi sulle quali 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 alla creazione di 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” nonché la percentuale di utenti che creano un account, mentre il 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 ancora non era chiaro da 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, assumiamo che il 70% della user base potrebbe vedere il banner;
  
• 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 dei feedback ricevuti dagli utenti, perciò avremo un livello di confidence alto (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.

(Avremmo potuto utilizzare anche l’lCE Score, un’altra metodologia per definire le priorità durante lo sviluppo di un prodotto digitale).

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 per essere testato.

Tuttavia, purtroppo, l’infrastruttura su cui stavamo lavorando in parallelo ancora non era pronta e ciò ha causato un ritardo.

Come scegliere i tool per fare A/B testing?

In parallelo, abbiamo 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 cercare, successivamente, una soluzione più avanzata se fosse stato necessaria.

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:

1. Semplifica l’hosting;
2. La gestione dei dati provenienti dall’app;
3. 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 per avere 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 quelle di dieci mesi fa: stiamo lavorando sul creare un processo per cui diversi team possono lanciare A/B test in parallelo e prioritizzare correttamente. 

Il nostro obiettivo di lungo termine è avere l’infrastruttura e le abilità per lanciare contemporaneamente multipli A/B test.

Spero che l’articolo possa essere stimolante e utile per startup e Product Manager interessati all’A/B testing.

Sono curioso di sapere quali sono state le vostre esperienze, lasciate un commento!