5 lecții pe care le-am învățat (pe calea grea) în CRO

Apropiindu-mă de o aniversare care comemora timpul petrecut în glorioasa arena a optimizării ratei de conversie sub umbrela unei agenții PPC stelare (nr. 8 pe lista AdAge’s Best Places to Work), am vrut să iau acest mic colț al Interwebs pentru a împărtăși câteva lecții cheie cu voi toți. De ce? Pentru că sunt un făcător. Învăț făcând. Astfel, tind să greșesc. Îmi solidifică reținerea lecției, dar uneori pur și simplu nu trebuie făcute greșeli. Pentru aceia dintre voi suficient de norocoși să învețe efectiv prin indirect, să învețe din greșelile mele și să le prevină pe ale tale! Pentru că credeți-mă, atunci când faceți aceste greșeli, îmbrățișați în general aspectul de rușine; ochii întoarse în jos și tot.

# 1 Limitați riscul

Mă mândresc că sunt unul dintre acei oameni care trebuie să facă TOATE cercetările înainte de a îndeplini orice sarcină; în viață, în CRO, ce vrei să spui. Cu toate acestea, când am intrat prima dată în CRO, am crezut, de asemenea, că are sens să testez 100% traficul meu direct din poartă.

Indiferent de câte date puneți în spatele unei recomandări de testare și de cât timp alocați pentru QA, există întotdeauna variabile de care este posibil să nu le cunoașteți și, prin urmare, pe care nu le puteți controla. Unul dintre acestea poate să iasă din câmpul din stânga și să-ți trântească testul și rata de conversie direct în valori la nivel de etaj. Nimeni nu vrea să experimenteze asta.

Când lansați un test de orice capacitate, limitați-vă traficul în primele zile în timp ce monitorizați totul îndeaproape pentru a vă asigura că testul funcționează fără probleme. Vrem să perturbăm traficul prin natură. Ne străduim să optimizăm performanța acestui trafic. Dar dacă merge repede spre sud, nu există niciun argument logic pe care să-l poți menține să funcționeze în speranța că se va întoarce în sus și la dreapta. Nu se va întâmpla în mod fiabil și consecvent și să trageți din priză mai devreme este mai bine decât să forțați acel trafic și site-ul să sufere în timp ce vă țineți respirația și sperați la ce este mai bun.

# 2 Datele sunt prietenul tău

Experiența este un profesor complet, dar într-o industrie în continuă schimbare, care se bazează pe comportamentul uman, instinctul tău și experiența ta ar putea să nu fie cea mai de încredere fundație pe care să te bazezi. Datele (de preferință cantitative) sunt înrădăcinate și solide și îți vor permite să te bazezi pe tine și pe eforturile tale de testare.

Promit să nu-ți fac prelegeri despre părtinire, dar voi afirma că ești părtinitor și ar trebui să te împaci cu asta mai devreme decât mai târziu. Este posibil să urăști absolut un anumit element al unui site sau modul în care funcționează. Acest element poate să nu aibă sens pentru tine, dar poate fi complet intuitiv pentru utilizatorii tăi. Presupunând că experiența dvs. este similară sau identică cu experiența tuturor celorlalți pe acel site este cunoscută și ca efect de consens fals.

Lăsați datele să vorbească și încercați să nu vă plasați propria lentilă personală asupra datelor respective. Dacă ajută, încerc să mă gândesc la fiecare analiză a datelor ca la o experiență de învățare. Demonstreaza-mi ca gresesc. Să readucem la punctul unu al metodei științifice: formează o ipoteză, apoi încearcă să-ți infirmi propria ipoteză.

# 3 Învață Regex

Nu vă pot spune de câte ori nu am reușit să captez tot traficul către o pagină de mulțumire, deoarece aveam un obiectiv de destinație foarte specific configurat pentru a se potrivi cu o adresă URL. Există tot felul de moduri prin care oricine poate adăuga un parametru la adresa URL pe care o urmăriți și dacă niciunul dintre acești oameni nu vă accesează, obiectivul dvs. este invalid. Dacă ați copiat incorect adresa URL, obiectivul dvs. va fi invalid.

Pentru a elimina majoritatea amenințărilor care încearcă să invalideze urmărirea obiectivelor dvs., izolați părțile critice ale acelei adrese URL și combinați-le folosind expresii regulate.

RegexBuddy descrie cu dragoste expresiile obișnuite ca „judcard-uri pe steroizi”. Limbajul este destul de robust și poți deveni foarte granular folosind regex, dar folosesc 3 simboluri în total: .,*, +.

• „.” – wildcard care reprezintă un caracter (folosit ca „*” în Excel cu limitare la atingere)
• „*” – califică wildcardul pentru a include 0 sau mai multe caractere
• „+” – califică wildcardul pentru a include 1 sau mai multe caractere

Imaginați-vă că pagina de mulțumire la care vrem să urmărim accesările este următoarea: www.ppchero.com/thank-you

Știți că cineva va urmări sursa de trafic prin intermediul parametrilor, așa că știm deja că oamenii pot intra pe o adresă URL cu tot felul de șmecherii după „mulțumesc”.

Aș folosi următoarea expresie pentru a urmări această adresă URL:

NU uitați meniul derulant.

