A/B teszt indítása előtt: a mérési előfeltételek ellenőrzése

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

Egy A/B teszt annyit ér, amennyit a mérése. Ha a konverziós esemény kétszer fut le, ha a riportban nem látod, melyik látogató melyik változatot kapta, vagy ha a teszt közben valaki átírja a hirdetéseket, a végén kapsz egy számot, ami pontosnak látszik, mégsem igaz. Ez a cikk a teszt indítása előtti napokról szól, vagyis arról a mérési alapról, amit rendbe kell tenni, mielőtt az első látogató belekerül a kísérletbe. Az eredmény értelmezéséről és a leállítás időpontjáról külön írásokban foglalkozunk.

A szövegben háromféle jelölést használunk. Hivatalosan igazolt az, ami a Google vagy más platform dokumentációjában, illetve a szakirodalomban szerepel. Saját tapasztalat az, amit mérési beállítások átvizsgálásakor újra és újra látunk. Szakmai feltételezés az, ami logikusan következik, de általános érvénnyel nem bizonyított.

Miért rosszabb a rosszul mért teszt, mint a meg nem tartott?

A meg nem tartott teszt után tudod, hogy nem tudsz semmit. A rosszul mért után azt hiszed, hogy tudsz. A hibás adatra épített döntést a csapat bizonyítottnak tekinti, és hónapokig senki nem kérdőjelezi meg.

Szakmai feltételezés. A mérési hiba ritkán véletlenszerű. Ha a B változat gombja más kattintáskezelőt használ, és emiatt az esemény kétszer rögzül, a hiba mindig a B javára dolgozik. Az ilyen szisztematikus torzítás nagy mintán sem tűnik el, a nagyobb minta miatt a hamis különbség ráadásul még szignifikánsnak is látszik. A statisztikai próba azt vizsgálja, lehet-e véletlen a két szám közti eltérés. Arról semmit nem mond, hogy maguk a számok jók-e.

Mi legyen az elsődleges cél, és miért csak egyetlen esemény?

Az elsődleges cél egyetlen, előre megnevezett esemény legyen, amelynek neve, feltétele és számolási módja a teszt indítása előtt írásban rögzítve van. Ha csak a végén választod ki, melyik mutató alapján nyert a változat, szinte mindig találsz nyertest.

Több mutatót nézni nem tilos. A gond ott kezdődik, amikor mindegyik egyenrangú. Húsz független mutatóból 5%-os szignifikanciaszinten átlagosan egy akkor is „nyerni” fog, ha a két változat valójában egyforma. Ez a többszörös összehasonlítás problémája, amelyet a statisztika régóta ismer.

A gyakorlatban ezt a négy dolgot érdemes leírni.

• Elsődleges esemény. Például generate_lead, ami csak a sikeres űrlapküldés visszaigazolásakor fut le, a gomb megnyomásakor még nem.
• Számolási egység. Felhasználóra vetítve számolsz (hány látogató küldött legalább egy űrlapot), vagy eseményre (hány űrlap jött összesen). A kettő eltérő eredményt adhat, ezért előre dönts.
• Védő mutatók. Kettő-három szám, amelynek nem szabad romlania, például a visszafordulási arány vagy az átlagos kosárérték. Ezek alapján nem hirdetsz győztest, csak figyelmeztető jelnek használod őket.
• Időablak. Meddig számít bele egy konverzió az adott látogatáshoz, ugyanabban a munkamenetben vagy például 7 napon belül.

Saját tapasztalat. A leggyakoribb hiba, hogy az elsődleges esemény a gombkattintás. Kattintást a hibás kitöltés, a dupla kattintás és a validációs hiba is kivált, így egy zavarosabb űrlapot mutató változat több „konverziót” hozhat, miközben kevesebb érdeklődő jut el valójában hozzád.

Honnan tudod, hogy az eseménygyűjtés működik és nem duplikál?

Onnan, hogy minden változatban, minden eszköztípuson végigcsinálod a konverziót, és a hibakereső nézetben pontosan egy eseményt látsz a megfelelő paraméterekkel. Amíg ezt nem láttad a saját szemeddel, a mérés csak feltételezés.

