5 lezioni che ho imparato (nel modo più duro) in CRO

Avvicinandomi a un anniversario che commemora il tempo che ho trascorso nella gloriosa arena dell'ottimizzazione del tasso di conversione sotto l'egida di un'agenzia PPC stellare (#8 nell'elenco dei migliori luoghi di lavoro di AdAge), ho voluto condividere questo piccolo angolo di Interwebs alcune lezioni chiave con tutti voi. Come mai? Perché sono un agente. Imparo facendo. Quindi, tendo a sbagliare. Consolida la mia conservazione della lezione, ma a volte non è necessario commettere errori. Per quelli di voi abbastanza fortunati da imparare efficacemente per procura, impara dai miei errori e previeni i tuoi! Perché fidati di me, quando commetti questi errori generalmente abbracci lo sguardo della vergogna; occhi rivolti verso il basso e tutto il resto.

#1 Limite di rischio

Sono orgoglioso di essere una di quelle persone che deve fare TUTTE le ricerche prima di svolgere qualsiasi compito; nella vita, in CRO, lo chiami. Tuttavia, quando sono entrato per la prima volta in CRO ho anche creduto che avesse senso testare il 100% del mio traffico subito fuori dal cancello.

Non importa quanti dati metti dietro a una raccomandazione di test e quanto tempo dedichi al QA, ci sono sempre variabili di cui potresti non essere a conoscenza e quindi incapace di controllare. Uno di questi potrebbe uscire dal campo sinistro e sbattere il tuo test e il tuo tasso di conversione direttamente nelle metriche a livello di pavimento. Nessuno vuole sperimentarlo.

Quando avvii un test di qualsiasi capacità, limita il traffico per i primi giorni mentre controlli attentamente tutto per assicurarti che il test funzioni senza intoppi. Vogliamo interrompere il traffico per natura. Ci sforziamo di ottimizzare le prestazioni di quel traffico. Ma se va a sud rapidamente, non c'è alcun argomento logico che tu possa sostenere per mantenerlo in funzione nella speranza che si presenti a destra. Non accadrà in modo affidabile e coerente e staccare la spina in anticipo è meglio che costringere quel traffico e il sito a soffrire mentre trattieni il respiro e speri per il meglio.

#2 I dati sono tuoi amici

L'esperienza è un insegnante a tutto tondo, ma in un settore in continua evoluzione che si basa sul comportamento umano il tuo istinto e la tua esperienza potrebbero non essere le basi più affidabili su cui stare. I dati (preferibilmente quantitativi) sono radicati e solidi e ti consentiranno di radicare te stesso e i tuoi sforzi di test.

Prometto di non darti lezioni di pregiudizio, ma affermerò che sei di parte e che dovresti venire a patti con questo prima o poi. Potresti odiare assolutamente un elemento specifico di un sito o il suo funzionamento. Quell'elemento potrebbe non avere senso per te, ma potrebbe essere completamente intuitivo per i tuoi utenti. Supporre che la tua esperienza sia simile o identica a quella di tutti gli altri su quel sito è noto anche come effetto del falso consenso.

Lascia che siano i dati a parlare e cerca di non mettere la tua lente personale su quei dati. Se aiuta, cerco di pensare a ogni analisi dei dati come un'esperienza di apprendimento. Dimostra che ho torto. Riportiamolo al punto di partenza del metodo scientifico: formulare un'ipotesi, quindi provare a confutare la propria ipotesi.

#3 Impara l'espressione regolare

Non posso dirti quante volte non sono riuscito a catturare tutto il traffico verso una pagina di ringraziamento perché avevo un obiettivo di destinazione molto specifico impostato per corrispondere a un URL. Ci sono molti modi in cui chiunque può aggiungere un parametro all'URL che stai monitorando e se nessuna di queste persone ti collega, il tuo obiettivo non è valido. Se hai copiato l'URL in modo errato, il tuo obiettivo non sarà valido.

Per eliminare la maggior parte delle minacce che cercano di invalidare il monitoraggio degli obiettivi, isolare le parti critiche di quell'URL e unirle utilizzando le espressioni regolari.

RegexBuddy descrive amorevolmente le espressioni regolari come "caratteri jolly su steroidi". Il linguaggio è piuttosto robusto e puoi diventare molto granulare usando regex, ma io uso 3 simboli in totale: .,*, +.

• “.” – carattere jolly che rappresenta un carattere (usato come “*” in excel con limitazione di portata)
• “*” – qualifica il carattere jolly per includere 0 o più caratteri
• “+” – qualifica il carattere jolly per includere 1 o più caratteri

Immagina che la pagina di ringraziamento in cui vogliamo monitorare i risultati sia la seguente: www.ppchero.com/thank-you

Sai che qualcuno terrà traccia della sorgente di traffico tramite parametri, quindi sappiamo già che la gente potrebbe arrivare su un URL con ogni sorta di imbrogli che seguono "grazie".

Userei la seguente espressione per tenere traccia di questo URL:

NON dimenticare il menu a tendina.

