Katalog produktů (Product catalog)

Příklady z praxe

1. 01

   Datový model produktu s variantami

   Obchod s oblečením drží společný obsah na rodičovském produktu a skladové položky na variantách. Každá varianta má vlastní SKU a zásobu, ale sdílí popis i galerii. Objednávka odkazuje vždy na variantu, nikdy na rodiče, jinak by sklad nevěděl, co má vyskladnit.

   CREATE TABLE product (
     id            bigserial PRIMARY KEY,
     slug          text UNIQUE NOT NULL,
     name          text NOT NULL,
     description   text,
     brand_id      bigint REFERENCES brand(id)
   );
   
   CREATE TABLE product_variant (
     id            bigserial PRIMARY KEY,
     product_id    bigint NOT NULL REFERENCES product(id) ON DELETE CASCADE,
     sku           text UNIQUE NOT NULL,
     ean           text,
     price_cents   integer NOT NULL,
     stock_qty     integer NOT NULL DEFAULT 0,
     attributes    jsonb NOT NULL DEFAULT '{}'::jsonb
   );
   
   CREATE INDEX ON product_variant USING gin (attributes);

2. 02

   Strukturovaná data na stránce produktu

   Stránka produktu vystaví údaje z katalogu i strojově, aby vyhledávače mohly zobrazit cenu a dostupnost. Pokud se hodnota v JSON-LD rozejde s cenou vykreslenou na stránce, jde o nesoulad, který vyhledávače penalizují. Generovat proto oba výstupy z jednoho zdroje.

   {
     "@context": "https://schema.org",
     "@type": "Product",
     "name": "Běžecká bunda Alpine",
     "sku": "ALP-JKT-M-BLK",
     "gtin13": "8594001234567",
     "brand": { "@type": "Brand", "name": "Alpine" },
     "offers": {
       "@type": "Offer",
       "price": "2490",
       "priceCurrency": "CZK",
       "availability": "https://schema.org/InStock"
     }
   }

Časté omyly

MýtusKatalog produktů je prostě tabulka zboží, tu si nadefinuju za odpoledne.

Ve skutečnostiKatalog musí současně zvládnout varianty, vícejazyčnost, ceníky pro různé skupiny zákazníků, historii cen a rozdílné požadavky exportních kanálů. Právě tyhle rozměry rozhodují o tom, jestli se e-shop dá po roce rozšířit, nebo se přepisuje.

MýtusFulltext ve vyhledávacím enginu nahradí databázi katalogu.

Ve skutečnostiVyhledávací index je odvozená kopie optimalizovaná pro čtení a nemá transakční záruky. Zdrojem pravdy pro ceny a zásoby zůstává databáze, index se z ní jen průběžně naplňuje.

MýtusPopisy stačí zkopírovat od dodavatele, jsou přece správné.

Ve skutečnostiIdentické texty sdílí desítky e-shopů, takže se stránka obtížně odlišuje ve vyhledávání a chybí v nich parametry potřebné pro filtry. Vlastní strukturované atributy mají větší hodnotu než převzatý odstavec.

Časté dotazy

Jak velký katalog produktů zvládne běžná relační databáze?

Relační databáze typu PostgreSQL zvládne stovky tisíc až miliony položek bez potíží, pokud jsou dotazy dobře indexované. Problém obvykle nedělá počet řádků, ale kombinace filtrů nad mnoha volitelnými atributy a řazení podle relevance. Jakmile výpis kategorie potřebuje deset spojení tabulek a fasetové počty u každého filtru, vyplatí se katalog denormalizovat do vyhledávacího indexu a databázi nechat jako zdroj pravdy pro objednávky a zásoby.

Kdy se vyplatí oddělit PIM od e-shopové platformy?

Oddělený PIM se vyplatí tehdy, když produktová data vznikají v několika odděleních nebo systémech, prodává se ve více jazycích a zemích, případně přes více prodejních kanálů současně. PIM pak drží jednu verzi pravdy, řeší schvalovací proces a překlady a do e-shopu i marketplace posílá hotová data. U jednoho obchodu s několika stovkami položek a jedním jazykem je samostatný PIM zbytečná vrstva navíc, kterou musí někdo provozovat a synchronizovat.

