Gyakorlati tanácsok A/B teszteléshez

Az előző bejegyezésben az A/B tesztelés alapjait mutattam be. A gyakorlati alkalmazás során előfordulhat pár tipikus eset, amelyre megéri előre felkészülni.

Hogyan teszteljünk, és hogyan ne?

Egyetlen jelentős különbség: Az eredeti és a módosított változat egyetlen jól meghatározható ponton különbözzön egymástól. Ha több változatás történik, akkor az átalakítás csak összességében értékelhető, így az egyes elemek szerepéről nem kapunk információt.

Párhuzamos tesztelés: A két változatot mindig párhuzamosan jelenítsük meg a meghatározott célcsoportnak. Ne szervezzük úgy a tesztet, hogy egy hétig az „A” változat jelenik meg mindenkinek, aztán pedig egy hétig a „B” változat. Ezzel kiküszöbölhetjük olyan külső tényezők hatását, amelyek meghamisíthatják az eredményünket. Ilyen lehet pl. ha az egyik időszakba egy hosszú hétvége, munkaszüneti nap, ünnepnap is beleesik, vagy ha az egyik héten nem ugyanaz a marketing kampány fut mint a másik héten.

Megfelelő időtartam: Ne állítsuk le túl hamar a tesztelést, hagyjunk időt arra, hogy valóban szignifikáns eredményeket kaphassunk. A tesztelés időtartamának becsléséhez használhatunk különböző kalkulátorokat, mint például a Visual Website Optimizer oldalán található A/B Split and Multivariate Test Duration Calculator eszközt.

Amennyiben nem áll rendelkezésünkre statisztikai háttértámogatás a teszt kielemzéséhez, a két verzió közötti eltérés szignifikanciáját a következő eszközzel ellenőrizhetjük: Split Test Calculator & Decision Tool

A kalkulátor által adott eredmény segít eldönteni, hogy leállítható-e a tesztelés, vagy a reális eredmény eléréséhez még további adatokra van-e szükség. (Abban az esetben, ha nem konverziót mérünk, a kalkulátor nem használható, ilyen esetekben részletesebb statisztikai elemzésre van szükség.)

Egyforma célközönség: A látogatók csoportba sorolásánál ügyeljünk arra, hogy mindkét csoportba egyforma felhasználók kerüljenek, ne használjunk semmilyen megkülönböztetést a kiválasztásnál. Ha pl. az egyik csoport látogatói más marketing kampányt látva érkeztek az oldalunkra, akkor lehet hogy jelentősen eltérő konverziós arányt fognak generálni, ennek az oka viszont nem a tesztelt oldal változtatása lesz, hanem a kampány hatása. Ezzel meghamisítjuk a tesztelés eredményét, és hamis következtetéseket vonhatunk le. Nemzetközi látogatottsággal rendelkező oldal esetén problémás lehet, ha kiválasztott országokon tesztelünk. Egyes országok között is lehet olyan demográfiai, preferenciabeli különbség, ami hibás következtetéseket eredményez.

Általánosságban elmondható, hogy a véletlenszerű besorolás a legmegbízhatóbb. Két csoportnál elterjedt megoldás az első látogatás időpontjának vizsgálata: ha az adott pillanatban az időbélyeg (vagy másodperc) páros, akkor az egyik csoportba kerül a látogató, ha páratlan, akkor pedig a másikba.

Régi látogatók kezelése: A változtatásokat igyekezzünk új látogatókon tesztelni. Ha egy már megszokott felületet megváltoztatunk, majd újra visszaalakítunk (mert a teszten mondjuk rosszul szerepelt) azzal bizonytalanságot kelthetünk a felhasználókban, ronthatjuk a komfortérzetüket.

Konzekvens megjelenítés: Ha egy látogatót egyszer egy A/B osztályba soroltunk, és annak megfelelően jelenítettünk meg a számára egy tartalmi elemet, akkor figyeljünk arra, hogy később is mindig ugyanazt a változatot lássa. Bizonytalanságot kelthet a felhasználóban, ha látogatásonként vagy akár lapletöltésenként ugyanaz az oldal más-más formában jelenik meg.

Ha egy elem többször is feltűnik az oldalon belül, ugyanezen elv alapján járjunk el. Ha egy funkció elnevezését teszteljük, akkor egy látogatónak mindenhol ugyanazt a variációt mutassuk: a menü, a címsor, a linkek mindenhol legyenek összhangban.

