Merchant Center termékállapot havi figyelése: az elutasított tételek visszaszerzése

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

A Google Merchant Center termékállapota olyan, mint egy raktár, amit senki nem leltároz. Amíg a kampányok futnak, senki nem néz bele, aztán egy átlagos hétfőn kiderül, hogy a legjobban fogyó termékcsalád két hete nem jelenik meg a Shopping-felületeken. Ez a cikk egy havi rutint ír le, amellyel az elutasított, a korlátozott és a csendben eltűnt tételek rendszeresen előkerülnek, a javítás sorrendje üzleti alapon dől el, és ugyanaz a hiba nem jön vissza a következő feedfrissítéssel.

A szövegben három jelölést használok. Hivatalosan igazolt az, ami a Google saját súgójában vagy fejlesztői dokumentációjában szerepel. Saját tapasztalat az, amit webshopok termékfeedjeinek rendszeres átnézése közben láttam. Szakmai feltételezés az, ami logikusan következik, de nem mértem, és nincs rá hivatalos forrás.

Mit érdemes havonta átnézni a Merchant Center termékállapotában?

Havonta négy dolgot érdemes átnézni, ezek a fiókszintű problémák, az aktív termékek számának változása az előző hónaphoz képest, az elutasított tételek és a korlátozott megjelenésű tételek. Az első, a harmadik és a negyedik a felületen látszik. A második csak akkor, ha te magad hasonlítod össze a számokat.

Hivatalosan igazolt. A Merchant Center minden termékhez állapotot rendel, és a problémákat termékszintű és fiókszintű hibákra bontja. Termékszintű problémánál a felület megmutatja, melyik attribútum okozza a gondot, hány terméket érint, és hogy a hiba a megjelenést teljesen megakadályozza vagy csak korlátozza. A fiókszintű problémák (például a weboldal ellenőrzése, a visszaküldési szabályzat vagy a szállítási beállítások hiánya) egyszerre a teljes kínálatot érinthetik, ezért a havi kör mindig ezekkel indul.

Saját tapasztalat. A legtöbb pénzbe kerülő hiba nem a piros, elutasított sorok között van, hanem a hiányzó sorokban. Ha egy webshop exportja egy kategóriaszűrő módosítása miatt kihagy kétszáz terméket, a Merchant Center semmilyen hibát nem jelez, hiszen azokról a termékekről nem is tud. A kampány közben tovább fut, csak kevesebb termékkel, és ezt a riportokban könnyű a szezonra fogni.

Mi a különbség az elutasított, a korlátozott és a csendben eltűnt termék között?

Az elutasított termék az érintett felületen egyáltalán nem jelenik meg, a korlátozott termék megjelenik, de szűkebb körben, a csendben eltűnt termék pedig semmilyen állapotot nem mutat, mert kikerült a feedből vagy lejárt. A három csoport más-más okból keletkezik, ezért más módszerrel is kell keresni őket.

• Elutasított tétel. Tipikus ok az ár vagy a készlet eltérése a feed és a céloldal között, a nem elérhető céloldal, a hiányzó kötelező attribútum, a nem megfelelő termékkép, illetve az irányelvsértés.
• Korlátozott tétel. Gyakori ok a hiányzó GTIN olyan terméknél, amelyhez a gyártó kiad GTIN-t, a hiányos szállítási adat egy-egy célországban, vagy egy tartalmi korlátozás, amely bizonyos felületeken vagy régiókban kizárja a megjelenést.
• Csendben eltűnt tétel. Ide tartozik a sikertelen feedletöltés, az exportszűrő változása, a 30 napnál régebben frissített (lejárt) termék, és az azonosító (id) megváltozása.

Hivatalosan igazolt. A Google termékadat-előírása szerint a beküldött termékek lejárnak, ha meghatározott időn belül nem frissülnek, ezért a termékadatokat legalább 30 naponta frissíteni kell. Az id attribútum a termék egyedi azonosítója, és a Google azt kéri, hogy frissítéskor ne változzon.

