Sloučení produktových dat z více feedů: pravidla priority a řešení konfliktů

Tento článek patří do pilíře Produktové feedy a je určen feed manažerům, katalogistům a technickým operátorům, kteří slučují produktová data z více zdrojů do jednoho výstupního feedu. Jde o informační průvodce vycházející z praxe se slučováním dat u e-shopů pracujících s třemi až osmi dodavatelskými feedy současně. V následujících sekcích projdeme pravidla priority zdrojů, řešení konfliktů atributů, hierarchii obrazových zdrojů, řešení nesouladů v cenách a skladových stavech a nastavení auditního logování. Téma navazuje na spojování XML feedů, kde jsme řešili příjem a validaci vstupních dat.

Sloučení produktových dat z více feedů je běžná operace, ale málokdo ji má skutečně pod kontrolou. Většina e-shopů začne s jedním dodavatelským feedem, postupně přidá další a řeší problémy ad hoc. Výsledkem je systém, kde nikdo přesně neví, odkud se vzala konkrétní hodnota atributu a proč se liší od toho, co vidí zákazník na webu.

Pravidla priority zdrojů

Každý datový zdroj má jinou úroveň spolehlivosti pro různé typy atributů. ERP systém je nejspolehlivější pro ceny a skladové stavy, protože reflektuje aktuální obchodní rozhodnutí. Dodavatelský feed je nejlepší zdroj technických specifikací, protože výrobce zná parametry svých produktů. PIM systém (pokud existuje) je autoritativní pro marketingové texty a strukturované popisy.

Pravidla priority musí být definována na úrovni atributu, ne na úrovni zdroje jako celku. Nestačí říct "ERP má přednost před dodavatelem". Správná formulace je: "Pro cenu má přednost ERP. Pro technické parametry má přednost dodavatelský feed. Pro obrázky má přednost PIM, pak vlastní fotobanka, pak dodavatel."

Tato pravidla zapište do konfiguračního souboru, který je verzovaný a přístupný celému týmu. Každé pravidlo by mělo obsahovat: název atributu, seřazený seznam zdrojů podle priority, chování při absenci dat v prioritním zdroji (použít další zdroj, nechat prázdné, nebo nastavit výchozí hodnotu) a datum poslední revize.

Praktická zkušenost ukazuje, že problémy nevznikají u atributů, kde je priorita jasná (cena, dostupnost). Vznikají u atributů, které se zdají nepodstatné, ale ovlivňují zákaznickou zkušenost: zkrácený název pro srovnávač, kategorizace, štítky pro filtraci. U těchto atributů mívají různé zdroje různou kvalitu a bez explicitního pravidla se výstup mění náhodně podle toho, který feed se zpracuje jako poslední.

Řešení konfliktů atributů

Konflikt nastane, když dva nebo více zdrojů obsahují stejný atribut se stejným produktovým identifikátorem (EAN, SKU), ale s různými hodnotami. Řešení závisí na typu atributu a na povaze konfliktu.

U číselných atributů (hmotnost, rozměry, výkon) je konflikt obvykle způsoben různými jednotkami, zaokrouhlením nebo chybou v jednom ze zdrojů. Řešení: normalizujte jednotky při importu, porovnejte hodnoty po normalizaci a pokud se liší o více než definovaný práh (například 5 procent), označte produkt k manuální revizi. Pokud se liší méně, použijte hodnotu z prioritního zdroje.

U textových atributů (název, popis, materiál) je konflikt často způsoben různou úrovní detailu. Dodavatel A uvede "bavlna", dodavatel B "100% bavlna, česaná". V tomto případě není konflikt chybou. Je to příležitost vybrat kvalitnější hodnotu. Pravidlo: u textových atributů preferujte delší a specifičtější hodnotu, pokud pochází z důvěryhodného zdroje.

U binárních atributů (dostupnost, aktivita) je konflikt kritický. Pokud jeden zdroj říká "skladem" a druhý "vyprodáno", musíte to vyřešit okamžitě. Bezpečný přístup: pokud jakýkoliv důvěryhodný zdroj říká "vyprodáno", považujte produkt za nedostupný. Falešné "skladem" generuje objednávky, které nemůžete splnit.

Hierarchie obrazových zdrojů

Obrázky jsou specifická kategorie atributů, protože jejich kvalitu nelze snadno porovnat automaticky. Cena, to je číslo. Název, to je text. Ale u obrázku potřebujete posoudit rozlišení, pozadí, perspektivu, přítomnost vodoznaku a soulad s požadavky cílové platformy.