Nota che ho sostituito ogni simbolo nell'URL con "." perché "." è un jolly e, come ho detto prima, mi piace sapere cosa sta facendo ogni personaggio. Non sono un esperto di regex ma so che tecnicamente è un linguaggio e ha la capacità di interpretare molti caratteri ed eseguire funzioni basate su quei caratteri. Non corro rischi in regex. I caratteri jolly sono sicuri.

Se sei ancora confuso o desideri approfondire le regex, ecco un sito molto informativo: RegexOne

Mentre pratichi le tue abilità, ricontrolla le tue frasi per la funzionalità completa con questo sito: Regex Tester

# 4 C'è sempre un catalizzatore per il tuo problema. O 2. O più...

Prestare molta attenzione quando si assume che qualsiasi variabile singolare sia responsabile di un problema.

Questo sembra controintuitivo per testare perché si cerca di controllare ogni variabile oltre l'alterazione di garantire somiglianza e può attribuire prestazioni a quella modificazione. Tuttavia, il "tentativo" è fondamentale lì. Ci sono troppe variabili coinvolte in tutto ciò che facciamo e potresti non essere sempre in grado di trovare tutte le variabili che hanno influenzato le tue prestazioni.

Ad esempio, mentre cercavamo un catalizzatore responsabile di un calo irregolare del tasso di conversione sui dispositivi mobili, abbiamo scoperto diversi fattori chiave su una sequenza temporale simile e nessuno di essi poteva essere ignorato.

1. La spesa in AdWords per campagne specifiche è stata anormalmente bassa, il che indica che non eravamo così diffusi come pensavamo di essere nelle SERP.
2. Il sito mobile è un sito desktop responsive che molto probabilmente aveva raggiunto la fine della sua efficacia nell'era dei siti mobile altamente funzionali e attraenti.
3. Anche i concorrenti in quel settore erano diventati sempre più diffusi e stavano diventando più competitivi nello spazio PPC e nello spazio dell'esperienza utente.

Tutti questi sono critici e sicuramente hanno un impatto sul tasso di conversione. Tutto in una volta? Forse no. Tuttavia, i problemi complessi sono ancora problemi.

Non considerare mai un problema completamente risolto (a meno che tu non sia sicuro di aver causato il problema). Tieni sempre occhi e orecchie aperti e chiediti se le anomalie potrebbero aver lavorato insieme per causare il tuo problema. Continua a scavare.

Inoltre, tieni presente che mentre la maggior parte del nostro lavoro vive su Internet, la vita delle persone no. Tutto ciò che i nostri utenti vedono, sentono o anche odorano possono influenzare il tuo tasso di conversione se raggiunge una parte significativa del tuo traffico.

#5 QA Test della tua pagina di destinazione

Questo è un passaggio fondamentale nel processo di configurazione del test e come tale tende a passare in secondo piano quando la tua fiducia personale riguardo al test inizia ad aumentare (o sono solo io? Bueller?).

Sia che tu stia testando per il tuo sito o per il sito del tuo cliente, dovresti sempre essere consapevole di come si presenta il tuo test. In un mondo ideale, testeremmo su ogni singolo browser (comprese le varie dimensioni del browser) e sistema operativo. Tuttavia, la maggior parte di noi non ha quel tipo di tempo a disposizione. Per scendere a compromessi, prova sui browser e sui sistemi operativi utilizzati dalla maggior parte del tuo traffico.

Non dimenticare mai questo passaggio. Il messaggio peggiore che puoi ricevere, il più indotto dalla "coda tra le gambe", è il messaggio con lo screenshot del rendering del tuo test in un formato molto involontario. Anche se cambi il colore di un pulsante, QA che assurdità. Non si è mai troppo al sicuro, vero?

Saresti anche stupito di quante volte scopro che browser casuali hanno gravi difficoltà a rendere correttamente la variazione. Non privare gli utenti del tuo browser di nicchia di esperienze esteticamente piacevoli o funzionali semplicemente perché non volevi passare il tempo in QA.

Pensieri finali

• Limita i rischi per le prestazioni limitando il traffico che scorre attraverso i tuoi test nei primi giorni (quando puoi).
• Costruisci una base affidabile di dati da cui puoi prendere decisioni che non sono influenzate dalla tua esperienza.
• Impara l'espressione regolare. Ti prometto che sarà utile se scegli come target qualcosa tramite URL.
• Ogni problema ha una solida gamma di catalizzatori. Dai loro la caccia e tieni d'occhio i ritardatari.
• Assicurati di sapere cosa vedono gli utenti. Senti i loro sentimenti. Vivi il sito come farebbero loro. Empatizzare! E non dimenticare quelli che utilizzano browser “strani” o poco conosciuti.

Quando ti ecciti e diventi un po' matto, fai un passo indietro, respira e ricorda che hai capito perfettamente e che non devi ripetere gli errori da novellina di Kate Wilcox perché hai letto questo articolo e hai imparato per procura.

Se ritieni di aver commesso un errore o ti piacerebbe semplicemente condividere una storia "Ci sono stato", contattaci via Twitter (@katewilcoxkcco) e rendimi felice la giornata.