Termékadat az AI-vásárlási felületeken

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

Ha valaki egy AI-asszisztenstől kér vásárlási tanácsot, a válasz jó eséllyel nem egyetlen weboldalból születik. Az asszisztens a boltok termékoldalairól, a strukturált adatokból és a termékfeedekből gyűjti össze az adatot, aztán ezekből rak össze egy rövid ajánlást névvel, árral és elérhetőséggel. Ha a te adataid ellentmondanak egymásnak, a jobbik esetben kimaradsz, a rosszabbik esetben rossz árral kerülsz a válaszba. A cikk sorra veszi, mit érdemes rendbe tenni egy webshopban ahhoz, hogy a terméked pontosan jelenjen meg ezeken a felületeken.

A cikkben háromféle jelölést használunk. A Hivatalosan igazolt állítás platformdokumentációból vagy szabványból származik. A Saját tapasztalat webshopok adatainak rendszeres átnézéséből leszűrt, visszatérő minta. A Szakmai feltételezés megalapozott következtetés, amelyet nyilvános dokumentáció nem erősít meg.

Milyen termékadatot olvas ki egy AI-asszisztens a webshopodból?

Nagyjából ugyanazt, amit egy gondos vásárló is megnézne, csak gépi formában. Kell neki a termék neve, márkája, azonosítói, az ár pénznemmel, a készletállapot, valamint a szállítási és a visszaküldési feltételek. Minél kevesebbet kell találgatnia, annál kisebb az esélye, hogy téved.

Hivatalosan igazolt: a Google Search Central a Product és Offer típusú strukturált adatokból olvassa ki a kereskedői termékinformációt (ár, elérhetőség, szállítás, visszaküldés), a Merchant Center pedig ugyanezeket a mezőket várja a termékfeedben. Az OpenAI is közzétett kereskedőknek szóló dokumentációt arról, milyen termékfeed-mezőkből dolgozik a ChatGPT vásárlási funkciója, és ezek a mezők nagyrészt ugyanazok (azonosító, cím, leírás, ár, elérhetőség, link).

Szakmai feltételezés: az egyes asszisztensek nem hozzák nyilvánosságra, hogyan súlyozzák a forrásokat. Hogy mikor a feedet, mikor az oldalt, mikor egy összehasonlító oldalt tekintenek irányadónak, azt kívülről csak következtetni lehet. A legbiztonságosabb stratégia ezért az, ha minden forrásod ugyanazt mondja.

Hogyan legyen egyértelmű a terméknév?

A jó terméknév a márkából, a modellből, a terméktípusból és a legfontosabb megkülönböztető jellemzőből áll. Egy gépnek a „Deluxe 2 kávéfőző” szinte semmit nem mond, a „Márka X200 kapszulás kávéfőző, 1,2 l, fekete” viszont egyértelműen azonosít egy terméket.

• Ugyanaz a név szerepeljen a H1 címben, a strukturált adat name mezőjében és a feed title mezőjében. Kisebb eltérés belefér (a feedcím lehet hosszabb), ellentmondás viszont nem.
• A névbe ne kerüljön promóciós szöveg („AKCIÓ”, „ingyen szállítás”, felkiáltójelek). Hivatalosan igazolt: a Merchant Center irányelvei tiltják a promóciós szöveget a termékcímben.
• A változatot jelölő jellemző (szín, méret, kapacitás) a változat nevében legyen benne, ne csak egy legördülő menüben.

Saját tapasztalat: kis webshopoknál gyakori, hogy a terméknév a beszállító belső kódjával kezdődik, vagy csak a bolton belül érthető rövidítést használ. Emberi vásárlónál ezt a kép és a leírás kompenzálja, gépi feldolgozásnál sokkal kevésbé.

Mely azonosítók számítanak, és hol legyenek?

A legfontosabb a GTIN (Magyarországon jellemzően a 13 jegyű EAN), mellette a márka és a gyártói cikkszám (MPN), a saját rendszeredben pedig az SKU. A GTIN-nel lehet ugyanazt a terméket több bolt kínálatában összekapcsolni, ezért ha ez hiányzik, a terméked könnyen csak egy névegyezésen alapuló találat lesz.

Hivatalosan igazolt: a Merchant Center kötelezővé teszi a GTIN megadását minden olyan terméknél, amelyhez a gyártó GTIN-t rendelt. A schema.org Product típusában erre a gtin13 (vagy az általános gtin), az mpn és a brand tulajdonság szolgál.

