Konverteringsoptimalisering (CRO): En praktisk guide

Konverteringsoptimalisering (CRO) er det systematiske arbeidet med å øke andelen besøkende som utfører en verdifull handling på nettstedet ditt, ved å finne ut hvorfor de ikke gjør det og fikse det. Det er hele ideen. Alt annet i denne guiden er metode: hvordan du finner de egentlige årsakene, hvordan du bestemmer hva du skal fikse først, hvordan du vet om en endring fungerte, og hvordan du fortsetter uten å lure deg selv.

Dette er en generell guide. Prinsippene gjelder like mye for en nettbutikk som for et B2B-programvareselskap, men vi bruker ekstra tid på situasjonen de fleste guider hopper over: nettsteder med moderat trafikk, lange salgssykluser og konverteringer med svært ulik verdi. Uansett hva du kaller det, er faget det samme.

Hva konverteringsoptimalisering egentlig er

En konvertering er enhver handling du vil at en besøkende skal gjøre: et kjøp, en demoforespørsel, en registrering for prøveperiode, et abonnement på nyhetsbrev. Konverteringsraten er andelen besøkende (eller økter) som fullfører den:

Konverteringsrate = konverteringer / besøkende × 100

Eksempel: en landingsside får 18 400 økter i løpet av en måned og gir 460 registreringer. 460 / 18 400 = 0,025, så konverteringsraten er 2,5 %. Hvis en endring løfter den til 3,0 % med samme trafikk, får du 552 registreringer: 92 flere i måneden uten å kjøpe et eneste ekstra klikk. Det er et relativt løft på 20 %, eller et absolutt løft på 0,5 prosentpoeng. Si alltid hvilket du mener; å blande dem er den vanligste rapporteringsfeilen i CRO. Du kan regne på dine egne tall i konverteringsratekalkulatoren.

To beslutninger skjuler seg i den formelen. Den første er nevneren: økter blåser opp grunnlaget for nettsteder med mange tilbakevendende besøkende, brukere undervurderer det hvis sporingen din ikke kan fjerne duplikater på tvers av enheter. Velg én og hold deg til den. Den andre er telleren: hvilken konvertering som teller.

Makro- og mikrokonverteringer

• Makrokonverteringer er handlingene virksomheten finnes for: en bestilling, en demoforespørsel, en betalt plan.
• Mikrokonverteringer er stegene som leder dit: legge i handlekurven, begynne på et skjema, se på priser, se en produktvideo, klikke på en CTA.

Mikrokonverteringer er viktige av to grunner. De viser hvor lekkasjen er (besøkende ser prisene, men klikker aldri på «Kom i gang»), og de skjer mye oftere enn makrokonverteringer, noe som gjør dem testbare på nettsteder der makrokonverteringen er for sjelden til å måles. Mer om det i avsnittet om lav trafikk.

Hva CRO ikke er

• Det er ikke testing av knappefarger. Kosmetiske tester flytter sjelden noe fordi de ikke tar tak i hvorfor folk nøler. God CRO endrer hva den besøkende forstår, tror eller må gjøre.
• Det er ikke bare A/B-testing. Testing er valideringssteget. Mesteparten av verdien kommer fra analysen som forteller deg hva du skal endre. Mange forbedringer (et ødelagt skjema i Safari, en manglende pris) bør rett og slett fikses, ikke testes.
• Det er ikke en pose med beste praksis. «Skap hastverk» eller «forkort skjemaet» kan hjelpe eller skade avhengig av målgruppen. En praksis er en hypotese inntil dine egne data støtter den.
• Det er ikke trafikkanskaffelse. CRO jobber med det som skjer etter at besøket starter. Det gjør alle anskaffelseskanaler mer effektive, men erstatter ingen av dem.

CRO-prosessen, steg for steg

Alle troverdige CRO-programmer kjører en variant av den samme sløyfen. Navnene varierer; rekkefølgen gjør det ikke.

1. Research: finn hvor og hvorfor besøkende ikke konverterer.
2. Hypoteser: gjør hvert funn om til en testbar påstand.
3. Prioritering: ranger hypotesene slik at knapp trafikk og utviklertid går til de beste kortene.
4. Testing: kjør et kontrollert eksperiment (eller, der det er umulig, den nest beste metoden).
5. Analyse: les resultatet ærlig, inkludert segmenter og sikkerhetsmetrikker.
6. Utrulling og læring: lanser vinnerne, registrer hvert resultat og før lærdommene tilbake inn i researchen.

