Il costo nascosto di una cattiva integrazione dei feed di prodotto

Ultimo aggiornamento: 7 luglio 2026. Scritto sulla base della realizzazione di integrazioni per l'import da fornitori e la sincronizzazione con i marketplace per PrestaShop 1.7, 8 e 9. Le query diagnostiche che seguono girano sulle tabelle core di PrestaShop che puoi ispezionare sul tuo negozio.

Autore: redazione di mypresta.rocks — sviluppiamo moduli PrestaShop e gestiamo negozi PrestaShop.

Una cattiva integrazione dei feed prodotto è quel raro tipo di guasto che ti costa denaro mentre tutto sembra in ordine. Niente va in errore — nessun banner rosso, nessun cron fallito, nessun ticket di assistenza. Il catalogo comincia semplicemente e silenziosamente a comunicare ai clienti il prezzo sbagliato, la giacenza sbagliata, la disponibilità sbagliata, e ogni piccola bugia è un ordine annullato, un rimborso o un chargeback pronto a scattare.

Qui parliamo della classe di rischio: cosa fa a un negozio un'integrazione di import in ingresso o di sincronizzazione con i marketplace economica, opaca o non mantenuta, e cosa fa invece di diverso una affidabile. Se ne usi già una e vuoi solo sapere se il problema ti sta colpendo, salta direttamente alle due query — trovano il danno nel tuo catalogo in circa un minuto.

Confronto rapido: feed economico vs. feed affidabile

1. Stock fantasma: vendere merce che non hai

Il modo più comune con cui un modulo di import economico dissangua un negozio è lo stock fantasma — un numero di giacenza in vetrina che non corrisponde a nulla di reale in magazzino. Accade quando una sincronizzazione scrive una quantità che non riesce ad attribuire al prodotto corretto: viene mappata la colonna sbagliata, un flag "disponibile" viene letto come un conteggio, oppure la quantità di un prodotto viene scritta su un altro perché la corrispondenza era errata. Due varianti: fantasma (un numero che non ha mai corrisposto alla realtà) e obsoleto (un numero un tempo vero, ma il feed ha smesso di aggiornarlo e il negozio ha continuato a vendere su un conteggio congelato). In entrambi i casi il numero sembra plausibile, quindi nessuno lo mette in dubbio — finché non ti ritrovi ad annullare ordini che non puoi evadere, a incassare rimborsi e, sui marketplace, a subire un colpo al tasso di difettosità che danneggia la salute dell'account.

La trappola specifica di PrestaShop: lo stock reale risiede in ps_stock_available (per prodotto, per combinazione, con ambito definito da id_shop o id_shop_group) e dovrebbe essere scritto tramite StockAvailable::setQuantity() in modo che l'hook actionUpdateQuantity venga attivato e lo stato dipendente resti coerente. Un import economico che scrive direttamente la vecchia colonna ps_product.quantity si desincronizza da ciò che la vetrina legge davvero. Combina questo con l'impostazione "consenti gli ordini quando esaurito" (PS_ORDER_OUT_OF_STOCK, globale o per prodotto) e una quantità fantasma o azzerata si converte direttamente in una sovravendita reale. Un'integrazione affidabile scrive solo una quantità che può attribuire a una riga sorgente correttamente abbinata, la verifica per plausibilità rispetto al valore precedente e sospende qualsiasi cosa di cui non può farsi garante invece di venderci sopra.

2. Quella costosa: un'inserzione danneggiata sul marketplace

Quando il tuo catalogo alimenta un marketplace — Allegro, Amazon, eBay — l'integrazione non sta più solo modificando righe nel tuo database. Sta manipolando un asset vivo sulla piattaforma di qualcun altro, secondo le sue regole. Un singolo push errato può violare quelle regole: un prezzo che la piattaforma legge come non valido, un valore di stock spinto a zero che chiude l'offerta, un identificatore mal mappato che fa sembrare l'offerta un prodotto diverso.

