A legtöbb webshop tulajdonos látja, hogy a pénztárba lépők jelentős része nem fizet. Azt viszont ritkán tudja megmondani, melyik mezőnél állt meg a vásárló. Pedig a pénztár-űrlap sokszor olyan okból akasztja meg a megrendelést, aminek semmi köze az árhoz vagy a bizalomhoz. A vásárló helyesen írja be a címét, a rendszer mégis elutasítja, ő pedig egy idő után feladja. Ez a cikk abban segít, hogy ezeket a néma megállásokat megtaláld, mérni tudd, és eldöntsd, mit kell javítani.
A cikkben háromféle jelölést használunk. [Hivatalosan igazolt] az, ami szabványban vagy hivatalos dokumentációban szerepel. [Saját tapasztalat] az, amit pénztár-átvizsgálások során rendszeresen látunk. [Szakmai feltételezés] az, ami logikus következtetés, de általános érvénnyel nem bizonyított.
Hol akad el leggyakrabban a vásárló a pénztárban?
A legtöbb néma megállás négy helyen történik, az irányítószámnál, a házszámnál, az adószámnál és ott, ahol a böngésző automatikus kitöltése ütközik a webshop saját ellenőrzésével. Közös bennük, hogy a vásárló szerint az adat jó, a rendszer szerint nem.
Irányítószám-ellenőrzés
A magyar irányítószám négy számjegy, ezt egyszerű ellenőrizni. A gond általában a ráépülő logikával van. Sok bővítmény az irányítószámból kitölti a települést, vagy összeveti a kettőt, és eltérésnél tilt. Budapesten ez rendszeresen félremegy, mert a vásárló „Budapest XI. kerület” alakot ír, a rendszer pedig csak a „Budapest” alakot fogadja el. Hasonló hiba, ha az adatbázis elavult, vagy ha a webshop külföldre is szállít, de a mező fixen négy számjegyet vár, így egy osztrák vagy német vásárló el sem jut a fizetésig. Szóköz a szám előtt vagy után, esetleg egy véletlen betű a mobilbillentyűzetről szintén elég egy elutasításhoz.
Házszámformátum
Ha a házszám külön mező, és a validáció csak számot fogad el, akkor a valós magyar címek egy része eleve beírhatatlan. Ilyen a „12/A”, a „12-14”, a „3. em. 5.”, vagy tanyás, külterületi címnél a helyrajzi szám. [Saját tapasztalat] A túl szigorú házszám-szabály az egyik leggyakoribb oka annak, hogy ugyanaz a vásárló kétszer-háromszor egymás után próbálja beküldeni az űrlapot, aztán kilép.
Adószámmező
A belföldi adószám 11 számjegy, a megszokott alakja 12345678-1-42. A vásárlók egy része kötőjel nélkül, szóközzel vagy „HU” előtaggal írja be, mert a közösségi adószámot szokta használni. Ha a mező csak a pontos, kötőjeles alakot fogadja el, a céges vásárló, aki pedig gyakran nagyobb kosárral érkezik, elakad. Másik tipikus hiba, hogy az adószám rejtetten is kötelező, vagyis akkor is hibát dob, ha a vásárló magánszemélyként rendel, és a mezőt nem is látja. Hogy céges vásárlótól mikor és milyen adatot kell kérni a számlához, azt a könyvelőddel egyeztesd. A mérés és a szövegezés szempontjából annyi a fontos, hogy a mező csak ott legyen kötelező, ahol ez valóban szükséges.
Automatikus kitöltés ütközése
A böngészők és a jelszókezelők a mezők autocomplete attribútuma alapján töltenek. [Hivatalosan igazolt] A HTML szabvány meghatározott tokeneket ír elő, például postal-code, address-line1, address-level2 (település) és tel. Ha ezek hiányoznak vagy rosszak, a teljes cím az első címsorba kerülhet, a házszám mező pedig üres marad. Gyakori az is, hogy a webshop ellenőrzése a mező elhagyásakor fut, az automatikus kitöltés viszont nem mindig váltja ki ezt az eseményt. Ilyenkor a mezőben ott az adat, mellette mégis piros hibaüzenet áll. A telefonszámnál a „+36” és a „06” alak keveredik, és ha a mezőnek túl rövid a maximális hossza, a böngésző által beírt szám vége levágódik.
Milyen eseményeket kell mérni mezőszinten?
Mezőszinten öt dolgot érdemes mérni, a mező fókuszba kerülését, a validációs hibát (melyik mező, milyen típusú hiba), a beküldési kísérletet, a sikertelen beküldést és a sikeres továbblépést. A beírt értéket soha ne küldd el, csak a mező nevét és a hiba típusát.
[Hivatalosan igazolt] A Google Analytics 4 ajánlott e-kereskedelmi eseményei közé tartozik a begin_checkout, az add_shipping_info, az add_payment_info és a purchase. Ezek a lépések közötti lemorzsolódást mutatják meg, azt viszont nem, hogy egy lépésen belül melyik mező a gond. Ehhez saját események kellenek, például ezek:
checkout_field_focusa mező nevével, hogy tudd, hányan jutottak el az adott mezőig;checkout_field_errora mező nevével, a hiba típusával (hiányzik, formátum, eltérés) és azzal, hányadik próbálkozásnál jött;checkout_submit_attemptminden kattintásra a Tovább vagy Megrendelés gombon;checkout_submit_faila hibás mezők számával;checkout_autofill_detected, ha a mező értéke gépelés nélkül változott meg.
[Hivatalosan igazolt] A GA4-ben az egyéni eseményparaméterek csak akkor jelennek meg a jelentésekben, ha egyéni dimenzióként regisztrálod őket. Ezt az esemény bekötése előtt érdemes megtenni, mert visszamenőleg nem tölti fel az adatot.
Natív böngészős ellenőrzésnél egy egyszerű figyelő is elég az invalid eseményre:
document.querySelectorAll('form.checkout input').forEach(function (el) { el.addEventListener('invalid', function () { window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'checkout_field_error', field_name: el.name, error_type: el.validity.valueMissing ? 'hianyzik' : 'formatum' }); }); });
WooCommerce-nél a sikertelen beküldés után a rendszer egy checkout_error eseményt vált ki a document.body elemen, erre is ráköthetsz egy dataLayer-hívást. A hibás mezőket ilyenkor a woocommerce-invalid osztály jelöli, ezekből kiolvasható a mezőnév. Ha munkamenet-rögzítő eszközt használsz, ellenőrizd, hogy a beviteli mezők tartalma maszkolva van, mert név, cím és adószám nem kerülhet harmadik félhez a vásárló tudta nélkül.
Hogyan olvasd ki a mérésből a hibás beküldéseket?
A legbeszédesebb mutató a mezőnkénti hibaarány, vagyis a hibaesemények száma osztva azzal, hányan kerültek az adott mezőbe. Ha egy mező kiemelkedik, és utána sokan kilépnek, ott van az elakadás.
- Készíts egy táblát mezőnként a fókuszok, a hibák és a hibát követő kilépések számával, eszköz szerint bontva.
- Nézd meg, melyik mezőnél jön ugyanabban a munkamenetben kétszer vagy többször ugyanaz a hiba. [Saját tapasztalat] Ez szinte mindig azt jelzi, hogy a vásárló nem érti, mit vár tőle a rendszer.
- Vesd össze a böngészős és a szerveroldali hibákat. Ha a böngésző átengedi az adatot, de a szerver elutasítja, a vásárló a beküldés után, az oldal tetején kap egy általános hibát, és sokszor nem találja, melyik mezőről van szó.
- Szűrj az automatikus kitöltésre. Ha az autofill utáni munkamenetekben feltűnően több a hiba, valószínűleg az
autocompletetokenekkel vagy az ellenőrzés időzítésével van gond. - Nézd meg a mobilt külön. [Szakmai feltételezés] Mobilon a rossz billentyűzettípus és a kis kijelző miatt ugyanaz a szabály várhatóan több hibát okoz, mint asztali gépen.
A szerveroldalon érdemes naplózni az elutasított beküldéseket is, itt is csak a mező nevét és a megsértett szabályt, érték nélkül. Ebből derül ki például az, ha egy bővítmény frissítés után más formátumot kezdett elvárni.
Mikor kell szövegezést javítani, és mikor validációt lazítani?
Ha a vásárló adata helyes, csak más formában írta be, lazíts a validáción, vagy alakítsd át az adatot a háttérben. Ha a kiszállításhoz vagy a számlához tényleg szükséges adat hiányzik, a szabály maradjon, és a címkét, a súgót meg a hibaüzenetet írd át.
Néhány gyakorlati döntési szabály:
- Adószám. Fogadd el kötőjel nélkül, szóközzel és „HU” előtaggal is, a háttérben pedig alakítsd a megfelelő formára. A tartalmi ellenőrzés (11 számjegy) maradhat.
- Házszám. Engedj szabad szöveget, mert a valós címek változatosságát egy szigorú minta nem tudja lefedni. Az üres mezőt viszont jelezd, mert házszám nélkül a futár sem talál oda.
- Irányítószám és település eltérése. Tiltás helyett ajánlj fel javítást, és hagyd, hogy a vásárló döntsön. Külföldi szállításnál az országhoz igazítsd a szabályt.
- Rejtett kötelező mezők. Ami nem látszik, az nem lehet kötelező. Ez egyértelműen hiba, nem szövegezési kérdés.
- Telefonszám. Fogadd el a „+36”, „06” és szóközös alakot, a mezőnek pedig ne legyen túl rövid a maximális hossza.
[Hivatalosan igazolt] A WCAG 2.2 3.3.7-es pontja (Redundant Entry) szerint a már megadott adatot ugyanabban a folyamatban nem kell újra bekérni. A pénztárban ez a „számlázási cím megegyezik a szállítási címmel” jelölőnégyzetet jelenti, ami a gépelést és vele a hibalehetőséget is csökkenti.
Miért konverzióoptimalizálás a hibaüzenet szövege?
A hibaüzenet az egyetlen pont, ahol a webshop pont az elakadás pillanatában beszél a vásárlóval. Ha érthető, a vásárló kijavítja az adatot és továbbmegy. Ha általános vagy hibáztató, a vásárló elbizonytalanodik, és egy része kilép.
[Hivatalosan igazolt] A WCAG 3.3.1-es pontja szerint a hibát azonosítani kell, és szövegesen le kell írni. A 3.3.3-as pont szerint, ha ismert a javítás módja, azt fel kell ajánlani. Ez akadálymentességi követelmény, de a konverzióra is jó eséllyel hat, mert minden vásárlónak könnyebb dolga lesz.
A jó hibaüzenet megmondja, melyik mezőről van szó, mi a probléma, és ad egy helyes példát. A mező mellett jelenik meg, a beírt adat pedig megmarad. Néhány átírás:
- „Érvénytelen formátum.” helyett „Az adószám 11 számjegyből áll, például 12345678-1-42. Kötőjel nélkül is beírhatod.”
- „Hibás cím.” helyett „Hiányzik a házszám. Ha nincs házszámod, írd be a helyrajzi számot.”
- „Az irányítószám nem egyezik.” helyett „A 8000-es irányítószám Székesfehérvárhoz tartozik. Ezt a települést írjuk be?”
- „Kötelező mező.” egy egész űrlap tetején helyett egy összesítő („2 mezőt kell még javítani”), amelyben a mezők nevére kattintva oda ugrik az oldal.
[Saját tapasztalat] Sokszor egyetlen jól megírt súgósor a mező alatt (például „Emelet, ajtó, ha van”) több hibát előz meg, mint bármilyen utólagos ellenőrzés. A szövegezés ráadásul olcsó és gyorsan visszafordítható módosítás, ezért az átírást A/B teszttel is érdemes ellenőrizni, ha a forgalom elegendő hozzá.
Mit nézz át egy kétórás pénztár-átvizsgálás során?
Két óra jó eséllyel elég ahhoz, hogy a legsúlyosabb elakadásokat megtaláld. Az idő nagyjából négy blokkra oszlik, adatokra, kézi tesztre, szabályokra és szövegekre.
0-20. perc: adatok
- Nézd meg a
begin_checkout,add_shipping_info,add_payment_infoéspurchaseközötti lemorzsolódást eszköz szerint. - Ha van mezőszintű mérés, rendezd a mezőket hibaarány szerint.
- Ha nincs, jegyezd fel, mert ez lesz az első bekötendő feladat.
20-60. perc: kézi tesztvásárlás
- Vásárolj végig mobilon és asztali gépen, Chrome és Safari böngészővel.
- Próbáld ki ezeket a címeket és adatokat: „12/A”, „12-14”, helyrajzi szám, „Budapest XI. kerület”, külföldi irányítószám, adószám kötőjel nélkül és „HU” előtaggal, telefonszám „+36” és „06” alakban.
- Töltsd ki az űrlapot a böngésző automatikus kitöltésével és egy jelszókezelővel is.
- Rendelj magánszemélyként, és figyeld, kér-e a rendszer rejtett céges adatot.
- Küldd be szándékosan hibásan, és nézd meg, megmarad-e a beírt adat.
60-90. perc: szabályok és kód
- Hasonlítsd össze a böngészős és a szerveroldali validációs szabályokat.
- Ellenőrizd mezőnként az
autocompletetokeneket, például<input name="billing_postcode" autocomplete="postal-code" inputmode="numeric">. - Nézd meg, hogy számmezőknél
inputmode="numeric"szerepel-e. Atype="number"irányítószámra és telefonszámra kevésbé alkalmas. - Ellenőrizd a maximális hosszakat és a rejtett kötelező mezőket.
90-120. perc: szövegek és teendőlista
- Gyűjtsd össze az összes hibaüzenetet, és írd át azokat, amelyekből nem derül ki a mező, a probléma és egy helyes példa.
- Állíts fel sorrendet aszerint, hány vásárlót érint a hiba, és mennyi munka a javítása.
- Írd le a mezőszintű mérés eseményeit és paramétereit, hogy a javítás hatása mérhető legyen.
- Rögzítsd a kiinduló hibaarányokat, mert később ezekhez tudod mérni, segített-e a módosítás.
Az átvizsgálás után a javításokat érdemes egyenként élesíteni, hogy lásd, melyik mit változtatott. Egy pénztár-javítás nem garantál több megrendelést, mert a döntést az ár, a szállítási feltételek és a bizalom is befolyásolja. Azt viszont jó eséllyel eléri, hogy aki már vásárolni akart, azt ne egy rosszul beállított mező állítsa meg.
Források és további olvasnivalók
- Google Analytics súgó, ajánlott események (e-kereskedelem) és egyéni dimenziók
- web.dev (Google), Payment and address form best practices
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, 3.3.1, 3.3.3 és 3.3.7 sikerkritérium
- WHATWG HTML Living Standard, az autocomplete attribútum és az autofill tokenek
- WooCommerce fejlesztői dokumentáció, pénztár-események és validáció
- Baymard Institute, Checkout Usability kutatások
- Magyar Posta, irányítószám-kereső
- A pénztár-űrlap hibáit mezőszinten kell mérni (fókusz, hiba, hibatípus, beküldési kísérlet), a beírt értéket viszont soha ne küldd el az analitikába.
- Ha a vásárló adata helyes, csak más formátumban írta be, a validációt lazítsd, vagy normalizáld az adatot a háttérben.
- Ha a szállításhoz tényleg szükséges adat hiányzik, a szabályt hagyd meg, és a címkét, a súgót és a hibaüzenetet írd át.
- A hibaüzenet az a pont, ahol a rendszer pont az elakadás pillanatában szól a vásárlóhoz, ezért a szövege konverziós kérdés.
- Egy kétórás átvizsgálás (adat, kézi teszt, szabályok, szövegek) jó eséllyel feltárja a legsúlyosabb elakadásokat, de eredményt nem garantál.
Gyakori kérdések
Miért nem látom a GA4-ben, melyik mezőnél akad el a vásárló?
A GA4 ajánlott e-kereskedelmi eseményei csak a pénztár lépései közötti lemorzsolódást mutatják. A mezőszintű elakadáshoz saját események kellenek (például checkout_field_error), a paramétereiket pedig egyéni dimenzióként regisztrálni kell.
Elküldhetem a hibás beírt értéket az analitikába, hogy lássam, mit írt a vásárló?
Nem érdemes, mert a név, a cím, az adószám és a telefonszám személyes adat. Elég a mező neve, a hiba típusa és a próbálkozás sorszáma, ebből a hiba oka jó eséllyel kiderül.
Lazítsak a házszám-ellenőrzésen, vagy maradjon szigorú?
A formátumon érdemes lazítani, mert a „12/A”, a „12-14” vagy a helyrajzi szám mind valós cím. Az üres házszámot viszont továbbra is jelezd, mert enélkül a kiszállítás meghiúsulhat.
Hogyan kezeljem az adószámot, ha a vásárlók különböző formában írják be?
Fogadd el kötőjel nélkül, szóközzel és HU előtaggal is, majd a háttérben alakítsd a megfelelő formára. A mező csak akkor legyen kötelező, ha a vásárló céges számlát kér.
Mitől jobb egy hibaüzenet?
Megmondja, melyik mezőről van szó, mi a gond, és ad egy helyes példát. A mező mellett jelenik meg, a beírt adat pedig megmarad, így a vásárló gyorsan tud javítani.
Mennyi idő alatt lehet átvizsgálni egy pénztárat?
Egy alapos első kör nagyjából két óra, ebben benne van az adatok áttekintése, a kézi tesztvásárlás, a szabályok ellenőrzése és a hibaüzenetek átírási listája. A javítás és a mérés bekötése külön munka.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.