1. Analyse: hvor og hvorfor

Research har to halvdeler. Kvantitative data forteller deg hvor problemet er. Kvalitative data forteller deg hvorfor. Du trenger begge: en traktrapport viser at 70 % av de besøkende forlater prissiden, men den kan ikke fortelle deg at de forsvant fordi enterprise-nivået sier «Kontakt oss» uten noe prisintervall.

Start med analysedata for å velge de to eller tre sidene som betyr mest (mye trafikk, nær inntekt, bratt frafall), og bruk så den kvalitative innsatsen bare der. En researchsprint på to til tre uker gir typisk flere testideer enn du rekker å kjøre på seks måneder.

Før du stoler på noe av dette, bør du sjekke rørleggerarbeidet. Bekreft at konverteringshendelser utløses én gang per konvertering, at traktstegene spores på alle enheter, og at intern trafikk filtreres bort. En overraskende stor andel av «konverteringsproblemene» viser seg å være måleproblemer.

2. Hypoteser: gjør hver idé falsifiserbar

En hypotese kobler en observasjon til en endring og et målbart resultat. Bruk denne malen:

«Fordi vi observerte» det dataene viste, «tror vi at å endre» ett element «for» én målgruppe «vil føre til» det forventede resultatet, «målt ved» ett primært mål.

Eksempel: «Fordi vi har sett i øktopptak og en exit-undersøkelse at mobilbesøkende på prissiden ikke klarer å se hvilken plan som inkluderer SSO, tror vi at en bryter for funksjonssammenligning over plankortene for mobilbesøkende vil gi flere planvalg, målt i klikk på en hvilken som helst «Velg plan»-knapp per besøkende på prissiden.»

Malen gjør tre jobber. Den tvinger frem dokumentasjon (ikke noe «fordi daglig leder liker det»). Den navngir målgruppen, slik at du tester der problemet er. Og den fastsetter den primære metrikken før testen starter, noe som hindrer at man velger en smigrende metrikk i etterkant. En versjon du kan kopiere, finner du i malen vår for A/B-testplan.

3. Prioritering: PIE, ICE eller PXL

Du vil alltid ha flere ideer enn kapasitet. Tre poengrammeverk dominerer:

• PIE (Potential, Importance, Ease), gjort populær av WiderFunnel: gi hver en score fra 1 til 10 og ta gjennomsnittet. «Importance» handler om hvor verdifull trafikken på siden er.
• ICE (Impact, Confidence, Ease) fra vekstmarkedsføring: gi hver en score fra 1–10 og ta gjennomsnittet. «Confidence» er hvor sterk dokumentasjonen din er.
• PXL, fra CXL: en sjekkliste med for det meste ja/nei-spørsmål med faste poeng, for eksempel om endringen er synlig uten å scrolle, om den merkes innen fem sekunder, om den legger til eller fjerner et element, om den kjører på en side med mye trafikk, og om den løser et problem som er funnet i brukertesting, kvalitative tilbakemeldinger eller analyse. Enkelhet scores etter anslått innsats. CXL utviklet den for å fjerne gjettingen som PIE og ICE etterlater i «effekt».

Eksempel (illustrerende score for én backlog, PXL forenklet til sju spørsmål):

Alle tre rammeverkene er enige om at A kommer først og D sist. De er uenige om C: PIE plasserer den nær B fordi «potensial» er rauslig vurdert, mens ICE og PXL straffer mangelen på bevis. Den uenigheten er nettopp grunnen til å velge rammeverk bevisst.

Vårt syn: Bruk ICE i et lite team som må rangere 20 ideer på en ettermiddag. Gå over til PXL når mer enn én person scorer ideer, fordi ja/nei-spørsmål gir konsistente scorer på tvers av personer og hindrer at den høyeste stemmen blåser opp «effekt». PIE er nyttig når du skal avgjøre hvilken side du skal jobbe med, mindre for enkeltideer. Uansett hva du velger, bør du vekte bevis tungt: Det som best forutsier en vinnende test, er en hypotese forankret i research.

4. Testing

Bygg varianten, kvalitetssikre den i alle store nettlesere og på alle store enheter, og kjør et kontrollert eksperiment der trafikken tillater det (se statistikkavsnittet nedenfor). Skriv ned før lansering: det primære måltallet, sikkerhetsmåltallene, utvalgsstørrelsen, planlagt varighet og stoppregelen. Hvis du ikke kan fylle ut disse fem, er du ikke klar til å lansere.

