Do’s and Don’ts til jeres nye test program

Igennem de sidste par år har fokus – når det gælder udviklingen af ‘web analytics’ – været på rapportering (implementering og opsætning af rapporter i SiteCatalyst). Men det er min helt klare opfattelse at flere virksomheder er begyndt at flytte fokus over på optimering af sitet via A/B test, MVT test, samt targeting.

Der er ikke nogen tvivl om at ligemeget hvilket værktøj du benytter – om det er Test&Target, Google Analytics Content Experiements, Myna, Optimizely, Monetate, Visual Website Optimizer, etc. – så ligger der utrolig meget teori og ikke mindst ‘best practices’ bag. Uden nogen større erfaring er det nærmest en umulig opgave at få et succesfuld test/optimerings program op at køre. Fejlen som mange typisk begår at de gaber over for meget, resultaterne bliver sværere at tyde, og pludselig kræver det for meget arbejde ved kun en enkel test. Hvorefter brugen af f.eks. Test&Target stille og rolig falder.

Med dette indlæg vil jeg komme med nogle simple Do’s and Don’ts til dig der er igang med at opbygge et test program i organisationen. At starte korrekt og sætte scenen til succes er alfa omega, hvis du ønsker at opbygge et effektivt program og samtidig sikre at du får den rigtige og ikke mindst, den mest optimale værdi ud af det. Nedenstående Do’s and Don’ts vil uden tvivl give dig en god start hvis du er ved at starte et test program for første gang. Sidder du i et team og allerede følger et test program, så vil rådene også gælde for dig. Uden at træde nogen over tæerne, så har du/i uden tvivl også lavet nogle af disse fejl i begyndelsen, uden at få rettet op på dem igennem årene.

DO – Tag en intern diskussion omkring én succes metric
Den allerførste og uden tvivl også den sværeste forhindring som et optimerings program møder er at få grupper og afdelinger til at blive enige om hvordan programmet skal køres. Typisk er det fordi at afdelingerne har forskellige mål og selvfølgelig kun har fokus på deres lille brik i det store puslespil. Hvis du ikke ønsker at tage mange interne kampe, så er det i denne du skal ligge dine kræfter. Hvis i først kan blive enige om den ene (1) succes metric som i alle kan tage actions på, så er du kommet rigtig langt.

En af fordelene ved at tage denne diskussion er at folk fra de forskellige afdelinger helt automatisk vil begynde en process hvor de gennemgår handlinger på sitet som de tror fører til succes på sitet. Alt for mange tror fejlagtigt at det handler om at måle actions på sitet i stedet for at fokusere på hvad det egentlige formål med testen er. Du har måske en idé……nej, din kollega har en idé om at hvis I får flere til at kigge på produkt X, så vil i også øge jeres omsætning. Mange vil derfor fejlagtigt mene at succes metric for testen er at få flere til at kigge på produkt X. Men ved at sætte succes metric’en til hvor mange der har kigget på produkt X, så måler du actions i stedet for det egentlige mål. Det egentlige mål er at øge omsætningen og når først det bliver det eneste mål, så kan i sammen begynde at kigge på hvilke måder I bedst kan nå lige præcis det mål.

DON’T – Tro ikke at hver test kræver at IT skal involveres
Alle værktøjer kræver en eller anden form for implementering, nogen mere end andre, men en af de større fejl du kan lave er at tro hver test vil kræve store ressourcer fra din IT afdeling. Hvis du sørger for at ligge lidt tanker bag hvordan det skal implementeres fra start (evt. med input fra en konsulent som er ekspert i dit værktøj) så kan du faktisk nøjes med kun at have udviklere ind over én gang.

At teste skal ikke opfattes som et projekt der har en start og en slut, men bør i stedet være en konstant proces som er en del af din organisation og feature på sitet. For at maksimere dette så kræver det at planen du ligger for implementeringen ikke har fokus på, at det blot handler om at validere nogle enkelte idéer. Men at du i stedet har gjort dig nogle tanker om hvilke af jeres top sider der skal testes på, samt hvilke succes metrics der er de vigtigste. Dermed sikrer du også at IT forstår at det ikke bliver et projekt de er nødt til at tage ejerskab på, da de ikke er nødvendige ved hver test.

