Mit kérdezz webshopkészítőtől a megrendelés előtt, ha nem csak egy szép boltot szeretnél

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

Egy webshop megrendelésekor a legtöbben a dizájnt, a mobilnézetet és a kosár kinézetét nézik. Ezek fontosak, de a bolt napi működése a háttérben dől el. Ki állítja ki a számlát, honnan tudja a rendszer, hogy elfogyott egy termék, hogyan jut el a csomag adata a futárhoz, és látod-e később, melyik hirdetés hozott vásárlást? Ez a cikk azokat a kérdéseket gyűjti össze, amelyeket érdemes már az ajánlatkérés idején feltenni, és megmutatja, melyik válasz figyelmeztető jel.

A szövegben külön jelölöm, mi a hivatalosan igazolt információ (jogszabály, platform-dokumentáció), mi a saját tapasztalat (webshop-átvételeknél látott minták), és mi a szakmai feltételezés, amit érdemes a saját helyzetedre ellenőrizni.

Miben más egy webshop megrendelése, mint egy bemutatkozó weboldalé?

Egy webshop folyamatosan adatot cserél más rendszerekkel, ezért a megrendelés előtt az összekötésekről, a termékadatokról és a mérésről is kérdezni kell, a kinézet mellett.

Egy webshopnál a weboldal mellé jön a számlázó, a raktár vagy készletnyilvántartás, a futárszolgálat, a kártyás fizetés, a Google Merchant Center és a mérőkód. Ha ezek közül egy rosszul van bekötve, a bolt szépen néz ki, a rendelések mégis kézi munkát, hibás számlát vagy elveszett adatot okoznak.

Saját tapasztalat. Webshop-átvételeknél a leggyakoribb panasz a kézi adminisztráció. Valaki minden reggel átmásolja a rendeléseket a számlázóba, és kézzel írja be a csomagadatokat a futár felületére.

Mit kérdezz a számlázó, a készletkezelő és a futárszolgálat összekötéséről?

Azt, hogy melyik rendszerrel van kész, kipróbált összekötés, mi történik automatikusan egy rendelés után, és mi marad kézi feladat.

Hivatalosan igazolt. Magyarországon a belföldi számlák adatait a NAV Online Számla rendszerébe kell jelenteni, a magánszemélynek kiállított számlákét is. Ezt a számlázóprogramok általában maguk intézik, ezért a webshopnak a számlázóval kell jól együttműködnie.

Kérdések a számlázásról

• Melyik számlázóval (például Számlázz.hu, Billingo) van kész összekötés, és ki tartja karban, ha a számlázó változtat a saját felületén?
• Mikor készül el a számla? Fizetéskor, teljesítéskor, vagy kézi jóváhagyás után?
• Céges vásárlónál bekéri-e az adószámot, és rákerül-e a számlára?

Kérdések a készletről

• Hol él a hiteles készletadat? A webshopban, egy külön raktárprogramban vagy egy vállalatirányítási rendszerben?
• Melyik irányba megy a szinkron, és milyen gyakran fut le?
• Mi történik, ha egy termék a bolti eladás miatt fogy el, miközben valaki a webshopban épp kosárba teszi?
• Van-e minden terméknek és változatnak egyedi cikkszáma (SKU), amire az összekötés épül?

Kérdések a szállításról

• Melyik futárszolgálatokkal (például GLS, MPL, Foxpost, Packeta) van közvetlen összekötés, és működik-e a csomagautomata-választó a pénztárban?
• A rendszer létrehozza-e a csomagot és a címkét a futár rendszerében, vagy exportfájlt kell kézzel feltölteni?
• Visszajön-e a nyomkövetési szám a rendelésbe, és megkapja-e a vásárló e-mailben?

Figyelmeztető jel, ha a válasz annyi, hogy „van rá bővítmény”. A bővítmény léte még nem jelenti, hogy a te folyamatodra be van állítva és ki van próbálva. Kérd, hogy mutassák meg egy próbarendelésen a teljes utat a rendeléstől a számláig és a címkéig.

Milyen kérdések tisztázzák a fizetési módokat?