Saját tapasztalat: sok boltban a GTIN-mezőbe a saját cikkszám kerül, vagy egy variánscsoport minden tagja ugyanazt az EAN-t kapja. Mindkettő rosszabb, mint az üres mező. Saját gyártású vagy egyedi terméknél, amelynek nincs GTIN-je, ne találj ki egyet, hanem add meg a márkát és az MPN-t.

Hogyan tedd gépileg olvashatóvá az árat és az elérhetőséget?

JSON-LD formátumú strukturált adattal, amely a szerver által küldött HTML-ben benne van, és pontosan azt az árat meg készletállapotot mutatja, amit a vásárló lát. Az ár szám legyen pénznemkóddal, a „Ft” felirat és ezres tagolás nélkül.

Egy minimális példa (az azonosítók csak szemléltető értékek):

{"@context":"https://schema.org","@type":"Product","name":"Márka X200 kapszulás kávéfőző, 1,2 l, fekete","brand":{"@type":"Brand","name":"Márka"},"gtin13":"5990000000000","mpn":"X200-BK","sku":"X200-BK","offers":{"@type":"Offer","url":"https://pelda.hu/marka-x200-fekete","price":"24990","priceCurrency":"HUF","availability":"https://schema.org/InStock","itemCondition":"https://schema.org/NewCondition"}}

Három dologra figyelj külön. Az ár az ÁFA-t tartalmazó bruttó ár legyen, mert a magyar vásárló ezt látja. Az availability értékét a készletkezelőből töltsd, ne a sablonba írd be fixen. Ha pedig az ár vagy a készlet csak JavaScriptből töltődik be az oldal megnyitása után, akkor az a lapletöltő, amelyik nem futtat JavaScriptet, üresen vagy elavultan látja.

Szakmai feltételezés: több független mérés szerint az AI-cégek lapletöltői közül sok nem futtat JavaScriptet. Ezt a cégek nem dokumentálják egységesen, ezért érdemes úgy számolni, hogy ami nincs benne a nyers HTML-ben, az nekik nem létezik.

Miért kell a szállítás és a visszaküldés a termék közelébe?

Mert a vásárlási döntésben a teljes költség és a kockázat számít, és az asszisztens csak azt tudja összevetni, amit megtalál. Ha a szállítási díj csak a pénztárban derül ki, a gép jó eséllyel nem látja.

Hivatalosan igazolt: a Google támogatja az Offer alatti shippingDetails (OfferShippingDetails) és hasMerchantReturnPolicy (MerchantReturnPolicy) tulajdonságot, és a visszaküldési szabályzatot szervezeti szinten is meg lehet adni. A Merchant Centerben a szállítási és visszaküldési beállítások fiókszinten is rögzíthetők.

• A termékoldalon, az ár közelében, egy mondatban álljon a szállítási díj és az ingyenes szállítás határa.
• A visszaküldési határidő és a visszaküldés költsége (ki fizeti) legyen szövegesen is olvasható, ne csak az ÁSZF 14. oldalán.
• A szállítási idő reális legyen, és egyezzen azzal, amit a feedben megadsz.

Saját tapasztalat: a leggyakoribb eltérés az, hogy a feedben régi ingyenes szállítási határ szerepel, mert a módosítás csak a kosár beállításaiban történt meg.

Miben tér el ez a klasszikus feedkezeléstől?

A klasszikus feedkezelés egy-egy fogadó rendszernek (Google Shopping, Árukereső és társaik) készít adatot, jellemzően hirdetési céllal. Az AI-vásárlási felületek viszont több forrást vetnek össze, és a termékoldalad is közvetlen forrássá válik.

• Egy csatorna helyett több forrás. Régen elég volt, ha a feed átment az ellenőrzésen. Most a feed, az oldal és a strukturált adat egymás ellenőrzőjévé válik.
• Kattintásra optimalizált cím helyett pontos leírás. Hirdetési feedben bevett gyakorlat a kulcsszavakkal megtömött cím. Egy válaszmotornak a tömör, pontos azonosítás a hasznosabb.
• A leírás kérdésekre felel. Az asszisztens gyakran olyan kérdésre keres választ, mint a kompatibilitás, a méret, az anyag vagy a tartozékok. Ha ezek szerkesztett, tényszerű szövegként megvannak, idézhetők.
• Nincs licit. Hivatalosan igazolt: az OpenAI a ChatGPT vásárlási találatait organikusként, nem fizetett elhelyezésként írja le. Itt tehát az adatminőség áll a helyezés mögött, nem a költés.

