Requisiti per l'esecuzione di programmi di sperimentazione seria

Gestire programmi di sperimentazione è un'arte e una scienza. Lo dico sempre. I programmi dovrebbero avere un certo livello di rigore, vale a dire sistemi, processi e procedure. Non è qualcosa da prendere alla leggera. Credere che chiunque possa iniziare un programma domani con una preparazione e una pianificazione minime è un errore. Sfortunatamente, però, succede sempre. Porta a un sacco di soldi, tempo e fatica sprecati - non sorprende. Questo mi porta al tema della preparazione.

Se vuoi prendere sul serio la sperimentazione e aumentare la tua competitività sul mercato, è meglio che tu lo faccia bene. Dovresti presumere che i tuoi concorrenti lo stiano facendo bene. Quindi, se questo risuona con te, continua a leggere e ti garantisco che raccoglierai una o due pepite d'oro da usare immediatamente.

L'inevitabile precursore della costruzione di un programma di sperimentazione che ti farà o ti distruggerà: calcoli pre-test

Calcoli preliminari. Mai sentito parlare di loro? Li hai fatti? L'MDE o l'effetto minimo rilevabile suona familiare? Che ne dici delle stime della durata o delle dimensioni del campione? Spero che tu sappia di cosa sto parlando, anche se scommetterei soldi che la maggior parte di voi non sa, semplicemente per la mia esperienza personale con i clienti.

Prima di fare qualsiasi cosa relativa alla sperimentazione, verifica se disponi di un volume di dati sufficiente per farlo. Verifica se sei in grado di testare affatto attraverso i calcoli pre-test. Per volume di dati intendo visitatori e conversioni. I visitatori possono essere qualsiasi cosa tu usi di solito (ad esempio, sessioni, utenti, MAU, ecc.). Le conversioni provengono dalla metrica principale che utilizzerai nei tuoi test. Conosci questo:

1. Non tutte le aziende dispongono di un volume di dati sufficiente per eseguire la sperimentazione a qualsiasi capacità.
2. Se puoi farlo, sappi che non scegli semplicemente la velocità desiderata dal nulla. Si basa su calcoli.

Il colpevole n. 1 per aver ignorato uno o entrambi questi punti: i venditori. Se stai cercando di acquistare qualsiasi tipo di strumento, assicurati che questo faccia parte della conversazione. La barriera minima all'ingresso per avere un programma di sperimentazione: volume di dati sufficiente per eseguire un test entro otto settimane o meno in una swimlane.

Ho trattato questo argomento in dettaglio alcuni mesi fa per Experiment Nation. Sappi che se non capisci questo argomento e lo fai dal primo giorno, ti perseguiterà e alla fine causerà sicuramente risultati indesiderati di qualche tipo. Un'altra nota molto importante: sapere se il tuo strumento di test (o quello che prevedi di utilizzare) è costruito sulla base di test a orizzonte fisso o test sequenziali. Ciò influisce sui calcoli e sul modo in cui esegui il programma.

Passaggio 1 (post-precursore): misurazione e qualità dei dati

Se hai eliminato l'ostacolo dei calcoli pre-test e hai confermato di disporre di un volume di dati sufficiente per testare, l'ostacolo successivo per andare avanti è la misurazione e la qualità dei dati. Devi sapere a cosa miri in questo lavoro; altrimenti ti arrampicherai come un pesce sulla riva di un fiume. Troppi team non sanno a cosa stanno lavorando, ad esempio invio di moduli, transazioni, entrate, LTV, ecc.

Comprendi quali sono le tue metriche primarie, secondarie e terziarie per la sperimentazione e l'azienda nel suo complesso. Comprendilo con assoluta chiarezza. Non permettere confusione o incertezza persistenti. Assicurati che tutti siano sulla stessa pagina.

Quindi, una volta che hai così tanto, assicurati di raccogliere quei dati nei posti giusti e di poterti fidare.

Se la misurazione e/o la qualità dei dati sono disastri, fermati. Ferma tutto e dedica tutti i tuoi sforzi per farlo bene. Pensa alla sperimentazione come a una piramide. Queste due cose sono gli strati fondamentali della piramide. Se si rompe in qualsiasi momento, tutto il resto si sgretolerà sopra di esso. Prometto.