Azok, amelyekből kiderül, melyik kártyás fizetési rendszerrel dolgozik a készítő, hogyan kerül vissza a fizetés eredménye a rendelésbe, és mi történik sikertelen vagy félbehagyott fizetésnél.

• Melyik kártyás fizetési rendszer (például SimplePay, Barion, Stripe) van bekötve, és ki köti meg vele a szerződést?
• Ha a vásárló a bankja oldalán megszakítja a fizetést, milyen állapotba kerül a rendelés, és kap-e új fizetési linket?
• Kezeli-e a rendszer az utánvétet, az előre utalást és a visszatérítést, és ezek megjelennek-e a számlázóban is?
• Helyesen fogadja-e a webshop a visszairányítást az erős ügyfél-hitelesítés (SCA) után?

Hivatalosan igazolt. Az uniós PSD2 irányelv alapján az online kártyás fizetéseknél főszabályként erős ügyfél-hitelesítés kell. Ezt a fizetési rendszer és a bank végzi, a webshop dolga a visszatérő állapot pontos feldolgozása.

Saját tapasztalat. A fizetési hibák jó része abból jön, hogy a bolt a köszönőoldal betöltéséből következtet a sikeres fizetésre, a fizetési rendszer szerveroldali értesítését (webhook, IPN) pedig nem dolgozza fel. Ha a vásárló a bank oldalán bezárja a böngészőt, a pénz megérkezik, a rendelés mégis „fizetésre vár” állapotban marad.

Ki tölti fel a termékadatokat, és milyen szerkezetben?

Ezt még a szerződés előtt tisztázd, mert a termékadatok feltöltése gyakran több munka, mint maga a bolt, és az ajánlatokból sokszor kimarad.

• Ki tölti fel a termékeket? Te, a készítő, vagy importtal kerülnek be egy meglévő táblázatból vagy rendszerből?
• Milyen mezők lesznek? Cikkszám, GTIN (vonalkód), márka, súly, méret, anyag, változatok.
• Hogyan kezeli a rendszer a változatokat (szín, méret), és mindegyiknek külön cikkszáma és készlete lesz-e?
• Ki készíti el a termékképeket, milyen méretben, és kap-e minden kép alt szöveget?

Szakmai feltételezés. Ha a termékleírásokat változtatás nélkül másolják át a gyártói oldalról, a termékoldalak jó eséllyel nehezebben különülnek el a többi viszonteladóétól a keresőben. Érdemes legalább a fő termékeknél saját leírással és valódi használati tapasztalattal számolni.

Mit kérdezz a termékfeedről?

Azt, hogy a webshop magától előállít-e a Google Merchant Center és a Meta katalógus számára érvényes, rendszeresen frissülő termékfeedet, és ki javítja, ha a Merchant Center hibát jelez.

Hivatalosan igazolt. A Google termékadat-specifikációja szerint a feedben kötelező az egyedi azonosító, a cím, a leírás, a termékoldal linkje, a képlink, az elérhetőség és az eladási összeg, és ahol a terméknek van, a GTIN is. A feed adatainak egyezniük kell azzal, amit a vásárló a termékoldalon lát. Eltérésnél a Merchant Center elutasíthatja a terméket.

• Van-e beépített feed, vagy külön bővítmény, esetleg külső feedkezelő kell hozzá?
• Változatoknál külön tételként adja-e át a színeket és méreteket, közös csoportazonosítóval (item_group_id)?
• Ki kezeli a Merchant Center fiókot, és kinek a nevén lesz?

Figyelmeztető jel, ha a készítő azt mondja, hogy „a feedet majd a hirdetéskezelő megcsinálja”. A feed minősége a webshop adatszerkezetén múlik, utólag kívülről csak korlátozottan javítható.

Hogyan derül ki előre, hogy az e-kereskedelmi mérés működni fog?

Úgy, hogy rákérdezel, mely GA4 e-kereskedelmi eseményeket küldi a bolt, honnan jön a rendelés értéke, és mi akadályozza meg a duplán rögzített vásárlást.

