Monitoring a alerty na chyby feedů: co hlídat a komu psát

Produktový feed se málokdy rozbije nahlas. Dodavatel přejmenuje element, export přestane plnit dostupnost, srovnávač nestáhne soubor, protože vypršel certifikát. E-shop dál běží, kampaně dál utrácejí. Jen s menším nebo horším katalogem.

Na chybu pak obvykle přijde někdo, kdo ji hledat neměl. Zákazník, obchodník, nebo účetní při měsíční uzávěrce. V článku ukazujeme, jak monitoring feedů postavit tak, aby se o chybě dozvěděl správný člověk během minut, ne týdnů. Jaké chyby ve feedech vznikají nejčastěji, rozebíráme v samostatném článku nejčastější chyby v produktových feedech. Tady se zaměříme na to, jak je chytat.

Dva směry, dvě různá rizika

E-shop obvykle pracuje se dvěma typy feedů. Každý se kazí jinak a každý potřebuje jiný monitoring.

Příchozí feedy posílají dodavatelé. XML feed se stáhne, zpracuje a zapíše do e-shopu. Chyba tady přímo mění data v obchodě: ceny, sklad, názvy. Rozbitý feed od dodavatele může během jednoho importu vyprodat polovinu katalogu nebo zlevnit tisíce produktů.

Odchozí feedy generuje e-shop pro Google Merchant Center, Heureku, Zboží.cz nebo marketplace. Chyba tady data v e-shopu nemění. Sebere vám ale zobrazení a tržby z kanálu, a to často potichu.

Z toho plyne jednoduché pravidlo. U příchozích feedů monitoring blokuje: když data nevypadají v pořádku, import se zastaví. U odchozích feedů monitoring upozorňuje: kanál si data stáhne tak jako tak, vy potřebujete vědět, co s nimi udělal.

Co hlídat: pět vrstev signálů

Monitoring feedu není jedna kontrola. Je to pět vrstev, od nejjednodušší po nejdražší.

1. Dostupnost. Odpověděl server? Jaký vrátil HTTP kód? Změnil se soubor od minula, nebo přišla stará verze? U feedů na FTP hlídáme čas poslední úpravy souboru.
2. Struktura. Je soubor validní XML nebo CSV? Nebyl useknutý uprostřed? Obsahuje očekávaný kořenový element a povinná pole?
3. Objem. Kolik přišlo položek oproti minulé verzi? Kolik z nich má sklad, cenu, obrázek, EAN?
4. Obsah. Změnily se ceny o víc, než je obvyklé? Přišly v jiné měně nebo bez DPH? Zmizela celá kategorie?
5. Stav v kanálu. Kolik produktů kanál přijal, kolik zamítl a proč?

První čtyři vrstvy řešíte sami a hned. Pátou vám dodá kanál, ale se zpožděním. Proto potřebujete obě.

Signály, prahy a závažnost

Nejčastější chyba v monitoringu není chybějící kontrola. Je to kontrola se špatným prahem, která buď nikdy nezazvoní, nebo zvoní pořád. Tabulka ukazuje, jak prahy nastavujeme jako výchozí. Čísla jsou orientační a ladí se podle konkrétního dodavatele a sezóny.

Relativní prahy fungují lépe než absolutní. Pokles o 500 položek je u katalogu s 50 000 produkty běžný den, u katalogu s 2 000 produkty havárie. Proto porovnáváme s minulou verzí a s obvyklým rozptylem, ne s pevným číslem.

Co vám řeknou samotné kanály

Každý velký kanál má vlastní diagnostiku. Monitoring ji nemá nahrazovat, ale číst.

Google Merchant Center. Problémy s produkty najdete v sekci Produkty na kartě Needs attention (produkty vyžadující pozornost), která nahradila dřívější Diagnostiku. Seznam dotčených položek jde vyfiltrovat a stáhnout jako CSV. E-mailová upozornění se zapínají v nastavení notifikací. Některé typy upozornění na produktová data jsou podle nápovědy Google dostupné jen po přihlášení k odběru, takže je potřeba je aktivně zapnout. Pozor na preventivní zamítnutí: když Google při procházení webu zjistí jinou cenu nebo dostupnost než ve feedu, může produkt stáhnout dřív, než vám cokoli přijde.

Merchant API. Pokud máte Merchant Center napojené přes API, můžete odebírat push notifikace. Podle dokumentace Google se na událost PRODUCT_STATUS_CHANGE zaregistruje veřejná HTTPS adresa a Google na ni posílá změny stavu produktů, například zamítnutí. Je to v podstatě webhook z Merchant Center. Připomínáme, že Content API for Shopping skončilo 18. 8. 2026 a od 1. 9. 2026 na něj podle Google dopadají postupně narůstající chyby. Starší integrace, které na něm stojí, jsou samy o sobě rizikem, které stojí za alert.

