Monitoring zamítnutých produktů v Merchant Center

Merchant Center vám ráno ukáže, že máte 260 zamítnutých produktů. Nezobrazí, že jich včera bylo dvanáct.

To je celý problém. Číslo bez včerejška nevypovídá o ničem. U jednoho katalogu je 260 zamítnutých produktů z osmdesáti tisíc běžné pondělí, u druhého to znamená, že v pátek večer někdo přepsal dostupnost u čtvrtiny sortimentu a od té doby přicházíte o tržby.

Ukážu vám čtyři signály, které stojí za sledování, a skript, který je hlídá za vás. Nasazení zabere deset minut, běží zdarma v Googlu a nepotřebuje server.

Co Merchant Center neukáže

Rozhraní ukazuje stav. Vy potřebujete změnu.

V Diagnostice sice najdete vývoj za posledních 30 dní, ale je to graf, na který se musíte jít podívat. Nemá prahy, nikoho neupozorní a nikam nic neposílá. Když se na něj podíváte v úterý, o pátečním incidentu se dozvíte se čtyřdenním zpožděním. Zamítnutý produkt přitom neběží od první minuty.

Merchant Center vám sám od sebe napíše ve dvou situacích: při zásahu na úrovni účtu a při velkých problémech, které vyhodnotí jako zásadní. Obojí je vážnější kategorie než ta, o které mluvím. Postupné zhoršování, které se dá zastavit dřív, než doroste do zásahu na účet, projde bez povšimnutí.

Přidejte k tomu, že katalog se hýbe. Produkty přibývají a mizí, ceny se mění, dostupnost skáče. Absolutní počet zamítnutí se proto pohybuje pořád a bez porovnání s předchozím dnem nepoznáte výkyv od trendu.

Čtyři signály, které hlídat

Jeden práh na všechno nefunguje. Malý katalog potřebuje jiný než osmdesátitisícový.

Používám kombinaci čtyř podmínek. Stačí, aby platila jedna:

1. Absolutní nárůst. Přibylo aspoň deset zamítnutých produktů. U katalogu s pěti sty položkami je to spolehlivý signál, protože relativní změna u malých čísel skáče i bez příčiny.
2. Relativní nárůst. Přibylo aspoň o 20 % proti včerejšku. U velkého katalogu je tohle hlavní práh: deset produktů z osmdesáti tisíc není zpráva, dva tisíce ano.
3. Nový důvod zamítnutí. Objevil se kód, který včera v účtu nebyl. Tohle chytí policy zásah i rozbitý atribut dřív, než se projeví v počtech.
4. Podíl na katalogu. Zamítnuté přesáhly 5 % sortimentu. Pojistka pro případ, že problém rostl pomalu a předchozí tři prahy propásl.

Žádné z těch čísel není doporučení Googlu. Google prahy neuvádí, jsou to hodnoty, se kterými mi dávají smysl výsledky na účtech, které spravuju. Nastavte si vlastní podle toho, co u vás znamená „něco se stalo".

Proč samotný počet nestačí

Nárůst vám řekne, že máte problém. Důvod vám řekne, koho na něj zavolat.

Zamítnutí kvůli chybějícímu GTIN opravíte v doplňkovém feedu za odpoledne a nikomu nemusíte volat. Zamítnutí kvůli porušení pravidel pro omezené kategorie znamená právníka, certifikaci nebo změnu sortimentu. Zamítnutí kvůli image_link_internal_error je výpadek na straně vašeho serveru a řeší ho vývojář, ne PPC specialista.

Souhrnné číslo „260 zamítnutých" mezi těmito situacemi nerozlišuje. Rozlišuje mezi nimi kód důvodu.

Proto z každého běhu potřebujete tabulku, ne jedno číslo:

184× availability_mismatch (disapproved)     +184  nový
  2× image_link_internal_error (disapproved)   ±0
  1× recalled_product (disapproved)            ±0