Sii preciso su cosa è realmente a rischio, perché le piattaforme differiscono. Ciò che puoi perdere è lo slancio a livello di offerta — anzianità dell'inserzione, posizione, i segnali di velocity che il ranking di un canale premia, gli osservatori — e, sui canali basati sull'offerta come Allegro ed eBay, lo storico di vendita associato a quell'inserzione. Le recensioni di prodotto sono più sfumate: su Amazon vivono sull'ASIN e in genere sopravvivono a un cambio di offerta; il feedback di eBay è a livello di venditore, non di inserzione. Quindi "un push errato cancella le tue recensioni" non è universalmente vero — ma lo slancio che rendeva l'offerta competitiva può senz'altro essere azzerato, e un'offerta ripubblicata lo ricostruisce da zero. La modalità di guasto che rende tutto questo pericoloso è la propagazione: un'integrazione economica rispecchia il catalogo sul canale senza alcun filtro, così una singola riga locale errata raggiunge un'inserzione attiva alla velocità della macchina. Una affidabile valida la scrittura di prezzo e stock, e blocca in attesa di revisione i push di massa di tipo "chiudi offerta" / azzeramento, prima che qualsiasi cosa si propaghi.

3. Inserzioni sotto il prezzo reale: esposizione legale e finanziaria

Un prodotto messo in vendita ben al di sotto del suo prezzo reale viene di solito archiviato come "margine perso". È una sottovalutazione. Una volta che accetti un ordine a un prezzo esposto, alcune giurisdizioni si aspettano l'evasione (il solo prezzo esposto spesso non costituisce un'offerta vincolante nei sistemi di common law; gli errori manifesti possono essere annullabili — dipende dalla legge locale e dai tuoi termini), e in ogni caso l'annullamento di massa costa più in chargeback e contestazioni del margine che stavi proteggendo. Gli articoli con prezzo errato vengono anche trovati in fretta: gli script di rivendita monitorano esattamente questo, così un articolo prezzato molto sotto mercato viene esaurito in pochi minuti. Sul fronte della conformità, la violazione di un accordo con il fornitore è l'esposizione realistica; la pura responsabilità in materia di diritto della concorrenza è ristretta (l'articolo 102 dell'UE richiede posizione dominante e abuso; il diritto statunitense in genere considera legale il prezzo sotto costo a meno che non sia predatorio). E Google Merchant richiede che il prezzo del feed corrisponda a quello della landing page, quindi una discrepanza si riversa in disapprovazioni sul canale a pagamento.

L'innesco è quasi sempre un errore di corrispondenza a monte, e nessuna eccezione viene sollevata — l'inserzione va semplicemente online a una frazione del suo valore. La difesa è un prezzo minimo che rifiuta una scrittura non plausibile prima che raggiunga la vetrina o un canale. L'unica finezza da prevedere: confronta cose omogenee — un prezzo base che supera il prezzo minimo può comunque scendere sotto costo una volta applicato uno sconto attivo ps_specific_price o una regola di catalogo, quindi il prezzo minimo deve considerare il prezzo effettivo, non solo ps_product_shop.price.

La causa radice: la corrispondenza su ID fornitore volatili

Questo è il peccato originale dell'integrazione dei feed. Gli ID interni dei fornitori non sono stabili — i distributori li riciclano e li riassegnano man mano che i loro sistemi cambiano. Fai la corrispondenza su quell'ID e leghi il tuo catalogo a un bersaglio mobile: il giorno in cui un fornitore riutilizza un ID per un articolo diverso, il tuo prodotto costoso adotta il prezzo e lo stock di quello economico. Ancorati invece a un identificatore stabile del prodotto di destinazione. In PrestaShop si tratta di un GTIN univoco (ean13 / upc), del codice ricambio del produttore mpn, o del tuo reference, a livello di combinazione (ps_product_attribute). PrestaShop 8.1+ valida ean13 come GTIN a livello di prodotto. Il riferimento proprio del fornitore va in ps_product_supplier.product_supplier_reference, con ambito definito da id_supplier, e dovrebbe essere usato solo come fallback deterministico — mai come chiave primaria che sovrascrive prezzo e stock.

Come capire se ti sta già succedendo

