Ridurre i tassi di reso Amazon FBA attraverso l'analisi sistematica dei dati

I resi rappresentano fino al 15% delle vendite Amazon FBA a seconda della categoria. I dati di settore indicano che l'80% dei costi di reso si concentra tipicamente nel 20% del catalogo — eppure la maggior parte delle operazioni tratta il tasso di reso come una metrica aggregata, senza scomporla al livello in cui diventa concretamente azionabile. Abbiamo costruito una pipeline che raccoglie i dati dei resi FBA, li raggruppa per codice motivo e SKU, identifica il pattern dominante e alimenta i calcoli di economicità unitaria e di soglia pubblicitaria. L'approccio si applica indipendentemente dalla categoria di prodotto.

La fonte dati: il report sui resi clienti FBA

Amazon fornisce un record strutturato per ogni reso gestito da FBA. Ogni record contiene l'ID ordine, l'ASIN, lo SKU, la data del reso e — elemento cruciale — un codice motivo selezionato dal cliente da un elenco predefinito. I codici motivo disponibili variano per categoria, ma includono tipicamente discrepanze negli attributi del prodotto (taglie, colori, specifiche tecniche), problemi di qualità, accuratezza della descrizione e categorie generiche come "articolo indesiderato".

Questi dati sono disponibili come report scaricabile in Seller Central o tramite pipeline automatizzate di estrazione dati. Il report è accessibile anche attraverso la SP-API di Amazon per l'integrazione programmatica in un data warehouse.

I dati grezzi richiedono una fase di preprocessing: deduplicazione (le esportazioni con intervalli di date sovrapposti producono record duplicati), normalizzazione dei codici motivo e join con i dati degli ordini per calcolare i tassi di reso a livello di SKU. Nulla di complesso — è un ETL standard — ma è un passaggio che la maggior parte delle operazioni salta completamente.

Fase 1: distribuzione dei codici motivo

La prima analisi è un'aggregazione: raggruppare tutti i resi per codice motivo e calcolare la distribuzione percentuale. L'obiettivo è determinare se un singolo motivo domina o se i resi si distribuiscono uniformemente su più cause.

Nel nostro dataset la distribuzione era nettamente concentrata: un solo codice motivo rappresentava il 65% di tutti i resi. Il secondo motivo più comune si attestava al 15%. Tutto il resto era nell'ordine di pochi punti percentuali. Questo tipo di concentrazione è comune — le analisi di settore confermano che la maggior parte delle categorie di prodotto ha uno o due driver di reso dominanti che spiegano la maggioranza dei casi.

La soglia che utilizziamo: se un singolo codice motivo supera il 40% dei resi, quello è il problema alla radice. Affrontarlo avrà un impatto maggiore di qualsiasi altra modifica al listing o al prodotto. Se la distribuzione è piatta (nessun motivo sopra il 25%), il problema è più diffuso e richiede un approccio diverso — tipicamente miglioramenti alla qualità del prodotto o all'accuratezza del listing su più dimensioni.

Fase 2: confronto con gli attributi di prodotto

I codici motivo mostrano ciò che i clienti dichiarano. Il confronto con gli attributi di prodotto — taglia, colore, variante, fascia di prezzo — rivela perché accade e se la causa è sistematica o casuale.

Facciamo il join tra il dataset dei resi e il catalogo prodotti e calcoliamo i tassi di reso per valore di attributo. Una causa sistematica produce una distribuzione asimmetrica: certi valori di attributo mostrano tassi di reso significativamente più alti degli altri, dominati dallo stesso codice motivo. Una causa casuale produce una distribuzione piatta.

Questo passaggio di validazione evita diagnosi errate. Una linea di prodotto può mostrare resi elevati per un certo motivo, ma l'intervento dipende dal fatto che il problema riguardi tutte le varianti in egual misura o si concentri su varianti specifiche. Sono i dati a determinare se l'intervento è una modifica a livello di listing (che interessa tutte le varianti) o una decisione a livello di SKU (interruzione o aggiustamento di varianti specifiche).

Fase 3: redditività per SKU con probabilità di reso

I calcoli di redditività standard trattano i resi come una voce di costo separata. Un modello più accurato pondera il margine di ogni SKU in base alla sua probabilità di reso. Il margine effettivo per SKU è:

effective_margin = (1 - return_rate) × revenue_per_unit - cogs - amazon_fees - (return_rate × return_processing_cost)

Questo calcolo rivela spesso SKU con margini effettivi negativi che nelle viste aggregate appaiono redditizi. Nella nostra analisi, tre SKU che contribuivano in modo significativo al fatturato stavano operando con margini negativi una volta incorporata la probabilità di reso — ogni vendita di quei prodotti generava una perdita.

Il dashboard Profit Analytics di Amazon (lanciato a settembre 2025) offre ora viste di redditività a livello di SKU, ma non incorpora la ponderazione per probabilità di reso. Costruire questo come strato aggiuntivo sopra i dati standard — in un foglio di calcolo o in una pipeline automatizzata — aggiunge la dimensione che rende difendibili le decisioni su inventario e pubblicità.