Hivatalosan igazolt. A Google Analytics 4 DebugView felülete és a Google Tag Manager előnézeti módja (Tag Assistant) arra készült, hogy valós időben lásd, milyen események és paraméterek mennek ki. A GA4 dokumentációja szerint a vásárlási eseményeknél a transaction_id paraméter segít kiszűrni az ugyanahhoz a tranzakcióhoz tartozó ismételt vásárlás-eseményeket.

Hogyan ellenőrizd lépésről lépésre?

1. Állítsd be, hogy az A változatot kapd (a tesztelő eszközök többsége ad erre előnézeti linket vagy URL-paramétert), és teljesítsd a konverziót.
2. A DebugView-ban számold meg az elsődleges eseményt. Pontosan egyet kell látnod.
3. Frissítsd a köszönőoldalt. Ha az esemény újra lefut, a köszönőoldalra kötött mérés duplikál.
4. Lépj vissza, majd előre a böngészőben, és nézd meg ugyanezt.
5. Kattints duplán a küldés gombra, hogy lásd, két esemény megy-e ki.
6. Ismételd meg az egészet a B változatban, mobilon és asztali gépen is.
7. Ellenőrizd, hogy az esemény nem fut-e két forrásból egyszerre, például a GTM-ből és egy bővítmény beépített követéséből.

Ha a köszönőoldal frissítése duplikál, egyszerű védelem, ha a böngésző munkamenet-tárában megjegyzed, hogy az esemény már elment.

var key = 'lead_sent_' + formId; if (!sessionStorage.getItem(key)) { dataLayer.push({ event: 'generate_lead', form_id: formId }); sessionStorage.setItem(key, '1'); }

Ez egy munkameneten belül véd. Webshopnál a tranzakcióazonosító szerveroldali ellenőrzése megbízhatóbb, mert független a böngészőtől.

Saját tapasztalat. A B változatban gyakran átépül az oldal egy része, és a régi eseményfigyelő (például egy CSS-szelektorra kötött kattintás-trigger) egyszerűen nem talál elemet. A mérés ilyenkor hibaüzenet nélkül nullát ad a B-re. Ezt csak a változatonkénti előzetes végigkattintás fogja meg.

Hogyan különböztesd meg a variánsokat a riportban?

Minden látogatónál rögzítsd a teszt azonosítóját és a kapott változatot egy saját dimenzióban, még a konverzió előtt, és ellenőrizd, hogy a riportban szűrni tudsz rá. Ha a változat csak a tesztelő eszközben látszik, az analitikában nem, a két rendszer számait nem tudod összevetni.

Hivatalosan igazolt. A GA4-ben az eseményparamétereket és a felhasználói tulajdonságokat egyéni dimenzióként kell regisztrálni ahhoz, hogy a riportokban megjelenjenek, és a regisztráció előtti adatokra a dimenzió visszamenőleg nem töltődik fel. Ezért a dimenziót a teszt indítása előtt kell létrehozni. A Google a saját tesztelő eszközét, a Google Optimize-t 2023 szeptemberében megszüntette, azóta külső eszközt vagy saját megoldást kell használni.

Egy lehetséges jelölés a dataLayerben, abban a pillanatban, amikor a tesztelő eszköz kiosztotta a változatot.

dataLayer.push({ event: 'experiment_impression', experiment_id: 'ajanlatkeres_cta_1', variant_id: 'B' });

A GA4-ben az experiment_id és a variant_id paramétert egyéni dimenzióként regisztrálod. Ha a konverzió később, egy másik munkamenetben is megtörténhet, a változatot felhasználói tulajdonságként is érdemes eltárolni, különben a késői konverzió változat nélkül érkezik.

Indítás előtt futtass egy próbaidőszakot belső forgalommal, és nézz meg két dolgot.

• Megjelenik-e mindkét változat a riportban a várt arányban.
• Nagyságrendben egyezik-e a tesztelő eszköz és az analitika látogatószáma változatonként. Tökéletes egyezés ritka, de ha az egyik rendszerben 30%-kal kevesebb a B, az mérési hibára utal.