Se oggi usi un modulo di import economico, non devi aspettare un reclamo. Il danno lascia impronte. Questi sono controlli di primo passaggio — in sola lettura, sicuri su una copia — non un audit completo, ma fanno emergere i due guasti che costano di più.

Identità duplicata — la precondizione per la corrispondenza sul prodotto errato. Qualsiasi GTIN condiviso da due prodotti base è un difetto dei dati e il presupposto per uno scambio di prodotto errato:

SELECT ean13, COUNT(*) AS n
FROM ps_product
WHERE ean13 <> ''
GROUP BY ean13
HAVING n > 1;
-- ripeti per upc, mpn e gli identificatori di ps_product_attribute (combinazioni)

Inserzioni sotto costo — qualsiasi articolo prezzato sotto il proprio costo all'ingrosso è una perdita di margine attiva o un errore di corrispondenza già scattato. Nota id_shop: in multistore lo stesso prodotto può essere sicuro in un negozio e sotto costo in un altro. Questo controllo verifica solo il prezzo base — non compensa gli sconti attivi specific_price, le imposte, le commissioni o le combinazioni, quindi tratta un risultato pulito come "nessuna perdita evidente sul prezzo base", non come "tutto a posto":

SELECT p.id_product, p.reference, ps.id_shop, ps.price, ps.wholesale_price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
WHERE ps.wholesale_price > 0
  AND ps.price < ps.wholesale_price;

Le righe sotto costo sono un guasto attivo; gli identificatori duplicati sono un difetto dei dati e uno scambio di prodotto errato pronto a scattare. In entrambi i casi è nel tuo catalogo adesso, non in teoria.

Trappole native di PrestaShop da conoscere

• La casella "Elimina tutti i prodotti prima dell'import" dell'import CSV — insieme a "Forza tutti i numeri ID", è l'azione più famigerata di distruzione del catalogo in PrestaShop. Una singola esecuzione non presidiata può cancellare e ri-mappare le chiavi del catalogo.
• Scrivere ps_product.quantity invece di usare StockAvailable. Lo stock reale risiede in ps_stock_available; bypassare l'API salta l'hook actionUpdateQuantity, così le cache e qualsiasi listener che vi dipende non vengono mai a sapere che il numero è cambiato.
• Ambito multistore. I prezzi hanno ambito definito da id_shop; lo stock da id_shop o da un id_shop_group condiviso. Un import che ignora l'ambito aggiorna la vetrina sbagliata, o tutte in una volta.

Deriva del catalogo e feed troncati

La deriva del catalogo è la lenta divergenza tra ciò che il tuo fornitore offre oggi e ciò che la tua vetrina mostra ancora — SKU aggiunti, dismessi e riprezzati che il tuo feed non ha riflesso. Il caso più insidioso è un prodotto fuori produzione che mostra ancora stock fantasma: il cliente compra qualcosa che non puoi procurarti. Gestirlo è delicato. Rileva lo "sparito dal feed", ma non uccidere ciecamente il prodotto — l'esaurimento dello stock reale di proprietà (giacenza fisica al netto delle prenotazioni, non il numero del fornitore) è denaro che hai già speso. In un catalogo multi-fornitore, "mancante da un feed" dovrebbe eliminare quella fonte, non il prodotto, e passi a "non più disponibile" solo quando lo stock reale disponibile arriva a zero e nessun altro fornitore lo copre.

Il guasto che trasforma un piccolo problema in una catastrofe è il feed troncato — un download che muore a metà, che un modulo ingenuo tratta come completo. Improvvisamente una grossa fetta di SKU sembra "mancante" e viene azzerata o dichiarata fuori produzione in massa. La soluzione è un audit dell'esecuzione di import: non agire mai su un feed che non hai validato rispetto all'esecuzione precedente.

