A/B-testaus: Yksinkertainen idea, joka on helppo mokata
Vaikka A/B-testauksen perusidean ymmärtää nopeasti, testi ei usein tuota yritykselle liiketoiminnallista hyötyä. Listamme yleisimmät virheet, joita testien yhteydessä tehdään.
A/B-testauksen perusidea on helppotajuinen. Testissä yhdestä palvelun osasta luodaan eri variaatiota ja variaatioiden keskinäistä menestystä vertaillaan reaaliaikaisesti. A/B-testissä variaatioita on yleensä kaksi, alkuperäinen ja muunnelma. Usein molemmat variantit ovat yhtä muutosta lukuun ottamatta samanlaisia, mutta suurienkin muutosten testaaminen on mahdollista. Pienten muutosten suunnittelu ja toteutus käy usein nopeasti, isojen testien tekeminen vaatii enemmän suunnittelu- ja koodausresursseja.
Vaikka A/B-testauksessa käytettävät työkalut kehittyvät, tämän kummemmasta asiasta ei pohjimmiltaan ole kyse. Tästä huolimatta moni testi ajaa karille, ja useimmiten syy on jokin näistä.
1. Testiä ei ylipäätään tehdä
A/B-testauksen tärkein ominaisuus on validoida tehtyjä design-päätöksiä. Jos päätöksiä tehdään sokkona suurella käyttäjäryhmällä, ratkaisu voi olla liiketoiminnalle haitallinen. Oikein tulkittuna A/B-testillä luodaan luotettava dataan perustuva vastaus kysymykseen, kumpi variaatioista toimii paremmin. Testien pohjalta voi myös kehittää uusia hypoteeseja tai sulkea pois design-ratkaisuja, jotka eivät edistä liiketoimintaa.
Pikaohje A/B-testaukseen
Kun teet muutoksia palveluun, mittaa sen vaikutusta palvelun keskeisimpiin mittareihin, kuten ostosten määrä, uutiskirjeen tilaus, ostoskoriin lisäys.
Älä riko sitä mikä toimii. Varmista, että jo hyvin toimivan palvelun designuudistus kehittää käyttöliittymää parempaan suuntaan.
Analysoi testin lopputulos – miksi testi onnistui tai epäonnistui – ja pohdi miten variaatioita voi kehittää.
2. Testin hypoteesi on heitetty hatusta
A/B-testaus on hypoteesiin pohjautuvaa suunnittelua, joten hypoteesin on oltava laadukas. Hypoteesilla tässä tilanteessa tarkoitetaan valistunutta arvausta, joka pohjautuu dataan, käyttäjien käytökseen, asiakaspalautteeseen tai muuhun löydettyyn tietoon. Hypoteesista jalostetaan muutos, joka validoidaan suorittamalla A/B-testi. Hypoteesin puuttuminen eli mutu-testaus ei kokemukseni mukaan tuota hyvää tulosta, vaan herättää usein kysymyksiä. A/B-testaus ei vastaa kysymykseen, mikä muutos tehdään seuraavaksi, joten signaali pitää löytää tutkimalla tai haastattelemalla. Hypoteesin muodostaminen auttaa myös kirkastamaan käyttöliittymän tarkoituksen.
Miten laadukas hypoteesi muodostetaan?
Löydä palvelun pullonkaulat analytiikkatyökalulla. Muodosta palvelupolusta suppilo ja tarkkaile missä kohdassa käyttäjät putoavat pois
Nauhoita käyttäjiä esim. Crazy Egg- tai Hotjar-palvelulla. Tutki nauhoituksia ja löydä verkkopalvelusta kohtia jotka vaativat kehittämistä.
Muodosta yhteys palvelun käyttäjiin esim. haastattelemalla tai lukemalla käyttäjäpalautetta. Palautteen perusteella voi muodostaa hyviä arvauksia siitä, mikä palvelussa on vikana.
3. Käyttäjämäärä ei riitä tilastolliseen varmuuteen
A/B-testillä pyritään saamaan tulos, jonka todennäköisyys on mahdollisimman luotettavaa. Liian pienellä kävijämäärä sattumanvaraisuus vaikuttaa testin lopputulokseen merkittävästi ja palvelun sivustot, joilla on vähäinen käyttäjäkunta tai konversiot ei tuota luotettavaa lopputulosta. Kannattaa kuitenkin varmistua, että alhainen kävijämäärä ja konversiot eivät johdu palvelun heikosta toteutuksesta.
Huomioi myös, että testi on tarpeeksi näkyvällä paikalla. Jos testi ei saa tarpeeksi näyttöjä, se ei tuota tilastollisesti merkittävää lopputulosta.
Mistä tiedän että testaan oikeaa asiaa?
Konversioita on oltava mielellään yli sata yhden testisyklin aikana.
Käyttäjien määrän riippuu vahvasti palvelusta, mutta minimitavoite on 50 000 näyttöä/variaatio.
Päätä testin aikasykli etukäteen.
Käytä resurssit mieluiten liikenteen lisäämisen kuin testien tekemiseen jos palvelulla on vähän käyttäjiä.
4. Värien ja painikkeiden testaaminen
Visuaalisuus on tärkeä osa erinomaisesta palvelua, mutta yksityiskohtien testaaminen voi olla ajanhukkaa. Värisävyjen vaihtaminen ja painikkeiden kulmien sekä tekstimuutoksen mittaamisen vaikutuksen näkeminen voi olla hankalaa.
Vaikka testaamalla värejä ja painikkeita on mahdollista saada aikaan merkittävääkin kehitystä, todennäköisemmin tuloksia saadaan vetoamalla käyttäjän tunteisiin. Lisää aiheesta voi lukea tästä tutkimuksesta.
Testaa mieluummin seuraavia asioita
Tuotesaatavuus: Jos tuotetta on vähän jäljellä ostopäätöksen tekemisestä voi tulla nopeampaa.
Arviot: Ilmoita miten muut käyttäjät suhtautuvat tuotteeseen. Jos tuote on esimerkiksi muiden käyttäjien suosima, voi käyttäjä rohkaistua valitsemaan tuotteen.
Suosittelu: ehdota tuotteita, joista käyttäjä voi olla kiinnostunut.
5. Laadukas hypoteesi hylätään liian helposti
A/B-testaus vaatii kärsivällisyyttä sillä variaatiot suoriutuvat vertailussa useimmiten yhtä hyvin. Jos testin hypoteesi on laadukas, mutta ensimmäinen testi ei tuota variaatioiden välille tilastollisesti merkittävää eroa, kannattaa harkita testaamista useaan otteeseen. Pohdi testin jälkeen mikä meni vikaan ja testaa hypoteesia uudelleen tehden variaatioon muutos. Onnistunut testi voi olla palvelun liiketoiminnan kannalta erittäin merkittävä, mutta testaamisessa vie myös aikaa. Jos hypoteesi ei ole laadukas eikä testi tuota tulosta, on kuitenkin järkevää lopettaa ajoissa.
Jos palvelu on esim. verkkokauppa kiinnitä huomiota käynnissä oleviin kampanjoihin ja ajankohtiin jotka vaikuttavat ostokäyttäytymiseen. Tällaisia ovat esim. Palkkapäivät (kuun lopussa ja keskivaiheilla) ja veronpalautukset.
Panosta hypoteesien laatuun.
Luo uusia variaatioita sillä harvoin ensimmäinen variaatio tuottaa tulosta.
Ota huomioon sesonkiajat tai muista syistä johtuva kasvu tai asiakaskäyttäytymisen siirtyminen.
6. Tehdään monta testiä samaan aikaan
Usean testin tekeminen samalla sivustolla voi vaikuttaa asiakkaiden käyttäytymiseen. Jos käyttäjä on useassa eri testissä samaan aikaan on vaikeaa tietää miten variaatiot vaikuttavat käyttäjään ristiin. Tämä vaikuttaa tilastolliseen todennäköisyyteen ja heikentää testin luotettavuutta. Mittaamisen kannalta on järkevämpää pilkkoa testi useaan osaan, jotta tiedetään miten yksittäinen muutos vaikuttaa käyttäjään.
Jos testiin otetaan enemmän kuin kaksi vaihtoehtoa, kyseessä on multivariate-testi, jota käytetään hieman eri tilanteissa kuin A/B-testiä ja joka vaatii onnistuakseen suuren käyttäjämäärän.
Kun rajaat testattavia ominaisuuksia, mieti tuottaako juuri kyseinen ominaisuus yritykselle lisäarvoa ja onko sitä todella syytä testata.
Priorisoi testejä esimerkiksi kustannustehokkuuden mukaan. Nopeasti tuotantoon menevä testi säästää aikaa devaajilta ja suunnittelijoilta. Kun nopea testi on jo ajossa niin sen ajan voi käyttää seuraavan suunnitteluun.
Jos käytät useampaa kuin kahta variaatiota, huomioi että se vaikuttaa testin tilastolliseen todennäköisyyteen. Jos testissä on enemmän kuin kaksi variaatiota huomio, että käyttäjiä on riittävästi.
7. Johtopäätös tehdään liian aikaisin
Analyysi on A/B-testauksen tärkeimpiä vaiheita, mutta sitä ei kannata tehdä liian aikaisin. Odota testin sykli loppuun asti, sillä testin käynnistämisen jälkeen toinen varianteista voi menestyä huomattavasti paremmin, mutta kyse voi olla täysin sattumasta. Konversiot tasoittuvat mitä enemmän näyttöä variaatiot saavat. Joskus variaatioiden merkittävä ero voi viestiä, että testin teknisessä toteutuksessa on jokin vika.
Testaaminen vaati aikaa, joten ole kärsivällinen.
Päätä konversioiden, käyttäjien määrä ja testiaika jo etukäteen. Tämä helpottaa myöhemmin myös analyysin tekemistä.
8.Hyötyä ei ymmärretä
Hyvin suunniteltu, toteutettu ja oikein analysoitu A/B-testi on erinomainen työkalu validoimaan suunnittelua sekä mittaroimaan, miten suunnittelu luo yritykselle lisäarvoa. Olennaista kuitenkin on, että kaikki työvaiheet tehdään huolella – muutoin testitulos ei ole luotettava tai kaikki työ menee hukkaan. Pelkän testauksen takia testiä ei kannata tehdä, vaan tuloksia pitää myös osata tulkita oikein ja hyödyntää.
A/B-testin avulla voit onnistua tai epäonnistua nopeasti, fail fast. Testin jälkeen voit aina palata takaisin vanhaan tai vaihtaa kokonaan suuntaa. Jokainen testi opettaa mikä käyttöliittymässä toimii ja mikä ei.
Tee testi huolella alusta loppuun ja validoi designisi.
Ota opiksi ja juhli jokaista testiä.
Epäonnistu nopeasti.