5. Analyse

Når det planlagte utvalget er nådd, sjekker du først datakvaliteten (utvalgsforhold, sporing), så det primære måltallet, så sikkerhetsmålingene, og deretter forhåndsregistrerte segmenter som enhet eller nye kontra tilbakevendende. Behandle segmentfunn du ikke planla, som nye hypoteser, ikke konklusjoner: deler du opp en test på nok måter, vil noe se signifikant ut ved en tilfeldighet.

6. Utrulling og læring

Implementer vinnerne skikkelig (i kodebasen, ikke la dem kjøre på 100 % i testverktøyet i månedsvis). Før hver test inn i en logg: hypotese, skjermbilder, tall, beslutning og hva den lærte deg om de besøkende. En tapende test som motbeviser en utbredt antakelse, er ofte mer verdt enn en liten seier, men bare hvis noen skriver det ned.

Teststatistikk gjort riktig

Du trenger ikke være statistiker for å kjøre gyldige tester, men du må respektere fem prinsipper. Det beste enkeltstående oppslagsverket er Kohavi, Tang og Xu, Trustworthy Online Controlled Experiments (2020).

Utvalgsstørrelse: bestem den før du starter

Antall besøkende du trenger, avhenger av den grunnleggende konverteringsraten din, den minste effekten du vil oppdage (minimum detectable effect, MDE), signifikansnivået ditt (alfa) og den statistiske styrken. For en tosidig test som sammenligner to andeler:

n per variant = [ z_1-α/2 × √(2 p̄(1-p̄)) + z_1-β × √(p₁(1-p₁) + p₂(1-p₂)) ]² / (p₂ - p₁)²

Gjennomregnet eksempel: basislinje p₁ = 3 %, MDE = 20 % relativt, så p₂ = 3,6 %. Alfa = 0,05 (tosidig), så z = 1,96. Styrke = 0,8, så z ≈ 0,8416. Den samlede raten p̄ = 3,3 %.

1. Første ledd: 1,96 × √(2 × 0,033 × 0,967) = 1,96 × √0,06382 = 1,96 × 0,2526 = 0,4951
2. Andre ledd: 0,8416 × √(0,03 × 0,97 + 0,036 × 0,964) = 0,8416 × √(0,02910 + 0,03470) = 0,8416 × 0,2526 = 0,2126
3. Teller: (0,4951 + 0,2126)² = 0,7077² = 0,5009
4. Nevner: (0,036 - 0,03)² = 0,006² = 0,000036
5. n = 0,5009 / 0,000036 ≈ 13 900 besøkende per variant, omtrent 27 800 totalt.

Det samsvarer med det Evan Millers kalkulator for utvalgsstørrelse gir for de samme verdiene, og du kan sjekke ditt eget scenario i A/B-testkalkulatoren vår. Legg merke til hvor brutal matematikken er: halver MDE til 10 %, og du trenger omtrent fire ganger så mye trafikk. Innlegget vårt om utvalgsstørrelse for A/B-tester har oppslagstabeller for vanlige grunnrater.

Varighet: utvalgsstørrelse delt på trafikk, i hele uker

Testvarighet = totalt utvalg som trengs / kvalifiserte besøkende per uke, rundet opp til hele uker.

Eksempel: siden over får 7 000 kvalifiserte besøkende i uken. 27 800 / 7 000 = 3,97, så kjør testen i 4 hele uker. Hele uker er viktig fordi besøkende på hverdager og i helger oppfører seg ulikt; stopper du på en onsdag, blir deler av uken overrepresentert. Som tommelfingerregel bør du kjøre minst én hel forretningssyklus og unngå tester lengre enn seks til åtte uker, siden sletting av informasjonskapsler og sesongendringer da begynner å forurense utvalget.

Ikke titt underveis (eller bruk en metode laget for det)

Å sjekke en vanlig test med fast horisont daglig og stoppe i det øyeblikket den når p < 0,05 øker antallet falske positiver dramatisk, slik Evan Miller viser i How Not To Run an A/B Test. Enten forplikter du deg til den planlagte utvalgsstørrelsen og leser resultatet først til slutt, eller så bruker du et verktøy med statistikk laget for løpende overvåking (sekvensiell testing). Det er greit å se på et dashbord; problemet er å handle på det for tidlig.