Rețineți că am înlocuit fiecare simbol din adresa URL cu „.” deoarece "." este un wildcard și, așa cum am menționat mai devreme, îmi place să știu ce face fiecare personaj. Nu sunt un expert regex, dar știu că din punct de vedere tehnic este un limbaj și are capacitatea de a interpreta multe caractere și de a îndeplini funcții bazate pe acele caractere. Nu îmi asum niciun risc în regex. Wildcardurile sunt sigure.

Dacă încă sunteți confuz sau doriți să vă aprofundați mai mult în regex, iată un site foarte informativ: RegexOne

În timp ce îți exersezi abilitățile, verifică-ți expresiile pentru funcționalitatea completă cu acest site: Regex Tester

# 4 Există întotdeauna un catalizator pentru problema ta. Sau 2. Sau mai multe...

Fiți foarte atenți când presupuneți că orice variabilă singulară este responsabilă pentru o problemă.

Acest lucru pare contra-intuitiv pentru testare, deoarece încercăm să controlăm fiecare variabilă dincolo de modificare pentru a asigura similaritatea și putem atribui performanța acelei modificări. Cu toate acestea, „încercarea” este critică acolo. Există prea multe variabile implicate în orice facem și este posibil să nu puteți găsi întotdeauna fiecare variabilă care v-a afectat performanța.

De exemplu, în timp ce căutam un catalizator responsabil pentru o scădere neregulată a ratei de conversie pe dispozitivele mobile, am descoperit mai mulți factori cheie pe o cronologie similară și niciunul dintre ei nu a putut fi ignorat.

1. Cheltuielile în AdWords pentru anumite campanii au fost anormal de scăzute, ceea ce indică faptul că nu am fost atât de răspândiți pe cât credeam că suntem în SERP-uri.
2. Site-ul mobil este un site desktop responsive care, cel mai probabil, ajunsese la capătul eficacității sale în era site-urilor mobile extrem de funcționale și atractive.
3. Concurenții din acea industrie deveniseră, de asemenea, din ce în ce mai răspândiți și deveneau mai competitivi în spațiul PPC, precum și în spațiul experienței utilizatorului.

Toate acestea sunt critice și cu siguranță au afectat rata de conversie. Dintr-o dată? Poate nu. Cu toate acestea, problemele combinate sunt încă probleme.

Nu considerați niciodată o problemă ca fiind complet rezolvată (cu excepția cazului în care sunteți sigur că ați cauzat problema). Țineți întotdeauna ochii și urechile deschiși și întrebați-vă dacă anomaliile ar fi putut funcționa împreună pentru a vă cauza problema. Continuă să sapi.

De asemenea, rețineți că, deși majoritatea muncii noastre trăiesc pe internet, viața oamenilor nu. Orice și tot ce văd, aud sau chiar miros utilizatorii noștri vă poate afecta rata de conversie dacă atinge o parte semnificativă a traficului dvs.

#5 QA Testele paginii de destinație

Acesta este un pas de bază în procesul de configurare a testului și, ca atare, tinde să treacă pe marginea drumului atunci când încrederea dvs. personală în ceea ce privește testarea începe să crească (sau sunt doar eu? Bueller?).

Indiferent dacă testați pentru propriul dvs. site sau pentru site-ul clientului dvs., ar trebui să fiți întotdeauna conștienți de cum arată testul dvs. Într-o lume ideală, am testa fiecare browser (inclusiv diferite dimensiuni de browser) și sistem de operare. Cu toate acestea, cei mai mulți dintre noi nu avem așa timp la dispoziție. Pentru a compromite, testați browserele și sistemele de operare pe care le utilizează majoritatea traficului dvs.

Nu uita niciodată acest pas. Cel mai prost mesaj pe care îl puteți primi, cel mai „coada între picioare”-inducător, este mesajul cu captura de ecran a redării dvs. de testare într-un format foarte neintenționat. Chiar dacă schimbi culoarea unui buton, QA prostia asta. Nu poți fi niciodată prea în siguranță, nu?

De asemenea, ați fi uimit de câte ori surprind browsere aleatorii care au dificultăți severe la redarea corectă a variației. Nu privați utilizatorii de browser de nișă de experiențe plăcute din punct de vedere estetic sau funcțional doar pentru că nu ați vrut să petreceți timp în QA.

Gânduri finale

• Limitați riscurile de performanță prin limitarea traficului care circulă prin testele dvs. în primele zile (când puteți).
• Construiți o bază de încredere de date din care puteți lua decizii care nu sunt părtinitoare de experiența dvs.
• Învață regex. Vă promit că va fi util dacă vizați ceva prin URL.
• Fiecare problemă are o gamă robustă de catalizatori. Vânează-i și fii cu ochii pe cei rătăciți.
• Asigurați-vă că știți ce văd utilizatorii. Simțiți-le sentimentele. Experimentați site-ul așa cum ar face-o. Empatizati! Și nu le uitați de cele care folosesc browsere „ciudate” sau puțin cunoscute.

Când te entuziasmezi și înnebunești puțin, fă un pas înapoi, respiră și amintește-ți că ai înțeles pe deplin acest lucru și că nu trebuie să repete greșelile noi ale lui Kate Wilcox pentru că ai citit acest articol și ai învățat indirect.

Dacă simți că ai încălcat o greșeală bună sau pur și simplu ți-ar plăcea să împărtășești o poveste „Am fost acolo”, contactează-te prin Twitter (@katweilcoxkcco) și fă-mi ziua.