Egyoldalas vagy többlépéses pénztár a webshopban, melyiket válaszd

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

A pénztárban a vásárló már döntött, mégis sokan itt hagyják ott a kosarat. A webshopmotorok és a sablonok gyakran egyetlen kérdésre szűkítik a választást (egy oldal vagy több lépés), pedig a jó válasz a saját forgalmadon, a termékeiden és a szállítási beállításaidon múlik. Ebből a cikkből megtudod, milyen szempontok szerint dönts, hogyan méred a mostani pénztárad lépéseit GA4-ben, és mit ellenőrizz az átállás előtt és után. A szövegben külön jelöljük, mi hivatalosan igazolt, mi saját tapasztalat és mi szakmai feltételezés.

Mi a különbség az egyoldalas és a többlépéses pénztár között?

Az egyoldalas pénztár a kapcsolati adatokat, a szállítást, a fizetést és az összesítőt egyetlen oldalon kéri be, a többlépéses ugyanezt két-négy egymás utáni képernyőre bontja. A vásárlótól kért adat jellemzően ugyanannyi. A különbség abban van, mennyit lát belőle egyszerre, és mikor kap visszajelzést a hibáiról.

Van egy köztes forma is, a harmonika (accordion) pénztár. Ez technikailag egy oldal, de a szakaszok egymás után nyílnak ki, így a vásárló lépésenként halad. Sok WooCommerce-, Shopify- és hazai bérelt webshopsablon ilyet használ, ezért mielőtt átállásban gondolkodsz, nézd meg, valójában melyik típus fut nálad.

Melyik pénztártípust válaszd a saját webshopodhoz?

Kevés termékes, kisebb kosárértékű, sok visszatérő vásárlót kiszolgáló boltnál az egyoldalas pénztár jó eséllyel kevesebb súrlódással jár. Bonyolult szállítási opcióknál és magas kosárértéknél a jól tagolt többlépéses pénztár is jól működhet. Az alábbi öt szempont külön-külön nem dönt, együtt érdemes nézni őket. (Szakmai feltételezés, amit a saját adatoddal kell igazolni.)

Kosárérték

Kisebb kosárértéknél a vásárló gyorsan dönt, és minden újabb képernyővel nő az esély, hogy meggondolja magát. Magasabb kosárértéknél (bútor, műszaki cikk, gépalkatrész) többet mérlegel, és megnyugtathatja, ha lépésenként látja az összesítőt, korán megtudja a szállítási díjat és a várható átvételi módot. Saját tapasztalat, hogy drága termékeknél a vásárlók sokszor visszalépnek a kosárba ellenőrizni, ezért ott a „Vissza” gomb és a megőrzött mezőtartalom többet számít a lépések számánál.

Termékszám a kosárban

Ha a rendelések többsége egy-két tételes, egy oldalon elfér a termékösszesítő, és a vásárlónak nem kell sokat görgetnie a fizetésig. Sok tételes kosárnál (utántöltő, alkatrész, viszonteladói rendelés) az összesítő hosszú lista lesz, ami egyoldalas pénztárban a képernyő aljára tolja a fizetési részt. Ilyenkor egy összecsukható tétellista vagy egy külön ellenőrző lépés segíthet.

Visszatérő vásárlók aránya

Ahol sok a belépett, visszatérő vásárló, ott a mentett cím és fizetési mód miatt alig marad kitöltendő mező, így a többlépéses pénztár lépései szinte üresen futnak le. Nekik az egyoldalas pénztár vagy egy gyorsfizetési gomb (Apple Pay, Google Pay) kisebb terhet jelent. Ha főleg új vásárlóid vannak, a kötelező regisztráció többet árthat, mint maga a pénztár felépítése, ezért a vendégvásárlás legyen jól látható. Az arányt a GA4 új és visszatérő felhasználói bontása is mutatja, de a webshop rendelési adataiból pontosabban látod.

Mobilos forgalom

Mobilon egy hosszú egyoldalas pénztár sok görgetéssel jár, és a hibaüzenet könnyen a képernyőn kívülre kerül. A többlépéses változat rövidebb képernyőket ad, viszont minden lépés újabb betöltés, ami gyenge mobilnetnél lassú. Szakmai feltételezés, hogy mobilon a harmonika megoldás adja a legjobb egyensúlyt, de ezt eszközbontású tölcsérrel érdemes ellenőrizni.

