Managing Product Catalogs in E-commerce
The product catalog is the structural core of an online store. How it is modelled determines what is possible downstream: in search, filtering, pricing rules, inventory tracking, and feed syndication to external channels. Catalog debt — accumulated from poorly defined attributes, duplicated SKUs, and inconsistent categorisation — is one of the most common sources of operational friction in growing online retail businesses.
1. Product data models: flat, hierarchical, and configurable
Most e-commerce platforms distinguish between three product types:
- Simple products — a single SKU with a fixed price and stock count. Appropriate for non-variable items such as a specific book edition or a single-size accessory.
- Variable products — a parent record linked to multiple child SKUs, each defined by a combination of attributes (size, colour, material). The parent holds shared content; each variant holds its own price, EAN, and stock quantity.
- Grouped or bundled products — collections of SKUs sold as a unit. Less common in general retail but standard in electronics and kit-based categories.
The choice of model affects database performance as the catalog grows. Stores with more than 50,000 SKUs typically need to review their variant model and attribute indexing configuration, since unoptimised variant queries are a frequent cause of slow filter pages.
2. Attribute schema design
Attributes describe product properties that buyers use to navigate and compare. A well-designed attribute schema is specific enough to enable meaningful filtering but not so granular that it creates maintenance overhead.
Common mistakes in attribute design:
- Using free-text fields for values that should be controlled vocabularies (e.g., colour names entered inconsistently across the catalog).
- Creating category-specific attributes that overlap with global attributes, resulting in duplicate data.
- Assigning attributes to products without populating them, creating blank facets in the front-end filter.
Categories with active filtering — footwear by size, electronics by technical specification, clothing by material composition — benefit from a controlled attribute taxonomy managed through the platform's admin interface rather than through direct database manipulation.
3. Pricing hierarchy and rules
Price management in multi-channel retail involves at least three distinct layers:
- Base price — the standard retail price recorded against the SKU in the ERP or platform database.
- Promotional price — a time-limited override applied at the SKU or category level. EU Omnibus Directive requirements mean the lowest price in the preceding 30 days must be displayed alongside any promotional price for Polish consumers.
- Channel-specific price — a separate price set for marketplaces or B2B customers. Typically managed through a price list table or a feed-level price modifier.
The EU Omnibus Directive (2019/2161) was transposed into Polish law in 2023. For any price reduction displayed as a promotion, retailers must show the lowest price charged during the 30 days before the promotion began. Non-compliance carries fines from UOKiK.
4. EAN codes and product identifiers
Every physical SKU should carry a GS1 EAN barcode. EAN codes are required for Allegro listings in most categories and are used by Google Shopping for product matching. Operators who manufacture or import own-brand products need to purchase a GS1 company prefix from GS1 Polska to generate valid EANs.
Internally, SKUs are often referenced by a separate internal article number. Maintaining a reliable mapping between internal article numbers and EAN codes is necessary for accurate inventory reconciliation between the e-commerce platform and the warehouse management system.
5. Feed management and channel syndication
Product data is rarely confined to a single storefront. Common feed destinations for Polish retailers include:
- Google Merchant Center — requires structured feed in XML or CSV format with defined attributes including availability, condition, price, and GTIN.
- Allegro — API-based listing with category-specific required attributes. Allegro's category tree does not map one-to-one to the store's internal category structure.
- Ceneo and Skąpiec — Polish price comparison engines that accept XML product feeds. Ceneo's feed specification requires net and gross price, availability, and EAN.
Feed quality directly affects visibility in price comparison results. Missing attributes, stale availability data, and price mismatches between the store and the feed are the most common causes of feed disapproval.
6. Catalog maintenance cadence
Catalog hygiene degrades over time without deliberate maintenance. A practical schedule for stores with over 1,000 SKUs:
- Weekly — review products marked out of stock for more than 30 days; assess whether to deactivate, archive, or reorder.
- Monthly — audit image completeness; flag SKUs without images or with images below resolution requirements.
- Quarterly — review attribute completeness for the top-selling categories; update controlled vocabulary lists if new values have been entered freehand.
- Annually — review category structure against the current product mix; merge or split categories where navigation logic has drifted from the catalog's actual composition.
Catalog debt compounds. A single unmapped attribute in a high-traffic category can suppress hundreds of products from relevant filter queries.
Last updated: