Mikor állítsd le az A/B tesztet: leállási szabály előre rögzítve

Scheo · 2026-09-17 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Van egy hiba, ami többe kerül minden rosszul megírt tesztverziónál, minden félrekattintott gombszínnél és minden elfelejtett eseménynél: az, hogy a harmadik napon ránézel az eredményre, látod, hogy a B verzió 18 százalékkal jobb, és leállítod a tesztet. Utána hónapokig egy olyan változtatással élsz, ami valójában soha nem volt jobb, csak éppen akkor nézted meg, amikor a véletlen a B-nek kedvezett.

Ez a cikk erről a hibáról szól, és arról, hogyan lehet egyetlen A4-es oldallal kivédeni.

Miért csal meg a „már látszik a különbség” érzés?

Rövid válasz: mert az A/B teszt köztes állása nem egy lassan kirajzolódó igazság, hanem egy ide-oda ugráló véletlen szám, ami a futás elején szinte biztosan mutat majd látványos különbséget, akkor is, ha a két verzió pontosan ugyanolyan jó.

Gondolj a mérésre így: két teljesen azonos oldalt teszelsz egymás ellen. Nulla a valódi különbség. Ha minden reggel megnézed a p-értéket, és az első olyan napon leállsz, amikor 5 százalék alá esik, akkor előbb-utóbb le fogsz állni, pusztán azért, mert elég sokszor néztél oda. Ez nem babona és nem véleménykérdés: a statisztikai szakirodalomban ez az ismételt szignifikancia-vizsgálat problémája, és a hatása mérhető. Hivatalosan igazolt: a folyamatos belenézés melletti leállítás a névleges 5 százalékos téves riasztási arányt sokszorosára emelheti, annál nagyobb mértékben, minél gyakrabban nézel oda (lásd Johari és szerzőtársai 2017-es tanulmányát, valamint Kohavi és munkatársai kísérletezési szakkönyvét a források között).

A gyakorlatban ehhez jön két másik torzítás. Az egyik, hogy az első napokban aránytalanul sok a visszatérő, elkötelezett látogató, ők pedig máshogy viselkednek, mint a teszt teljes közönsége. A másik, hogy a kicsi mintán született „nyertes” eredmények szisztematikusan túlbecsülik a valódi hatást, mert csak a szerencsés kilengések jutnak el a szignifikancia-küszöbig. Saját tapasztalat: ha egy korán leállított teszt 30 százalék fölötti javulást mutat egy amúgy apró szövegmódosításra, az szinte mindig zsugorodik a nullához, amikor ugyanazt később rendesen, végigfuttatva újramérjük.

Mit jelent pontosan előre rögzíteni egy tesztet?

Rövid válasz: azt jelenti, hogy a teszt indítása előtt leírod, mikor és milyen adat alapján fogsz dönteni, és onnantól az adat dönt, nem te.

Négy dolgot kell rögzíteni, mielőtt az első látogató megérkezik.

Az elsődleges mérőszám

Pontosan egy mérőszám dönt. Nem három, nem „a konverzió és a kosárérték és a visszafordulás”. Ha több mérőszámot engedsz meg magadnak, akkor ugyanaz történik, mint a napi kukucskálásnál: valamelyik előbb-utóbb szignifikáns lesz, és utólag könnyű megtalálni az érvet, hogy éppen az volt a fontos. A többi mérőszám maradhat a dokumentumban másodlagos vagy őrszem címkével: ezekre ránézel, ezek jelezhetik, hogy valami elromlott, de a döntést nem hozhatják meg.

A minimális érzékelhető hatás

Ez az a legkisebb javulás, ami üzletileg még számít neked. Nem az, amit remélsz, hanem az, ami alatt nem érné meg bevezetni a változtatást. Ha egy gombfelirat cseréje 0,3 százalékpontnyi konverziót hozna, de az fedezné a munkát, akkor ez a szám a kiindulás. Minél kisebb hatást akarsz megbízhatóan kimutatni, annál nagyobb mintára van szükséged, és ez a viszony nem lineáris: a fele akkora hatás nagyjából négyszer akkora mintát kíván.

A mintaméret

Arányokra (például konverziós ráta) jó közelítés ez a hüvelykujjszabály, 95 százalékos megbízhatóság és 80 százalékos erő mellett, ágyanként:

• n = 16 * p * (1 - p) / d^2, ahol p a jelenlegi konverziós ráta tizedes törtben, d pedig az abszolút javulás, amit ki akarsz mutatni.
• Példa: jelenlegi ráta 2 százalék (p = 0,02), kimutatandó javulás fél százalékpont (d = 0,005). Ekkor n = 16 * 0,02 * 0,98 / 0,000025, ami nagyjából 12 500 látogató ágyanként, tehát összesen 25 ezer.
• Ha napi 600 látogató érkezik a tesztelt oldalra, ez körülbelül 42 nap, vagyis hat teljes hét.

