Feed · Multichannel · PIM
Multichannel product feed architecture (storefront, marketplaces, Sho…
Every sales channel wants the catalog its own way: Google Shopping, eBay, Amazon, comparison engines and storefronts have different attributes, formats and rules. Building a dedicated feed for each, by hand, is unmanageable. The answer is a multichannel feed architecture: a single source and per-channel transformations.
The principle: a canonical model
At the center sits a canonical product data model, independent of channels: identifiers, attributes, prices, availability, images, internal categories. Each channel is a projection of this model, produced through mapping and rules. Changing one channel does not touch the others.
The layers of the architecture
| Layer | Responsibility |
|---|---|
| Source | ERP/PIM: authoritative product data |
| Canonical model | A single, normalised representation |
| Transformation | Per-channel mapping and rules |
| Publication | Feed file generation or API calls |
| Monitoring | Status, errors and coverage per channel |
Per-channel mapping and rules
The heart of the system is the set of transformation rules:
- attribute mapping: from the internal field to the channel field;
- category mapping: from the internal taxonomy to the channel's;
- inclusion rules: which products to publish on which channel;
- value transformations: price formats, units, language, rounding.
Full vs incremental
It pays to combine two rhythms: a periodic full feed that guarantees consistency, and incremental updates (event-driven) for volatile fields like price and stock, so channels that support APIs stay aligned quickly.
Architecture on Azure
On Microsoft Azure the model maps well to decoupled components: a process that builds the canonical model, a queue of change events, per-channel workers that apply the mapping and publish, and storage for feed files. Per-channel separation lets you add a new marketplace without rewriting the rest.
Governance and data quality
A multichannel feed is only effective if the upstream data is good. Measure coverage (how many products have all the attributes each channel requires) and block publication of non-compliant products, reporting issues back to the PIM.
Common mistakes
- building isolated feeds per channel, with no common model;
- duplicating rules instead of centralising them;
- full feed only, with no fast price/stock updates;
- no measure of coverage and data quality.
Conclusion
A well-designed multichannel feed architecture turns a problem that grows with channels into one that scales with configuration: a single canonical model, per-channel transformations and decoupled publication. It is how you sell everywhere without multiplying the chaos.