Webáruházi konverzió: hét vizsgálat a találgatás helyett

A webáruházi konverzió javítása azzal kezdődik, hogy pontosan meghatározod, mit számolsz. A kifizetett rendelés, a leadott rendelés és a sikeres fizetési oldal megnyitása külön esemény. Ha ezeket összekevered, egy mérési hiba is növekedésnek látszhat.

Nincs minden magyar boltra érvényes célkonverzió. Egy visszatérő céges beszerzőket kiszolgáló alkatrészbolt és egy ajándékokat hirdető új márka más forgalmat kap. Az alábbi hét vizsgálat tesztelhető hipotéziseket ad. Egyikhez sem tartozik garantált bevételi többlet.

1. Előbb ellenőrizd a mérési alapot

Döntsd el, hogy a vásárlási arányt munkamenetre vagy felhasználóra számolod, milyen időszakban, és milyen rendelések kerülnek a számlálóba. Az átutalásra váró rendelés más állapot, mint a sikeresen kifizetett vásárlás. Az utánvétes, törölt és visszatérített tételek kezelése is legyen következetes.

Egy használható eseménylánc a termékmegtekintésből, kosárba helyezésből, pénztárindításból, szállítási és fizetési adatok megadásából, majd vásárlásból áll. A GA4 ehhez például a view_item, add_to_cart, begin_checkout és purchase eseményeket adja. A pontos mezőket a Google e-kereskedelmi mérési dokumentációja írja le.

A rendelési azonosító segít felismerni a duplikációt. Teszteld, mi történik oldalfrissítéskor, sikertelen fizetés után és újrapróbálkozáskor. A vásárlási eseményt ne egy olyan gombkattintás indítsa, amely után a fizetés még meghiúsulhat.

Az analitika számai nem feltétlenül egyeznek a rendelési adatbázissal, például a hozzájárulás hiánya miatt. A teljes üzleti elszámolás forrása a rendelési és pénzügyi nyilvántartás legyen. A viselkedési analitika az útvonalak vizsgálatát segíti, a mérési lefedettség korlátainak feltüntetésével.

2. Keresd meg a pénztár valódi akadályát

A rövidebb űrlap jó hipotézis, de minden mező elhagyása nem javítás. Szállításhoz cím kellhet, céges számlához adószám, egyes átvételi módokhoz telefonszám. A szükséges adatokat a választott folyamat határozza meg.

Magyar vásárlónál teszteld az ékezetes nevet, a hosszú közterületnevet, az emelet és ajtó megadását. A számlázási cím ne írja felül váratlanul a szállítási címet. Ha külön céges vásárlási mód van, az adószámmező és annak ellenőrzése legyen érthető.

Vendégként is lehessen végigmenni a vásárláson, ha az üzleti modell ezt lehetővé teszi. A regisztráció értékét magyarázd el, például a későbbi rendeléskövetéssel. Ne egy kötelező fióklétrehozás legyen az egyetlen út pusztán azért, mert a sablon így működik.

A teszt hipotézise lehet: „Ha a céges adatmezők csak a céges számlázás kiválasztásakor jelennek meg, kevesebb lesz az értelmezési hiba.” Mérd a mezőhibákat, a sikeres továbblépést és a hibás számlázási adatokat is. A gyorsabb kitöltés nem előny, ha utólag több javítás szükséges.

3. Tedd előre láthatóvá a szállítás feltételeit

A vásárló számára a végösszeg és az átvétel módja együtt alkotja az ajánlatot. A termékoldalon vagy a kosárban legyen elérhető a szállítási díj logikája, az esetleges értékhatár és a várható teljesítési idő. Csak olyan határidőt írj, amelyet a készlet és a logisztikai folyamat alátámaszt.

Egy szemléltető példa: ha a házhozszállítás díja 1 990 Ft, a kosárban ne csak a termékek összege látszódjon, miközben ez a tétel a fizetés előtt jelenik meg először. Ez kitalált példadíj, nem piaci átlag és nem a Neocart szállítási ajánlata.

Csomagpontnál próbáld ki, mi történik, ha a kiválasztott hely időközben nem elérhető. A rendszer kérjen új választást, és ne küldjön rendelést üres vagy elavult pontazonosítóval. Mobilon a térkép mellett kereshető lista is hasznos lehet; ennek hatását feladattesztben ellenőrizd.

4. A fizetési hibát kezeld üzleti állapotként

A bankkártyás folyamat megszakadhat, a vásárló bezárhatja az ablakot, vagy a szolgáltatói visszajelzés később érkezhet. A visszatérési oldal szövege és a tényleges rendelési állapot ezért nem kezelhető ugyanannak.

A fizetési eredmény hitelesítését a szerver végezze a szolgáltató dokumentációja szerint. Ismételt értesítés ne hozzon létre új rendelést vagy új számlát. A böngészőben átírt összeg, kedvezmény vagy szállítási díj nem válhat hiteles fizetési adattá.