Saját tapasztalat. Az azonosítóváltás különösen alattomos. Ha egy webshopmotor vagy feedbővítmény frissítése után megváltozik az azonosítók formátuma (például a cikkszám helyett a belső adatbázis-azonosító kerül az id mezőbe), a Merchant Center a terméket újként kezeli. A régi tétel teljesítménytörténete ezzel leválik, a felületen pedig nem hibaként, hanem egy rövid ideig megugró termékszámként látszik a változás.

Hogyan épül fel a havi rutin lépésről lépésre?

A rutin egy fix napon, mindig ugyanabban a sorrendben fut, a fiókszinttől halad a darabszámon és az elutasított, majd korlátozott tételeken át a javításig és a nyilvántartásig. Közepes méretű katalógusnál (néhány ezer termék) ez saját tapasztalat szerint nagyjából egy-másfél óra, ha a nyilvántartás már létezik.

1. Fiókszintű problémák. Nyisd meg a fiók diagnosztikáját, és nézd meg, van-e új figyelmeztetés. Ami itt van, az minden más előtt jön.
2. Darabszám-összevetés. Töltsd le a teljes terméklistát az azonosítókkal, és vesd össze az előző havi mentéssel. A hiányzó azonosítók listája a csendben eltűnt termékek listája.
3. Elutasított tételek. Szűrj az elutasított állapotra, és csoportosítsd a tételeket hibakódonként. Egy hibakód egy feladat, nem száz.
4. Korlátozott tételek. Ugyanígy, hibakódonként. Itt érdemes külön figyelni a GTIN- és a szállítási hibákra, mert ezek gyakran egész márkákat vagy célországokat érintenek.
5. Rangsorolás. Minden hibakódhoz rendeld hozzá az érintett termékek forgalmát és árrését (részletesen lent).
6. Javítás a forrásban. A javítás helye a webshop, a raktárprogram vagy a feedgenerátor. A Merchant Center szabálya csak átmeneti megoldás.
7. Nyilvántartás frissítése. Minden hibakód kerüljön be a sablonba gazdával és gyökérokkal.
8. Utóellenőrzés. Néhány nappal a javítás után nézd meg újra az érintett tételeket, mert az újrafeldolgozás és az újraellenőrzés időbe telik.

A darabszám-összevetéshez nem kell külön eszköz. Ha mindkét hónap azonosítóit egy-egy rendezett szövegfájlba mented, egy terminálparancs kiadja a különbséget.

sort elozo_honap.txt -o elozo_honap.txt; sort e_honap.txt -o e_honap.txt; comm -23 elozo_honap.txt e_honap.txt > eltunt_termekek.txt

A kapott listát érdemes összevetni a webshop aktív termékeivel. Ami a boltban kapható, de a feedből hiányzik, az exportszűrő vagy azonosítóváltás áldozata. Ami a boltból is lekerült, az szándékos kivezetés lehet.

Hivatalosan igazolt. A Google a Content API for Shopping utódjaként a Merchant API-t jelölte meg. Ennek riport része lekérdező nyelvvel adja vissza a termékek összesített állapotát, így a havi lista automatizálható. Egy példa a nem megjeleníthető tételek lekérésére:

SELECT offer_id, title, aggregated_reporting_context_status FROM product_view WHERE aggregated_reporting_context_status = 'NOT_ELIGIBLE_OR_DISAPPROVED'

A mezőneveket és az állapotértékeket a dokumentáció aktuális változatában ellenőrizd, mert az API az elmúlt időszakban többször változott.

Hogyan rangsorold a javítást forgalom és árrés szerint?

A javítás sorrendjét az dönti el, mennyi kieső forgalom és árrés áll egy-egy hibakód mögött, nem az érintett termékek darabszáma. Egy hibakód, amely három erősen fogyó, jó árrésű terméket érint, előrébb való, mint egy másik, amely háromszáz, soha nem kattintott tételt.

