Feed · Multicanale · PIM
Architettura di un feed prodotto multicanale (shop, marketplace, Shop…
Ogni canale di vendita vuole il catalogo a modo suo: Google Shopping, eBay, Amazon, comparatori e shop hanno attributi, formati e regole diversi. Costruire un feed dedicato per ciascuno, a mano, è ingestibile. La soluzione è un'architettura di feed multicanale: una sorgente unica e trasformazioni per canale.
Il principio: un modello canonico
Al centro c'è un modello dati canonico del prodotto, indipendente dai canali: identificatori, attributi, prezzi, disponibilità, immagini, categorie interne. Ogni canale è una proiezione di questo modello, ottenuta tramite mapping e regole. Cambiare un canale non tocca gli altri.
I livelli dell'architettura
| Livello | Responsabilità |
|---|---|
| Sorgente | ERP/PIM: dato di prodotto autorevole |
| Modello canonico | Rappresentazione unica e normalizzata |
| Trasformazione | Mapping e regole specifiche per canale |
| Pubblicazione | Generazione feed file o chiamate API |
| Monitoraggio | Stato, errori e copertura per canale |
Mapping e regole per canale
Il cuore del sistema sono le regole di trasformazione:
- mapping attributi: dal campo interno al campo del canale;
- mapping categorie: dalla tassonomia interna a quella del canale;
- regole di inclusione: quali prodotti pubblicare su quale canale;
- trasformazioni di valore: formati prezzo, unità, lingua, arrotondamenti.
Completo vs incrementale
Conviene combinare due ritmi: un feed completo periodico che garantisce coerenza, e aggiornamenti incrementali (event-driven) per i campi volatili come prezzo e stock, così i canali che supportano le API restano allineati in tempi rapidi.
Architettura su Azure
Su Microsoft Azure il modello si realizza bene con componenti disaccoppiati: un processo che costruisce il modello canonico, una coda di eventi di cambiamento, worker per ogni canale che applicano il mapping e pubblicano, e storage per i feed file. La separazione per canale permette di aggiungere un nuovo marketplace senza riscrivere il resto.
Governance e qualità del dato
Un feed multicanale è efficace solo se il dato a monte è buono. Conviene misurare la copertura (quanti prodotti hanno tutti gli attributi richiesti per canale) e bloccare la pubblicazione dei prodotti non conformi, riportando i problemi al PIM.
Errori comuni
- costruire feed isolati per canale, senza modello comune;
- duplicare le regole invece di centralizzarle;
- solo feed completo, senza aggiornamenti rapidi di prezzo/stock;
- nessuna misura di copertura e qualità del dato.
Conclusione
Un'architettura di feed multicanale ben progettata trasforma un problema che cresce con i canali in uno che si scala con configurazione: modello canonico unico, trasformazioni per canale e pubblicazione disaccoppiata. È il modo per vendere ovunque senza moltiplicare il caos.