Hivatalosan igazolt. A kiosztási arány eltérését (sample ratio mismatch, SRM) a kísérletezési szakirodalom, például Kohavi, Tang és Xu könyve, az egyik legfontosabb megbízhatósági ellenőrzésként írja le. Ha 50/50 kiosztást terveztél, és 10 000 látogatóból 5 300 és 4 700 a megoszlás, az a véletlenből nagyságrendileg egy a milliárdhoz eséllyel jönne ki. Valami tehát eltérően oszt vagy eltérően mér. Az ellenőrzés egy sor.

from scipy.stats import chisquare; print(chisquare([5300, 4700]).pvalue)

Ezt a próbát a teszt első napjai után már érdemes lefuttatni, és a teendőt előre eldönteni arra az esetre, ha eltérést mutat.

Hogyan torzítja a hozzájárulás miatti adatvesztés a mintát?

A cookie-hozzájárulást elutasító látogatók egy része kiesik a mérésből, így a teszt valójában a hozzájárulók körében fut. Ez akkor veszélyes, ha a két változatban eltér a hozzájárulási arány, vagy ha a hozzájárulók másként viselkednek, mint a teljes közönség.

Hivatalosan igazolt. A Google Consent Mode alapváltozatában elutasítás esetén a Google-címkék nem küldenek adatot. A fejlett változatban hozzájárulás nélkül is mennek cookie nélküli jelzések, és a GA4 ezekből viselkedési modellezéssel pótolhatja a hiányt, ha a tulajdon eléri a dokumentációban megadott forgalmi küszöböket.

Szakmai feltételezés. A modellezés összesített szinten becsül, egyedi látogatóhoz nem rendel tesztváltozatot. A változat szerinti bontásban ezért jó eséllyel csak a hozzájárulók szerepelnek. Ha a hozzájárulók és az elutasítók vásárlási hajlandósága eltér, az eredmény a hozzájárulókra érvényes, a teljes közönségre csak óvatosan általánosítható.

Saját tapasztalat. A hozzájárulási arány erősen függ a banner kialakításától, és a mobilos meg az asztali arány gyakran látványosan eltér. Ha a tesztelt változtatás a hajtás feletti részt érinti, és ezzel eltakarja vagy áthelyezi a bannert, a két változat eltérő hozzájárulási arányt hozhat. Ilyenkor a különbség egy része a mérhetőségből jön, a viselkedéshez nincs köze.

Indítás előtt ezeket érdemes megtenni.

• Mérd meg a jelenlegi hozzájárulási arányt eszköztípusonként, hogy lásd, a forgalom mekkora része látszik egyáltalán.
• Számold újra a szükséges mintaméretet a látható forgalomra. Ha a látogatók 55%-a járul hozzá, a teszt a tervezettnél nagyjából 1,8-szor tovább tart.
• Vedd fel a hozzájárulási arányt változatonkénti védő mutatónak.
• Ha a tesztelő eszköz sütit használ a kiosztáshoz, az adatvédelmi felelőssel tisztázd, melyik hozzájárulási kategóriába tartozik, és mi történik az elutasítókkal.

Miért ne változtass semmin a tesztidőszak alatt?

Mert minden egyéb változás eltérően hathat a két változatra, és utólag nem választható szét, mi okozta a különbséget. A tesztidőszakban a forgalom forrása, az ajánlat és az oldal többi része maradjon a lehető legállandóbb.

A leggyakoribb zavaró változtatások ezek.

• Új hirdetési kampány vagy költségkeret-emelés, ami más szándékú látogatókat hoz.
• Akció, kupon vagy szállítási feltétel módosítása.
• Bővítmény- vagy témafrissítés, ami a mérést vagy az oldal sebességét érinti.
• Új címke vagy átírt trigger a címkekezelőben.
• Hírlevél-kiküldés, ami egyszerre sok visszatérő látogatót hoz.

Saját tapasztalat. Az ilyen változtatást legtöbbször jó szándékkal végzi egy kolléga, aki nem tud a tesztről. Egy rövid, írásos fagyasztási megállapodás (mit nem módosítunk, meddig, ki felel érte) többet ér bármilyen utólagos korrekciónál. A GTM munkaterület leírásába is érdemes beírni, hogy teszt fut.