Teszt változat keresőindexelése: Törekedjünk arra, hogy a módosított variánsokat addig ne indexeljék a keresők, amíg azokat véglegesen nem alkalmazzuk. Ha egy rosszul megválasztott szövegezés kerül be a keresők adatbázisába, az nem szolgálja az oldalunk érdekeit.

Figyeljünk az ütemezésre: Ha egy oldalon egyszerre több független tesztet is futtatunk (vagy több fejlesztő dolgozik egy adott projekt különböző részein), akkor ügyeljünk arra, hogy a tesztek valóban függetlenek legyenek. Ha az A/B tesztek célcsoportjai fedik egymást, vagy az egyik tesztelt funkció egy másik tesztelt funkció egyik ágától függ, akkor a kapott eredmények hitelessége megkérdőjelezhető és akár hamis következtetésekre is juthatunk.

Több változós (multivariáns) tesztelés

Ha a weboldal megfelelő látogatottságú, akkor a tesztelést kibővíthetjük úgy is, hogy egy adott elemnek egyszerre több változatát is próbára tesszük, A/B/C/D… variációt készítünk belőle.

Multivariáns tesztelés tervezésekor dönthetünk úgy, hogy csak egyetlen elemet változtatunk meg és annak különböző változatait próbáljuk ki, de akár több különböző elem módosítását is elvégezhetjük. Az előkészítés ilyenkor több időt vesz igénybe, de gyorsabban eredményhez juthatunk azáltal, hogy nem páronként hasonlíthatjuk össze a változatokat, hanem párhuzamosan futtatjuk őket.

A felhasználók osztályba sorolása itt természetesen a variációk számától függően változik, 4 változatnál pl. a 25-25-25-25%-os elosztás a célszerű.  Látható, hogy ebben az esetben egy-egy változatra kevesebb látogató jut, így ha az oldal látogatottsága nem megfelelő, azzal a teszt eredményességét is kockára tehetjük.

Önellentmondás

Multivariáns teszteknél előfordulhat az, hogy a teszt eredménye önellentmondó. Ennek az oka az, hogy összehasonlítani mindig csak két változatot tudunk.

Ezt a legegyszerűbb egy példán szemléltetni: egy előfizetési csomagokat felkínáló oldalon az alábbi tesztet hajtjuk végre:

  • Kontrollcsoport: a csomagok növekvő sorrendben jelennek meg, a legnagyobb értéke 15.900
  • A csoport: a csomagok csökkenő sorrendben jelennek meg, a legnagyobb értéke 15.900
  • B csoport: a csomagok növekvő sorrendben jelennek meg, a legnagyobb értéke 19.900
  • C csoport: a csomagok csökkenő sorrendben jelennek meg, a legnagyobb értéke 19.900

A teszt eredménye a következő: C < K < A < B

Eszerint a leghatékonyabb megoldás a B változat, viszont az alábbi ellentmondást kapjuk: A és B külön-külön is jobbak, mint K, viszont az együttes hatásuk – C – gyengébb K-nál. Ilyen esetekben célszerű inkább több egyszerű A/B tesztet futtatni egymás után.

További ajánlott írások

Az A/B tesztekkel kapcsolatban további ajánlott írások (angol nyelven):

The Ultimate Guide To A/B Testing (Smashing Magazine)

An Introduction to Website Split Testing (Six Revisions)

30 Reasons to Use AB Split Testing for Conversion Optimization (Wider Funnel)

In Defense Of A/B Testing (Smashing Magazine)

Schmidi

Webfejlesztő, termékmenedzser, használhatósági hittérítő. Korábban a DoclerHoldingnál tevékenykedett, jelenleg az Extreme Digital csapatának tagja. A könnyen használható weboldalak, a usability és az információmegosztás lelkes híve.