Szállítási opciók bonyolultsága

A hazai webshopokban gyakran lehet házhozszállítás, több csomagpont-szolgáltató, csomagautomata és személyes átvétel közül választani. A csomagpont-választó térkép nehéz elem, és a mezők a választástól függenek, mert csomagpontnál nem kell szállítási cím, házhozszállításnál viszont kell. Ha ezek egy oldalon, egymás alatt váltakoznak, a vásárló könnyen elveszíti a fonalat. Bonyolult szállításnál egy külön szállítási lépés sokszor átláthatóbb, egyetlen futárszolgálatnál viszont fölösleges.

Hogyan rakd össze az öt szempontot?

Írd fel mind az öt szempontot, és mindegyik mellé, hogy a te boltodnál melyik típus felé húz. Ha négy-öt egy irányba mutat, a döntés viszonylag biztos. Ha megoszlanak, gyakran jobb a meglévő pénztárt javítani (mezők, sorrend, szállítási díj korábbi mutatása), mint egy teljes cserébe belevágni, mert a csere maga is hónapokra összezavarja az összehasonlítást. (Saját tapasztalat.)

Miért számít sokszor többet a mezők száma és sorrendje, mint a lépések száma?

A saját nézőpontunk az, hogy a lemorzsolódást ritkán a lépések száma okozza, sokkal gyakrabban egy rosszul elhelyezett vagy fölösleges mező. Egy háromlépéses pénztár tizenkét jól sorrendezett mezővel jó eséllyel könnyebb, mint egy egyoldalas, húsz mezővel, amelyből hármat a vásárló nem ért, mégis kötelező. (Saját tapasztalat és szakmai feltételezés, a te boltodban mérni kell.)

Ezeket érdemes átnézni a mezőknél:

• Tényleg kötelező minden mező? A második címsor, a cégnév és a megjegyzés legyen opcionális, és ezt jelöld is.
• Céges számla. Az adószámot és a cégnevet csak egy „Céges vásárlás” jelölőnégyzet bepipálása után mutasd, így a magánvásárlók nem is látják.
• Irányítószám elöl. Hazai címnél ha az irányítószám kerül előre, abból a település kitölthető, így eggyel kevesebb mezőt kell kézzel kitölteni, és eggyel kevesebb az elgépelés esélye. (Saját tapasztalat.)
• A számlázási cím egyezik a szállításival. Ez a jelölőnégyzet alapból legyen bepipálva, így a legtöbb vásárló megspórol egy teljes címblokkot. A WCAG 2.2 3.3.7-es (Redundant Entry) sikerkritériuma kifejezetten azt kéri, hogy egy folyamaton belül a korábban megadott adatot ne kelljen újra beírni. (Hivatalosan igazolt.)
• Automatikus kitöltés. A HTML autocomplete attribútum szabványos értékeivel (például email, tel, shipping postal-code) a böngésző maga kitölti a mezőket. A WCAG 2.2 1.3.5-ös sikerkritériuma is erre épít. (Hivatalosan igazolt.)
• Megfelelő billentyűzet mobilon. Telefonszámnál a type="tel", irányítószámnál az inputmode="numeric" hozza elő a számbillentyűzetet.

A sorrendnél az a szabály vált be nekünk, hogy előbb jöjjön, amit a vásárló fejből tud (e-mail, név, cím), utána a döntések (szállítási és fizetési mód), a végén az összesítő. Az e-mail cím azért is jó elöl, mert ha a vásárló félúton kilép, a webshop kosárelhagyási levelet küldhet neki, feltéve, hogy ehhez megvan a jogalap. (Saját tapasztalat.)

Hogyan méred a pénztár lépéseit GA4-ben?

A GA4-ben a pénztár lépéseit az ajánlott e-kereskedelmi eseményekkel méred, begin_checkout, add_shipping_info, add_payment_info és purchase sorrendben, majd ezekből tölcsért építesz. Az események nevét és paramétereit a Google dokumentációja rögzíti, és a GA4 beépített Checkout journey jelentése is ezekre épül. (Hivatalosan igazolt.)

Mely események kellenek?

1. view_cart a kosároldalon.
2. begin_checkout, amikor a vásárló belép a pénztárba.
3. add_shipping_info, amikor kiválasztotta a szállítási módot, a shipping_tier paraméterben a választott móddal.
4. add_payment_info, amikor kiválasztotta a fizetési módot, a payment_type paraméterrel.
5. purchase a sikeres rendelés után, egyedi transaction_id értékkel.