Se etter skjev fordeling av utvalget (sample ratio mismatch)

Hvis du deler trafikken 50/50 og får 10 000 besøkende i kontrollgruppen og 9 400 i varianten, er noe galt: en omdirigering som mister brukere, et robotfilter som treffer én gruppe, en variant som krasjer i enkelte nettlesere. En kjikvadrattest på antall besøkende fanger opp dette. Kohavi og kolleger behandler skjevhet i utvalgsforholdet (sample ratio mismatch) som en av de viktigste tillitssjekkene; når den feiler, skal du ikke tolke resultatet, men finne feilen.

Nyhetseffekter, ett primært måltall og sikkerhetsmål

• Nyhets- og vaneeffekter: tilbakevendende besøkende kan klikke på et nytt element fordi det er nytt, eller ignorere det fordi de er vant til den gamle layouten. Sammenlign første uke med de neste ukene; avtar effekten, bør du være skeptisk.
• Ett primært måltall: bestemt på forhånd, helst det måltallet nærmest inntekter som du kan måle med nok volum. Ti «primære» måltall garanterer en falsk vinner et eller annet sted.
• Sikkerhetsmål (guardrails): ting som ikke må bli dårligere, for eksempel inntekt per besøkende, leadkvalitet, refusjonsrate og lastetid. En variant som øker registreringene med 10 % mens gjennomsnittlig ordreverdi faller med 15 %, er ingen vinner.

Og test én helhetlig endring per variant, med mindre du har mye trafikk. Sammenligningen vår av A/B-testing og multivariat testing forklarer når den multivariate veien er verdt trafikkostnaden (sjelden under sekssifrede besøkstall per måned).

CRO for nettsteder med lite trafikk og B2B-nettsteder

De fleste CRO-råd er skrevet av folk som optimaliserer forbrukernettsteder med store volumer. B2B-nettsteder, og små forbrukernettsteder, har tre strukturelle problemer:

1. Lav trafikk. Det gjennomregnede eksempelet over trenger rundt 27 800 besøkende for én test. En side med 5 000 besøkende i måneden ville brukt fem til seks måneder, og innen den tid har markedet, annonsene og selve siden endret seg.
2. Lange salgssykluser. En test kan telle skjemainnsendinger på uker, men om disse leadsene ble til pipeline, tar måneder å se. Varianten som vinner på demoforespørsler i februar, kan tape på inntekter innen juni hvis den tiltrakk selskaper som passet dårlig.
3. Ulik verdi per konvertering. Én demoforespørsel kan komme fra et selskap som kan bli din største kunde, en annen fra en student. Konverteringsraten behandler dem likt, og inntektsvektede måltall har mye mer støy, så de krever enda mer data.

Ingenting av dette betyr «ikke driv med CRO». Det betyr at du må endre metoden.

Hva du bør teste først

Når du bare kan kjøre en håndfull tester i året, kjører du dem med store forventede effekter på sider nær inntektene. En fornuftig rekkefølge:

1. Overskrifter og verdiforslag på de kommersielle sidene med mest trafikk: resultatfokusert eller funksjonsfokusert, målgruppespesifikk eller generisk, problemfokusert eller løsningsfokusert.
2. Tilbudet og CTA-en: ikke bare knappeteksten, men hva du tilbyr (demo, produktomvisning, vurdering, prissamtale) og hvor det vises.
3. Skjemaer: felt, kvalifiserende spørsmål, ett steg eller flere. Mål leadkvalitet, ikke bare fullføring.
4. Layout og sidestruktur til slutt: dyrest å bygge, i gjennomsnitt minst effekt og tregest å måle.

Ta større sjanser

Utvalgsstørrelsen som trengs, øker med den inverse kvadraten av effekten. Å oppdage en økning på 40 % krever omtrent en firedel av trafikken som trengs for en økning på 20 %. Små justeringer er umulige å teste med lite trafikk; dristige, research-baserte endringer (et helt annet argument i overskriften, et annet tilbud) er det ikke. De lærer deg også mer om kjøperne dine, mens små justeringer bare lærer deg om siden.

Test mikrokonverteringer høyere opp i trakten

