Sconti programmati: configurare promozioni che iniziano e terminano automaticamente

Ultima revisione: giugno 2026. Verificato con PrestaShop 1.7, 8 e 9. Nota su PS9: il back office degli sconti viene unificato in quattro tipi di sconto (Catalogo, Carrello, Spedizione gratuita, Regalo gratuito) dietro un feature flag, ma ogni tipo mantiene comunque la finestra di date su cui si basa questa guida.

Sono le 23:00 di giovedì e ti ricordi che la promozione del Black Friday doveva partire a mezzanotte. Ti metti di corsa a creare regole carrello e modificare prezzi, sperando di non sbagliare una virgola decimale sotto pressione. Oppure c'è la versione più silenziosa dello stesso errore: imposti uno sconto "solo weekend" il venerdì, te ne dimentichi il lunedì e regali margine per tre giorni in più prima che qualcuno se ne accorga. Entrambi gli errori hanno la stessa causa di fondo — una persona è l'interruttore on/off.

PrestaShop può essere quell'interruttore al posto tuo. Entrambi i meccanismi di sconto della piattaforma — regole carrello e prezzi specifici — hanno i propri timestamp di inizio e fine, e il negozio li valuta a ogni caricamento di pagina. Imposti le date una volta sola e la promozione si attiva e si disattiva da sé, che tu sia sveglio o meno. Questa guida riguarda proprio quel livello di programmazione: dove si trovano i campi data, come PrestaShop decide se uno sconto è "attivo" in un dato momento, la trappola del fuso orario che può spostare silenziosamente il lancio, e i contenuti che vanno programmati insieme al prezzo. Per scegliere quale tipo di sconto usare in partenza, leggi come gestire una promozione in PrestaShop; per capire quando lanciarli durante l'anno, consulta il calendario delle promozioni stagionali.

Come PrestaShop decide davvero se uno sconto è "attivo"

Capire cosa succede sotto il cofano aiuta, perché determina tutto ciò che viene dopo. PrestaShop non esegue a mezzanotte un'attività programmata che accende la promozione. Non c'è nessun cron, nessuna coda. Invece, sia le regole carrello sia i prezzi specifici salvano nel database un date_from e un date_to, e il prezzo viene ricalcolato al momento della richiesta: quando un cliente carica una pagina prodotto o aggiorna il carrello, il core confronta quei timestamp con ora e include lo sconto solo se il momento corrente rientra nella finestra.

Che cosa significa, in pratica? Tre cose. Primo, l'attivazione è immediata e affidabile — non c'è un processo che può non partire, quindi una promozione impostata per le 00:00 inizia davvero alle 00:00. Secondo, "ora" viene valutato in base alla configurazione del fuso orario del negozio/runtime PHP, non al fuso locale del visitatore (vedi la trappola del fuso orario più sotto). Terzo, poiché il prezzo viene calcolato live e poi memorizzato in cache, una promozione che dovrebbe essere già partita può continuare a mostrare il vecchio prezzo finché la cache della pagina non viene rigenerata — ed è per questo che cache full-page aggressive e sconti programmati vanno coordinati, come vedremo più avanti.

Programmare una regola carrello (Catalogo → Sconti)

Le regole carrello sono il motore dei buoni sconto di PrestaShop — sia i codici inseriti dal cliente sia gli sconti automatici applicati silenziosamente quando le condizioni sono rispettate. Puoi crearne una da Catalogo → Sconti → Nuova regola carrello (in PrestaShop 1.6 il percorso è Regole prezzi → Regole carrello). Per programmarla, apri la scheda Condizioni e imposta Valido dal / Valido fino al:

• Valido dal — data e ora in cui la regola diventa utilizzabile. Salvata come date_from.
• Valido fino al — data e ora di scadenza. Salvata come date_to.

Dentro quella finestra la regola è attiva; fuori, il codice viene rifiutato con "questo buono non è valido" e una regola automatica semplicemente non viene applicata. Due campi che molti commercianti saltano meritano invece di essere impostati con attenzione:

• Totale disponibile e Totale disponibile per ogni utente — limiti di utilizzo. L'intervallo di date risponde a "quando"; questi campi rispondono a "quante volte", ed è così che impedisci a un codice trapelato di essere abusato per tutta la durata della finestra.
• Evidenzia e Uso parziale — nella scheda Azioni. Evidenzia indirizza il cliente verso un buono applicabile nel carrello; Uso parziale decide se il residuo non speso di un buono a importo fisso resta valido per l'ordine successivo.

Una cosa che il back office non ti impedirà di fare: impostare "Valido fino al" prima di "Valido dal". Non c'è una protezione, la regola semplicemente non si attiva mai, e lo scopri quando un cliente scrive per chiedere perché EARLY20 non funziona. Ricontrolla le due date prima di salvare.