DO – Kill your Darlings
Hvis du ikke er bekendt med begrebet “kill your darlings”, så er det helt sikkert på tide at blive det nu. Begrebet stammer fra Arthur Quiller-Couch, der i sin undervisning som professor i engelsk på Cambridge University i England, indførte begrebet ‘murder your darlings‘. Det er i nyere tid blevet til ‘kill your darlings’, men budskabet er det samme.
Essensen i begrebet handler om at de idéer, du selv synes er geniale, kan være til mere skade end gavn, og du gør klogt i at aflive dem – selvom det gør ondt langt ind i sjælen på dig. Dine darlings (dine test idéer) er der i virkeligheden for din egen skyld, og ikke dine modtagers; derfor er de farlige! Når det omhandler test programmet, så er det ikke kun dine egne darlings du bliver nødt til at tage livet af. Du vil helt sikkert modtage en masse test idéer som er baseret på hvad folk tror der virker, så der må du påtage dig rollen som bøddel – eller stille de rigtige test spørgsmål!

En af de mindst vigtige punkter i dit test program er rent faktisk at genere test idéer. Det er en af de sjove processer da alle er interesseret i at køre en test der bekræfter dem i at det de tror rent faktisk holder vand. Men nøglen til succes er ikke at have en masse idéer, men istedet at opbygge en infrastruktur samt indføre og forstå den disciplin det kræver at opnå succes med dine test. Test idéer kommer helt naturligt via daglige diskussioner i teamet, men vigtigere endnu så kommer de fra forrige test og den viden man har fået fra dem. Den største fejl du kan lave er at basere en masse test på dine teorier (eller andres teorier – kill your darlings). Sker det først så vil dit ego kollidere med din analyse af test resultatet. I stedet så tag udgangspunkt i noget konkret som er bakket op af data du har indsamlet – mest oplagte er resultatet fra en tidligere test.

DON’T – Et test program er ikke en forlængelse af jeres web analytics
Den måde du skal se på jeres optimering af sitet er næsten præcis det modsatte af jeres analytics. I stedet for mønstre og uregelmæssigheder i store data sets, så har du nu kun et punkt du fokuserer på.

For at få succes er du også nødt til at tænke anderledes når det gælder segmentation. Du er nødt til finde ud af hvad en succes metric egentlig er og hvordan den er anderledes når det gælder test. Ligeledes så skal dit fokus være på analyser hvor du sammenligner, i stedet for validering. Typisk, når du har implementeret en ny side med f.eks. SiteCatalyst, så er dit fokus på at det er korrekt implementeret og at data helst skal være 100% præcist. Med dit optimerings program er du nødt til at give slip på den holdning.

Jeg oplever tit at mine kunder helst vil validere data i Test&Target ved at sammenligne det med SiteCatalyst – hvilket du ikke bør gøre, da data ikke vil stemme 100%. Der er flere grunde til dette og uafhængigt af hvilke værktøjer du benytter så vil du med stor sansynlighed opleve det samme på tværs af alle værktøjer. Data i dit test værktøj og dit web analyse værktøj kommer ikke til at stemme overens, men det betyder ikke at du ikke kan bruge det. Blot at du ikke bør lave nogle dybe analyser på dit test data i dit web analyse værktøj (f.eks. SiteCatalyst). Det betyder ikke at du ikke kan gøre det, men du bør ikke ligge ud med det fra begyndelsen. Her bør du i stedet holde det simpelt og derfor ikke begynde at blande data. Hold det adskilt og det vil give dig langt større værdi med langt mindre arbejde.

DO – Overvej hvordan du vil gemme og dele resultaterne
Når først du begynder at teste korrekt, så vil du konstant lære nye ting og de erfaringer du vil få kan gå hen og blive langt mere værdifulde end de enkelte resultater. Du er derfor nødt til at gøre dig nogle overvejelser omkring hvor du vil dele denne information, formatet og tilgængeligheden. Og ligeledes sikre at det ikke bliver et statisk dokument, men en knowledge base der er levende.

DON’T – Lad aldrig en test gå live, hvis den har mindre end 2 alternativer
En af de sværeste ting at lære er at optimering ikke handler om at validere et enkelt element, men handler om at sammenligne mulige alternative og være klar til at gå i retninger du aldrig havde forestillet dig. Det er ikke alle som vil være klar til dette den første dag, men den letteste måde at forberede folk på dette er ved at tvinge disciplin ned over dem. Sikre dig at der altid bliver testet minimum 3 alternativer som samtidig er meget forskellige. Det vil være med til at give dig væsentlig mere information og vil samtidig hjælpe med at finde områder, hvor folk tror de ved hvad der virker, uden at det egentlig er tilfældet.

 

Der er tusind andre ting du er nødt til at tage stilling til når du skal starte jeres optimerings program, men hvis du tager hånd om ovenstående punkter, så undgår du nogen af de mest åbenlyse faldgruber. Du vil samtidig opnå langt bedre resultater, have større indflydelse på forretningen og samtidig bruge lang færre ressourcer.
Find ud af hvad du virkelig ønsker fra jeres optimerings program og stop med at fokusere på individuelle test og i stedet fokuser på at få de vigtigste ting på plads til langsigtet succes.


Skriv et svar