Mobilalkalmazás felhasználói felület A/B tesztelésének lebonyolítása

A/B tesztelés mobilalkalmazáshoz

Az A/B tesztelés akkor hasznos, amikor egy mobilalkalmazásban két vagy több megoldás közül kell eldönteni, melyik működik jobban a valódi felhasználók szempontjából. Nem érzésre kell választani gombszínt, belépési folyamatot, kezdőképernyőt vagy értesítési szöveget, hanem mérhető adatok alapján. Én azt látom, hogy sok magánügyfél már akkor kér ilyen online szolgáltatást, amikor az alkalmazás alapvetően működik, de nem hozza a várt regisztrációt, vásárlást, foglalást vagy visszatérést.

A tesztelés távolról is jól végezhető, mert a szakember a leírás, a képernyőképek, az alkalmazás próbaverziója, az analitikai adatok és a mérési célok alapján dolgozik. A Qjob.hu felületén magánszemélyként is lehet olyan szabadúszót keresni, aki segít az ötlet pontosításában, a változatok összehasonlításában és az eredmények értelmezésében. Itt nem egy cégre kell várni, hanem egy konkrét online szakemberrel lehet egyeztetni.

Szerintem az A/B próba fő értéke nem az, hogy minden apró döntést igazol. Inkább az, hogy csökkenti a találgatást. Ha egy alkalmazásnál már van forgalom, akkor egy jól előkészített összehasonlítás gyorsan megmutathatja, hogy a felhasználók mit értenek meg könnyebben, hol akadnak el, és melyik változat hoz jobb eredményt.

A/B tesztelés célja

Az A/B tesztelés célja egy konkrét kérdés megválaszolása. Például az, hogy melyik kezdőképernyő ösztönöz több regisztrációt, melyik értesítési szöveg vezet több megnyitáshoz, vagy melyik fizetési oldalnál kevesebb a kilépés. Ha nincs pontos kérdés, a mérés könnyen szétesik.

Tapasztalatom szerint a jó teszt nem túl nagy. Egy időben csak kevés dolgot érdemes változtatni. Ha egyszerre módosul a szöveg, a gomb helye, a képernyő sorrendje és az ajánlat, akkor később nehéz megmondani, mi okozta az eltérést. A felhasználói viselkedés sokszor apró részleteken múlik, de az eredmény csak akkor értelmezhető, ha a mérés tiszta.

Volt olyan eset, amikor egy ügyfél csak egy új főoldali szöveget akart kipróbálni. A szabadúszó tesztelő először azt javasolta, hogy a cél ne a szöveg tetszése legyen, hanem az első művelet elvégzése. Így nem vélemények alapján döntöttek, hanem azt nézték, melyik változat után kezdik el többen a kívánt folyamatot. Ez egyszerűbb volt, és sokkal használhatóbb eredményt adott.

A/B próba előkészítése

Az A/B próba előkészítése a feladat pontos leírásával kezdődik. A megbízónak meg kell adnia, mit szeretne mérni, milyen változatok vannak, milyen felhasználói útvonal érintett, és milyen eredményt tekint elfogadhatónak. A szakember ezután meg tudja mondani, hogy a teszt valóban mérhető-e, vagy előbb rendbe kell tenni az eseménykövetést.

A jó előkészítés része a kiinduló állapot rögzítése is. Ide tartozik a jelenlegi konverzió, a meglévő forgalom, a célcsoport, az eszköztípusok aránya és az alkalmazás aktuális hibái. Ha az alapadatok pontatlanok, az összehasonlítás is bizonytalan lesz. Sokan ott hibáznak, hogy azonnal új változatokat akarnak indítani, miközben nem tudják, mit csinálnak most a felhasználók.

Egy online tesztelési feladatnál a kommunikáció általában üzenetekben, megosztott dokumentumban és képernyőképekkel történik. A fejlesztői hozzáférés nem mindig szükséges. Sokszor elég egy próbaverzió, egy részletes leírás, az analitikai képernyők és a célok listája. De ha eseményeket is kell ellenőrizni, akkor a szakembernek pontosabb technikai információkra lesz szüksége.

A/B tesztelés ára

Az A/B tesztelés ára attól függ, mennyire összetett a mérés, hány változatot kell összehasonlítani, és van-e már használható adatgyűjtés az alkalmazásban. Egy rövid szakmai terv olcsóbb, mint egy teljes folyamat, ahol a szakember a hipotézist, a mérési pontokat, az eredmények olvasását és a javítási javaslatokat is elkészíti.

A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent. Nem azért, mert minden drágább ajánlat jobb, hanem mert az adatok értelmezése időt igényel. Egy szabadúszó tesztelőnek meg kell értenie az alkalmazás célját, át kell néznie a változatokat, és külön kell választania a valódi eltérést a véletlen zajtól. Ez nem csak egy gyors kattintgatás.