Doporučená hierarchie: první prioritu mají vlastní fotografie (fotobanka e-shopu), protože nad nimi máte plnou kontrolu. Druhou prioritu mají obrázky z PIM systému, pokud procházejí schvalovacím procesem. Třetí prioritu mají dodavatelské obrázky, ale pouze pokud splňují minimální požadavky: rozlišení alespoň 800 x 800 pixelů, bílé nebo transparentní pozadí, bez vodoznaku, bez textu v obrázku.

Automatická kontrola obrázků by měla ověřovat: existenci souboru na dané URL (HTTP 200), rozlišení (minimální šířka a výška), formát (JPEG, PNG, WebP) a velikost souboru (příliš malý soubor naznačuje nízkou kvalitu, příliš velký zpomaluje načítání). Tuto kontrolu spouštějte denně, protože dodavatelé občas mění URL obrázků nebo vypínají hosting bez upozornění.

Důležitý detail: některé marketplace platformy vyžadují, aby hlavní obrázek ukazoval produkt bez obalu. Pokud dodavatelský feed obsahuje obrázek obalu a vaše fotobanka nemá alternativu, musíte to řešit. Nestačí jen prioritní řazení, potřebujete i pravidla pro obsah obrázku.

Nesoulady v cenách a skladových stavech

Cenové nesoulady mezi zdroji patří k nejrizikovějším konfliktům. Pokud feed zobrazí nižší cenu, než za kterou skutečně prodáváte, zákazník si produkt objedná za nižší cenu a vy budete muset buď objednávku splnit se ztrátou, nebo ji stornovat a poškodit si reputaci.

Zdroj pravdy pro ceny musí být jednoznačný. V naprosté většině případů je to ERP systém nebo cenotvorný modul e-shopové platformy. Dodavatelské ceny slouží jako referenční bod pro nákup, ne pro prodej. Nikdy nepropagujte dodavatelskou cenu jako prodejní, pokud nemáte automatický přepočet s aktuální marží.

Pro skladové stavy platí podobné pravidlo. Interní systém ví, kolik kusů máte fyzicky na skladě. Dodavatelský feed říká, kolik kusů má dodavatel. Pokud prodáváte ze skladu dodavatele (dropshipping), musíte počítat s prodlevou mezi dodavatelovým feedem a skutečným stavem. Bezpečnostní opatření: snižte zobrazovanou dostupnost o 10 až 20 procent oproti dodavatelskému feedu a nastavte prahovou hodnotu, pod kterou produkt přepnete do stavu "na dotaz".

Synchronizace mezi zdroji by měla probíhat minimálně jednou za hodinu u cen a dostupnosti. U ostatních atributů (parametry, popisy, obrázky) stačí denní frekvence. Při každé synchronizaci porovnejte klíčové metriky: celkový počet produktů, počet produktů s cenou, počet produktů skladem. Pokud se jakákoliv metrika změní o více než 10 procent oproti předchozímu běhu, pozastavte zpracování a zkontrolujte vstupní data.

Auditní logování

Bez auditního logu nemáte šanci zjistit, co se stalo, když zákazník reklamuje nesprávnou cenu nebo parametr. Log musí zachycovat: identifikátor produktu, název atributu, původní hodnotu, novou hodnotu, zdroj nové hodnoty, časové razítko a pravidlo, které změnu vyvolalo.

Ukládejte log do strukturovaného formátu (CSV, JSON nebo databáze), ne do prostého textu. Strukturovaný formát umožňuje filtrování a analýzu. Například: "Ukaž mi všechny cenové změny za poslední týden, kde nová cena je nižší než původní o více než 20 procent." Tento dotaz pomůže odhalit buď chyby v datech, nebo neplánované cenové války.

Retenci logu nastavte na minimálně 90 dní. Delší retence je užitečná pro sezónní analýzu (porovnání stavu dat ve stejném období minulého roku), ale zvyšuje nároky na úložiště. Kompromis: detailní log 90 dní, agregovaný přehled 12 měsíců.

Praktický tip: nastavte automatické upozornění na neobvyklé vzorce v logu. Pokud se za jednu hodinu změní více než 5 procent cen v katalogu, něco je pravděpodobně špatně. Může jít o chybný feed od dodavatele, o omyl v cenotvorbě nebo o technický problém při importu. Včasné upozornění zabrání propagaci chybných dat na srovnávače a marketplace.

Slučování produktových dat není jednorázové nastavení. Je to průběžný proces, který vyžaduje pravidelnou revizi pravidel, kontrolu kvality výstupů a reakci na změny ve vstupních zdrojích. Kdo toto ignoruje, dříve nebo později narazí na problém, který ho bude stát víc než čas strávený správným nastavením.