Hivatalosan igazolt. A Google Analytics 4 ajánlott e-kereskedelmi eseményei között szerepel a view_item, az add_to_cart, a begin_checkout és a purchase. A purchase eseménynél a transaction_id segít kiszűrni az ismétlődő tranzakciókat. Az Európai Gazdasági Térségben a Google hirdetési és mérési funkcióihoz a hozzájárulási mód (Consent Mode) második verziója szükséges, ha a látogatói hozzájárulás jeleit fel akarod használni.

Egy működő vásárlási esemény a dataLayerben nagyjából így néz ki. A változókat a bolt tölti ki a rendelés adataiból.

dataLayer.push({ event: 'purchase', ecommerce: { transaction_id: rendeles.azonosito, value: rendeles.osszeg, currency: rendeles.penznem, items: rendeles.tetelek } });

• Hol fut le a purchase esemény? Ha a köszönőoldalon, mi történik, amikor a vásárló újratölti az oldalt?
• A rendelés értéke bruttó vagy nettó, és benne van-e a szállítás? Ezt egyszer kell eldönteni, és minden rendszerben ugyanígy használni.
• Lesz-e szerveroldali mérés vagy Meta Conversions API, és ki tartja karban?
• Hogyan kapcsolódik a sütisáv a mérőkódokhoz, és kipróbálják-e elutasított hozzájárulással is?

Figyelmeztető jel, ha a válasz annyi, hogy „bekötjük az Analyticset”. Az oldalmegtekintések mérése és az e-kereskedelmi mérés két külön munka.

Mitől lesz a webshop később is keresőoptimalizálható?

A tiszta URL-szerkezettől, a szűrőoldalak kezelésétől, a strukturált adattól, és attól, hogy a fontos elemeket (cím, leírás, átirányítás) te magad is szerkesztheted.

• Szerkesztheted-e kategóriánként és termékenként az oldal címét, a meta leírást és az URL-t?
• Hogyan kezeli a rendszer a szűrőket (szín, méret, rendezés)? Minden kombináció új, indexelhető URL-t kap?
• Kerül-e a termékoldalakra Product típusú strukturált adat az elérhetőséggel együtt?
• Mi történik a megszűnt termék oldalával? Törlődik, átirányít, vagy „elfogyott” jelzéssel marad?
• Ha meglévő boltot váltasz, ki készíti el a régi és az új URL-ek átirányítási tábláját?

Hivatalosan igazolt. A Google Search Central külön útmutatót írt a szűrős (faceted) navigációról, mert a szűrőkombinációkból keletkező sok URL lassíthatja a fontos oldalak feltérképezését. A Product strukturált adat jogosulttá teheti a termékoldalt bővített találati megjelenésre, de a Google nem vállalja, hogy minden oldalnál meg is jeleníti.

Szakmai feltételezés. Kis boltnál a szűrős URL-ek ritkán okoznak súlyos gondot, nagyobb termékkörnél viszont érdemes előre megbeszélni, mely szűrőoldalak legyenek indexelhetők.

Milyen válaszok mutatják, hogy a készítő csak a felületet látja?

Azok, amelyek a kinézetről szólnak, amikor folyamatra kérdezel, és amelyek a felelősséget későbbre vagy másra tolják.

• „Ezt majd a bővítmény megoldja.” Kérdezz vissza, melyik bővítmény, és ki állítja be.
• „A számlát a rendelésből ki tudod tölteni.” Ez kézi munkát jelent minden egyes rendelésnél.
• „A készletet a webshopban is vezetheted.” Ha máshol is értékesítesz, ez két helyen vezetett készletet jelent.
• „Az Analytics be lesz kötve.” Az e-kereskedelmi eseményekről ebben nem esett szó.
• „A SEO-t majd később csináljuk.” Az URL-szerkezet és a szűrők kezelése az építéskor dől el.
• „A feedet a hirdetéskezelő intézi.” A feed a bolt adataiból készül, a hibái is onnan jönnek.
• „Ezt mi üzemeltetjük, neked nem kell hozzányúlnod.” Kérdezd meg, kinek a nevén lesz a domain, a tárhely, az admin fiók, a Merchant Center és az Analytics.

