Jak sestavit QA checklist pro feed, než ho pustíte ven

QA checklist pro feed: proč testovat před publikací

QA checklist pro feed je poslední brána mezi vašimi produktovými daty a kanálem, který je schválí nebo zamítne. Většina e-commerce týmů validuje katalog interně, ale přeskočí strukturované testování samotného výstupu feedu — souboru nebo API payloadu, který Google Merchant Center, Amazon nebo Meta zpracuje.

Tento mezera je drahá. Jediný bug v transformaci může potichu smazat povinný atribut u tisíců SKU. Chyba ve formátování ceny může spustit hromadná zamítnutí přes noc. Špatné mapování kategorií může zařadit celou produktovou řadu do nesprávné taxonomie.

Tyto problémy mají jedno společné: dají se detekovat, než feed opustí váš systém. Stačí opakovatelný QA proces, který pokryje čtyři oblasti:

1. Unit testy pro jednotlivá transformační pravidla
2. Validace schématu a souboru vygenerovaného feedu
3. Sampling před spuštěním pro zachycení toho, co automatizace mine
4. Monitoring a alerting po publikaci pro omezení škod

Pokud řešíte širší pravidla kvality katalogových dat (kompletnost polí, datové typy, křížové validace), začněte naším validačním frameworkem katalogu. Tento článek se soustředí na testování výstupu feedu a pipeline, která ho produkuje.

Unit testování transformací feedu

Transformace feedu jsou pravidla, která převádí vaše interní produktová data do formátu specifického pro kanál. Šablony titulků, formátování měny, mapování dostupnosti, normalizace GTIN, lookup taxonomie — každá z nich je funkce se vstupem a výstupem. To je činí testovatelnými.

Co testovat

Napište unit testy pro každou transformaci, která mění hodnotu pole:

• Šablony titulků — ověřte, že produkt se značkou „Acme", názvem „Widget Pro" a barvou „Red" vytvoří Acme Widget Pro - Red (nebo co váš kanál očekává)
• Formátování cen — potvrďte, že interní cena 29.9 se stane 29.90 USD pro Google nebo 29,90 EUR pro evropský marketplace
• Mapování dostupnosti — ověřte, že vaše statusy skladu (in_stock, backorder, discontinued) odpovídají akceptovanému enumu kanálu
• Mapování kategorií — testujte, že váš interní strom kategorií vede ke správnému Google Product Taxonomy ID nebo Amazon Browse Node
• Validace GTIN/EAN — kontrolujte, že 13místné EAN kódy projdou kontrolou checksum a chybné hodnoty se označí místo tichého exportu
• Konstrukce URL obrázků — ujistěte se, že relativní cesty vedou k absolutním URL se správnou CDN doménou

Jak strukturovat testy

Udržujte testy transformací izolované od databáze a API. Každý test by měl:

1. Vytvořit minimální produktovou fixture jen s potřebnými poli
2. Spustit transformační funkci
3. Porovnat výstup s očekávanou hodnotou

Pokud transformace závisí na externích datech (lookup tabulka taxonomie), mockujte ji malou in-memory fixture. Cílem jsou rychlé, deterministické testy, které běží v sekundách a přesně řeknou, které pravidlo selhalo.

Spouštějte tyto testy při každé změně kódu, která se dotýká logiky feedu. I drobný refactoring může změnit výchozí hodnotu nebo pořadí řetězení stringů.

Validace vygenerovaného souboru feedu

Unit testy potvrzují, že jednotlivé transformace fungují. Další vrstva kontroluje sestavený feed — kompletní XML, CSV, JSON nebo TSV soubor.

Validace schématu

Každý velký kanál publikuje specifikaci. Použijte ji jako strojově čitelné schéma:

• Google Merchant Center — validujte proti specifikaci produktových dat. Povinná pole zahrnují id, title, description, link, image_link, availability, price a brand (nebo gtin).
• Meta Product Catalog — kontrolujte minimálně id, title, description, availability, condition, price, link a image_link, plus atributy specifické pro kategorii.
• Amazon — validujte proti flat file šabloně specifické pro kategorii nebo SP-API schématu pro váš product type.

