Historie změn feedů: proč ji uchovávat a jak na to

Pondělí ráno. Polovina katalogu jednoho dodavatele je v e-shopu o třetinu levnější než v pátek. Chyba dodavatele? Chyba přepočtu měny? Někdo změnil přirážku? Bez historie feedů odpověď hádáte. Voláte dodavateli, ten tvrdí, že u něj je všechno v pořádku, a vy nemáte čím doložit opak.

S historií otevřete záznam změn a za dvě minuty víte, že cenu změnil dodavatelův feed v neděli ve 3:12 a že to bylo u všech produktů jedné značky. Tohle je nejčastější důvod, proč historii feedů uchovávat. Není ale jediný.

Co historie feedů řeší

Aktuální stav v e-shopu říká, jak věci jsou. Historie říká, jak se k tomu došlo. Konkrétně pomáhá v těchto situacích:

Návrat po špatném importu

Dodavatel pošle useknutý feed. Nebo feed, kde je u všech produktů sklad nula. Nebo změní strukturu a místo popisů přijdou prázdné řetězce. Dobré zpracování většinu z toho zachytí kontrolami, které popisujeme v článku XML feedy: jak fungují a jak je zpracovat. Ale ne všechno.

Když chyba projde až do e-shopu, historie rozhodne, jak rychle ji opravíte. Pokud víte, která pole který import změnil, můžete vrátit přesně je. Bez toho zbývá obnova celé zálohy e-shopu, a ta přepíše i objednávky a úpravy, které mezitím vznikly. Nebo ruční oprava stovek produktů.

Ceny, slevy a 30 dní

Tady historie přestává být technický luxus. Podle § 12a zákona o ochraně spotřebitele musí oznámení o slevě obsahovat nejnižší cenu, za kterou jste zboží nabízeli a prodávali během 30 dnů před slevou. Pravidlo platí pro kamenné obchody i e-shopy a podle ČOI se týká slev v jakékoli podobě, včetně označení „akce". U postupně zvyšované slevy lze podle ČOI uvádět nejnižší cenu za 30 dní před první slevou.

Pokud prodejní ceny nastavujete ručně, e-shop si je obvykle pamatuje sám. Pokud je ale počítáte automaticky z nákupní ceny ve feedu a přirážky, cena se může měnit několikrát denně. Pak potřebujete vlastní záznam prodejních cen po dnech, abyste nejnižší cenu uměli spočítat a doložit. Jak automatické přeceňování nastavit, rozebíráme v článku Automatické přeceňování podle marže.

Historii cen sleduje i Heureka. Slevu na produktu podle svých pravidel označí sama, jen když ji ověří z vlastní historie cen, a produkt k tomu musí mít aspoň 30denní historii. Přeškrtnutá cena na e-shopu, která neodpovídá vývoji ceny, je vidět v grafu na detailu produktu.

Data pro nákup a jednání s dodavateli

Historie feedů je zároveň levný zdroj dat, který se často bez užitku zahazuje. Z uložených změn zjistíte:

• jak často dodavatel mění nákupní ceny a o kolik,
• jak často a na jak dlouho mu dochází sklad u vašich nejprodávanějších produktů,
• kolikrát feed nepřišel, přišel pozdě nebo neprošel kontrolou,
• které produkty dodavatel tiše vyřadil nebo vrátil do nabídky.

To jsou argumenty pro jednání o podmínkách i pro rozhodnutí, u koho produkt objednávat, když ho má víc dodavatelů. Jak kvalitu dat od dodavatelů měřit a vyžadovat, popisujeme v článku Kvalita dat od dodavatelů.

Co ukládat a jak dlouho

Nemusíte ukládat všechno navždy. Osvědčily se nám tři vrstvy:

1. Syrové soubory. Přesně to, co přišlo od dodavatele, komprimované. Slouží k dohledání chyb a k důkazu vůči dodavateli. Typicky stačí týdny, u problematických dodavatelů déle.
2. Záznam změn. U každé změny produkt, pole, stará hodnota, nová hodnota, čas a zdroj. Vzniká při porovnání s minulým stavem, které stejně děláte v rámci ETL zpracování. Je malý, protože obsahuje jen změny, a vyplatí se ho držet dlouho.
3. Denní přehled cen a skladu. Pro každý produkt nejnižší a nejvyšší cenu a dostupnost za den. Z toho se počítá nejnižší cena za 30 dní a statistiky dodavatelů.

Modelový záznam změny může vypadat takto (ilustrační příklad):

Z takových dvou řádků je hned vidět, že prodejní cenu nezměnil člověk, ale automatický přepočet po změně nákupní ceny. A že oprava patří do feedu, ne do nastavení přirážky.

Pro syrové soubory stačí objektové úložiště s verzováním. Například Amazon S3 umí podle dokumentace pravidly životního cyklu staré verze po nastaveném počtu dní přesunout do levnější třídy úložiště nebo smazat a ponechat jen určitý počet posledních verzí. Záznam změn patří do databáze, kde se dá dotazovat.

Délku uchovávání určete podle účelu, ne podle místa na disku. Pokud z dat dokládáte cenu pro slevy, musí historie vždy pokrýt aspoň 30 dní před každou slevou. Pokud je používáte pro jednání s dodavatelem, dává smysl aspoň rok.

Historie jako základ pro monitoring

Záznam změn je přesně to, co potřebují upozornění na chyby. Pokud víte, jak se feed choval včera a minulý týden, poznáte anomálii: o polovinu méně položek, cenový skok u celé značky, sklad nula u všeho. Bez historie nemáte s čím porovnávat. Jak na tom postavit alerty, popisujeme v článku Monitoring a alerty na chyby feedů.

Na stejných datech stavíme i AI správce feedů, který neobvyklé změny vyhodnocuje dřív, než se dostanou do e-shopu.

Jak na to prakticky

Checklist pro zavedení historie feedů:

1. Ukládejte každý stažený feed do vlastního úložiště před zpracováním.
2. Při porovnání s minulým stavem zapisujte změny po polích se zdrojem a časem.
3. U prodejních cen držte denní přehled aspoň pro 30 dní zpětně, raději déle.
4. Nastavte pravidla uchovávání pro každou vrstvu zvlášť.
5. Připravte postup pro vrácení změn z konkrétního importu.
6. Napojte na historii kontroly a upozornění.
7. Jednou za čtvrtletí se podívejte na statistiky dodavatelů.

Historii změn stavíme jako součást napojení v rámci služby napojení dodavatelů a feedů. Jednorázová implementace začíná od 3 000 Kč za dodavatele, správa běží měsíčním paušálem. Pokud už feedy máte napojené a historii ne, doplníme ji do stávajícího řešení.