Saját tapasztalat. A jó válasz rendszerint kérdéssel indul. Az üzemeltetésben gondolkodó készítő megkérdezi, hány rendelésed van naponta, ki csomagol, milyen számlázót használsz, és van-e bolti értékesítésed. Ha ilyen kérdés egyáltalán nem jön, az önmagában is jelzés.

Milyen gond származhat egy kihagyott kérdésből?

Egy kihagyott kérdés jellemzően hónapokkal később, élesben derül ki, amikor a javítás már adatátalakítással, átirányítással vagy részleges újraépítéssel jár.

Vegyünk egy általános, de gyakori helyzetet (szakmai példa, nem konkrét ügyfél). Egy ruházati bolt webshopot rendel, a termékeket a készítő tölti fel, a színváltozatokat pedig külön termékként hozza létre, egységes cikkszám nélkül. Senki nem kérdezett rá a változatok kezelésére, és az induláskor minden rendben látszik.

1. Néhány hónap múlva a bolt Google Shopping hirdetést indítana. A feedben ugyanaz a modell sok külön termékként jelenik meg, csoportazonosító és több helyen GTIN nélkül, ezért a Merchant Center számos tételt figyelmeztetéssel jelöl.
2. A bolt raktárprogramot vezet be, ami cikkszám alapján szinkronizálna. A webshopban nincs egységes cikkszám, így a szinkron nem tudja párosítani a termékeket.
3. A javításhoz a termékeket változatos termékké kell alakítani. Ettől megváltoznak a termékoldalak URL-jei, ezért minden régi címet át kell irányítani, különben a már indexelt oldalak és a rájuk mutató linkek értéke elvész.

Mindezt egyetlen kérdés kivédte volna a megrendeléskor, mégpedig az, hogy hogyan kezeli a rendszer a változatokat, és mi lesz a cikkszám-szabály.

Hogyan használd a kérdéslistát a gyakorlatban?

Küldd el írásban az ajánlatkéréssel együtt, kérj pontonként választ, és amire nem kapsz érdemi választ, azt jelöld nyitott kockázatként.

1. Írd össze a mostani folyamatodat (számlázó, raktár, futár, fizetés, bolti eladás, hirdetések).
2. Küldd el a fenti kérdéseket a készítőnek, és kérd, hogy mindegyiknél írja le, mi automatikus, mi kézi, és mi nincs benne az ajánlatban.
3. Kérj bemutatót egy próbarendelésről a rendeléstől a számláig, a csomagcímkéig és a GA4 vásárlási eseményéig.
4. Rögzítsd a szerződésben, kinek a nevén lesznek a fiókok (domain, tárhely, admin, Merchant Center, GA4, Search Console).
5. Kérj az átadáskor írásos leírást a beállításokról, hogy egy másik szakember is folytatni tudja a munkát.

Szeretnéd, hogy valaki átnézze a kapott webshop-ajánlatot?

Ha már a kezedben van egy vagy több webshop-ajánlat, a Scheo szívesen átnézi őket szakmai szemmel, a fenti szempontok alapján.

Megnézzük, mely összekötések szerepelnek bennük ténylegesen, mi maradt ki a feed, a mérés és a keresőoptimalizálás oldaláról, és mit kérdezz még a döntés előtt. Az átnézés a készítővel folytatott egyeztetést nem váltja ki, és azt sem tudjuk előre megmondani, melyik bolt hoz majd több rendelést. Abban viszont segíthet, hogy tisztán lásd, mit rendelsz meg, és mi marad rád az indulás után.

Források és további olvasnivalók

• Google Search Central, a szűrős (faceted) navigáció kezeléséről szóló útmutató
• Google Search Central, Product strukturált adat dokumentáció
• Google Merchant Center súgó, termékadat-specifikáció
• Google Analytics 4 fejlesztői dokumentáció, e-kereskedelmi mérés
• Google, a hozzájárulási mód (Consent Mode) dokumentációja
• Schema.org, Product és Offer típus
• Nemzeti Adó- és Vámhivatal, Online Számla rendszer tájékoztatója
• Az Európai Parlament és a Tanács (EU) 2015/2366 irányelve (PSD2)