1. En vinnende test er ikke i seg selv bedre enn en tapende test
Bare 12 % av eksperimentene gir en statistisk signifikant forbedring på den primære metrikken. Det er omtrent like sannsynlig at team ser et negativt resultat som et positivt.
Optimizelys kunder ser at hvert omsetningsfokuserte eksperiment i gjennomsnitt gir en inkrementell løft på 0,4 % i digital omsetning når resultatene brukes, forbedres og bygges videre på. En vinnerrate på 12 % kombinert med 0,4 % løft per vinner, anvendt konsekvent, gir kumulativ forbedring over tid.
Bildekilde: Optimizely
Hvis ni av ti tester vinner, er noe galt. Enten er kontrollen svak, metrikken er for vid, eller testene avsluttes i det øyeblikket de viser grønt. De fleste ideer overlever ikke møtet med brukerne, og slik bør det være.
Forankre verdien av eksperimentering i løft over tid, ikke i antall seire per kvartal.
De fleste tester mislykkes. Eksperimentering fungerer. Det er paradokset og poenget.
2. Knytt hvert eksperiment til et forretningsmål – ellers risikerer du at det blir ignorert
Programmer i tidlig fase har gjerne de samme tre problemene.
Eksperimenter som flytter sidenivå-metrikker ledelsen aldri ser på, resultater som diskuteres men aldri handles på, og en verdihistorie som er umulig å kommunisere – slik at suksess forblir i siloer i stedet for å skape momentum.
Løsningen er å gjøre koblingen eksplisitt. Hvert eksperiment forankret i et mål virksomheten allerede bryr seg om. Resultater målt konsekvent. Eksperimentering behandlet som et beslutningssystem i stedet for et sideprosjekt.
Bildekilde: Optimizely
Du kan kjøre statistisk perfekte eksperimenter og likevel slite med å forklare hvorfor noen bør bry seg. Det er slik programmer mister finansiering selv når arbeidet er godt.
3. Definer hva godt ser ut for programmet, ikke bare for testen
De fleste team måler enkelttester og antar at programmet er sunt hvis nok tester kjører. Det er det ikke.
Et fungerende program trenger egne suksesskriterier, uavhengig av enkeltresultater:
- Tester du ofte nok?
- Tester du godt?
- Er endringene betydelige nok til å flytte forretningen?
- Deler du det du lærer på en måte folk kan handle på?
Disse fire spørsmålene står over spørsmålet om hvorvidt en enkelt test vant, og programmene som kan svare på dem beholder plassen sin ved bordet når budsjettene strammes inn.
4. Kan du ikke spore en test tilbake til North Star, mangler det forankring
Sterke programmer bruker et trelags hierarki.
-
Én enkelt North Star på toppen: resultatet virksomheten til syvende og sist styrer mot, som omsetning, retensjon eller kundens livstidsverdi. Det er retningen, ikke metrikken du tester mot. Hvis hvert eksperiment skal flytte denne metrikken direkte, brukes North Star feil.
-
Tre til fem strategiske metrikker i midten: spakene ledelsen allerede bruker for å vurdere ytelse. Konverteringsrate, anskaffelseseffektivitet, gjennomsnittlig ordreverdi, funksjonsadopsjon.
-
Optimaliseringsmål nederst: brukeratferden et enkelt eksperiment kan påvirke direkte. Legg-i-handlekurv-rate, frafall ved levering, fullføring av registrering.
Hvert eksperiment bør klatre tydelig fra et optimaliseringsmål til en strategisk metrikk til North Star.
Bildekilde: Optimizely
Velg et hvilket som helst aktivt eksperiment og spør eieren hvilken strategisk metrikk det støtter og hvordan. Hvis svaret er uklart, gjør ikke måltreet jobben sin.
5. Hastighet, kvalitet og omfang – mål alle tre
Hastighet er viktigst i starten, når flaskehalsen er frekvens og teamet fortsatt lærer seg å levere tester pålitelig.
Medianbedriften kjører 34 eksperimenter i året. De øverste 3 % kjører over 500.
Bildekilde: Optimizely
For å være blant de 10 % beste på eksperimenteringshastighet, må bedrifter kjøre rundt 200 tester årlig.
Bildekilde: Optimizely
Volum er måten du gjør uforutsigbare enkeltresultater om til pålitelig forbedring på programnivå, fordi de fleste eksperimenter ikke gir en statistisk signifikant seier, og fremgang kommer av å teste ofte nok til at seire kan oppstå.
Men hastighet alene gir samme forretningseffekt til dobbel kostnad når et program skalerer. Teamene som fortsetter å vokse, måler to ting til i tillegg.
Kvalitet gjenspeiler om du beveger deg forbi enkle A/B-tester mot rikere tilnærminger. Eksperimenter med fire variasjoner leverer 3,5x den forventede effekten av en typisk A/B-test. Programmer som aldri går videre fra A/B-testing, lar dette løftet ligge på bordet.
Omfang gjenspeiler om du tester endringer som er betydelige nok til faktisk å påvirke brukeratferd. Lavthengende frukt tar slutt. Varig effekt krever testing på tvers av flere sider, flere brukerreiser og flere typer endringer. Eksperimenter som kombinerer tre eller flere endringstyper gir de sterkeste resultatene.
Hvis volumet ditt øker, men de fleste testene fortsatt sammenligner A mot B på de samme få sidene, blir programmet travlere uten å bli bedre.
6. Et program er en livssyklus, ikke en kø
De fleste programmer kjøres som en kø. Ideer sendes inn, tester bygges, resultater arkiveres, og nye ideer sendes inn. Arbeidet fortsetter, men ingenting mellom stegene henger sammen.
En livssyklus har seks faser, og hver enkelt gir næring til den neste.
- Hypoteseutvikling
- Prioritering
- Planlegging og design
- Gjennomføring og overvåking
- Analyse og tolkning
- Utrulling og iterasjon
Bildekilde: Optimizely
Analyser fra forrige kvartal former hypotesene som genereres dette kvartalet. Prioriteringen endres når en utsjekkingstest lærer teamet noe om leveringsgebyr. Utrulling blir input til neste eksperiment, ikke slutten på dette.
Det er slik et team slutter å kjøre eksperimenter og begynner å bygge en eksperimenteringskapabilitet. Mekanikken i en enkelt test betyr mindre enn om sløyfen lukkes.
7. Start med problemet, ikke ideen
De fleste eksperimenter mislykkes i hypotesefasen, lenge før gjennomføring eller analyse.
«Vi bør prøve en lengre overskrift» er en løsning som leter etter et problem.
«Brukerne forstår ikke hvordan leveringsgebyr fungerer før det siste utsjekkingssteget, og 25 % av spurte brukere sier at det er grunnen til at de forlot» er et problem som er spesifikt nok til å bygge en test rundt.
Problem-Solution-Result-rammeverket (PSR) opprettholder denne disiplinen: et validert bruker- eller forretningsproblem, en foreslått endring for å løse det, og et målbart utfall som indikerer suksess.
Bildekilde: Optimizely
En sterk problembeskrivelse er brukersentrert, evidensbasert, spesifikk men ikke foreskrivende om løsningen, og relevant nå. Hopper du over dette, tester du meninger.
8. Test tre til fem løsninger per problem, ikke bare én
Et team som kjører A mot kontroll, satser én gang per problem. Et team som kjører tre til fem variasjoner, tester om noen av flere tilnærminger løser problemet.
Det forbedrer mer enn sjansene dine. Det endrer hvordan teamet jobber. Risikoviljen øker fordi tryggere alternativer er dekket. Eierskapet utvides fordi flere bidragsytere ser ideene sine testet. Teamet utforsker flere retninger samtidig i stedet for å forplikte seg til én vei og vente ukesvis for å lære at den var feil.
Testing av 4+ variasjoner endrer teamatferd:
- Risikoviljen øker fordi trygge alternativer er dekket.
- Eierskapet utvides fordi flere bidragsytere ser ideene sine testet.
- Smidigheten øker fordi teamet utforsker flere retninger samtidig.
9. Backloggen din er enten et prioriteringsverktøy eller en unnskyldning
Alle programmer har flere ideer enn kapasitet. Uten en felles prioriteringsmodell vinner den høylytte interessenten, og backloggen begynner å ligne organisasjonskartet.
RICE (reach, impact, confidence, effort) er det vanlige valget fordi det tvinger fire avveininger inn i én sammenlignbar poengsum.
Bildekilde: Optimizely
En utsjekkingsflyttest kan score høyt på reach og impact, men kreve ukevis med engineering. En tekst-test på prissiden kan score lavere på impact, men høyere på confidence og langt lavere på effort. RICE gjør avveiningen eksplisitt, slik at prioriteringen drives av felles kriterier i stedet for hastverk eller hierarki.
Poengsummen er ment å starte samtalen, ikke avslutte den. Når det samme teamet scorer ideer på samme måte over tid, blir backloggen et levende bilde av eksperimenteringsstrategien. Hva som testes nå, hva som kommer neste, og hvilke usikkerheter organisasjonen har valgt å løse i hvilken rekkefølge.
Fem ting å unngå:
- Å blåse opp impact for å presse ideer gjennom
- Å behandle confidence som intuisjon i stedet for evidens
- Å ignorere begrensninger i reach
- Å undervurdere effort ved å utelate QA og analysearbeid
- Å behandle poengsummen som det endelige svaret i stedet for et rangert utgangspunkt
10. Hvert eksperiment bør gjøre det neste smartere
Et program gir kumulativ effekt når resultater aktivt former fremtidige beslutninger. Bevisste mekanismer gjenbrukes, motbeviste antakelser sluttes å retestes, og tillit bygges gjennom evidens i stedet for å nullstilles til intuisjon hver syklus. Tidligere eksperimenter refereres under idéutvikling og planlegging, ikke bare i den kvartalsvise gjennomgangen.
Når den sløyfen fungerer, blir eksperimentering en delt, evidensbasert forståelse av hvordan brukere oppfører seg, som informerer alle beslutninger – ikke bare de som testes. Når den ikke fungerer, produserer eksperimentering dokumentasjon i stedet for fremgang.
To ting må stemme:
1. Ikkeavgjørende resultater må behandles som læring
Et sunt program har en konklusjonsrate på 35–40 %, noe som betyr at omtrent 60 % av testene ikke gir en klar seier eller tap. Det nyttige spørsmålet etter en ikkeavgjørende test er hva som gikk galt med deteksjonen, ikke med ideen.
- Var utvalgsstørrelsen for liten?
- Var metrikken for langt nedstrøms fra endringen?
- Var kontrasten mellom variasjonene for tynn?
2. Læring må være søkbar
De fleste team klarer ikke å opprettholde dette manuelt når testvolumet vokser. Innsikt begraves, og forskjellige team retester den samme hypotesen uten å vite det. Hos Optimizely utgjør eksperimentering nå 58,74 % av all Opal-agentbruk, og 19,54 % av oppfølgingstestene drives av agentanbefalinger forankret i tidligere resultater. Agenter refererer teamets eksperimenter, resultater og flagg, og viser hva som er prøvd før en ny hypotese skrives.
Hvis du ikke tydelig kan si hva det forrige eksperimentet lærte deg og hvilket nytt spørsmål det neste skal besvare, itererer du ikke. Du bare endrer ting.