Mi történik, ha az oldalon és a feedben más ár szerepel?

A Google Merchant Centerben a termék elutasítást kaphat, az AI-válaszban pedig rossz ár jelenhet meg, vagy a termék kimaradhat. Mindkettő a te bizalmi tőkédből fizet.

Hivatalosan igazolt: a Merchant Center összeveti a feed árát és elérhetőségét a céloldallal, és eltérés esetén a terméket elutasíthatja. Ismételt vagy súlyos eltérésnél fiókszintű figyelmeztetés is jöhet. Bekapcsolható az automatikus termékfrissítés, amely az oldal strukturált adatai alapján javítja az árat és az elérhetőséget. Ez tűzoltásra jó, de nem helyettesíti a rendes szinkront.

Szakmai feltételezés: az AI-asszisztensnél a helyzet kockázatosabb, mert ott nincs hibaüzenet. Ha a feed még a tegnapi alacsonyabb árat mutatja, a válasz ezt adhatja tovább, a vásárló pedig a pénztárban mást lát. Ellentmondó források között a rendszer a kevésbé megbízhatónak ítélt forrást hagyhatja ki, és ez akár a te boltod is lehet.

Az eltérés tipikus okai a következők:

• a feed naponta egyszer frissül, az ár pedig napközben változik;
• az oldal gyorsítótára (cache) a régi árat szolgálja ki;
• az akciót egy bővítmény csak a megjelenítésben alkalmazza, a feedben és a strukturált adatban nem;
• a variánsos terméknél a feed a legolcsóbb, az oldal az alapértelmezett változat árát mutatja;
• nettó és bruttó ár keveredik.

Hol csúszik el leggyakrabban a termékadat? Hibakereső lista

A tapasztalat szerint a hibák túlnyomó része négy helyzetben jelentkezik. Mindegyiknél ugyanaz a kérdés, egyezik-e az oldal, a strukturált adat és a feed.

Elfogyott termék

• Az oldalon „nincs készleten” áll, a strukturált adatban viszont fixen InStock. Saját tapasztalat: ez az egyik leggyakoribb hiba, és sokszor egy sablonba beégetett érték okozza.
• Ideiglenes hiánynál használd az OutOfStock, utánrendelésnél a BackOrder, előrendelésnél a PreOrder értéket, és a feedben is ugyanezt.
• Ne töröld az oldalt azonnal. Ha a termék visszajön, maradjon ugyanazon az URL-en, ha véglegesen megszűnt, irányítsd át az utódtermékre.

Variánsok

• Minden változatnak legyen saját azonosítója, GTIN-je és ára, és lehetőleg saját, közvetlenül megnyitható URL-je (vagy olyan paramétere, amely előre kiválasztja a változatot).
• Hivatalosan igazolt: a Google dokumentálja a termékváltozatok jelölését a ProductGroup, hasVariant és variesBy tulajdonságokkal. A feedben az item_group_id köti össze a változatokat.
• Ellenőrizd, hogy a változat URL-jén megnyitott oldal valóban a változat árát és készletét mutatja-e.

Akciós ár időzítése

• A feedben add meg a sale_price mellett a sale_price_effective_date mezőt, így az akció kezdete és vége nem egy kézi frissítésen múlik.
• Az akció indulásakor és lejártakor ürítsd a gyorsítótárat, különben órákig az előző ár látszik.
• A strukturált adatban az aktuálisan fizetendő ár szerepeljen. Hivatalosan igazolt: a Google az áthúzott eredeti ár jelölésére a StrikethroughPrice ártípust támogatja.
• Hivatalosan igazolt: az EU 2019/2161-es (Omnibus) irányelve szerint árcsökkentés hirdetésekor az előző árnak az akciót megelőző 30 nap legalacsonyabb árának kell lennie. Ha az „eredeti ár” nem ez, az jogi kockázat is.

Félrevezető egységár