Programmare un ribasso sui prodotti (prezzi specifici)

Le regole carrello scontano il carrello. Per mostrare un prezzo barrato sulla pagina prodotto — la classica presentazione da saldi, vecchio prezzo barrato e nuovo prezzo in rosso — si usa un prezzo specifico, impostato per singolo prodotto da Catalogo → Prodotti → [il tuo prodotto] → Prezzi → Prezzi specifici → Aggiungi un prezzo specifico. La stessa finestra compare quando assegni in blocco una regola prezzo catalogo da Catalogo → Sconti → Regole prezzo catalogo, che è il modo per programmare uno sconto su un'intera categoria o su un fornitore in una sola volta, invece che prodotto per prodotto.

La finestra ha i propri campi data-ora Da e A — le stesse colonne from/to della tabella ps_specific_price — più alcuni controlli che le regole carrello non hanno:

• Per (gruppo clienti) — limita il prezzo programmato a un gruppo, così "settimana all'ingrosso, −20% per rivenditori" può coesistere nella stessa finestra con il normale prezzo al dettaglio.
• Quantità disponibile / Da quantità — applica lo sconto per scaglioni in base alle unità acquistate, dentro un intervallo di date programmato.
• Lascia le date vuote — e il prezzo specifico diventa permanente. I campi data sono ciò che trasforma un prezzo fisso in una promozione temporizzata; cancellarli è il modo per rendere intenzionalmente "stabile" un prezzo in saldo.

La differenza visibile per chi acquista è il motivo per scegliere un meccanismo invece dell'altro: un prezzo specifico appare nel catalogo e sulla pagina prodotto prima che qualcosa venga aggiunto al carrello, quindi pubblicizza l'offerta; una regola carrello di solito si rivela al carrello. Se non sai quale meccanismo sia più adatto a una promozione, il confronto tra regole carrello e prezzi specifici è il quadro decisionale da seguire.

Controllare le finestre programmate con una sola query

Quando hai preparato in anticipo un trimestre di promozioni, conviene rileggerle tutte in un unico punto invece di cliccare dentro ogni prodotto. Questi sono controlli in sola lettura — non modificano nulla. Per vedere ogni regola carrello la cui finestra si apre in futuro o è attualmente attiva (adatta il prefisso ps_ alla tua installazione):

-- Cart rules with their scheduled windows, soonest first.
SELECT id_cart_rule, code, active, date_from, date_to,
       quantity, quantity_per_user
FROM ps_cart_rule
WHERE date_to >= NOW()
ORDER BY date_from;

E per intercettare il classico errore "Valido fino al prima di Valido dal" su tutte le regole in una volta sola, prima che lo trovi un cliente:

-- Any rule whose window can never open (to is before from).
SELECT id_cart_rule, code, date_from, date_to
FROM ps_cart_rule
WHERE date_to < date_from;

L'equivalente per i ribassi sui prodotti legge la tabella ps_specific_price — le colonne from e to sono gli stessi campi di programmazione scritti dalla finestra, e una riga con entrambi impostati a 0000-00-00 00:00:00 è un prezzo permanente (senza date), non una promozione programmata.

La trappola del fuso orario che sposta il lancio

Questo è il modo più comune in cui uno sconto programmato va storto, ed è invisibile finché non colpisce. PrestaShop valuta date_from / date_to rispetto al fuso orario configurato per il negozio, impostato in Internazionale → Localizzazione → Fuso orario (internamente viene salvato come PS_TIMEZONE) — che non è necessariamente lo stesso dell'orologio di sistema del tuo hosting, e quasi mai lo stesso di un cliente che naviga da un altro Paese.

L'errore si presenta così: il fuso orario del negozio resta quello predefinito scelto dall'host, oppure UTC, mentre la tua attività e i tuoi clienti lavorano in CET (UTC+1). Imposti l'inizio dei saldi alle 00:00. Per i tuoi clienti in Europa centrale, in realtà parte alle 01:00 — e il "flash di mezzanotte" annunciato via email è perso per la prima ora. Anche gli orari di fine slittano allo stesso modo: una chiusura "domenica 23:59" in UTC finisce alle 00:59 locali del lunedì, regalando un'ora in più che non avevi previsto.

Prima di qualsiasi lancio importante, conferma prima il fuso orario del negozio, poi leggi l'orario di inizio come "00:00 in quel fuso orario" invece che "00:00 nel mio orario".

Il dettaglio che quasi tutti dimenticano: cache e parte visiva

Tra uno sconto datato correttamente e un cliente che lo vede davvero ci sono due elementi.

