Le logiche di prezzo e promozione costituiscono l’insieme di regole commerciali che determina quanto deve pagare un cliente, perché si applica quell’importo e come lo store deve rappresentare il risultato. Un Product può avere un prezzo base, un prezzo promozionale, un prezzo specifico per variante, un prezzo riservato a un determinato livello cliente, una soglia quantitativa, uno sconto di catalogo, un coupon, un incentivo sulla spedizione, una variazione legata a un abbonamento, un premio fedeltà e una condizione fiscale o regionale. Lo storefront può mostrare un solo importo finale, ma quel valore può derivare da più record e da diverse regole di calcolo.
In una piattaforma e-commerce, i dati di prezzo non si limitano a un singolo campo del Product. Possono essere distribuiti tra Product, varianti, listini, gruppi cliente, regole di catalogo, regole del carrello, tabelle coupon, impostazioni fiscali, regole di spedizione, configurazione delle valute, sistemi di abbonamento, applicazioni loyalty, motori di prezzo enterprise, integrazioni ERP o dati gestiti da estensioni. Il funzionamento delle promozioni dipende ancora di più dalle strutture circostanti, perché uno sconto richiede spesso condizioni di idoneità, esclusioni, intervalli di validità, limiti d’uso, priorità, regole di combinazione e una sequenza di calcolo.
Una revisione tecnica deve quindi stabilire dove risiede la regola commerciale, da quali dati dipende, come la piattaforma la calcola e come il risultato viene rappresentato nel carrello, nel processo di acquisto, negli Orders, nei report, nei rimborsi e nelle comunicazioni rivolte ai clienti.
Cosa rappresentano le logiche di prezzo e promozione in uno store e-commerce
Le logiche di prezzo e promozione costituiscono il sistema decisionale commerciale dello store. Devono rispondere contemporaneamente a più domande: quanto costa normalmente un articolo, se un determinato cliente ha diritto a un prezzo diverso, se il carrello soddisfa i requisiti per uno sconto, quali Product sono esclusi, se la spedizione viene modificata, se l’imposta viene calcolata prima o dopo lo sconto e se più incentivi possono essere combinati.
Uno stesso store può utilizzare diversi livelli di prezzo per finalità differenti:
| Livello di prezzo o promozione | Cosa rappresenta | Funzionamento dello store interessato |
|---|---|---|
| Prezzo base | Il normale prezzo di vendita di un Product o di una variante | Visualizzazione nella pagina Product, importo della riga nel carrello, feed, report e totale Order |
| Prezzo promozionale o prezzo di confronto | Una differenza temporanea o di merchandising rispetto al prezzo ordinario | Badge promozionali, prezzi barrati, pagine campagna e messaggi commerciali |
| Prezzo a livello di variante | Prezzi differenti in base a taglia, colore, materiale, quantità del bundle o configurazione | Selezione delle opzioni, totale carrello, acquisto collegato all’inventario e aspettative di evasione |
| Prezzo per gruppo cliente | Prezzo riservato a gruppi wholesale, retail, VIP, B2B, dipendenti o membership | Prezzi dopo il login, prezzi account, segmentazione cliente e vendita contrattuale |
| Prezzo a fasce o quantità | Prezzo che cambia in base alla quantità acquistata | Acquisti in volume, wholesale, tabelle prezzi e calcolo del carrello |
| Regola di catalogo | Sconto applicato prima che il cliente arrivi al carrello | Merchandising di Category, visualizzazione nelle liste Product e visibilità delle promozioni |
| Regola del carrello | Sconto applicato in base alle condizioni del carrello | Coupon, totale carrello, incentivi nel processo di acquisto e offerte a soglia |
| Incentivo sulla spedizione | Spedizione gratuita o ridotta in condizioni definite | Conversione nel processo di acquisto, offerte regionali e calcolo del margine |
| Regola loyalty o premio | Credito, punti, sconto membership o vantaggio maturato | Fidelizzazione, funzionamento dell’account ed economia degli acquisti ripetuti |
| Prezzo di abbonamento o ricorrente | Logica di prezzo per acquisti ripetuti o cicli di membership | Fatturazione, rinnovi, gestione account e automazione Orders |
| Fonte prezzo esterna | Prezzo controllato da ERP, POS, PIM, marketplace o motore di prezzo | Titolarità del dato, sincronizzazione e governance operativa |
Questi livelli possono sovrapporsi. Un Product può avere contemporaneamente un prezzo promozionale, un prezzo specifico per cliente, una promozione di Category, un coupon e una soglia per la spedizione gratuita. La domanda tecnica non è soltanto se ogni livello esiste, ma quale ha la precedenza, quali possono essere combinati e come la piattaforma registra il risultato finale.
Strutture dati comuni alla base dei prezzi dei Product
La gestione del prezzo parte spesso da un campo numerico, ma la maggior parte degli store richiede una struttura più articolata. Un Product semplice può avere un solo prezzo base. Un Product con varianti può conservare un prezzo per SKU. Uno store collegato a marketplace o orientato al B2B può utilizzare listini per mercato, valuta, gruppo cliente, catalogo, contratto o canale.
I campi più comuni includono:
| Campo o proprietà | Funzione tipica | Aspetto tecnico da verificare |
|---|---|---|
| ID Product o ID variante | Collega il prezzo all’articolo vendibile | Determina se il prezzo appartiene al Product padre o a una singola variante |
| Prezzo base | Prezzo di vendita standard | Può essere a livello Product in una piattaforma e a livello variante in un’altra |
| Prezzo promozionale | Prezzo attivo ridotto | Può avere date autonome o dipendere da regole di campagna |
| Prezzo di confronto o listino | Prezzo di riferimento mostrato accanto a quello attivo | Può incidere sulla visualizzazione senza modificare il prezzo calcolato |
| Costo o margine | Base di costo interna | Spesso non visibile al cliente, ma importante per report e analisi del margine |
| Codice valuta | Valuta del prezzo | Può richiedere listini, regole di cambio o valori specifici per mercato |
| Classe fiscale | Categoria fiscale del Product | Influenza calcolo delle imposte e conformità regionale |
| ID gruppo cliente o listino | Relazione di idoneità | Governa prezzi B2B, wholesale, membership o contrattuali |
| Soglia quantitativa | Punto a partire dal quale cambia il prezzo unitario | Determina l’applicazione delle fasce quantità |
| Ambito di canale o mercato | Storefront, area geografica, marketplace o canale commerciale | Determina quale prezzo viene mostrato in ciascun contesto |
| Data di inizio e fine | Finestra di attivazione | Controlla la durata della campagna e il rischio di prezzi obsoleti |
| Priorità o ordine | Valore per la risoluzione dei conflitti | Determina quale prezzo o regola prevale quando ne esistono più di una |
Una piattaforma che registra un solo prezzo per Product si comporta in modo molto diverso da una piattaforma che conserva più righe di prezzo per Product, variante, gruppo cliente, mercato o canale. Questa differenza incide su visualizzazione, modifica, esportazione, sincronizzazione e validazione.
Le promozioni come dati basati su condizioni
Un record promozionale contiene normalmente due parti: un’attivazione e una regola. L’attivazione può essere un codice coupon, uno sconto automatico, un segmento cliente, una pianificazione di campagna o una condizione del carrello. La regola definisce cosa accade quando l’attivazione è valida.
| Condizione promozionale | Esempi | Cosa può cambiare tra piattaforme |
|---|---|---|
| Idoneità del Product | SKU, varianti, Categories, collezioni, brand, tag, vendor o attributi specifici | Il targeting può usare tipi di oggetti o logiche di query differenti |
| Esclusioni | Articoli già scontati, fine serie, gift card, brand limitati, bundle, abbonamenti o varianti specifiche | Le esclusioni possono essere limitate o richiedere regole separate |
| Idoneità del cliente | Gruppi, tag, segmenti, domini email, membership, livello loyalty o account B2B | I modelli di segmentazione possono non avere equivalenza diretta |
| Soglia del carrello | Spesa minima, quantità minima, spesa massima, numero articoli o subtotale dopo le esclusioni | Il calcolo può avvenire prima o dopo sconto, imposta o spedizione |
| Azione di sconto | Percentuale, importo fisso, buy-one-get-one, articolo gratuito, spedizione gratuita, offerta a fasce o prezzo bundle | Alcune azioni possono essere native e altre richiedere applicazioni |
| Limite d’uso | Per cliente, codice, Order, durata complessiva o campagna | Lo storico utilizzo può non essere trasferibile nello stesso modo |
| Periodo di validità | Data iniziale, finale, campagna pianificata, fuso orario o finestra ricorrente | Il funzionamento dipende da fuso orario e scheduler della piattaforma |
| Regola di combinazione | Combinazione con sconti Product, Order, spedizione, loyalty o rettifiche manuali | La possibilità di combinare gli sconti è spesso specifica della piattaforma |
| Priorità | Regola applicata per prima o vincente in caso di conflitto | La priorità può essere esplicita, implicita o non disponibile |
Un coupon può mantenere lo stesso codice dopo la migrazione e comportarsi comunque in modo diverso. Il codice è soltanto l’identificatore visibile al cliente. Il motore di regole determina idoneità, esclusioni, importo dello sconto, combinazione e calcolo finale.
Ordine di calcolo e combinazione degli sconti
L’ordine di calcolo è una delle differenze più rilevanti tra piattaforme. Due store possono usare lo stesso nome per uno sconto e produrre totali diversi se una piattaforma applica lo sconto alle righe prima delle imposte e un’altra lo applica al subtotale dopo altri sconti.
Domande importanti includono:
- lo sconto viene applicato alla riga Product, al subtotale del carrello, alla spedizione, all’importo comprensivo di imposte o a quello al netto delle imposte?
- il prezzo promozionale sostituisce il prezzo base prima che venga calcolato il coupon?
- un coupon può essere applicato a un articolo già scontato?
- gli sconti sui Product e quelli sull’Order possono essere combinati?
- uno sconto sulla spedizione viene applicato prima o dopo la selezione del metodo di spedizione?
- la piattaforma ripartisce gli sconti a livello Order tra le singole righe?
- la logica di rimborso conserva l’allocazione originale degli sconti?
- l’arrotondamento avviene per riga, per riga fiscale o soltanto sul totale finale?
La combinazione degli sconti è particolarmente delicata. Alcune piattaforme consentono più sconti automatici e coupon contemporaneamente; altre limitano le combinazioni o applicano una gerarchia. Anche quando entrambe supportano la stessa tipologia di sconto, il risultato può cambiare perché la sequenza di applicazione è diversa.
Come differiscono i modelli di piattaforma
Le piattaforme differiscono per quanto le logiche di prezzo e promozione siano native, configurabili, dipendenti da estensioni o controllate da sistemi esterni.
Le piattaforme SaaS offrono spesso prezzi Product e variante strutturati, codici sconto, sconti automatici, prezzi specifici per mercato ed estensioni basate su app. Possono semplificare l’amministrazione, ma limitare combinazioni, pricing B2B avanzato, priorità delle regole o campagne complesse senza app aggiuntive o funzionalità di livello superiore.
Le piattaforme Open-Source offrono spesso accesso più profondo a regole di catalogo e carrello, gruppi Customer, classi fiscali e tabelle delle estensioni. Questo abilita logiche commerciali complesse, ma i dati possono essere distribuiti tra tabelle core, moduli, attributi custom, configurazioni serializzate e codice personalizzato.
Le piattaforme enterprise possono separare prezzi in price book, cataloghi condivisi, gruppi Customer, siti, mercati, contratti e business account. Il pricing B2B può dipendere da gerarchie account, permessi aziendali, ruolo del buyer, contratti negoziati, purchase list o sincronizzazione ERP.
Gli store omnichannel o collegati a marketplace possono non usare la piattaforma e-commerce come unica fonte dei prezzi. ERP, POS, PIM, marketplace tool, repricing engine o channel manager possono controllare i valori. In questo modello, lo store mostra ed elabora i prezzi mentre la fonte autorevole può risiedere altrove.
Relazioni con gli altri dati dello store
Prezzi e promozioni dipendono da più strutture:
| Struttura collegata | Effetto sulle regole commerciali |
|---|---|
| Product e varianti | Determina se il prezzo o lo sconto si applica al Product padre, allo SKU, a un bundle, kit o configurazione |
| Attributi e tag | Possono governare idoneità, esclusioni, collezioni automatiche, pagine promozionali o etichette |
| Categories e collezioni | Controllano spesso regole di catalogo, landing page promozionali, campagne stagionali e merchandising |
| Gruppi cliente e segmenti | Determinano prezzi B2B, wholesale, loyalty, membership, dipendenti o VIP |
| Impostazioni fiscali | Controllano prezzi comprensivi di imposta, classi fiscali, calcolo regionale e totali fattura |
| Zone e metodi di spedizione | Governano spedizione gratuita, offerte regionali, soglie e incentivi nel processo di acquisto |
| Valute e mercati | Controllano prezzi locali, arrotondamenti, valori mostrati e differenze di cambio |
| Inventario ed evasione | Possono influenzare bundle, promozioni su backorder, disponibilità di abbonamenti e vendita regionale |
| Sistemi esterni | Possono sovrascrivere o sincronizzare prezzi, sconti, idoneità del cliente o totale Order |
Una regola deve essere valutata insieme alle strutture da cui dipende. Se cambia il modello delle varianti, cambiano le assegnazioni di Category oppure i gruppi cliente vengono ricreati come tag o segmenti, la promozione può richiedere una reinterpretazione anche quando il nome della regola rimane riconoscibile.
Funzionalità specifiche e comportamenti esclusivi delle piattaforme
Alcuni comportamenti di prezzo e promozione dipendono da funzionalità non disponibili in tutte le piattaforme. Possono essere native, basate su applicazioni o estensioni, disponibili soltanto in piani enterprise oppure controllate da sistemi esterni.
Esempi importanti includono:
- listini per mercato e prezzi regionali;
- prezzi per gruppo cliente e account B2B;
- cataloghi condivisi e listini specifici per azienda;
- fasce quantità wholesale e prezzi unitari a scaglioni;
- sconti per abbonamenti e regole di prezzo ricorrente;
- calcoli di prezzo per bundle, kit e Product configurabili;
- utilizzo di punti loyalty e crediti premio;
- interazioni tra gift card e credito store;
- sconti automatici senza codice coupon;
- logiche buy-one-get-one e omaggi;
- arrotondamenti per valuta, mercato, regola fiscale o provider di pagamento;
- prezzi gestiti dall’ERP e prezzi contrattuali per account;
- repricing marketplace e prezzi specifici per canale.
Questi comportamenti non sono intercambiabili. Un prezzo per gruppo cliente non equivale necessariamente a uno sconto basato su tag. Una regola di catalogo non equivale a una regola del carrello. Un prezzo di confronto non equivale a un prezzo promozionale con pianificazione. Un prezzo bundle calcolato da un’app non equivale a un prezzo nativo di variante. Per mantenere il comportamento commerciale previsto bisogna identificare la funzionalità che produceva il risultato originale.
Cosa si rompe più spesso quando la logica di prezzo viene interpretata male
I problemi possono essere difficili da rilevare perché il record amministrativo può sembrare corretto mentre il risultato nello storefront o nel processo di acquisto è errato.
| Problema | Causa probabile | Impatto su cliente o attività |
|---|---|---|
| Codice coupon corretto, importo errato | Cambiata l’azione o il subtotale idoneo | Reclami, errori di campagna, perdita di margine |
| Sconto applicato a Product esclusi | Modello di esclusione non ricreato correttamente | Rischio sul margine e violazioni delle policy di brand |
| Clienti wholesale vedono prezzi retail | Cambiata la relazione con gruppo cliente o listino | Attrito B2B e aumento delle richieste di assistenza |
| Badge promozionale visibile ma prezzo calcolato errato | Prezzo mostrato e prezzo attivo sono strutture separate | Confusione nello storefront e merchandising impreciso |
| Totale carrello diverso da quello atteso | Differenze nell’ordine di calcolo, imposte o arrotondamenti | Abbandono del processo di acquisto, disallineamenti contabili, rimborsi complessi |
| Spedizione gratuita troppo ampia o assente | Cambiata relazione tra regola, zona, soglia o metodo | Perdita di margine o riduzione della conversione |
| Scompare uno sconto loyalty o abbonamento | La logica gestita da app o sistema esterno non è stata ricreata | Problemi di fidelizzazione e interruzione degli ordini ricorrenti |
| Prezzi multivaluta divergono | Cambiate regole di cambio, mercato o arrotondamento | Incoerenza regionale e report non affidabili |
Questi problemi sono strutturali: derivano in genere da modelli non equivalenti, non dalla sola mancanza di un’etichetta.
Come esaminare prezzi e promozioni prima della migrazione
Una revisione utile deve separare il valore numerico del prezzo dalla logica commerciale che decide quando tale valore cambia.
È opportuno verificare:
- Product e varianti con prezzi non standard;
- prezzi promozionali attivi e campagne pianificate;
- prezzi per gruppi cliente, wholesale, B2B o membership;
- prezzi a scaglioni, volume, abbonamento e bundle;
- coupon attivi e sconti automatici;
- regole di catalogo e del carrello;
- limiti d’uso, date, priorità e combinazioni;
- dipendenze da Product, Category, cliente, regione, spedizione e imposte;
- prezzi controllati da app, estensioni, ERP, POS, loyalty, sistemi di abbonamento o marketplace;
- regole storiche da dismettere anziché trasferire.
La revisione più efficace parte dagli scenari commercialmente importanti, non da ogni coupon obsoleto. Offerte attive al lancio, prezzi B2B, sconti loyalty, prezzi di abbonamento, esclusioni ad alto impatto sul margine e soglie di spedizione gratuita meritano più attenzione delle campagne stagionali scadute.
Implicazioni della migrazione per prezzi e promozioni
La migrazione dovrebbe mantenere gli esiti commerciali previsti quando la piattaforma di destinazione può supportarli. Alcuni dati possono essere trasferiti come valori diretti. Alcune regole devono essere ricreate nelle impostazioni native. Altri comportamenti richiedono sostituzione di app, configurazione, attività manuale o trattamento personalizzato perché il modello di prezzo target è differente.
La validazione deve quindi usare scenari realistici di cliente e carrello, non limitarsi a verificare che il codice coupon o il valore del prezzo compaiano nell’area amministrativa.
Scenari importanti includono:
- Product retail normale senza promozioni;
- variante con prezzo diverso dal Product padre;
- Product con prezzo promozionale e prezzo di confronto;
- sconto basato su Category o collezione;
- prezzo per gruppo cliente o account B2B;
- fascia quantitativa;
- coupon con esclusioni e limiti d’uso;
- carrello con sconti combinabili o non combinabili;
- soglia per spedizione gratuita;
- Order sensibile al calcolo fiscale;
- Order multivaluta o regionale;
- abbonamento, bundle, loyalty o prezzo gestito da estensione.
Quando le regole non possono essere rappresentate con una corrispondenza diretta, occorre distinguere tra trasformazione dei valori, mappatura delle relazioni, gestione selettiva dei record, configurazione target e logica personalizzata. Regole gestite da app, tabelle prezzi personalizzate, identificatori esterni e calcoli su misura richiedono un’interpretazione esplicita e criteri di accettazione, non l’assunzione che il semplice trasferimento dei valori ricrei il comportamento.
Conclusione
Le logiche di prezzo e promozione sono un problema di architettura dei dati, non soltanto una configurazione di marketing. Il prezzo visibile, il codice coupon o l’etichetta dello sconto sono soltanto la superficie di un sistema più ampio che può coinvolgere Product, varianti, Categories, Customers, imposte, zone di spedizione, valute, sistemi esterni e ordine di calcolo specifico della piattaforma.
Prima della migrazione, la priorità è identificare quali comportamenti commerciali devono rimanere corretti dopo il lancio. Prezzi base, prezzi promozionali, prezzi per gruppi cliente, fasce quantità, regole di carrello e catalogo, incentivi sulla spedizione e sconti gestiti da estensioni devono essere valutati in base alle strutture che li producono.
Per i casi complessi, la validazione deve usare scenari rappresentativi di carrello. Se una regola dipende da strutture di sconto non supportate, logica di prezzo personalizzata, dati gestiti da app o estensioni, fonti esterne o funzionalità non equivalenti, il trattamento necessario va chiarito prima dell’esecuzione su scala più ampia.
Domande frequenti
Perché la stessa promozione può comportarsi diversamente su un’altra piattaforma?
Perché una promozione dipende da molto più del nome o del codice coupon. Condizioni di idoneità, esclusioni, regole del subtotale, momento del calcolo fiscale, spedizione, combinazione degli sconti, priorità, limiti d’uso e arrotondamento possono variare tra i motori di regole.
Qual è la differenza tra prezzo di un Product e regola di prezzo?
Il prezzo è un valore memorizzato sul Product, sulla variante, nel listino o nel mercato. Una regola di prezzo stabilisce quando quel valore cambia o quando si applica uno sconto aggiuntivo in base a condizioni relative a cliente, carrello, Product, Category, quantità, data, spedizione o altri fattori.
Le promozioni scadute devono essere migrate?
Non necessariamente. Promozioni scadute, obsolete, di test o a basso impatto possono spesso essere dismesse. Campagne attive, prezzi specifici per cliente, offerte del periodo di lancio, prezzi wholesale, regole loyalty, sconti di abbonamento ed esclusioni sensibili al margine richiedono invece una revisione più accurata.
Come si valida il funzionamento di prezzi e promozioni?
Con scenari realistici di cliente e carrello. Bisogna verificare sconti specifici per Product, articoli esclusi, prezzi per gruppi cliente, fasce quantitative, sconti combinati, soglie di spedizione gratuita, totali fiscali, prezzi regionali e comportamenti gestiti da estensioni.
Quando le logiche di prezzo richiedono un trattamento personalizzato?
Può essere necessario quando il risultato dipende da trasformazioni di regole non supportate, dati di app o estensioni, logiche loyalty, prezzi di abbonamento, listini specifici per cliente, prezzi ERP/POS esterni, combinazioni complesse o calcoli su misura che la piattaforma di destinazione non può ricreare direttamente.