Hvis demoforespørsler er for sjeldne, velger du et primært måltall høyere opp i trakten som rimelig sannsynlig henger sammen med dem: klikk til demosiden, påbegynte skjemaer, besøk på prissiden fra forsiden. Et måltall som skjer ti ganger så ofte, gjør at tester når nok styrke omtrent ti ganger raskere. Ulempen er at du fortsatt må følge med på hovedkonverteringen som et sikkerhetsmål, fordi en mikrokonvertering kan stige mens de reelle konverteringene står stille.

Godta en sikkerhet som passer beslutningen

Ikke alle beslutninger trenger 95 % konfidens. For tekstendringer som er lette å reversere, er en lavere terskel (eller en bayesiansk avlesning av «sannsynlighet for å være best») en rimelig avveining mellom fart og sikkerhet. For strukturelle endringer som er dyre å reversere, som et redesign av prissiden, bør du vente på sterke bevis. Bestem terskelen før testen, ikke etter at du har sett tallene.

Sekvensielle tester og før/etter-tester, med forbehold

Når en splittest er umulig (opplevelser for målkontoer med noen få dusin besøk, en endring i navigasjonen for hele nettstedet), er en før/etter-sammenligning bedre enn ingenting, men vær ærlig om svakheten: sesongvariasjoner, kampanjer, salgsaktivitet og nyheter i markedet endrer seg samtidig med siden din. Reduser risikoen ved å sammenligne like lange perioder, sjekke et kontrollmåltall som endringen din ikke bør påvirke (beveget det seg også, skyldes skiftet trolig noe eksternt), og gjenta byttet (på, av, på) der du kan.

Støtt deg på kvalitativ research

Med lite trafikk er fem kundeintervjuer og tjue opptak av salgssamtaler mer verdt enn en test uten nok styrke. Bruk kvalitativt arbeid til å gjøre endringer du er rimelig sikker på, og spar testingen til de virkelig usikre beslutningene med mye på spill.

Mål pipeline, ikke skjemautfyllinger

Eksempel: variant A gir 20 leads, der 25 % blir muligheter (5 muligheter). Variant B gir 30 leads, der 10 % blir muligheter (3). B «vant» på konverteringsrate og tapte på måltallet som betyr noe. Koble testverktøyet eller analyseverktøyet til CRM, så hvert lead har med seg varianten sin, og se på resultatene igjen når mulighetsdataene er modne. Sjekk også resultatene per segment: et flatt samlet resultat kan skjule en vinner for besøkende fra store virksomheter og en taper for små selskaper som nuller hverandre ut. For CRO-taktikker spesielt for B2B, som kvalifiserende skjemaer, sosialt bevis for store virksomheter og innhold for innkjøpsgruppen, se den grundigere guiden vår til konverteringsoptimalisering for B2B.

Gjennomfør en CRO-revisjon

En CRO-revisjon er researchsteget komprimert til en engangsgjennomgang, nyttig når du arver et nettsted eller raskt trenger en prioritert plan. Kortversjonen:

1. Sjekk målingen: konverteringshendelser, traktsteg, sporing på tvers av domener, filtrert intern trafikk.
2. Kartlegg trakten etter enhet og kanal, og finn de to stegene med størst absolutt tap.
3. Gå gjennom disse sidene heuristisk: hvor tydelig tilbudet er på fem sekunder, relevans for trafikkilden, friksjon (felt, steg, lastetid), usikkerhet (tillit, pris, personvern) og distraksjoner.
4. Samle kvalitative bevis på de samme sidene: opptak, en kort spørreundersøkelse, noen brukertester.
5. Loggfør funn enten som «bare fiks» (feil, ødelagte flyter), «undersøk» eller «test», hver med en hypotese og en prioritetsscore.

Sjekklisten vår for CRO-revisjon lister opp alle kontrollene, og gjennomgangen av CRO-revisjon viser hvordan du gjør funnene om til et veikart.

Hva du bør fokusere på, etter sidetype

To eksterne referansetall er verdt å kjenne til. Baymard Institute, som tar snittet av 50 studier, anslår dokumentert forlatelse av handlekurver på nett til omtrent 70 %; blant kunder som forlot kurven av andre grunner enn at de «bare så seg rundt», rangerer ekstra kostnader (40 %) og tvungen kontoopprettelse (18 %) høyt, og Baymard anslår at en ideell kasse bare trenger 7–8 skjemafelt mot et amerikansk snitt på rundt 15. For skjemaer generelt er Nielsen Norman Groups anbefalinger for brukervennlige skjemaer (hold skjemaene korte, i én kolonne, forklar kravene på forhånd, bruk konkrete feilmeldinger) en solid sjekkliste. B2B-skjemaer er et delvis unntak fra «kortere er alltid bedre», fordi kvalifiseringsfelt beskytter tiden til salg; guiden vår til utforming av skjemaer for leadfangst viser hvordan du tilpasser skjemalengden til intensjonen, og optimalisering av B2B-landingssider går dypere inn i kampanjesider.