Hivatalosan igazolt. A Google Search Central tesztelési útmutatója szerint a tesztet csak addig érdemes futtatni, ameddig szükséges, átirányításos tesztnél 302-es (ideiglenes) átirányítást kell használni, a variáns-URL-eken rel=canonical hivatkozás mutasson az eredetire, és a Googlebot ugyanazt lássa, amit a látogatók.

Mi legyen az indítás előtti ellenőrzőlistán?

Az alábbi lista akkor teljes, ha minden pont mellé oda tudod írni, ki ellenőrizte és mikor.

1. Az elsődleges esemény neve, feltétele és számolási egysége írásban rögzítve.
2. Két-három védő mutató kijelölve.
3. A hipotézis egy mondatban leírva (mit változtatsz, milyen hatást vársz, miért).
4. A szükséges mintaméret és a várható futási idő kiszámolva a hozzájáruló forgalomra.
5. Mindkét változatban, mobilon és asztalon végigkattintva, a DebugView-ban pontosan egy elsődleges esemény látszik.
6. Oldalfrissítés, visszalépés és dupla kattintás nem okoz duplikációt.
7. Az experiment_id és a variant_id egyéni dimenzióként regisztrálva, és a próbaadatban megjelenik.
8. A tesztelő eszköz és az analitika változatonkénti látogatószáma nagyságrendben egyezik.
9. Az SRM-ellenőrzés időpontja és a teendő eltérés esetén előre eldöntve.
10. A belső forgalom (saját gépek, fejlesztők) szűrve.
11. A hozzájárulási arány változatonként mérhető.
12. Írásos fagyasztási megállapodás a tesztidőszakra (kampány, ajánlat, címkék, bővítmények).
13. Rögzítve, hogy a teszt végén ki dönt, és milyen szabály alapján.

Saját tapasztalat. Egy egyszerű, egyetlen űrlapra épülő teszt mérési előkészítése jellemzően fél-egy munkanapot vesz igénybe. Ennek nagy része a végigkattintás és a hibák javítása, maga a beállítás gyorsan megvan.

Mikor ne indítsd el a tesztet?

Ha az alábbiak közül bármelyik igaz, várj az indítással. Ilyenkor a teszt jó eséllyel olyan választ ad, amit később nem tudsz megvédeni.

• Ne indítsd el, ha nem tudod egy mondatban megmondani, melyik esemény dönt.
• Ne indítsd el, ha az elsődleges esemény a gombkattintás, és a sikeres művelet visszaigazolását nem méred.
• Ne indítsd el, ha a változatonkénti végigkattintás még nem történt meg.
• Ne indítsd el, ha a riportban nem tudod változat szerint szűrni az adatot.
• Ne indítsd el, ha a látható forgalomból a szükséges minta csak hónapok alatt gyűlne össze. Ilyenkor érdemesebb egy merészebb változtatást tesztelni, vagy kvalitatív módszerhez fordulni (felhasználói interjú, munkamenet-felvétel).
• Ne indítsd el, ha a tesztidőszakra olyan akció, kampányindítás vagy szezonális csúcs esik, amit nem tudsz elhalasztani.
• Ne indítsd el, ha a mérést az indítás napján még módosítják.
• Ne indítsd el, ha senki nem felel azért, hogy a teszt alatt rendszeresen ránézzen az SRM-re és a védő mutatókra.

Egy elhalasztott teszt semmibe nem kerül, csak időbe. Egy rosszul mért teszt viszont olyan döntést hagy maga után, amit mindenki igaznak hisz.

Források és további olvasnivalók

• Google Analytics súgó, GA4 DebugView és egyéni dimenziók
• Google Analytics súgó, Consent Mode és viselkedési modellezés
• Google Tag Manager súgó, előnézeti mód és Tag Assistant
• Google for Developers, GA4 ajánlott események (generate_lead, purchase, transaction_id)
• Google Search Central, Website testing and Google Search
• Európai Adatvédelmi Testület (EDPB), 05/2020 iránymutatás a hozzájárulásról
• Ron Kohavi, Diane Tang, Ya Xu, Trustworthy Online Controlled Experiments, Cambridge University Press, 2020