Szerintem magánügyfélként akkor érdemes fizetni ilyen szolgáltatásért, ha már van mit mérni. Ha az alkalmazás még teljesen nyers, először használhatósági ellenőrzés vagy funkcionális teszt lehet hasznosabb. Ha viszont a fő folyamat működik, és a kérdés már az, melyik megoldás teljesít jobban, akkor az összehasonlító teszt valódi segítség.

A/B tesztelés online menete

Az online folyamat rövid egyeztetéssel indul. A megbízó elküldi az alkalmazás állapotát, a tesztelni kívánt változatokat és a célokat. A szakember visszakérdez, ha a cél túl általános. Például az, hogy jobb legyen az alkalmazás, nem elég. Az viszont már használható cél, hogy több felhasználó jusson el a regisztráció végéig.

Ezután készül egy tesztterv. Ebben szerepel a hipotézis, a két vagy több változat, a mérendő esemény, a szükséges időtartam és az eredmény értékelési módja. Nem minden feladatnál kell hosszú dokumentum. De a lényegnek írásban kell maradnia, mert így később nem keveredik össze, mi volt az eredeti kérdés.

A teszt futása alatt a szakember figyelheti az adatokat, de nem jó túl korán dönteni. Egy nap vagy néhány tucat felhasználó sokszor kevés. A mérés végén rövid összefoglaló készül. Ebben nem csak az áll, melyik változat nyert, hanem az is, mennyire biztos az eredmény, milyen kockázat maradt, és milyen következő lépés javasolt.

A megfelelő A/B tesztelő kiválasztása

A megfelelő szakember kiválasztásánál nem elég azt nézni, hogy valaki tesztelt-e már mobilalkalmazást. Fontos, hogy értse a mérési logikát, a felhasználói viselkedést és az alapvető analitikai fogalmakat. Egy jó szabadúszó tesztelő nem csak hibákat keres, hanem segít tisztázni, mit lehet egyáltalán bizonyítani.

Érdemes portfóliót, korábbi példákat vagy legalább egy rövid munkamódszert kérni. Nem kell üzleti titkokat megmutatnia, de látszania kell, hogy tud különbséget tenni vélemény, megfigyelés és adat között. Ha mindenre azonnal biztos választ ad, az inkább intő jel. Az A/B tesztelés sokszor valószínűségekkel dolgozik, nem teljes bizonyossággal.

A megbízónak az is fontos, hogy a szakember érthetően írjon. Egy bonyolult riport kevés hasznot ad, ha nem derül ki belőle, mit kell módosítani. Jó jel, ha a tesztelő már az elején rákérdez a célcsoportra, a jelenlegi forgalomra, a döntési határra és arra, hogy a fejlesztő mikor tudja beépíteni a változatokat.

Gyakori hibák A/B próbánál

Sokan ott hibáznak, hogy túl sok mindent akarnak egyszerre tesztelni. Ilyenkor a változatok már nem hasonlíthatók össze tisztán. Egy másik gyakori gond, hogy a teszt túl rövid ideig fut. Ha kevés a felhasználó, egy véletlen napi eltérés is nagy különbségnek látszhat.

Gyakori hiba az is, hogy a megbízó csak azt nézi, melyik változat tetszik jobban neki. Ez érthető, de nem ugyanaz, mint a felhasználói eredmény. Egy egyszerűbb, kevésbé látványos képernyő néha jobb teljesítményt ad, mert gyorsabban érthető. Tapasztalatom szerint ez sok ügyfélnek meglepő, főleg akkor, ha sok időt töltött a látványtervvel.

Probléma lehet a rossz mérési esemény is. Ha például csak a gomb megnyomását mérik, de a következő lépésnél sokan kilépnek, akkor a kép félrevezető. Az összehasonlító teszt akkor ad használható választ, ha a mérés a valódi üzleti vagy felhasználói célhoz kapcsolódik.

Eredmények és döntések az A/B teszt után

Az A/B teszt után nem mindig az a jó döntés, hogy az egyik változatot azonnal véglegesen be kell vezetni. Néha az eredmény egyértelmű. Máskor csak azt mutatja meg, hogy a különbség kicsi, vagy a méréshez több adat kell. Ez nem kudarc. Ez is információ.

A szakember feladata ilyenkor az, hogy közérthető következtetést adjon. Mi működött jobban, mi nem változott érdemben, és mit érdemes következőként vizsgálni. A jó összefoglaló nem túl hosszú, de tartalmazza a számokat, a feltételeket és a javaslatot. És ha az adat nem elég erős, ezt ki kell mondani.

Én azt látom, hogy a legjobb eredményt azok az ügyfelek kapják, akik nem egyetlen csodateszttől várnak megoldást. Inkább sorban javítják az alkalmazást. Először a belépést, aztán az első műveletet, később az értesítéseket vagy a fizetési folyamatot. Így az online munka nem elvont elemzés marad, hanem gyakorlati döntésekhez vezet.