Szakmai feltételezés: a legtöbb magyar kis- és középvállalati weboldalon éppen ez a számítás az, ami leleplezi a tesztelési terveket. Sok oldalnak egyszerűen nincs annyi forgalma, hogy értelmesen tudjon kis hatásokat mérni, és ilyenkor a helyes döntés nem a teszt korai leállítása, hanem az, hogy nem apró finomhangolásokat tesztelsz, hanem nagy, bátor változtatásokat, vagy egyáltalán nem tesztelsz, hanem szakmai megfontolás alapján döntesz, és vállalod.

A futásidő és a leállási feltétel

A futásidő a mintaméretből jön, de felfelé kerekítve teljes hetekre. A leállási feltétel pedig egyetlen mondat, amit előre leírsz, és ami után nincs mérlegelés.

Hogyan néz ki az egyoldalas tesztdokumentum?

Rövid válasz: nyolc sor, amit öt perc alatt kitöltesz, és ami utólag megakadályozza, hogy a saját reményeidhez igazítsd az eredményt.

Ezt a sablont másold be egy dokumentumba minden teszt indítása előtt, és töltsd ki az utolsó sorig. Ha bármelyik sor üresen marad, a teszt nem indul.

• 1. Hipotézis: Ha [változtatás], akkor [elsődleges mérőszám] javul, mert [miért, egy mondatban].
• 2. Elsődleges mérőszám: pontos definíció és esemény-név (például: ajanlatkeres_elkuldve esemény / munkamenet).
• 3. Másodlagos és őrszem mérőszámok: mit nézel még, de amitől NEM döntesz.
• 4. Kiindulási érték: az elmúlt 4 teljes hét mért értéke.
• 5. Minimális érzékelhető hatás: abszolút és relatív formában is.
• 6. Szükséges mintaméret: ágyanként X látogató, összesen Y.
• 7. Tervezett futásidő: ÉÉÉÉ-HH-NN-től ÉÉÉÉ-HH-NN-ig, N teljes hét, ünnepnapok kezelése.
• 8. Leállási feltétel: a tesztet a tervezett végnapon állítom le, a mintaméret elérése után. Korábbi leállítás csak műszaki hiba vagy mért károkozás esetén.
• 9. Nem szignifikáns eredménynél: mit teszek konkrétan.
• 10. Ki dönt és mikor: név és dátum.

A kilencedik sor a legfontosabb, és a legtöbb tesztdokumentumból hiányzik. Ha előre leírod, hogy „nem szignifikáns eredménynél maradunk az A verziónál, és a témát fél évig nem nyitjuk újra”, akkor az eredmény napján nem kell megküzdened azzal a kísértéssel, hogy „hátha még két hét”. A kísértés valódi, és a két hét toldozgatás pontosan ugyanaz a hiba, mint a napi kukucskálás, csak lassítva.

Miért kell teljes hetes ciklusokban futtatni?

Rövid válasz: mert a hétfői és a vasárnapi látogató nem ugyanaz az ember, és ha a teszted szerdától keddig tart, akkor az egyik szerdából kettő lesz, a te hibádból.

A legtöbb üzletben erős napszakos és heti mintázat van. Egy Székesfehérváron működő szervizt hétfő reggel keresik meg a leggyakrabban, egy éttermet péntek délután, egy B2B tanácsadót kedd és csütörtök között. Ha a teszt nem tartalmaz minden hétköznapot és hétvégét egyenlő számban, akkor az eredménybe beleszámolsz egy olyan különbséget, aminek semmi köze a változtatásodhoz.

Hivatalosan igazolt: a nagy kísérletezési platformok dokumentációja és szakirodalma egységesen legalább egy teljes hetes futást javasol, és a hét napja szerinti hatást külön torzító tényezőként kezeli. Saját tapasztalat: kéthetes futásnál szoktuk látni először, hogy a napi bontásban ugráló eredmény kisimul, és ilyenkor derül ki, hogy az első hét „nyertese” valójában egyetlen erős nap volt.

Gyakorlati szabály: a futásidő mindig egész számú hét, és lehetőleg ugyanazon a napon és nagyjából ugyanabban az órában indítod és zárod. Ha a mintaméret 9 napra jönne ki, akkor a teszt 14 napos, nem 9.

Hogyan kezeld az ünnepnapokat és a kampányidőszakokat?