Pokud si nejste jistí, která pole prioritizovat, náš checklist kvality produktových dat pokrývá 30 nejdůležitějších polí napříč kanály.

Kontroly na úrovni souboru

Kromě validace jednotlivých polí testujte feed jako celek:

• Počet řádků — porovnejte s posledním úspěšným feedem. Pokles o víc než 5-10 % obvykle signalizuje bug, ne legitimní odstranění produktů.
• Pokrytí povinných polí — vypočítejte procento řádků s neprázdnými hodnotami pro každé povinné pole. Když pokrytí image_link klesne z 98 % na 72 %, něco se rozbilo.
• Duplicitní ID — zajistěte, že žádné dva řádky nesdílí stejné product ID. Duplikáty způsobují nepředvídatelné přepisování.
• Kódování a formát — potvrďte, že soubor je validní XML nebo správně formátované CSV. Jediný neescapovaný ampersand v XML může způsobit zamítnutí celého feedu.
• Velikost souboru — neočekávaně malý (nebo velký) feed si zaslouží prověření.

Tyto kontroly se snadno automatizují a měly by běžet při každém generování feedu. Pokud váš tým používá platformu pro produktová data jako Lasso, mnoho z těchto validací probíhá automaticky jako součást enrichment a export pipeline — ale nezávislá kontrolní vrstva je stále dobrý zvyk.

Sampling před spuštěním: lidská vrstva

Automatizované testy zachytí známé vzory selhání. Sampling zachytí zbytek — edge case, na které nikdo nepomyslel.

Jak efektivně samplingovat

Před odesláním nového feedu nebo velké změny na kanál vytáhněte stratifikovaný vzorek z vygenerovaného souboru:

• Podle kategorie — vyberte 10-20 produktů z každé top-level kategorie. Požadavky na atributy se liší a chyby v mapování se shlukují uvnitř kategorie.
• Podle cenového pásma — zahrňte produkty z nízkého, středního i vysokého segmentu. Formátování cen, daně a logika dopravy se často chovají odlišně na extrémech.
• Podle typu varianty — pokud prodáváte produkty s variantami velikost/barva, zahrňte parent i child záznamy. Variantové feedy jsou nejčastějším zdrojem strukturálních chyb.
• Podle typu změny — prioritizujte nedávno přidané nebo upravené produkty. Nové importy a hromadné úpravy jsou rizikovější než stabilní záznamy.

U katalogu s 10 000+ SKU obvykle stačí ruční kontrola 50-100 záznamů pro odhalení systematických problémů. Nehledáte chybu v každém produktu — hledáte vzory.

Co kontrolovat v každém záznamu

Otevřete vzorové záznamy vedle specifikace kanálu a ověřte:

• Titulky jsou čitelné a sledují doporučenou strukturu kanálu
• Obrázky se načtou, když URL vložíte do prohlížeče
• Ceny odpovídají vašemu e-shopu a obsahují správný kód měny
• Dostupnost odráží aktuální stav skladu
• GTIN/MPN jsou přítomny tam, kde mají být, a chybí u custom produktů
• Kategorie je přesná, ne jen „přibližně správná"

Všechny nalezené problémy zdokumentujte. Pokud se jeden vzor objeví u více než dvou vzorků, pravděpodobně postihuje stovky dalších. Opravte kořenovou příčinu v transformaci, přidejte unit test a přegenerujte.

CI/CD brány pro feed pipeline

Pokud generování feedu běží jako naplánovaná úloha nebo build step, zacházejte s ním jako s produkčním kódem. Přidejte CI/CD brány, které zablokují odeslání špatného feedu na kanál.

Struktura brány

Minimální pipeline vypadá takto:

1. Build — vygenerujte soubor feedu z aktuálních produktových dat
2. Test — spusťte unit testy transformační logiky
3. Validate — spusťte validaci schématu a kontrol na úrovni souboru
4. Compare — porovnejte nový feed s posledním známým dobrým. Označte velké delty v počtu řádků, pokrytí polí nebo distribucích hodnot.
5. Gate — pokud jakákoli kontrola selže, zablokujte odeslání feedu. Notifikujte tým.
6. Deploy — odešlete feed na kanál (upload na SFTP, submit přes API, aktualizace hostované feed URL)