Dirò che so che questi possono essere difficili. Farli bene può richiedere più tempo. Forse anche più di un mese o due. Ne vale la pena però. Ho visto problemi sorgere sei mesi o più dopo l'avvio di un programma, solo che alla fine tutto si è fermato bruscamente. Nessuno è felice a quel punto.

Una nota su cosa dovrebbe essere una metrica primaria...

Questo è un argomento di divisione tra i professionisti a volte. Ho una posizione molto ferma sulla questione, in particolare quando si tratta di team di marketing e siti Web (non necessariamente team e prodotti di prodotto).

Le metriche primarie dovrebbero sempre essere metriche down-funnel. Ordini. Invii di moduli. MQL. Reddito. LTV. SQL. Hai capito. Alcune persone dicono che dovrebbero sempre essere l'azione più vicina al cambiamento che stai apportando o alle metriche di coinvolgimento. Sbagliato. No. No. Errato. Cavolo. Chi ti dice questo dovrebbe essere quello che deve giustificare il programma in sei mesi o un anno al CMO o al CEO dell'azienda. Saranno nel posto caldo. NON avere un programma pieno di test incentrati su clic sui pulsanti, click-through, visualizzazioni di pagina, media. durata della sessione, frequenza di uscita, frequenza di rimbalzo, visualizzazioni di video e così via. Questo non giustificherà le migliaia o centinaia di migliaia di dollari spesi per fare questo lavoro. Tutti vogliono conoscere il proprio ROI e l'impatto del lavoro sui profitti. I clic sui pulsanti non lo faranno.

Non sto dicendo di non misurare le metriche di coinvolgimento o le metriche di canalizzazione superiore, ma dovrebbero essere metriche secondarie o terziarie. Non quelli primari. Aggiungono contesto alla storia di un test. Non sono ciò su cui si basano i test quando arriva il momento di prendere una decisione. Nota, inoltre, non sto dicendo che non ci siano mai eccezioni. Valuta comunque i test caso per caso.

Un consiglio: a coloro che discutono di questo argomento tra di voi, dico sempre ai team di discutere le opzioni e decidere da soli. Assicurati solo di giungere a una conclusione collettiva che tutti rispettano andando avanti.

Passaggio 2: ricerca e ideazione dell'utente

A questo punto, dovresti (1) sapere di avere un volume di dati sufficiente per testare e (2) sapere cosa stai misurando e che stai raccogliendo dati corretti di cui ti puoi fidare. Allora, qual è il prossimo? Sta arrivando con cosa testare. Quali sono le tue idee per i test? Come li genererai?

Indovina cosa fa la maggior parte delle squadre? Escono da sentimenti istintivi e un sacco di "pensiamo", "sentiamo" e "crediamo". È troppo soggettivo ed è un modo terribile di eseguire un programma. Questo approccio non è affatto supportato da dati. È quello che i praticanti chiamano "spaghetti testing" ovvero lanciare roba contro il muro sperando che si attacchi. Le conversazioni basate sui dati non coinvolgono gran parte di quel tipo di linguaggio e i dati necessari provengono dalla ricerca degli utenti. Mi viene sempre chiesto cosa significhi "ricerca".

Bene, ci sono diverse metodologie che raccolgono dati inclusi ma non limitati a analisi, sondaggi, sondaggi, test degli utenti, test dei messaggi, mappe di calore, registrazioni delle sessioni, ordinamento delle carte, test degli alberi, mappatura del percorso del cliente, personaggi e molti altri. Ci sono anche diversi strumenti per aiutarci a completare ognuno di questi. Dico sempre di iniziare con uno o due e di arrivare ad altri da lì. Questo è sicuramente meglio di niente. Tecnicamente, in realtà non conto più l'analisi perché ogni azienda ha dati di analisi in questi giorni. Se non ce l'hai, probabilmente hai pesci più grandi da friggere. Se ce l'hai, però, sforzati per uno o due anche oltre (e non dire "oh, allora siamo bravi").

Esiste una metodologia chiamata valutazione euristica. Questo è quando qualcuno valuta visivamente un'esperienza e sviluppa intuizioni basate sulla loro esperienza e competenza. C'è un tempo e un luogo per farlo, ma la maggior parte delle volte non è supportato da “dati concreti”. È abbastanza soggettivo e sarà diverso in una certa misura a seconda di chi lo completa. Sappi che il tuo programma non dovrebbe essere basato su questo tipo di intuizioni.