Mindegyik eseményhez tartozzon currency, value és items paraméter. Ezek nélkül a tölcsér megjelenik, de a bevételi bontás üres marad.

Hogyan mérsz lépéseket egy egyoldalas pénztárban?

Egyoldalas pénztárnál nincs új oldalbetöltés, ezért az eseményt egy felhasználói művelethez kell kötni. Az alábbi egyszerű gtag.js példa a szállítási mód kiválasztásakor küldi el az eseményt, a mezőnevet a saját sablonodhoz kell igazítani.

document.querySelectorAll('input[name^=shipping_method]').forEach(function (el) { el.addEventListener('change', function () { gtag('event', 'add_shipping_info', { currency: 'HUF', value: kosarErtek, shipping_tier: el.dataset.label, items: kosarTetelek }); }); });

Ha a vásárló többször vált szállítási módot, az esemény többször lefut. A tölcsért ez nem rontja el, mert a lépés elérését nézi, az eseményszámot viszont torzítja, ezért érdemes egy jelzővel csak az első választást beküldeni. WooCommerce-nél a GTM4WP bővítmény, Shopifynál a Google-csatorna küldi ezeknek az eseményeknek egy részét. Egyoldalas pénztárnál a DebugView-ban ellenőrizd, hogy tényleg a választás pillanatában futnak-e, és nem csak a rendelés leadásakor, egyszerre. (Saját tapasztalat.)

A mezőszintű lemorzsolódáshoz saját eseményt is küldhetsz, például checkout_field_error néven, egy field_name paraméterrel, amely csak a mező nevét tartalmazza. A paramétert egyéni dimenzióként regisztráld, különben nem látod a jelentésekben. A beírt értéket soha ne küldd el, mert a Google Analytics szabályai tiltják a személyazonosításra alkalmas adatok küldését. (Hivatalosan igazolt.)

Hogyan építed fel a tölcsért?

1. A GA4 Felfedezés (Explore) menüjében válaszd a tölcsér típusú felfedezést (Funnel exploration).
2. Lépésként add meg sorban a begin_checkout, add_shipping_info, add_payment_info és purchase eseményt.
3. Zárt tölcsért használj, ha azt akarod látni, ki halad végig sorban. Nyitottat akkor, ha arra vagy kíváncsi, hányan lépnek be középen, például egy mentett kosárból.
4. Bontásnak állítsd be az eszközkategóriát, így külön látod a mobilt és az asztali gépet.
5. Kapcsold be az eltelt idő megjelenítését, és az elhagyott lépéseknél nézd meg a következő műveletet.

Hogyan látszik az adatból, hol morzsolódnak le a vásárlók?

A tölcsérben a két egymást követő lépés közti legnagyobb arányú esés mutatja meg a lemorzsolódás helyét, az eszközbontásból pedig az is kiderül, hogy ez minden eszközön így van-e. A tipikus mintázatok (szakmai feltételezés, a saját boltodban ellenőrizni kell):

• Nagy esés a pénztár kezdete és a szállítás között. Gyakran itt derül ki először a szállítási díj, vagy itt jön a kötelező regisztráció. Segíthet, ha a díj már a kosárban látszik.
• Esés a szállítás és a fizetés között. Hiányzik a vásárló által várt fizetési mód (utánvét, átutalás, kártya), vagy a választás után váratlan pótdíj jelenik meg.
• Esés a fizetés és a vásárlás között. Ez lehet valódi kilépés a kártyás fizetési oldalon, de lehet mérési hiba is. Ha a vásárló a sikeres fizetés után nem tér vissza a köszönőoldalra, a purchase esemény nem fut le, a rendelés mégis létrejön. Ezt a lépést ezért mindig vesd össze a webshop admin felületén látható rendelésszámmal.
• Csak mobilon nagy az esés. Ez többnyire felületi gond (takart gomb, rossz billentyűzet, képernyőn kívüli hibaüzenet). Ilyenkor a mezőhiba-esemény és néhány munkamenet-felvétel többet elárul, mint a tölcsér.

Az eltelt idő is árulkodó. Ha a szállítási lépés átlagosan percekig tart, jó eséllyel a csomagpont-választó vagy a címmezők lassítanak. (Saját tapasztalat.)