Personalisering som CRO-spak

En klassisk A/B-test spør «hvilken versjon er best for alle?» Noen ganger er det ærlige svaret «ingen av dem»: en enterprise-kjøper og en oppstartsbedrift med fem ansatte vil ha ulike bevis, ulikt språk og et ulikt neste steg, og gjennomsnittsresultatet skjuler det. Personalisering betyr å gi definerte segmenter ulike opplevelser, og så måle hver av dem mot en kontrollgruppe for det segmentet.

Det slår testing med én versjon for alle når tre betingelser er oppfylt: målgruppen din deler seg i segmenter med reelt ulike behov (etter bransje, selskapsstørrelse, fase i trakten eller trafikkilde), du kan pålitelig gjenkjenne disse segmentene når de kommer, og du har innhold som faktisk er forskjellig for hvert av dem. Mangler én av dem, gir personalisering kompleksitet uten løft. Det deler også trafikken din, så det er ingen snarvei rundt regnestykket for utvalgsstørrelse; start med ett eller to store segmenter og én side. Vil du strukturere segmentene først, tar guiden til segmenteringsstrategi deg gjennom det, og segmenteringsfunksjonene våre viser hvordan Markettailor leverer segmentspesifikke varianter med en kontrollgruppe.

Vanlige CRO-feil (og løsninger)

1. Testing uten research. Ideer fra idémyldring vinner sjeldnere enn ideer basert på dokumentasjon. Løsning: hver test viser til observasjonen bak den.
2. Å stoppe tester tidlig. Tidlige ledelser er stort sett støy, og titting underveis øker andelen falske positiver. Løsning: fastsett utvalgsstørrelse og varighet på forhånd.
3. Tester med for lav statistisk styrke. En test som bare kan påvise en økning på 50 %, vil kalle de fleste reelle forbedringer «ingen forskjell». Løsning: regn ut hvilken MDE du kan påvise før lansering, og kjør bare tester som realistisk kan nå den.
4. Å optimalisere for feil mål. Flere leads, dårligere pipeline. Løsning: et primærmål så nær omsetning som volumet tillater, pluss kvalitetsrekkverk.
5. Å kalle tap for fiaskoer. Team dropper stille og rolig tapende tester og mister lærdommen. Løsning: loggfør hvert resultat og hva det motbeviste.
6. Å ignorere segmenter, eller overtolke dem. Begge deler skjer. Løsning: forhåndsregistrer to eller tre segmenter (enhet, ny mot gjenkommende, selskapsstørrelse) og behandle resten som hypoteser.
7. Å kopiere konkurrenter eller lister over «beste praksis». Du ser siden deres, ikke resultatene deres. Løsning: bruk dem som kilder til hypoteser, aldri som svar.
8. Å hoppe over QA. En variant som brekker i én nettleser, gir en falsk taper og en skjevhet i utvalgsforholdet. Løsning: test hver variant i de viktigste nettleserne og enhetene før lansering.
9. Å behandle CRO som et prosjekt. Én revisjon, fem rettelser, ferdig. Løsning: en fast rytme med en ansvarlig, en backlog og en logg.
10. Å ikke fikse åpenbare feil fordi «vi bør teste det». Løsning: ting som er ødelagt, fikses; ting som er usikre, testes.

CRO-verktøy etter oppgave

Velg verktøy etter oppgaven de gjør, og kjøp testverktøyet sist: De fleste team trenger bedre research før de trenger mer testkapasitet.

• Analyse: trakter, segmenter og hendelser. Google Analytics 4, Adobe Analytics eller produktanalyse som Mixpanel og Amplitude.
• Atferdsanalyse: varmekart og øktopptak. Microsoft Clarity, Hotjar, Contentsquare.
• Testing og personalisering: eksperimentering på klientsiden eller serversiden. Optimizely, VWO, AB Tasty eller plattformer for feature flags til tester på serversiden.
• Undersøkelser og brukerresearch: avstemninger på siden og modererte eller umodererte brukertester. Hotjar surveys, Typeform, UserTesting, Maze.