1. Teljesítményadat. Minden érintett termékhez tedd oda az elmúlt 90 nap kattintásait és konverziós értékét. Ezt a Merchant Center teljesítményriportjából vagy a Google Ads termékszintű Shopping-riportjából kapod meg. A 90 nap kisimítja a szezonális kilengéseket.
2. Árrés-kategória. Adj minden terméknek magas, közepes vagy alacsony árrés-kategóriát a belső adataitok alapján. Ha a kategória már szerepel a feedben valamelyik custom_label mezőben, ez a lépés automatikus.
3. Pontszám. Egyszerű képlet is elég, például a konverziós érték szorozva egy árrés-szorzóval (magas 3, közepes 2, alacsony 1). Ahol nincs konverziós adat (új termék, friss beszerzés), a kattintás vagy a raktárkészlet mennyisége legyen az alap.
4. Összesítés hibakódonként. Add össze a pontszámokat hibakódonként. Ez megmutatja, melyik javítás hozza vissza a legtöbbet egyetlen munkával.
5. Kivételek. Fiókszintű hiba és irányelvsértés mindig a lista elejére kerül, a pontszámtól függetlenül, mert a fiók egészét veszélyeztetheti.

Hivatalosan igazolt. A custom_label_0 és custom_label_4 közötti egyéni címkék szabadon használhatók termékcsoportosításra, és a Google Ads kampányaiban szűrésre is alkalmasak.

Szakmai feltételezés. Az elutasítás előtti teljesítmény csak becslés arra, mit hozna a termék a javítás után, hiszen közben változhat az ár, a szezon és a versenyhelyzet. Sorrend felállítására ettől még megbízható, bevétel-előrejelzésre nem.

Miért adatgazdai kérdés a feedhibák nagy része?

A hibák többsége abból fakad, hogy egy adatnak (ár, készlet, GTIN, kép, szállítási idő) nincs kijelölt gazdája, aki a forrásrendszerben felel érte, és nem abból, hogy a feed technikailag rosszul működik. Ez a cikk saját nézőpontja, és saját tapasztalaton alapul.

Néhány tipikus helyzet. Az akciós ár éjfélkor élesedik a webshopban, a feed viszont reggel generálódik, így néhány órán át eltér a két ár. A GTIN mező azért üres, mert a beszerzés soha nem kérte el a beszállítótól. A termékképre a tartalomkészítő akciós feliratot tesz, ami ütközik a képekre vonatkozó előírással. A készletadat a raktárprogramból késve érkezik, így elfogyott termék szerepel elérhetőként. Ezek egyike sem programozási feladat. Mindegyiknél van egy ember vagy csapat, akinek a munkafolyamatába egy szabályt kell beépíteni.

• Ár és akció gazdája az árazásért felelős munkatárs.
• Készlet és elérhetőség gazdája a raktár vagy a logisztika.
• GTIN, márka, MPN gazdája a beszerzés, mert a beszállítótól ő tudja elkérni.
• Cím, leírás, kép gazdája a tartalomért felelős munkatárs.
• Szállítás és visszaküldés gazdája az üzemeltetés vagy az ügyfélszolgálat.
• Feedgenerálás, ütemezés, azonosítók gazdája a fejlesztő.

Szakmai feltételezés. Ha a havi rutin kizárólag a hirdetéskezelőn múlik, a javítások egy része tünetkezelés marad, mert ő a Merchant Centerben tud beavatkozni, a forrásrendszerben jellemzően nem.

Hogyan előzd meg, hogy ugyanaz a hiba visszajöjjön a feed forrásában?

Úgy, hogy minden hibát ott javítasz, ahol keletkezett, ahol lehet, a forrásban ellenőrzést teszel elé, a Merchant Center szabályait pedig csak átmeneti vagy szándékos felülírásra használod.

Hivatalosan igazolt. A Merchant Centerben adatforrás-szabályokkal és kiegészítő adatforrásokkal módosíthatók a beküldött termékadatok. Az automatikus termékfrissítés funkció a céloldal strukturált adatai alapján frissítheti az árat és az elérhetőséget, ha a feed és az oldal eltér. Ez csökkentheti az eltérés miatti elutasításokat, de a forrás hibáját nem szünteti meg.

Saját tapasztalat. A Merchant Centerben összekattintott szabály gyakran feledésbe merül. Fél évvel később valaki kijavítja az adatot a forrásban, a régi szabály pedig felülírja a jó értéket, és senki nem érti, miért. Ezért minden szabály kerüljön be a nyilvántartásba, gazdával és lejárati dátummal.