Fase 4: ricalcolo delle soglie pubblicitarie

Il tasso di reso si ripercuote direttamente sull'Advertising Cost of Sales (ACoS) di pareggio — la percentuale massima di fatturato che può essere destinata alla pubblicità prima che una vendita diventi non redditizia. La relazione è meccanica:

break_even_acos = effective_margin / revenue_per_unit

Un tasso di reso più basso aumenta il margine effettivo, il che innalza l'ACoS di pareggio e amplia il budget pubblicitario sostenibile. Nel nostro caso, la riduzione attesa del tasso di reso ha allargato l'ACoS di pareggio di quasi dieci punti percentuali — abbastanza da scalare significativamente gli investimenti pubblicitari mantenendo invariata la redditività unitaria.

Questo significa che l'ottimizzazione del tasso di reso e la gestione del budget pubblicitario non sono flussi di lavoro indipendenti. Sono collegati attraverso l'economicità unitaria. Qualsiasi team che definisce i budget pubblicitari senza incorporare il tasso di reso nel calcolo del margine sta lasciando budget sul tavolo oppure spendendo troppo senza visibilità sulla soglia effettiva.

Fase 5: implementare e misurare la soluzione

Una volta identificata e validata la causa alla radice, l'intervento è tipicamente una modifica al listing — descrizioni di prodotto aggiornate, specifiche tecniche aggiunte, immagini revisionate o indicazioni esplicite che rispondono al motivo di reso prevalente. La correzione prende di mira il codice motivo specifico, non il listing in generale.

Misurare i risultati richiede pazienza. I clienti Amazon hanno 30 giorni per avviare un reso, quindi l'impatto reale di una modifica al listing impiega tre o quattro settimane per emergere nei dati. L'approccio: raccogliere dieci giorni di dati sulle performance pubblicitarie dopo la modifica, poi attendere ulteriori due settimane per la conferma del tasso di reso prima di aggiustare i budget.

Per le operazioni su più marketplace, questa analisi viene eseguita in modo indipendente per ciascun marketplace. I pattern di reso variano per area geografica — una soluzione validata in un mercato non deve essere data per scontata anche in un altro senza dati propri.

Operativizzare: dall'analisi una tantum alla pipeline continua

I pattern di reso non sono statici. Cambiano con i comportamenti dei clienti, le variazioni nelle linee guida di categoria, i cambiamenti dei fornitori e le dinamiche competitive. Un'analisi una tantum produce un'istantanea; una pipeline continua produce un sistema di allerta precoce.

Integriamo l'analisi dei resi nella nostra pipeline del data warehouse, dove i record vengono raccolti automaticamente, deduplicati, aggregati per codice motivo e SKU e confrontati con baseline dinamiche. Le anomalie — un picco in un codice motivo precedentemente stabile dopo un cambio di lotto fornitore, per esempio — attivano una revisione prima che si traducano in un problema materiale di margine.

La versione minima praticabile è un'esportazione manuale e una tabella pivot. La versione in produzione è una pipeline automatizzata che gira a cadenza regolare, calcola i margini effettivi con la probabilità di reso, ricalcola le soglie ACoS di pareggio e segnala gli SKU che sono passati da redditizi a non redditizi. La logica analitica è identica — la differenza è la frequenza e la scalabilità.

Punti chiave

Raggruppare i resi per codice motivo prima di apportare modifiche al listing. Nella maggior parte delle categorie, un singolo motivo spiega la maggioranza dei resi. Identificarlo prima di investire in modifiche che prendono di mira la variabile sbagliata.
Validare con il confronto degli attributi di prodotto. I soli codici motivo mostrano ciò che i clienti dichiarano. Il join con i dati di prodotto conferma se il problema è sistematico o casuale, e se l'intervento deve essere a livello di listing o di SKU.
Calcolare il margine effettivo con la probabilità di reso. I calcoli di margine standard sovrastimano la redditività degli SKU con alto tasso di reso. I margini ponderati per probabilità rivelano quali prodotti stanno effettivamente perdendo denaro.
Collegare il tasso di reso alle soglie pubblicitarie. Tasso di reso e ACoS di pareggio sono collegati attraverso l'economicità unitaria. Una riduzione del tasso di reso amplia direttamente il budget pubblicitario sostenibile senza modificare nulla nelle campagne.
Automatizzare per la continuità. I pattern di reso cambiano. Una pipeline continua con rilevamento delle anomalie sostituisce i controlli manuali periodici e intercetta i problemi prima che si accumulino.

Approfondimenti correlati

tva costruisce pipeline di dati automatizzate per le operazioni dei seller Amazon — dall'estrazione dati da Seller Central all'analisi dei motivi di reso, fino a modelli di redditività per SKU con ponderazione per probabilità di reso. Aiutiamo i team operativi a sostituire i dashboard aggregati con analytics strutturate e per singolo SKU, che guidano le decisioni su pubblicità, inventario e prodotto. Contattaci se hai bisogno di un partner tecnico per la tua infrastruttura dati Amazon.