Jak řešit v katalogu produktů více ceníků a měn?

Cena nepatří jako jediné číslo přímo k variantě, jakmile existují velkoobchodní skupiny, akce nebo více zemí. Osvědčený model zavádí samostatnou tabulku cen s vazbou na variantu, ceníkovou skupinu, měnu a časovou platnost. Aplikace pak při zobrazení vybírá nejkonkrétnější platný záznam. Tenhle model navíc umožňuje připravit budoucí akci dopředu a zpětně doložit, za jakou cenu se položka v daný den prodávala, což je užitečné při reklamacích i kontrolách.

Co dělat s produkty, které se přestaly prodávat?

Vyřazené položky se z katalogu nemažou. Historické objednávky na ně odkazují, stránky mohou mít zpětné odkazy a návštěvnost z vyhledávačů. Doporučený postup je označit položku jako neaktivní, skrýt ji z výpisů a exportů, ale stránku ponechat dostupnou s informací o nedostupnosti a odkazem na alternativu. Pokud produkt nahradil nástupce, dává smysl trvalé přesměrování. Úplné smazání záznamu z databáze vede k nekonzistentním objednávkám a ztrátě reportingu.

Zdroje

1. Product(otevře se v novém okně)Schema.org
2. Product structured data(otevře se v novém okně)Google Search Central
3. JSON Types(otevře se v novém okně)PostgreSQL Global Development Group

Související pojmy

• Feed produktůFeed produktů je strukturovaný soubor nebo datový výstup, kterým e-shop předává katalog zboží reklamním systémům, srovnávačům, tržištím nebo interním aplikacím. Obsahuje položky jako název, cena, dostupnost, URL, obrázek a identifikátory. Kvalitní feed umožňuje automatickou aktualizaci nabídek bez ručního přepisování dat.
• Fulltextové vyhledáváníFulltextové vyhledávání je způsob hledání v textových dokumentech, který neporovnává jen přesný řetězec znaků, ale pracuje s tokeny, jazykovými tvary a pořadím slov. Vyhledávač si obvykle vytváří index, podle dotazu najde kandidáty a seřadí výsledky podle relevance, případně zvýrazní nalezené pasáže.
• Normalizace databázeNormalizace databáze je způsob návrhu relační databáze, při kterém se data rozdělují do tabulek podle významu a závislostí, aby se omezila duplicita a nekonzistence. Typicky se opírá o normální formy, primární klíče a cizí klíče; výsledkem je čistší model, ale někdy složitější dotazy.
• Strukturovaná dataStrukturovaná data jsou strojově čitelný popis obsahu stránky zapsaný ve sjednoceném slovníku, nejčastěji podle schema.org ve formátu JSON-LD. Vyhledávačům a dalším programům říkají, že určitý text je cena, autor, hodnocení nebo otevírací doba, místo aby si význam musely odhadovat z vizuálního rozvržení a formulací v HTML.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• AcquirerAcquirer je finanční instituce nebo platební poskytovatel, který obchodníkovi umožňuje přijímat karetní platby a předává transakce do karetních schémat. V online platbách stojí mezi platební bránou, vydavatelem karty a obchodníkem, zajišťuje autorizaci, zúčtování, vyplacení peněz a část řízení rizik.
• Alt atributAlt atribut je atribut HTML značky <img>, který nese textovou alternativu obrázku pro situace, kdy uživatel obrázek nevidí. Čtou ho odečítače obrazovky, zobrazí se při nenačtení souboru a vyhledávače z něj odvozují obsah obrázku. Prázdná hodnota alt="" je platná a znamená, že obrázek je čistě dekorativní.
• Anchor textAnchor text je viditelný, klikatelný text odkazu, tedy obsah mezi značkami <a> a </a>. Vyhledávačům i uživatelům popisuje, co najdou na cílové stránce, a spoluurčuje, na jaké dotazy cílová stránka hodnotí. Kvalitní anchor text je krátký, popisný a čitelný i vytržený ze zbytku věty.