Praktické tipy

• Verzujte feedy. Uchovávejte posledních 3-5 souborů feedu pro porovnání, rollback nebo vyšetřování problémů.
• Oddělte deploye kanálů. Nebalte Google, Amazon a Meta do jednoho deploy stepu. Bug specifický pro Google by neměl blokovat váš Meta feed.
• Používejte dry runy. Google Merchant Center podporuje testovací feedy přes Content API. Meta umožňuje otestovat feed URL před aktivací.
• Nastavte deploy okna. Vyhněte se aktualizacím feedu v době špičky. Pokud se něco pokazí, potřebujete čas na vyšetření.

Pro týmy škálující napříč více kanály náš průvodce správou produktových feedů pokrývá operační model pro udržitelné multi-channel pipeline.

Monitoring a alerting po spuštění

I se silným pre-launch QA se věci v produkci rozbíjí. Kanály mění požadavky bez upozornění. Upstream datové zdroje se posouvají. Naplánovaná úloha selže potichu. Monitoring po spuštění je záchranná síť.

Klíčové metriky ke sledování

Nastavte dashboardy nebo automatizované reporty pro tyto indikátory zdraví feedu:

• Míra zamítnutí — procento odeslaných produktů, které kanál zamítnul. Sledujte denně. Skok znamená změnu ve vašich datech nebo ve validačních pravidlech kanálu.
• Změna impression share — náhlý pokles impresí může indikovat problémy s feedem ještě před objevením zamítnutí.
• Doba zpracování feedu — pokud zpracování trvá výrazně déle než obvykle, kanál může narážet na chyby parsování.
• Počet řádků v čase — sledujte počet aktivních, schválených produktů na kanál. Klesající trend signalizuje záměrné změny nebo tichý úbytek dat.
• Distribuce kategorií chyb — Google Merchant Center skupinuje chyby podle typu. Sledujte distribuci, ne jen celkový počet.

Prahy pro alerting

Definujte jasné prahy, které spustí alert:

• Míra zamítnutí přesáhne 5 % odeslaných produktů (nebo vzroste o více než 2 procentní body den ode dne)
• Počet řádků klesne o více než 5 % oproti předchozímu feedu
• Feed nebyl aktualizován v očekávaném intervalu (např. žádný nový feed za 25 hodin pro denní feed)
• Jakékoli varování na úrovni účtu z dashboardu kanálu

Směrujte alerty osobě, která vlastní feed pipeline, ne do sdíleného inboxu. Více o prevenci problémů na úrovni kanálu najdete v našem průvodci řešením chyb v Google Merchant Center.

Kompaktní QA checklist pro váš tým

Před prvním spuštěním:

• Unit testy existují pro každé transformační pravidlo feedu
• Validace schématu běží proti specifikaci kanálu
• Kontroly souboru pokrývají počet řádků, povinná pole, duplikáty a kódování
• Stratifikovaný vzorek 50-100 záznamů byl ručně zkontrolován
• Dry-run nebo testovací feed byl odeslán na kanál
• Verzování feedů a možnost rollbacku jsou na místě

Při každé aktualizaci feedu:

• CI/CD pipeline spouští unit testy, validaci a porovnávací kontroly
• Velké odchylky v počtu řádků nebo pokrytí polí blokují deploy
• Feedy se deployují zvlášť pro každý kanál

Po spuštění (průběžně):

• Míra zamítnutí, počet řádků a stáří feedu se sledují denně
• Prahy pro alerting jsou nastaveny s jasným vlastníkem
• Distribuce chyb se kontroluje týdně
• Změny specifikací kanálů jsou monitorovány a pravidla aktualizována

Pokud chcete snížit manuální QA zátěž a zachytit datové problémy dříve v pipeline, podívejte se, jak Lasso řeší validaci a enrichment feedů, nebo si domluvte ukázku s týmem.