• A termékfelvételi űrlapon legyen kötelező a GTIN, vagy egy jelölés, hogy a terméknek nincs GTIN-je.
• Az akció élesítése indítson azonnali feedgenerálást, ne a napi ütemezésre várjon.
• A termékképekre vonatkozó szabály (felirat, vízjel, keret nélkül) legyen leírva a tartalomkészítés folyamatában.
• URL-változásnál legyen átirányítás, és a feed a végleges címet tartalmazza.
• Az exportszűrőket dokumentáld, és minden módosításuk után nézd meg a termékszámot.
• Webshopmotor- vagy bővítményfrissítés után ellenőrizd, hogy az azonosítók formátuma nem változott.

Milyen nyilvántartási sablon kell a visszatérő hibákhoz?

Egy egyszerű táblázat elég, soronként egy hibatípussal, nem pedig egy termékkel. A cél az, hogy egy pillantással látszódjon, mi tér vissza, ki a gazdája, és mi volt a gyökérok.

• Hibakód a Merchant Center szövegével, szó szerint.
• Első észlelés hónapja.
• Érintett termékek száma havonta.
• Prioritás-pontszám a fenti számítás szerint.
• Gyökérok egy mondatban.
• Adatgazda szerepkörrel vagy névvel.
• Javítás helye (forrásrendszer, feedgenerátor vagy Merchant Center szabály).
• Megelőző lépés, ami a forrásban változott.
• Állapot (nyitott, javítva, visszatért).
• Visszatérések száma.
• Ideiglenes szabály lejárata, ha van.

Egy szemléltető sor (nem valós eset):

Árütközés a céloldallal | 2026. szeptember | 14 termék | Gyökérok: az akció éjfélkor indul, a feed reggel frissül | Gazda: árazás | Javítás helye: feedgenerálás ütemezése | Megelőzés: akcióindításkor azonnali feedfrissítés | Állapot: javítva | Visszatérés: 1

Saját tapasztalat. A visszatérések száma a legtöbbet érő oszlop. Ha egy hiba harmadszor jelenik meg, az már nem feedhiba, hanem folyamathiba, és a megoldása egy beszélgetés az adatgazdával, nem újabb kattintás a Merchant Centerben.

Mi kerüljön a havi ellenőrzőlistára?

Az ellenőrzőlista a havi rutin lépéseit rögzíti úgy, hogy bárki el tudja végezni, akkor is, ha nem ő építette fel a feedet.

• Van-e új fiókszintű figyelmeztetés a diagnosztikában?
• Mennyi az aktív termékek száma, és mennyivel tér el az előző hónaptól?
• Elkészült-e az eltűnt azonosítók listája, és megvan-e mindegyiknél az ok?
• Hibakódonként csoportosítva megvannak-e az elutasított tételek?
• Hibakódonként csoportosítva megvannak-e a korlátozott tételek?
• Minden hibakódhoz tartozik-e prioritás-pontszám?
• Minden hibakódnak van-e adatgazdája?
• A javítás a forrásban történt-e, vagy csak szabállyal?
• Az ideiglenes szabályoknak van-e lejárata, és lejárt-e valamelyik?
• Változott-e az azonosítók formátuma a legutóbbi rendszerfrissítés óta?
• Frissült-e a nyilvántartás, és nőtt-e valamelyik hiba visszatérési száma?
• Ki van-e jelölve az utóellenőrzés napja?

A rutin nem jelenti azt, hogy minden termék jóváhagyott marad, hiszen az irányelvek és az ellenőrzések változnak. Jó eséllyel viszont hamarabb észreveszed a kiesést, és a javítások idővel kevesebb munkát igényelnek, mert ugyanaz a hiba ritkábban jön vissza.

Források és további olvasnivalók

• Google Merchant Center súgó, termékállapotok és problémák diagnosztikája
• Google Merchant Center súgó, termékadat-előírások
• Google Merchant Center súgó, automatikus termékfrissítések
• Google Merchant Center súgó, adatforrás-szabályok és kiegészítő adatforrások
• Google for Developers, Merchant API dokumentáció (Reports, product_view)
• Google Ads súgó, egyéni címkék használata Shopping-kampányokban
• Schema.org, Product és Offer típusok