• Kiszerelt termékeknél (élelmiszer, vegyi áru, kozmetikum) a hazai árfeltüntetési szabályok egységárat írnak elő, például Ft/kg vagy Ft/l formában.
• A feedben erre a unit_pricing_measure és a unit_pricing_base_measure mező szolgál, a schema.org-ban a UnitPriceSpecification a referenceQuantity tulajdonsággal.
• Saját tapasztalat: a gyakori hiba az, hogy a gyűjtőcsomag (például 6 darab) ára mellett az egységár egy darabra van kiszámolva, vagy fordítva. Ilyenkor a gép kétszer olcsóbbnak vagy drágábbnak látja a terméket, mint amilyen valójában.

Hogyan ellenőrizd lépésről lépésre egy délután alatt?

Nem kell az egész katalógussal kezdeni. A legtöbbet eladott tíz termék átnézése megmutatja, hol rendszerszintű a hiba.

1. Válaszd ki a tíz legfontosabb terméket, köztük legalább egy variánsosat, egy akciósat és egy elfogyottat.
2. Nyisd meg a termékoldal forráskódját (nem a böngésző által már felépített nézetet), és keresd meg a JSON-LD blokkot. Ha nincs benne ár vagy készlet, az már egy lelet.
3. Futtasd le az oldalt a Google Rich Results Test eszközén és a Schema.org validátorán.
4. Tedd egymás mellé a látható árat, a strukturált adat árát és a feedsor árát. Ugyanezt tedd meg a készlettel és a szállítási díjjal.
5. Nézd meg a Merchant Center diagnosztikáját, van-e ár- vagy elérhetőség-eltérés miatti figyelmeztetés.
6. Tegyél egy terméket próbaképpen „nincs készleten” állapotba, és ellenőrizd, hogy mindhárom forrás követi-e.
7. Kérdezz meg két-három AI-asszisztenst a termékkategóriádra jellemző vásárlási kérdésekkel, és jegyezd fel, mit mondanak a termékedről. Ez pillanatkép, nem mérés, és a válaszok időről időre változnak.

Megéri egy kis webshopnak ma külön erőforrást tenni erre?

A saját álláspontunk az, hogy az adatrendezésbe érdemes időt tenni, egy külön „AI-vásárlási projektbe” viszont ma még ritkán. A kettő között nagy a különbség.

Az adatrendezés (pontos név, GTIN, szinkronban lévő ár és készlet, látható szállítási és visszaküldési feltételek) akkor is megtérülhet, ha egyetlen AI-asszisztens sem ajánl soha: kevesebb Merchant Center-elutasítást, tisztább összehasonlító oldali megjelenést és kevesebb ügyfélszolgálati vitát eredményezhet. Ez olyan befektetés, amit nem kell visszacsinálni, ha a piac más irányba megy.

Szakmai feltételezés: a magyar vásárlások közül ma még kis arányban indulnak AI-asszisztensből, és a platformok kereskedői programjai sem mind érhetők el hazai boltoknak. Ezért egy kis webshopnak nem javasoljuk, hogy most külön feedet építsen minden új platformra, vagy fizetős eszközre költsön, amely „AI-láthatóságot” ígér. Ha egy platform magyar kereskedőknek is megnyitja a feedfeltöltést, és a te kategóriádban látszik forgalom, akkor érdemes újra mérlegelni.

A gyakorlatban ez egy egyszeri adattisztítást jelent a legfontosabb termékekre, utána havi egy rövid ellenőrzést a fenti lista alapján. Ha a katalógus több ezer termékből áll, az ár- és készletösszevetést érdemes automatizálni. Garanciát ez sem ad arra, hogy egy asszisztens a te termékedet ajánlja, azt viszont jó eséllyel kizárja, hogy a saját adataid miatt maradj ki, vagy rossz árral szerepelj.

Források és további olvasnivalók

• Google Search Central, Termék (Product) strukturált adatok és kereskedői termékadatok
• Google Search Central, Termékváltozatok (ProductGroup) strukturált adatai
• Google Merchant Center súgó, Termékadat-specifikáció
• Google Merchant Center súgó, Automatikus termékfrissítések és az ár eltérése a céloldaltól
• Schema.org, Product, Offer, OfferShippingDetails, MerchantReturnPolicy, UnitPriceSpecification
• OpenAI, kereskedői dokumentáció a ChatGPT vásárlási funkciójához és a termékfeed-specifikációhoz
• Az Európai Parlament és a Tanács (EU) 2019/2161 irányelve (Omnibus irányelv)
• W3C, JSON-LD 1.1 ajánlás