Z tohohle výpisu je za tři vteřiny jasné, že jde o jednu příčinu, je nová a týká se stovky produktů. To je import feedu nebo výpadek dostupnosti, tedy něco, co jde vrátit zpátky. Kdyby přibylo pět různých důvodů po třiceti produktech, řešíte úplně jiný scénář.

Kompletní seznam kódů i s postupem opravy mám v článku o deseti nejčastějších důvodech, proč Merchant Center zamítá produkty. Monitoring vám řekne, který z nich právě hoří.

Jak si to postavit

Data vytáhnete přes Merchant API, konkrétně přes dotaz nad tabulkou product_view. Jeden dotaz vrátí status každého produktu i se seznamem důvodů:

SELECT product_view.id,
       product_view.aggregated_reporting_context_status,
       product_view.item_issues
FROM product_view

Status nabývá čtyř hodnot. ELIGIBLE je v pořádku, ELIGIBLE_LIMITED běží s omezením, NOT_ELIGIBLE_OR_DISAPPROVED neběží vůbec a PENDING čeká na kontrolu.

Sledoval bych obě problémové kategorie. Omezený výkon bývá předstupeň zamítnutí a všímat si ho až ve chvíli, kdy se překlopí, znamená přijít o týden náskoku.

Jedna past na začátek: Merchant API má od 28. února 2026 jen verzi v1. Verze v1beta byla zrušena a vrací HTTP 409 s odkazem na migraci. Většina návodů, které dneska na internetu najdete, na ni pořád odkazuje, takže je nezkoušejte opsat.

Celý skript i s návodem jsem dal veřejně na GitHub. Je to Google Apps Script, takže běží zdarma v Googlu, spouští se sám jednou denně a alert posílá do Google Chatu nebo e-mailem. Nastavení zabere deset minut a nepotřebujete k němu vývojáře.

Stejným způsobem jsem před časem řešil změnu Google biddingu k 17. srpnu, kde Google taky nedal žádnou diagnostiku a seznam dotčených kampaní si musel každý sestavit sám.

Co s alertem dělat

Alert, na který nikdo nereaguje, je horší než žádný, protože vytváří dojem, že se hlídá.

Nastavte si proto tři věci. Zprávy posílejte do místa, kde se pracuje, ne na e-mail, který nikdo nečte. Prahy nastavte tak, aby vám nechodilo nic ve dnech, kdy je klid. A pojmenujte dopředu, kdo reaguje na které důvody, aby se zpráva nezastavila u někoho, kdo s ní nic neudělá.

Když alert dorazí, postup je vždycky stejný:

1. Podívejte se na důvod, ne na počet.
2. Ověřte, jestli je důvod nový, nebo jen narostl.
3. U nového a početného důvodu zkontrolujte poslední import feedu.
4. Opravu udělejte v doplňkovém feedu, pokud jde o data, a ne o pravidla.
5. V Diagnostice označte položky jako opravené a počkejte na další procházení.

Když je zamítnutých produktů nad 30 % katalogu, řešíte jinou ligu problému. Tam hrozí zásah na úrovni účtu a postup je popsaný v článku o misrepresentation a zamítnutí účtu.

Shrnutí

1. Merchant Center ukazuje stav, ne změnu. Číslo bez včerejška nevypovídá o ničem.
2. Hlídejte čtyři signály současně: absolutní nárůst, relativní nárůst, nový důvod zamítnutí a podíl na katalogu. Prahy si nastavte sami, Google žádné nedává.
3. Počet zamítnutých produktů říká, že máte problém. Kód důvodu říká, kdo ho má řešit.
4. Data vytáhnete jedním dotazem nad product_view v Merchant API. Používejte verzi v1, v1beta skončila 28. února 2026.
5. Skript i s návodem je na GitHubu, běží zdarma v Apps Scriptu a alert posílá do Google Chatu nebo e-mailem.
6. Kontrolujte denně. Mezi dvěma kontrolami se má vejít nejvýš jeden import feedu.

Pokud řešíte Shopping a Merchant Center dlouhodobě, mrkněte na správu Google Ads. Feed, měření i kampaně beru jako jednu věc, protože se navzájem podmiňují.