A vásárló kapjon érthető következő lépést: újrapróbálkozás, másik rendelkezésre álló fizetési mód vagy ügyfélszolgálat. Ne állítsd biztosan, hogy nem történt terhelés, amíg a fizetési állapot bizonytalan. Az ügyfélszolgálatnak legyen rendelési azonosítója a kivizsgáláshoz.

A HTTPS a kapcsolat titkosítását és a tanúsítvány szerinti végpontazonosítást segíti; önmagában nem bizonyítja a kereskedő megbízhatóságát. Fizetési logó csak ténylegesen használható szolgáltatásnál szerepeljen. A garancia feltétele legyen konkrét, és az önkéntes vállalást különítsd el a jogszabályi jogoktól.

5. A termékoldal a döntési kérdésre válaszoljon

Nem minden termékhez ugyanannyi fotó vagy videó kell. Egy csatlakozónál a méret, kompatibilitás és cikkszám lehet döntő; egy textilnél az anyag, szín és használat közbeni megjelenés. Az ügyfélszolgálati kérdésekből derül ki, mi hiányzik leginkább.

A képek mutassák azt, amit a vásárló valóban kap. A méretarányt, a tartozékokat és a külön megvásárolandó elemeket egyértelműen jelöld. Egy látványos videó nem pótolja a pontos műszaki adatot, és ne töltsön be automatikusan indokolatlan mennyiségű adatot.

A keresésnél vizsgáld a saját sikertelen lekérdezéseket. Magyar boltnál releváns próba az ékezet nélküli szó, a cikkszám és a gyakori szinonima. Ne tetszőleges termékszámhatár döntse el, hogy kell-e szűrő: a választás összetettsége és a vásárlói feladat számít.

6. Válaszd el a gyorsulást a bevételi hatástól

A lassú termékoldal vagy akadozó csomagpontválasztó javítása indokolt lehet, de nincs általános szabály arra, hogy minden másodperc ugyanannyi vásárlót veszít. A hibát oldaltípus és eszköz szerint kell megkeresni.

Mérj egy jellemző termékoldalt, listát, kosarat és pénztárt. A fontos nyitóképet ne késleltesd, az alatta lévő képeknél viszont vizsgáld a késleltetett betöltést. A Google LCP-optimalizálási útmutatója technikai kiindulópontot ad ehhez.

A kiadás után nézd meg, megszűnt-e az azonosított akadály. A bevétel változását csak a forgalmi források, akciók, készlethiány és szezonalitás mellett értékeld. Egy kampányváltással egy időben kiadott új pénztár hatását egyszerű időbeli összehasonlítás nem választja szét.

7. Kísérletezz előre rögzített szabályokkal

Minden vizsgálathoz írj hipotézist, elsődleges mutatót és védőkorlátot. Például a sikeres vásárlás mellett figyeld az átlagos kosárértéket, a visszamondásokat és az ügyfélszolgálati terhelést. Előre döntsd el, mikor értékelitek az eredményt; ne az első kedvező nap után állítsátok le a tesztet.

Kis forgalomnál egy A/B teszt könnyen bizonytalan marad. Ilyenkor a használhatósági megfigyelés, a hibajegyek és az eseménylánc vizsgálata célszerűbb első lépés lehet. Néhány beszélgetésből azonban ne számolj piaci arányt: az kvalitatív bizonyíték.

Az elhagyott kosárhoz kapcsolódó e-mail külön adatkezelési és reklámjogi döntést igényel. A cím pénztárban történő megadása önmagában nem marketing-hozzájárulás. Természetes személynek küldött elektronikus reklámnál főszabály szerint előzetes, egyértelmű és kifejezett hozzájárulás szükséges; lásd a 2008. évi XLVIII. törvény 6. §-át. A leiratkozást, a megőrzési időt és a jogosultság igazolását is rendezni kell.

A százalékos javulást pontosan számold

Szemléltető számítás, nem mért eredmény: ha a havi bevétel 1 000 000 Ft, és változatlan forgalom meg kosárérték mellett a vásárlási arány 2%-ról 2,04%-ra nő, az 0,04 százalékpontos, illetve 2%-os relatív javulás. Ennek bevételi megfelelője havi 20 000, tizenkét azonos hónapra 240 000 Ft.

A 2%-ról 4%-ra emelkedés ezzel szemben 2 százalékpont és 100%-os relatív növekedés. A többletbevétel egyik esetben sem azonos a többletnyereséggel: a termék-, fizetési, szállítási és fejlesztési költséget is figyelembe kell venni.

A Neocart jelenlegi képességei között a stúdió tényadatlapja GLS-választót, adószámos számlázást, SimplePay-fizetést, átutalást és tranzakciós e-maileket sorol fel. Az elhagyottkosár-e-mail tervezett Piactér-modul, jelenleg nem alapfunkció. Az itt bemutatott kísérleti ötletek tehát nem automatikusan elérhető termékfunkciók és nem vállalt eredmények.