Mit ellenőrizz az átállás előtt és után?

Átállás előtt legalább négy-hat hétnyi tiszta, ellenőrzött alapadatra van szükség, utána ugyanazzal a tölcsér-beállítással mérsz tovább. Ha közben a mérés is megváltozik, a két időszak nem vethető össze. (Az időtartam szakmai feltételezés, a szezonalitástól is függ.)

Átállás előtt

• Mind az öt e-kereskedelmi esemény megjelenik a DebugView-ban, a megfelelő pillanatban.
• A purchase események heti száma nagyjából egyezik az admin rendelésszámmal, és tudod, mekkora az eltérés.
• Oldalfrissítéskor nem keletkezik dupla vásárlás, mert a transaction_id egyedi.
• Elmentetted a tölcsér képét eszközbontásban, a pénztári konverziós arányt és az átlagos rendelésértéket.
• Feljegyezted a mezők listáját és sorrendjét, valamint a szállítási és fizetési módokat.
• Rögzítetted a futó kampányokat és akciókat, mert ezek elhúzzák az összevetést.

Átállás után

• Az első napon tesztrendelést adsz le minden szállítási és fizetési kombinációval, mobilon és asztali gépen is.
• Újra átnézed a DebugView-t, mert az új pénztársablon gyakran máshogy küldi az eseményeket.
• Az első hetekben naponta egyezteted a purchase eseményeket az admin rendelésszámmal.
• Az átállás napját megjegyzésként rögzíted a GA4-ben.
• Ugyanazzal a tölcsér-beállítással, eszközbontásban, összehasonlítható időszakot választva (azonos napok, hasonló kampányterhelés) veted össze az eredményt.

Mit tesztelj, ha a forgalmad nem elég egy A/B teszthez?

Kis forgalomnál egy teljes pénztárcserét A/B teszttel jó eséllyel nem tudsz megbízhatóan kiértékelni, ezért kisebb, egyenként mérhető változtatásokkal és minőségi módszerekkel érdemes haladni. A szükséges minta a mostani konverziós aránytól és a kimutatni kívánt különbségtől függ, és havi néhány tucat rendelésnél egy kisebb javulás sokszor statisztikailag nem látszik. (Szakmai feltételezés, a pontos számot egy mintaméret-kalkulátor adja meg.)

Ilyenkor ezek jöhetnek szóba:

• Egyszerre egy változtatás, előtte-utána méréssel. Például csak az irányítószám kerül előre, vagy csak a céges mezőket rejted el, és két-négy hétig figyeled a tölcsér adott lépését.
• Mezőhiba-esemény. A checkout_field_error számából kiderül, melyik mezőnél akadnak el a legtöbben, és ehhez nem kell nagy forgalom.
• Munkamenet-felvétel. Egy hőtérkép-eszköz (például Microsoft Clarity) felvételein látod, hol görget vissza vagy áll meg a vásárló. Előtte frissítsd a süti-tájékoztatót és a hozzájárulás-kezelést.
• Öt-hat fős használhatósági teszt. Kérj meg néhány embert, aki nem ismeri a boltot, hogy telefonon rendeljen, és közben hangosan gondolkodjon. A Nielsen Norman Group ajánlása szerint már néhány résztvevővel előkerül a legtöbb súlyos akadály.
• Mikroszöveg és elrendezés. A gombfeliratok, a szállítási díj helye és a kötelező mezők jelölése gyorsan cserélhető, és a hatása egy-egy lépésnél mérhető.

Ha a forgalom elbírja az A/B tesztet, akkor is egy lépésre vagy egy mezőcsoportra fókuszálj, és a teszt előtt rögzítsd a fő mutatót, vagyis hogy a pénztárt elkezdők közül hányan vásárolnak. Így az eredményt kevésbé zavarják a többi változók.

Források és további olvasnivalók

• Google Analytics súgó, ajánlott események és e-kereskedelmi mérés
• Google for Developers, GA4 e-kereskedelmi események (gtag.js)
• Google Analytics súgó, tölcsér típusú felfedezés
• Google Analytics súgó, a személyazonosításra alkalmas adatok kerülése
• web.dev, Payment and address form best practices
• WHATWG HTML Living Standard, az autocomplete attribútum
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2
• Baymard Institute, Checkout Usability kutatási anyagok
• Nielsen Norman Group, Why You Only Need to Test with 5 Users