A/B-testaus on kotoisin tilastotieteen menetelmäpakista ja sillä voidaan saada aikaan konkreettista liiketoimintahyötyä. A/B-testauksessa mitataan yksittäisen muutoksen vaikutusta lopputulokseen: mitä kannattaa tehdä toisin?
“A/B-testauksessa on tärkeää tietää mitä ollaan tekemässä ja päättää tavoitteet etukäteen, ettei sorruta jälkikäteisiin selityksiin ja tulkintoihin”, sanoo Compilen Timo Mikkolainen, jolla on vuosien kokemus vaativien projektien toteutuksesta ja testauksesta. Timon uraan mahtuu toteutuksia mm. Nokialle ja Maanmittauslaitokselle ja massiivinen ajokorttitoimivallan siirtoon poliisilta Trafille liittyvä projekti. “Se oli muuten malliesimerkki julkisesta IT-hankkeesta, josta ei kukaan koskaan kuullut mitään, koska mikään ei mennyt pieleen ja budjetti piti”, toteaa Timo. “Itselleni siirtymä Compileen oli yllättävänkin helppo – no bullshit -filosofia istuu minulle oikein hyvin.”
A/B-testaus, mitä se on?
“On jokin mitä haluat mitata: vaikuttaako jokin yksittäinen asia toiseen?” kuvailee Timo. “On jokin absoluuttinen asia, joka joko tapahtuu tai ei tapahdu. Ympäristö pysyy muuten täysin samana ajan ja paikan suhteen, mutta yksi asia on eri lailla. Saadaanko aikaan tilastollisesti merkittävä ero, kun muutos eristetään?”
Testausta voi toki tehdä useillakin muuttujilla, mutta se ei yleensä kannata, koska liikkuvia osia tulee liikaa ja otoskokoa pitää kasvattaa huomattavasti. Testejä kannattaa harvoin pyörittää pitkään. Otoskoon pitää kuitenkin olla tilastollisesti riittävä, muuten testaamisessa ei ole mieltä. Riittävää otoskokoa ei tosin aina ole helppo määrittää.
Mihin A/B-testausta käytetään?
“Tässä on se hauskuus että voi laittaa oikeat käyttäjät testaamaan”, nauraa Timo. “A/B-testausta käytetään tyypillisesti apuna, kun halutaan ohjata käyttäjää tekemään jotain – esimerkiksi tekemään ostopäätös tai hakeutumaan ohjesivulle ja selvittämään ongelmansa mahdollisimman helposti.” Käyttäjä kun ei yleensä ole rationaalinen otus, jonka tekemisiä voidaan noin vain olettaa. A/B-testauksella voidaan tutkia esimerkiksi mikrokonversiota – saako vaikkapa mobiilisovelluksesta tuleva notifikaatio asiakkaan siirtymään askelen lähemmäs ostamista verkkokaupassa?
“Kun lähdetään kokeilemaan eroja, on tärkeintä ettei ennakkoon oleteta mitään”, muistuttaa Timo. “Lätkitään vaan kamaa ja katsotaan mikä oikeasti futaa. Tuo toimii, tuo ei.” Käyttäjää saattaa esimerkiksi kiinnostaa loppupeleissä aivan toinen asia kuin mikä lähtötilanteessa on ollut oletuksena, ja tämä selviää testaamalla. Hinta, väri, nopeus?
Mitä hyötyä A/B-testaamisesta on?
Rahakirstun päällä istujat saattavat ajatella, että varmaan tulee kalliiksi moinen testaaminen. “A/B-testaamisesta saadaan ihan konkreettista liiketoimintahyötyä”, Timo painottaa. “Siksi onkin tärkeää, että testausryhmällä on mandaatti riittävän korkealta tasolta. Ihanteellista olisi, että tiimissä on mukana sekä johtoa että data-analyysin osaamista.” Erityisen tärkeää tämä on silloin, kun testauksen perusteella aletaan tehdä korjauksia olemassa oleviin prosesseihin, kuten esimerkiksi tekemään käyttöliittymämuutoksia. Oikeaa dataa ei voida saada käyttöön ilman riittävän korkean tason lupaa.
“On turha seurata numeroita, jos numerot ovat pielessä. Oikein tehtynä yksittäinen testi ei ole kallis, kun verrataan siihen mitä on mahdollista saada aikaan”, sanoo Timo. “Testeissä yleensä tavoitellaan 95 % varmuutta tuloksesta. Jos tulos on tilastollisesti merkittävä ja positiivinen, testattu asia on toimiva. A/B-testausta ei kuitenkaan tehdä vain yhden asian takia, vaan tässä nimenomaan kerätään tuntemusta asiakkaista. Ennakko-oletukset voivat kumoutua täysin.”
Jatkuvaa ja sitkeää kehitystä
Usein A/B-testaus on jatkuvaa kehitystä: etsitään, missä ongelma on, ja muutetaan sitkeästi huonoja lukuja hyviksi luvuiksi prosessia optimoimalla. Testejä varten tiimi kehittää useita erilaisia ideoita ja laskee, miten pitkään testiä kannattaa pyörittää. Ideoita haetaan myös ulkopuolisten kanssa keskustelemalla – ja tietysti perinteisesti tutkailemalla, miten muut ovat asian tehneet.
Esimerkiksi verkkokaupassa Amazon ja muut isot nettikaupat ovat hyviä benchmarkeja. “Tosin mieluummin ei sitten kopioida niitä epärehellisiä keinoja, dark patterns, vaan hyvät jutut”, huomauttaa Timo. “Kun tarkastellaan isoissa nettikaupoissa käytettäviä keinoja, niin niissä esimerkiksi ohjataan käyttäjä vahvasti rekisteröitymiseen eikä sisäänkirjautumiseen: tämä ei vaikuta vanhojen asiakkaiden kirjautumisten määrään, mutta nostaa merkittävästi uusien asiakkaiden rekisteröitymisiä.” Myös negatiiviset vaikutukset tulee ottaa huomioon: yksi liikkuva osa saattaa vaikuttaa moneen asiaan. Kaikkia mittareita pitää seurata ainakin päällisin puolin.
A/B-testaajat eivät yleensä ole varsinaisesti osa kehitystiimiä vaan oma erillinen iskuryhmänsä. “Ollaan niin agiileja kuin agiili voi olla.” Testaustiimin työn tuloksena asetetaan vaatimuksia varsinaiseen kehitykseen. “Tämä ei ole mitään sankarikoodaamista – oma ego on syytä laittaa syrjään. Testausta varten tehtävä koodi on täysin kertakäyttöistä”, sanoo Timo.