Frågan kommer nästan alltid när ett företag börjat testa på allvar: ska vi fortsätta testa en sak i taget, eller testa allt på en gång? Skillnaden mellan ett A/B-test och ett multivariattest handlar mindre om hur mycket trafik du har än om vad du vill veta. Vill du bara veta vilka av dina förändringar som fungerar räcker enkla test. Vill du veta om två förändringar påverkar varandra behöver du ett multivariattest. Och den vanligaste föreställningen om metoden, att den kräver enorma trafikmängder, stämmer bara om du analyserar resultatet på ett sätt som statistikerna bakom metoden avråder från.
A/B, A/B/n och MVT är tre olika saker
Ett A/B-test är grundmetoden, och den du bör börja med: en faktor, två versioner, kontroll mot utmanare. Ett A/B/n-test utvidgar den med fler versioner av samma faktor, till exempel fyra olika rubriker på samma sida. Faktorn är fortfarande en. Det är antalet nivåer som ökar.
Ett multivariattest är något annat. Där testas flera faktorer samtidigt, och besökarna fördelas över kombinationer av dem. Rubrik, knappfärg och produktbild är tre faktorer, och varje besökare ser en kombination av de tre. Skillnaden mot A/B/n är inte antalet versioner, utan att versionerna korsas med varandra. De två blandas ihop ständigt i svensk CRO-text, och det är inte oskyldigt: metoderna svarar på olika frågor och kostar olika mycket trafik.
Terminologin är rörig även på engelska. Ron Kohavi, Roger Longbotham, Dan Sommerfield och Randal Henne, samtliga på Microsoft, valde medvetet begreppet MultiVariable Testing framför multivariate testing i sin genomgång Controlled experiments on the web: survey and practical guide (Data Mining and Knowledge Discovery, 2009). Motiveringen är att multivariat statistik är ett eget statistiskt fält som inte handlar om det här alls. Förkortningen MVT slog ändå igenom, och den används i dag om båda begreppen.
Interaktionen är hela poängen
Att testa fler saker snabbare är inte multivariattestets starkaste argument, även om det ofta framställs så. Det egentliga argumentet är interaktioner. Två faktorer interagerar när deras kombinerade effekt skiljer sig från summan av de två enskilda effekterna. Drar de åt samma håll är interaktionen synergistisk, motverkar de varandra är den antagonistisk.
Kohavi och hans medförfattare ger ett exempel från en näthandel. En faktor är att göra produktbilden större, en annan att lägga till mer produktinformation. Var för sig kan båda öka försäljningen. Görs de samtidigt trycks köprutan ner under skärmkanten, och försäljningen faller. Det är en kraftig antagonistisk interaktion, och den syns inte i två separata A/B-test som körts efter varandra. Varje test visar en vinst, och kombinationen som går i produktion förlorar.
Sekventiella test kan alltså inte upptäcka den sortens krock. Det är den enda funktion multivariattestet har som inte går att ersätta med disciplin och tålamod.
Räkneexempel: åtta celler, två helt olika trafikkrav
Antalet celler i ett fullfaktoriellt test växer multiplikativt. Tre faktorer med två nivåer vardera ger åtta celler, alltså två upphöjt till tre. Fem faktorer med två nivåer ger 32 celler, vilket är precis det exempel Kohavis genomgång räknar upp för MSN:s startsida. Byter du en av tre faktorer mot tre nivåer i stället för två blir det tolv celler.
Här börjar de påhittade tumreglerna. Det cirkulerar siffror i branschen om hur många besökare per månad en sajt måste ha för att multivariattest ska bli meningsfullt. Någon sådan gräns finns inte, av samma skäl som det inte finns ett fast antal besökare för ett A/B-test: kravet följer av din baskonvertering, hur liten effekt du vill kunna upptäcka och vilken säkerhet du väljer. Vad cellerna avgör är hur den räkningen ska tolkas, och där skiljer sig två analysvägar dramatiskt.
Ta vårt eget räkneexempel från guiden om statistisk signifikans som utgångspunkt: två procents baskonvertering, en relativ förbättring på 20 procent att upptäcka, 95 procents signifikansnivå och 80 procents styrka. Det ger ungefär 21 100 besökare per variant. Kör du nu ett fullfaktoriellt test med tre faktorer i två nivåer, alltså åtta celler, och envisas med att jämföra varje cell mot kontrollcellen, behöver varje cell den storleken. Åtta celler ger cirka 169 000 besökare. Justerar du dessutom för att du gör sju jämförelser mot kontrollen i stället för en, vilket du bör, stiger kravet per cell till cirka 33 500 och totalen till cirka 268 000.
Analyserar du i stället huvudeffekterna, alltså jämför alla celler där en faktor är påslagen mot alla celler där den är avslagen, använder varje faktor hela urvalet. Då behöver testet cirka 42 200 besökare totalt, precis som ett enda A/B-test med samma krav. Samma test och samma data, men trafikkravet skiljer fyra till drygt sex gånger beroende på hur du räknar.
Det är inte vår egen tolkning. Kohavi och medförfattarna skriver rakt ut att föreställningen om att styrkan sjunker med antalet celler kan stämma om analysen görs genom att jämföra varje enskild cell mot kontrollcellen, men att lite eller ingen styrka går förlorad om huvudeffekter och interaktioner beräknas på hela underlaget. Med fast urvalsstorlek är styrkan att upptäcka en huvudeffekt densamma oavsett om du testar en faktor eller många.
Priset för huvudeffektsanalysen är att svaret blir ett genomsnitt. Du får veta hur mycket faktorn lyfter konverteringen i snitt över de andra faktorernas nivåer, inte vad just kombination nummer sex gör med den. Vill du ha det senare är du tillbaka i celljämförelserna och deras trafikkrav.
Det som verkligen kostar trafik
Två saker sänker styrkan enligt samma genomgång, och antalet faktorer är inte någon av dem. Den första är fler nivåer per faktor. Den andra är att skicka mindre än hälften av trafiken till utmanaren. En konservativ formel som genomgången återger från Wheeler visar hur brutalt det första slår: där växer antalet användare per variant med kvadraten på antalet varianter, just för att hålla nere risken för slumpfynd när många jämförelser görs samtidigt.
Slutsatsen är obekväm för den som gärna provar sju rubrikförslag på en gång. A/B/n-testet, som ser enklare ut än multivariattestet, är det som verkligen äter trafik. Justeringar för många jämförelser, Bonferroni och dess släktingar, motsvarar i praktiken en skärpt signifikansnivå och sänker därmed styrkan, vilket är samma sak som att kräva mer data. Vår A/B-testkalkylator är byggd för en enda jämförelse: du matar in besökare och konverteringar för A och B, och den svarar med ett tvåsidigt z-test för två andelar på 95 procents nivå. Den justerar inte för flera celler eller flera jämförelser, så använd den per jämförelse och håll själv räkning på hur många du har gjort.
Fullfaktoriellt eller fraktionsfaktoriellt
Traditionella multivariattest sparar celler genom att testa ett urval av kombinationerna i stället för alla. Designerna är oftast fraktionsfaktoriella, eller så kallade Plackett-Burman-designer, populariserade av Genichi Taguchi och därför ofta kallade Taguchi-designer. En fraktionsfaktoriell design är precis vad namnet säger, en bråkdel av den fullfaktoriella.
Här sitter fällan. Kohavis genomgång visar en fraktionsfaktoriell design som testar fem faktorer i åtta grupper i stället för 32. Den kan skatta alla fem huvudeffekterna, men den kan inte skatta interaktionerna, eftersom varje interaktion är fullständigt sammanblandad med en huvudeffekt eller med en annan tvåfaktorsinteraktion. Ingen efteranalys och ingen datautgrävning kan reda ut dem i efterhand, konstaterar författarna. Vill du skatta alla tvåfaktorsinteraktioner mellan fem faktorer krävs 16 kombinationer, inte åtta.
Den design som marknadsförs som sättet att få ner trafikkravet tar alltså bort exakt det som var multivariattestets skäl att finnas. En snålt tilltagen fraktionsfaktoriell design är rätt val när du vill mäta flera huvudeffekter på kort tid och inte bryr dig om interaktioner. Är interaktionen din fråga måste designen ha tillräcklig upplösning, alltså de 16 kombinationerna i stället för åtta.
Kohavis eget råd går på tvärs mot branschens
Rekommendationen i genomgången är varken traditionellt multivariattest eller strikt en faktor i taget. Författarna föreslår i stället att varje faktor körs som ett eget enfaktorstest, men parallellt, och med besökarna slumpade oberoende till varje test. Startar och stoppar de samtidigt på samma användare blir slutresultatet ett fullfaktoriellt experiment där alla interaktioner går att beräkna. En praktisk fördel är att en enskild faktor kan stängas av mitt i utan att de andra testerna påverkas.
Vill du hellre maximera takten kör du varje faktor som ett test så snart den är klar, utan att synkronisera starterna. Då får du interaktionerna bara för de faktorer som råkar överlappa i tid. Författarna bedömer att det är ett rimligt pris, eftersom stora interaktioner mellan faktorer enligt deras erfarenhet från riktiga sajter är ovanligare än de flesta antar.
De är också tydliga med ordningsföljden. Det första experiment ett företag gör bör vara ett A/B-test, just för att det blir komplicerat att testa mer än en faktor i samma test. Deras sammanfattande råd är att köra enfaktorstest för insikter och stegvisa förändringar, att våga ställa radikalt olika designer mot varandra, och att spara de faktoriella designerna till fall där man på förhand misstänker starka interaktioner. Då gäller det att begränsa antalet nivåer per faktor och ge utmanarna samma andel av trafiken som kontrollen får.
Så väljer du
- A/B-test: när du har en förändring i taget, när förändringarna är oberoende av varandra, eller när det här är din första testomgång.
- Parallella enfaktorstest med oberoende slumpning: förstavalet när du har flera färdiga förändringar. Du får takten från multivariattestet och kan ändå räkna ut interaktionerna.
- Fullfaktoriellt multivariattest: när du på förhand misstänker att två bestämda element påverkar varandra, till exempel två saker som konkurrerar om samma utrymme ovanför skärmkanten.
- Fraktionsfaktoriellt eller Taguchi: när du vill mäta många huvudeffekter samtidigt. Skalar du ner för hårt, som fem faktorer i åtta grupper, går interaktionerna inte längre att räkna ut.
- Fler varianter av samma element: det alternativ som kräver mest extra trafik. Begränsa antalet nivåer.
Det mest användbara i den här jämförelsen är att metodvalet sällan avgörs av trafikvolym. Det avgörs av vilken fråga du ställer, och av om du bestämmer analysmetoden innan data börjar rulla in. Gör du det blir cellräkningen ett problem du kan lösa på förhand. Gör du det inte spelar det ingen roll hur många celler du har. Vill du gräva djupare i experimentmetodik har Ron Kohavi senare skrivit en bok om ämnet tillsammans med Diane Tang och Ya Xu, Trustworthy Online Controlled Experiments (Cambridge University Press, 2020).
Senast faktagranskad: 30 juli 2026