Cache. Poiché i prezzi vengono calcolati al momento della richiesta e poi memorizzati in cache, un negozio con cache full-page, cache Smarty o CDN può continuare a servire il prezzo pre-saldi dopo il passaggio di date_from — e continuare a servire il prezzo scontato dopo la fine. Per una promozione con partenza rigida, lo schema più sicuro è programmare le date normalmente e poi svuotare la cache al momento del lancio (Parametri avanzati → Prestazioni → Svuota cache), così il primo rendering ricalcola il prezzo. Se usi una cache edge con durata lunga, includi il suo TTL nel momento effettivo di purge.

Se l'orario di inizio della promozione è davvero fisso (un flash di mezzanotte), puoi eliminare l'intervento umano anche dallo svuotamento della cache. PrestaShop non programma l'attivazione degli sconti, ma il tuo server può programmare lo svuotamento della cache — un cron di una riga che esegue il comando console di cache-clear al momento del lancio, così il primo rendering dopo l'apertura ricalcola i prezzi senza che tu debba accedere:

# crontab entry: clear PrestaShop's cache at 00:00 on 27 Nov 2026,
# the minute a hard-start sale opens. Run as the web user.
# (path to the PrestaShop root; --no-debug for prod)
0 0 27 11 * cd /var/www/html && php bin/console cache:clear --env=prod --no-debug

Questo non attiva lo sconto — lo fa da sola la finestra di date — ma garantisce che la pagina pre-saldi memorizzata in cache sparisca nell'istante in cui la finestra si apre. Su una CDN o una cache edge lo abbineresti alla purge dello stesso provider nello stesso minuto. Consideralo una doppia sicurezza per le promozioni in cui conta il primo minuto, non un requisito per la normale programmazione quotidiana.

La parte visiva. Lo sconto è programmato; lo slider in homepage però dice ancora "Saldi estivi" mentre la promozione autunnale è attiva, oppure il banner che pubblicizza il codice è scaduto tre giorni prima del codice stesso. In PrestaShop programmazione dei prezzi e programmazione dei contenuti sono sistemi separati, e il secondo non ha campi data nativi nello slider predefinito. Abbina a ogni sconto programmato un cambio creativo programmato, così messaggio e prezzo cambiano nello stesso minuto — il nostro approccio ai banner per le promozioni spiega come produrli senza coinvolgere un designer.

Sconti sovrapposti: cosa prevale quando due regole si scontrano

Nel momento in cui programmi più di una promozione, puoi cumularle per errore. Un prodotto con un prezzo specifico al 20% che rientra anche in una regola carrello automatica del 15% non si comporta sempre come il cliente (o il tuo margine) si aspetta. PrestaShop risolve questi casi con impostazioni di priorità e combinazione, non semplicemente sommando tutto:

• Prezzi specifici — quando ne possono essere applicati diversi, i conflitti vengono risolti dalle regole di priorità dei prezzi specifici di PrestaShop e dai criteri corrispondenti (negozio/valuta/Paese/gruppo più quantità e date); testa il prezzo prodotto risultante.
• Regole carrello hanno una propria Priorità e un interruttore per singola regola che controlla se la regola può essere combinata con altri buoni nello stesso carrello.
• Una riduzione da prezzo specifico e uno sconto da regola carrello vengono calcolati in fasi diverse (prezzo riga vs totale carrello), quindi possono sommarsi se non lo hai previsto.

La logica è davvero macchinosa e non vale la pena ragionarci in astratto. Prima di qualunque finestra in cui le promozioni si sovrappongono, fai l'unico test che risolve la questione: inserisci un ordine di prova reale con gli sconti programmati attivi e leggi il totale finale. Se è più basso di quanto volevi, regola priorità/compatibilità delle regole carrello, restrizioni sui prodotti, oppure escludi i prodotti già scontati, poi testa di nuovo. I meccanismi più profondi della stratificazione delle riduzioni sono spiegati nella guida alle strategie promozionali; per i prodotti che devono essere protetti da qualsiasi sconto programmato, vedi l'esclusione dagli sconti.

Checklist pre-lancio per qualsiasi promozione programmata

Imposta ogni promozione circa una settimana prima dell'avvio, così rivedi le impostazioni con calma invece che alle 23:00. Prima che vada online, passa questa lista:

• Le date sono corrette — "Valido fino al" è davvero dopo "Valido dal" ed entrambe sono nel fuso orario del tuo negozio, non nel tuo orologio da parete.
• L'ambito è giusto — una regola "20% sugli accessori" che si applica silenziosamente a tutto il catalogo può costare un pomeriggio molto caro. Conferma categoria, gruppo o condizione prodotto.
• Limiti di utilizzo impostati — totale disponibile e limiti per utente su qualunque codice che potrebbe circolare.
• Sovrapposizioni testate — un ordine di prova reale attraverso gli sconti programmati; leggi il totale finale.
• Piano cache — sai se svuotare la cache al lancio e alla fine.
• Creatività programmata — banner, slider e qualsiasi email sincronizzati con la stessa finestra del prezzo.