Rövid válasz: az ünnepnap nem átlagos nap, ezért vagy kihagyod a tesztből, vagy a teszt eredményét csak arra az időszakra érvényesnek tekinted.

Magyarországon ez konkrét naptári kérdés: a húsvéti és pünkösdi hosszú hétvégék, augusztus 20., október 23., a november eleji hosszabbított hétvége, a karácsony és a két ünnep közötti időszak mind érdemben más forgalmat és más vásárlói szándékot hoz. Ugyanez igaz a Black Friday időszakára és a nagyobb saját akciókra.

Három használható megoldás van, sorrendben:

1. Kerüld el. A tesztet úgy ütemezd, hogy az ünnepi hét ne essen bele. Ez a legtisztább, és általában csak egy-két hét csúszást jelent.
2. Nyújtsd meg. Ha az ünnep belecsúszik, futtasd tovább annyival, hogy az ünnepi napok aránya mindkét ágban azonos legyen, és a torzítás elmerüljön a nagyobb mintában. Ez a mintaméretet növeli, tehát a dokumentumban a futásidőt írod át, nem a leállási szabályt.
3. Indítsd újra. Ha az ünnep alatt más kampány futott, más árazás élt, vagy az oldal tartalma is változott, akkor a teszt már nem azt méri, amit terveztél. Ilyenkor a tisztességes lépés az újraindítás, nem az adat megmentése.

Amit soha ne csinálj: ne vágd ki utólag a „rossz” napokat az adatból. Az adatszűrés a leállási szabály megkerülésének legelegánsabb formája, és pontosan ugyanoda vezet.

Mit tegyél, ha az eredmény nem szignifikáns?

Rövid válasz: a nem szignifikáns eredmény is eredmény, és a helyes válasz rá nem a hosszabbítás, hanem egy előre eldöntött lépés.

A dokumentum kilencedik sora három reális válasz közül az egyiket tartalmazza:

• Maradunk a jelenlegi verziónál. Ez az alapértelmezés. Ha a változtatás nem hozott mérhető javulást a rögzített minimális hatás fölött, akkor nem éri meg bevezetni, még akkor sem, ha neked jobban tetszik.
• Bevezetjük, de nem a mérés miatt. Van, hogy egy változtatás semlegesen teljesít, de más okból akarod (egyszerűbb karbantartás, akadálymentesség, márkakonzisztencia). Ezt szabad, csak mondd ki, hogy nem a teszt döntött.
• Újratervezzük a hipotézist. Ha az eredmény semleges, az gyakran azt jelenti, hogy túl kicsi változtatást teszteltél. A következő kör legyen bátrabb, ne finomabb.

Szakmai feltételezés: a semleges eredmények aránya a legtöbb kisebb oldalon magasabb, mint amire a cégvezetők számítanak, és ez nem kudarc. Az elkerült rossz bevezetés ugyanolyan értékes, mint egy megtalált jó változtatás, csak nem lehet vele dicsekedni.

Van olyan eset, amikor mégis szabad korán leállítani?

Rövid válasz: igen, kettő van, és mindkettőt előre bele kell írni a dokumentumba.

Az első a műszaki hiba vagy mért károkozás. Ha a B verzióban elromlik az űrlap, hibát dob a fizetés, összeesik a mobilnézet, vagy az őrszem mérőszám egyértelmű romlást mutat, akkor azonnal leállítod. Ez nem a leállási szabály megsértése, hanem a szabály része. Fontos, hogy ez egyirányú kapu: a romlás miatti leállítás megengedett, a javulás miatti nem.

A második a szekvenciális teszt. Léteznek olyan statisztikai eljárások (csoportos szekvenciális tesztek, mindig érvényes p-értékek), amelyek eleve úgy készültek, hogy menet közben is szabad legyen belenézni az adatba, mert a többszöri vizsgálatot beépítik a számításba. Hivatalosan igazolt: több nagyobb kísérletezési platform dokumentációja leírja ezt a megközelítést, és több tesztelő eszköz alapértelmezésben ilyen módszert használ. A lényeg viszont változatlan: ilyenkor is előre kell eldöntened, hogy szekvenciális módszerrel futtatsz, és a leállási feltételed akkor is egy előre rögzített, matematikailag korrekt küszöb, nem a szemmérték.

Amit nem tekintünk kivételnek: „a főnök kérte”, „kifogyunk az időből”, „már úgyis látszik”, „csak még egy hetet”.

Miért számít ez az AI-válaszok és a keresés szempontjából is?