4 thoughts on “Gyakorlati tanácsok A/B teszteléshez

  1. Szia Schmidi!

    Jó hogy időnként rád találok, így mindig olvasok nálad érdekes dolgokról. Kérdés: jellemzően mennyi mérés után lesz reális egy A/B teszt? Nyilván látogatószámban lehet mérni, és minél nagyobb a testesetszám annál jobb a méres, de eleve van-e értelme A/B-tesztelni kicsi látogatószám mellett? 1000-1000 A/B eset után már pl. ok?

    Extrém eset: ha ritkán néznek akkor az is félreviheti a tesztet, hogy mondjuk az ‘A’-t napközben nézték, a ‘B’-t meg mondjuk este. Az ilyen dolgokat a nagy esetszám tudja csak úm. elmosni. 🙂

    Az iménti ló másik fele, hogy lehet-e pl. hogy napi/heti lefolyása is van egy tesztnek? Pl. a hétközben nyerő az ‘A’ de hétvégén a ‘B’ vagy más jön be napközben és más este, más jön be pasiknak és más nőknek, stb… Nagy nézettségnél akár ilyen érdekességek is kijöhetnek…

    Szóval szerintem ne hallgas a fanyalgókra, érdekes dolgok ezek, és hasznosak is, akkor is, ha dedikált A/B teszter állásokat még nem is hirdetnek… 🙂

  2. Szia Nyözö!

    Igen, a tesztesetek száma a kulcs, de úgy gondolom nem lehet egyértelműen/univerzálisan számszerűsíteni.

    Az időtartam függ a látogatószámtól és a két változat eredményességének különbségétől is. Ha pl. olyan B változatot csinálsz, ami “lemossa” az A változatot, az jellemzően már hamar látszani fog az eredményekben (bár láttunk már csalóka tesztet, ami hosszabb idő alatt megfordult). Míg ha kicsi a különbség, akkor sokkal több teszt alany kell ahhoz, hogy megbízható eredményt kapj.

    Ennek a kiértékelésében segítenek a cikkben linkelt kalkulátorok, amik statisztikai elemzések eredményeit mutatják. Egy aktuálisan futó tesztünket elemezve pl.:
    A: 156806 visitor / 50511 goal / 32.21% conversion
    B: 156964 visitor / 53490 goal / 34.08% conversion

    Erre azt mondja: “Group B is a clear winner (99.9%*)”
    Tehát 99.9% bizonyossággal állítja, hogy a B a nyerő változat.
    (Általában 95% konfidenciaszint felett szokták az ilyeneket elfogadni.)

    Az első pár napban ez erősen ingatag volt, aztán pár nap után beállt fix B-re. Ha nagyobb lett volna a változtatás hatása, valószínűleg már az elején is egyértelműbb.

    Azt gondolom, hogy akár 1000-1000 esettel is érdemes lehet tesztelni, de mindenképp számolni kell vele, hogy a hiteles kiértékelés több időt fog igénybe venni, mint egy nagy látogatottságú oldalnál.

    Arra kevesebb esélyt látok, hogy más tetszik az embereknek reggel/este, hét közben/hétvégén, vagy hogy ennyire változna a látogatók eloszlása (hölgyek reggel, urak este, stb.). Egy hosszú hétvége, ünnepnap, hétvégi kánikula például látszani szokott a statisztikákban, de inkább általános forgalmi visszaesést mutat és nem a preferenciák változását.

    A megfelelő időtartamú teszt mindenesetre ezeket is kiegyenlíti.

    Dedikált A/B teszter állást nem hiszem, hogy bárki is hirdeti fog 🙂 Ez nem önálló pozíció, csak egy eszköz a marketing, fejlesztés eszköztárában.

  3. Érdekes a példádban levő számhalmaz. 🙂
    Nekem ott a problémám, hogy olyan oldalon kellene dönteni változatok között ahol gyakorlatilag nincs még látogató. Így nyilván ez a tesztmódszer sem alkalmas a döntéstámogatásra, illetve talán az lesz a jó megoldás, ha egy alaposabb átgondolás közben döntök hogy lyuk/fa aztán ha a lap beindul valamenynire, akkor mehetne ilyen tesztelésekkel finomítani, refaktorolgatni a cuccot.

    Az 1000-et amúgy azért kérdeztem, mert ugye pl. egy választás sem más mint egy A/B teszt, max. többszereplős. És a statisztikusok szerint az 1000 fő válasza már reprezentatív mintának számít a legtöbb esetben.

    Mindenesetre köszi a választ, azt hiszem olvasgatlak még ha lesz időm. 🙂

    1. Valóban, látogatók nélkül ez a módszer nem igazán lesz eredményes.

      Attól függ, hogy pontosan mit szeretnél tesztelni, indulás előtt érdemes használhatósági teszteket csinálni valós célközönségbe eső teszt felhasználókkal. Ha jól sikerül megfogalmazni a teszt feladatokat, akkor a teszt alanyok viselkedéséből sok minden kiderül.

      Nyilván itt a projekttől függ, hogy mennyire merül el benne az ember. Munkahelyi vagy fizetős privát munka, mekkora az igény/hajlandóság az ilyen jellegű tesztelésre a megrendelő esetén. Ha magán/hobby projekt, akkor mennyi szabad idő és energia van ilyesmikre…

      Lesz előbb-utóbb írás az ilyen tesztről is, addig egy korábbi előadásomat tudom ajánlani a témában: Usability tesztelés (Docler Akadémia)

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.