Non tratterò qui come fare ricerche in dettaglio, ma puoi dare un'occhiata a uno dei miei webinar VWO qui dove parlo di più sul modello ResearchXL di CXL.

Passaggio 3: assegnazione delle priorità

Una volta che hai un elenco di idee per i test, non puoi farle tutte in una volta. Hai bisogno di un modo strategico e logico per creare un piano d'azione. È qui che entrano in gioco i quadri di definizione delle priorità. Esistono molti. Mi piace uno in particolare: il framework PXL di CXL. Altri comuni includono PIE, ICE o PILL. Il PXL è il più obiettivo secondo me. È personalizzabile e più robusto (in senso buono).

Altri modelli vanno bene e meglio di niente. Se hai qualcosa e funziona per te, bene. Basta averne uno e assicurarsi che tutti lo stiano usando! Ti salva dall'affrontare il caos extra.

Passaggio 4: tabella di marcia

Le roadmap mostrano visivamente cosa è in esecuzione in un dato momento. Combina la tua definizione delle priorità e i calcoli pre-test e boom. Hai una tabella di marcia. Questi sono fatti meglio nei diagrammi di Gantt. Aggiungi tutte le tue swimlane e test con durate stimate, dispositivi e altri metadati utili. Eviterai sovrapposizioni indesiderate ed effetti di interazione indesiderati. Aiuta tutti a pianificare in modo molto più efficace ed efficiente. Questo ti salverà da più caos.

Passaggio 5 e oltre: Business as usual

Ora che tutto ciò che abbiamo trattato è fuori mano, è tutto come al solito. Hai un test a portata di mano che stai per eseguire. Lo invii attraverso il normale flusso di lavoro dell'esperimento: mockup > progettazione > sviluppo > QA > lancio > monitoraggio > conclusione > analisi > condivisione e archiviazione > ripetizione.

Argomenti correlati: Gestione e governance del programma

Al di fuori dei singoli test, ci sono altri argomenti da considerare in relazione a un intero "programma". Questi includono la gestione e la governance del programma. Ecco come li penso in un modo molto ridotto...

Gestione del programma: come organizzerete e terrete traccia di tutto questo lavoro? Scopri quali strumenti utilizzerai per le attività, la gestione dei dati e la comunicazione. (Ho avuto quel guasto da Ben Labay, CEO di Speero.)

Governance: quali ruoli e responsabilità hanno tutti? Un modo utile per determinarlo è (1) scegliere un modello di governance e (2) completare un grafico RASCI allineato con il modello di governance. Modelli di governance comuni da esaminare e considerare: individuale, centralizzato, decentralizzato, centro di eccellenza, consiglio di test e ibridi.

Se non inchiodi entrambi con tutto il resto, sarà un ulteriore caos e lo pagherai in ogni fase del percorso. Inchioda questi. Ci vuole più tempo, ma ne vale la pena. Se ti fai strada tra le cose per un po', le conseguenze alla fine ti raggiungeranno. Prometto. (Apparentemente, ho fatto parecchie promesse qui.)

Conclusione

Dovresti sentirti un po' (o molto) più sicuro di quello che puoi fare per iniziare la sperimentazione o di quello che puoi fare per far salire di livello il tuo programma che è già in esecuzione. Non pensare che sia troppo difficile o troppo facile. Di solito è da qualche parte nel mezzo. La mia più grande raccomandazione applicabile a tutto ciò che ho menzionato: avere un quarterback. Avere qualcuno che guida tutto questo lavoro. Non deve essere il loro ruolo a tempo pieno, ma qualcuno dovrebbe possederlo. Di solito è quando ho visto il maggior successo.

Per concludere, spero che tu abbia un programma di sperimentazione pieno di rigore, risultati e un po' di divertimento. Alla fine, è un lavoro divertente ed entusiasmante che può fare un'enorme differenza per un'azienda.

Se vuoi saperne di più su come la sperimentazione guida l'innovazione e la crescita e vale tutto il clamore, guarda il mio ultimo webinar con VWO.