Zboží.cz a Seznam Nákupy. Kampaně Zboží.cz se ve Skliku jmenují Seznam Nákupy a diagnostika feedu je tamtéž. Seznam v nápovědě uvádí jako nejčastější chyby duplicitní nebo chybějící ITEM_ID, chybějící či neplatný DELIVERY_DATE, neplatný EAN a neplatné URL obrázků. Chybné položky a duplicity se do Zboží.cz nenahrají.

Heureka. V administraci obchodu sledujte hlavně přehled spárovanosti produktů. Nespárované produkty nejsou chyba feedu v technickém smyslu, ale přicházíte kvůli nim o zobrazení u produktových karet.

Shoptet jako příjemce. U automatického importu produktů lze podle nápovědy Shoptetu na kartě Historie zadat e-mail, na který přijde zpráva, když dodavatel pošle nevalidní feed. Je to užitečná první pojistka. Zachytí ale jen strukturu, ne obsah. Feed se 70 % nulových skladů je validní.

Alerty, které lidé nepřestanou číst

Alert, který chodí desetkrát denně, přestane někdo číst do týdne. Pak přehlédne i ten jediný důležitý. Při návrhu alertů proto držíme několik zásad:

• Každý alert má vlastníka. Feed dodavatele hlídá nákup nebo produktový tým, feed do Merchant Center ten, kdo řídí kampaně. Alert do obecného kanálu, kam píše všech deset lidí, neřeší nikdo.
• Každý alert vyžaduje akci. Informativní změny, třeba „přibylo 40 produktů“, patří do denního souhrnu.
• Jedna příčina, jeden alert. Když spadne feed dodavatele, nechcete 3 000 zpráv o produktech bez skladu. Chcete jednu zprávu: feed dodavatele X je od 6:00 nedostupný.
• Alert říká, co dělat. Odkaz na feed, na poslední úspěšnou verzi, na log a jednu větu, co zkontrolovat jako první.
• Kanál podle závažnosti. Kritické chyby přes SMS nebo chat, vysoké do chatu vlastníka, střední do denního souhrnu e-mailem.
• Alert se sám uzavře. Když se feed při dalším běhu opraví, přijde zpráva „vyřešeno“. Jinak lidé nevědí, jestli se problém ještě řeší.

Hlídejte i to, co se nestalo

Nejzákeřnější chyby nevyhodí žádnou výjimku. Cron úloha přestane běžet po aktualizaci serveru. Dodavatel posílá pořád stejný soubor s včerejším datem. Merchant Center stahuje feed z adresy, kterou už nikdo neaktualizuje.

Proti tomu pomáhá kontrola tlukotu srdce (heartbeat). Každý úspěšný běh zapíše čas. Samostatná kontrola pak hlídá, jestli čas není starší, než by měl být. Když import běží každou hodinu a poslední úspěšný běh je tři hodiny starý, přijde alert, i když žádná chyba nikde nezazněla.

Stejně to platí pro kanály. Produkty v Merchant Center, které se neobnoví, podle Google po 30 dnech vyprší. Plánované stahování feedu tomu brání, ale jen dokud funguje. Čas poslední úspěšné aktualizace u každého kanálu proto patří mezi hlídané signály. Obecnější pohled na tenhle princip u všech integrací najdete v článku monitoring integrací.

Kde monitoring běží

Technicky existují tři úrovně, podle velikosti katalogu a počtu feedů:

Ve všech variantách doporučujeme ukládat každou staženou verzi feedu. Bez ní se prahy „proti minulé verzi“ nedají spočítat a při chybě nemáte na co vrátit data. Proč se historie vyplatí i jinak, píšeme v článku historie změn feedu.

Jak na to prakticky

Pokud monitoring feedů zavádíte od nuly, tento postup vás dostane k funkčnímu základu:

1. Sepište všechny feedy: odkud, kam, jak často, kdo je vlastník.
2. U příchozích feedů zapněte kontrolu dostupnosti a validity před každým importem.
3. Ukládejte každou verzi a nastavte prahy pro počet položek, sklad a ceny.
4. Rozhodněte, co import pozastaví a co jen upozorní.
5. V Merchant Center zapněte e-mailová upozornění a pravidelně stahujte report problémů. Totéž u diagnostiky ve Skliku a spárovanosti na Heurece.
6. Přidejte heartbeat pro každý import i export.
7. Po měsíci projděte, které alerty nikdo neřešil, a upravte prahy nebo je přesuňte do souhrnu.

Monitoring příchozích feedů stavíme jako součást napojení v rámci služby dodavatelé a feedy. Průběžný dohled nad feedy, dostupností a výkonem e-shopu nabízíme jako Performance Monitoring, cenu připravíme podle počtu feedů a kanálů. Pokud chcete kontrolu obsahu posunout ještě dál, podívejte se, jak funguje AI správce feedů.