For en fyldigere sammenligning etter trafikknivå og budsjett, se oversikten vår over verktøy for konverteringsoptimalisering.

Slik bygger du et CRO-program

CRO gir akkumulerende effekt bare når det drives som et program og ikke som en rekke enkeltstående rettelser. Minimumsstrukturen:

• En eier med øremerket tid til det, pluss tilgang til design- og utviklingskapasitet. Uten utviklertid blir backloggen en ønskeliste.
• En rytme: en researchsprint hvert kvartal, en prioriteringsgjennomgang annenhver uke og en månedlig resultatgjennomgang for interessentene.
• En testlogg som alle kan søke i: hypotese, målgruppe, skjermbilder, utvalg, resultat, beslutning, læring. Etter et år er det den mest verdifulle CRO-ressursen du har.
• Et realistisk mål for kapasitet. Et forbrukernettsted med mye trafikk kan kjøre flere tester i måneden parallelt på ulike sider. Et B2B-nettsted med 10 000 besøkende i måneden klarer kanskje én eller to i måneden, kombinert med forbedringer basert på research.

Avklar forventningene til vinnerandel på forhånd. I Online Experimentation at Microsoft (Kohavi et al., 2009) rapporterer forfatterne at bare omtrent en tredjedel av ideene forbedret måltallene de var ment å forbedre, mens omtrent en tredjedel var flate og en tredjedel negative. Microsofts ideer var ikke dårlige; gode ideer er rett og slett vanskelige å forutsi. Hvis programmet ditt «vinner» 80 % av testene, er den mer sannsynlige forklaringen slapp statistikk, ikke enestående ideer. Vurder et CRO-program etter validert samlet effekt og kvaliteten på det det har lært, ikke etter vinnerandelen.

Ofte stilte spørsmål

Hva er en god konverteringsrate?

Det finnes ikke ett universelt godt tall, fordi konverteringsraten avhenger av hva du teller, trafikkmiksen, prisnivået og kjøpssyklusen. En gratis påmelding til et nyhetsbrev og en demoforespørsel for en sekssifret enterprise-avtale kan ikke dele samme benchmark. Den nyttige sammenligningen er mot din egen grunnlinje for den samme siden, trafikkilden og enheten. Sikt mot å forbedre den jevnt, og vurder suksess etter inntekt eller pipeline per besøkende i stedet for raten alene.

Hvor lenge bør en A/B-test kjøre?

Kjør den til den når utvalgsstørrelsen du regnet ut før lansering, rundet opp til hele uker så alle ukedager er like representert. Del det totale antallet besøkende som trengs på den ukentlige kvalifiserte trafikken din. For de fleste nettsteder betyr det to til seks uker. Hvis regnestykket sier flere måneder, tester du heller en større endring eller et måltall med høyere volum enn å kjøre en endeløs test.

Hva er forskjellen mellom CRO og SEO?

SEO øker hvor mange kvalifiserte besøkende som kommer til nettstedet ditt fra organisk søk. CRO øker andelen av disse besøkende, fra alle kanaler, som utfører en verdifull handling. De støtter hverandre: sider som tydelig svarer på søkerens intensjon, har en tendens til både å rangere og konvertere bedre. Konflikter er sjeldne, men unngå CRO-endringer som skjuler eller fjerner innhold søkemotorer og besøkende trenger.

Lønner CRO seg for nettsteder med lite trafikk?

Ja, men metoden endres. Med begrenset trafikk bør du lene deg på kvalitativ research som kundeintervjuer, øktopptak og brukertester, rette åpenbare problemer direkte og spare A/B-tester til dristige endringer med mye på spill, målt på hyppige måltall tidligere i trakten. Selv uten noen testing i det hele tatt finner en researchdrevet revisjon av de to eller tre viktigste sidene dine som regel friksjon som er verdt å fjerne.

Hva gjør en CRO-spesialist?

En CRO-spesialist driver optimaliseringssløyfen: analyserer trakter, gjennomfører brukerundersøkelser, skriver hypoteser, prioriterer og designer eksperimenter, sjekker at de er statistisk gyldige og gjør resultatene om til anbefalinger. Rollen kombinerer analyse, UX-research, skjønn i tekstarbeid og nok statistikk til å unngå falske vinnere. Vurderer du denne karrieren, gir oversikten vår over jobber innen konverteringsoptimalisering deg roller, ferdigheter og hvordan du kommer i gang.