Quando il calendario diventa più grande del back office

I campi data nativi gestiscono bene una singola promozione. La fatica emerge quando stai portando avanti un calendario continuo — saldi stagionali uno dopo l'altro, offerte weekend ricorrenti, eventi flash a tempo — e ti ritrovi a modificare a mano decine di regole carrello e prezzi specifici, ciascuno con il proprio ragionamento sul fuso orario e lo svuotamento della cache. È esattamente il carico di lavoro che i nostri moduli di automazione sono pensati per eliminare. Sales Revolution gestisce offerte flash programmate e con scadenza automatica come una campagna controllata, non come un mucchio di regole manuali — imposti la finestra, i prodotti e l'entità dello sconto, e lui si occupa di avviare e terminare l'offerta; lo abbiamo presentato in offerte flash automatizzate per PrestaShop. Il vantaggio è lo stesso di cui parla tutto questo articolo, ma su scala più ampia: l'interruttore on/off non è più una persona a mezzanotte. Per la psicologia dietro offerte a tempo gestite in modo corretto — countdown reali, niente timer che si resettano in modo finto — leggi offerte flash senza manipolazione.

Il vero fascino degli sconti programmati è volutamente noioso: decidi una volta, alla luce del giorno, con date e ambito davanti, e il negozio li fa rispettare esattamente. Imposta bene il fuso orario, considera la cache, programma la creatività insieme al prezzo e testa le sovrapposizioni — poi lascia che tutto giri. Il tuo io futuro, alle 23:00 di un giovedì, non dovrà pensarci affatto.

Sconti programmati: domande frequenti

PrestaShop ha bisogno di un cron per attivare uno sconto all'orario di inizio?

No. L'attivazione non è un'attività programmata — non c'è alcun cron che accende le promozioni. PrestaShop salva un date_from/date_to su ogni regola carrello e prezzo specifico e ricalcola il prezzo al momento della richiesta, includendo lo sconto solo quando "ora" rientra nella finestra. È per questo che una promozione impostata per le 00:00 inizia davvero alle 00:00, senza processi che possano non partire. Un cron è utile solo per lo svuotamento della cache al momento del lancio, non per lo sconto in sé.

La data della mia promozione era passata, ma il vecchio prezzo continuava a comparire — perché?

Cache. I prezzi vengono calcolati al momento della richiesta e poi memorizzati in cache, quindi una cache full-page, la cache Smarty o una CDN possono continuare a servire il prezzo pre-saldi dopo l'apertura della finestra. Svuota la cache al momento del lancio (Parametri avanzati → Prestazioni → Svuota cache) e, se usi una cache edge o una CDN, esegui anche la purge e considera il suo TTL. Per una promozione con partenza rigida, programma quello svuotamento così il primo rendering dopo il lancio ricalcola i prezzi.

La promozione è partita con un'ora di ritardo — che cosa è successo?

La trappola del fuso orario. PrestaShop valuta la finestra rispetto al fuso orario configurato del negozio (PS_TIMEZONE, in Internazionale → Localizzazione → Fuso orario), non all'orologio del server o all'ora locale del visitatore. Se il tuo negozio resta su UTC mentre il tuo mercato lavora in CET, un inizio alle "00:00" scatta alle 01:00 per i clienti. Imposta il fuso orario del negozio sul tuo mercato principale, poi leggi ogni orario promozionale come "mezzanotte in quel fuso orario".

Posso impostare una finestra di sconto senza data di fine?

Sì — lascia vuoto il campo A / Valido fino al. Su un prezzo specifico, cancellare entrambi i campi data rende il prezzo permanente (un ribasso stabile invece di una promozione temporizzata). Su una regola carrello, un Valido fino al senza fine significa che la regola resta utilizzabile finché non la disattivi o finché non si esauriscono i limiti di utilizzo. I campi data sono esattamente ciò che trasforma un prezzo stabile in uno temporizzato, quindi lasciarli vuoti è una scelta deliberata, non una dimenticanza.

Come evito che due sconti programmati si sommino fino a generare una perdita?

Non ragionarci in astratto — testalo. Inserisci un ordine reale con entrambi gli sconti programmati attivi e leggi il totale finale. Se lo sconto è più profondo del previsto, le leve sono: Priorità della regola carrello, l'opzione per singola regola "combina con altri buoni" ed "Escludi prodotti scontati" su una regola carrello percentuale, così ignora tutto ciò che ha già un prezzo specifico. Modifica e poi testa di nuovo. Per gli SKU che non devono mai essere toccati da alcuna promozione, vedi l'esclusione dagli sconti.