CREATE TABLE ps_feedrun (
  id_run         INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  supplier       VARCHAR(64),
  started_at     DATETIME,
  row_count      INT UNSIGNED,
  prev_row_count INT UNSIGNED,
  checksum       CHAR(64),
  state          ENUM('running','applied','rejected'),
  reject_reason  VARCHAR(255)
);
-- Rifiuta l'esecuzione (non applicare mai rimozioni) quando il download è incompleto,
-- il checksum fallisce, il timestamp di export è obsoleto, o row_count crolla
-- rispetto a prev_row_count.

Come una singola esecuzione errata provoca un effetto a catena

È un esempio, ma ogni passaggio è un meccanismo reale: un import pianificato gira di notte come fa da mesi. Questa volta l'export si tronca a metà, e il modulo lo ingerisce come verità assoluta. I prodotti oltre il punto di taglio sembrano "spariti", quindi il loro stock viene azzerato. Una manciata di ID che il fornitore ha riciclato quella settimana lega articoli costosi a righe economiche, e quei prezzi vengono sovrascritti. Quando qualcuno accede, la vetrina mostra esaurito su prodotti attivi, alcuni articoli sono ben sotto costo e già in vendita ai bot e — poiché il catalogo ha spinto tutto in avanti senza alcun filtro — le offerte sul marketplace sono state resettate per dati non validi. Nemmeno una riga ha generato un errore. Ogni protezione che l'avrebbe intercettato — l'audit dell'esecuzione di import, il prezzo minimo, il controllo di provenienza, il filtro sul canale — era semplicemente assente.

Cosa deve fare un'integrazione dei feed affidabile

• Corrispondere su un'identità stabile — un GTIN (ean13/upc), mpn, o il tuo reference, a livello di combinazione; il riferimento del fornitore solo come fallback con ambito definito.
• Proteggere i prezzi prima della pubblicazione — un prezzo minimo sul prezzo effettivo (dopo specific_price e le regole di catalogo), che rifiuta e avvisa invece di pubblicare.
• Scrivere lo stock in modo attribuibile — tramite StockAvailable, solo da una riga sorgente correttamente abbinata, con una fascia di plausibilità sui grandi salti.
• Auditare ogni esecuzione di import — checksum, conteggio righe vs. precedente, freschezza dell'export; un feed sospetto non guida mai le rimozioni.
• Filtrare la propagazione ai canali e restare reversibili — validare prima che qualsiasi cosa raggiunga un marketplace, e fare uno snapshot prima di modificare così che il ripristino sia un restore, non una ricostruzione.

FAQ

Perché il mio negozio vende articoli esauriti?

Di solito è stock fantasma o obsoleto, spesso amplificato da "consenti gli ordini quando esaurito", oppure un ordine che cade nella finestra tra due sincronizzazioni. La soluzione è un'integrazione che scrive lo stock in modo attribuibile tramite StockAvailable, distingue uno zero confermato da un aggiornamento mancante e protegge dai salti non plausibili.

Come smetto di vendere sotto costo?

Metti un prezzo minimo davanti a ogni scrittura di prezzo, confrontato sul prezzo effettivo dopo ogni specific_price o regola di catalogo attiva — non solo su ps_product_shop.price. Rifiuta e avvisa invece di pubblicare, e mantieni aggiornati i dati di costo, perché un costo obsoleto nasconde una vendita sotto costo finché non arriva il report sui margini. La query sotto costo qui sopra trova quelle già online.

Cos'è la deriva del catalogo?

Il divario crescente tra ciò che il tuo fornitore offre ora e ciò che la tua vetrina mostra ancora. Misura la tua confrontando (diff) il feed attuale del fornitore con il tuo catalogo live — ogni SKU presente in uno e non nell'altro è deriva: un prezzo errato, stock fantasma, o un articolo che non puoi più procurarti.

Il punto

Un'integrazione dei feed si guadagna il pane nel suo giorno peggiore, non in quello medio. Quando l'export si tronca, un ID viene riciclato, o un distributore riprezza durante la notte, un'integrazione ben costruita rifiuta i dati errati e una economica li applica. Nessuno di questi guasti è esotico — sono il risultato prevedibile del saltare una manciata di protezioni che non sono difficili da costruire. Esegui le due query qui sopra sul tuo catalogo; se restituiscono righe, hai già la risposta.