Rövid válasz: mert a tesztelés technikai megvalósítása befolyásolhatja, hogyan látja az oldalt a kereső és a válaszmotorok crawlerje, és mert a kapkodó leállítás után bevezetett változtatások gyakran pont a válaszolható tartalmat rontják el.

Hivatalosan igazolt: a Google Search Central dokumentációja külön iránymutatást ad a weboldalas tesztekre. A lényege, hogy a teszt ne minősüljön eltérő tartalom kiszolgálásának a kereső felé (ne mutass mást a botnak, mint a felhasználónak), a variánsokon használj rel=canonical hivatkozást az eredeti oldalra, átirányításnál ideiglenes (302) átirányítást alkalmazz, és a tesztet csak addig futtasd, ameddig az eredményhez szükséges. Ez az utolsó pont éppen azt támogatja, amiről az egész cikk szól: a futásidőt előre meg kell tervezni, mert a végtelenségig nyitva hagyott teszt is probléma, nem csak a korán lezárt.

Szakmai feltételezés: a válaszmotorok és AI-asszisztensek szempontjából a stabilitás önmagában is érték. Ha egy oldal tartalma hetente ugrál, mert minden félbehagyott teszt után átírtok valamit, akkor nehezebb rá hivatkozni, és a korábban idézett megfogalmazás eltűnhet. Ezt hivatalos dokumentáció nem mondja ki így, de a gyakorlat és a hivatkozás-stabilitásról szóló általános megfontolások ebbe az irányba mutatnak.

Milyen ellenőrzőlistát futtass indítás előtt és után?

Rövid válasz: indítás előtt hét pontot, leállás után négyet, és mindkettőt írásban.

Indítás előtt:

1. Az elsődleges mérőszám eseménye valóban él, és tesztkörnyezetben leellenőrizted, hogy tüzel.
2. Az A és a B verzió közötti különbség pontosan egyetlen, leírható változtatás.
3. A forgalom elosztása 50-50, és nem zárja ki a mobilos vagy a visszatérő látogatókat.
4. A mintaméret kiszámolva, a futásidő teljes hetekre kerekítve.
5. A futásidőbe nem esik ünnepnap, kampánycsúcs vagy tervezett fejlesztés.
6. A variánsokon rendben van a rel=canonical, és nem szolgálsz ki eltérő tartalmat a crawlereknek.
7. A dokumentum kilencedik sora ki van töltve, és a döntéshozó elolvasta.

Leállás után:

1. Ellenőrizd a minta kiegyensúlyozottságát: ha az egyik ágba érdemben több látogató került, valami elromlott a kiosztásban, és az eredmény gyanús.
2. Nézd meg a napi bontást, de csak azért, hogy kiszúrd a mérési hibát, nem azért, hogy jobb napot keress.
3. Az eredményt a rögzített minimális hatáshoz mérd, ne a nullához.
4. Írd le a döntést és a dátumot ugyanabban a dokumentumban, alá.

Mi a lényeg, ha csak egy dolgot viszel el?

A saját nézőpontom ebben határozott: a leállási szabályt utólag megváltoztatni annyi, mint nem tesztelni. Ha a teszt közben mozdítod el a célvonalat, akkor nem mérést végeztél, hanem alátámasztást gyűjtöttél egy döntéshez, amit már meghoztál. Az ilyen tesztnek negatív értéke van, mert nemcsak hogy nem tanulsz belőle, hanem magabiztosságot ad egy megalapozatlan változtatáshoz, és gyakran fél évre lezárja a kérdést.

Az egyoldalas dokumentum öt percbe kerül, és pontosan ezt az egy hibát zárja ki. A nehéz része nem a statisztika, hanem az, hogy a harmadik napon nem nyúlsz hozzá. Erre nincs eszköz, csak megállapodás magaddal és a csapattal, előre, írásban.

Források és további olvasnivalók

• Google Search Central: Website testing and Google Search (A/B és több változatos tesztek keresőbarát megvalósítása)
• Google Analytics Súgó: kísérletek, mérési alapfogalmak és eseménykonfiguráció
• Ron Kohavi, Diane Tang, Ya Xu: Trustworthy Online Controlled Experiments (Cambridge University Press)
• Johari, Koomen, Pekelis, Walsh: Peeking at A/B Tests, KDD 2017
• Evan Miller: How Not to Run an A/B Test (szakmai írás az ismételt szignifikancia-vizsgálatról)
• NIST/SEMATECH e-Handbook of Statistical Methods (mintaméret, statisztikai erő, hipotézisvizsgálat)
• Optimizely Developer Documentation: Stats Engine és szekvenciális tesztelés
• Microsoft Experimentation Platform (ExP) publikációi az online kontrollált kísérletekről