Geplante Rabatte: Aktionen einrichten, die automatisch starten und enden

Verifiziert mit PrestaShop 1.7, 8 und 9. Hinweis zu PS9: Die Rabattverwaltung im Backoffice wird hinter einem Feature-Flag in vier Rabattarten zusammengeführt (Katalog, Warenkorb, kostenloser Versand, Gratisgeschenk), aber jede Art besitzt weiterhin das Datumsfenster, auf dem dieser Leitfaden basiert.

Es ist Donnerstag, 23 Uhr, und Ihnen fällt ein, dass die Black-Friday-Aktion um Mitternacht live gehen sollte. Unter Zeitdruck erstellen Sie Warenkorbregeln und ändern Preise, in der Hoffnung, keine Dezimalstelle falsch einzugeben. Oder die stillere Variante desselben Fehlers: Sie richten am Freitag einen Rabatt "nur fürs Wochenende" ein, vergessen ihn am Montag und verschenken drei zusätzliche Tage Marge, bevor es jemand bemerkt. Beide Fehler haben dieselbe Ursache. Ein Mensch ist der Ein-/Ausschalter.

PrestaShop kann stattdessen dieser Schalter sein. Beide Rabattmechanismen der Plattform, Warenkorbregeln und spezifische Preise, haben eigene Start- und Endzeitpunkte, und der Shop wertet sie bei jedem Seitenaufruf aus. Setzen Sie die Daten einmal, und die Aktion schaltet sich selbst ein und aus, ob Sie wach sind oder nicht. In diesem Leitfaden geht es gezielt um diese Planungsebene: wo die Datumsfelder liegen, wie PrestaShop entscheidet, ob ein Rabatt zu einem bestimmten Zeitpunkt "aktiv" ist, welche Zeitzonenfalle Ihren Start unbemerkt verschieben kann und welche Inhalte parallel zum Preis geplant werden müssen. Wenn es um die Strategie geht, welche Rabattart Sie überhaupt wählen sollten, lesen Sie eine Verkaufsaktion in PrestaShop durchführen; für die Frage, wann im Jahr Aktionen sinnvoll sind, den saisonalen Verkaufskalender.

Wie PrestaShop tatsächlich entscheidet, ob ein Rabatt "live" ist

Es hilft zu verstehen, was unter der Haube passiert, denn daraus ergibt sich alles Weitere. PrestaShop führt keinen geplanten Job um Mitternacht aus, der Ihre Aktion einschaltet. Es gibt keinen Cron-Task, keine Warteschlange. Stattdessen speichern sowohl Warenkorbregeln als auch spezifische Preise ein date_from und date_to in der Datenbank, und der Preis wird zur Anfragezeit neu berechnet: Wenn ein Kunde eine Produktseite lädt oder den Warenkorb aktualisiert, vergleicht der Kern diese Zeitstempel mit jetzt und berücksichtigt den Rabatt nur, wenn der aktuelle Zeitpunkt innerhalb des Fensters liegt.

Was bedeutet das also für Sie? Drei praktische Dinge. Erstens ist die Aktivierung sofort und zuverlässig. Es gibt keinen Job, der nicht ausgelöst werden könnte, daher startet eine auf 00:00 gesetzte Aktion tatsächlich um 00:00. Zweitens wird "jetzt" anhand der Zeitzonenkonfiguration des Shops bzw. der PHP-Laufzeit ausgewertet, nicht anhand der lokalen Zeitzone des Besuchers (die Zeitzonenfalle unten). Drittens: Weil der Preis live berechnet und anschließend zwischengespeichert wird, kann eine Aktion, die bereits gestartet sein sollte, noch den alten Preis zeigen, bis der Seiten-Cache neu aufgebaut ist. Deshalb müssen aggressives Full-Page-Caching und geplante Rabatte aufeinander abgestimmt werden, wie weiter unten beschrieben.

Eine Warenkorbregel planen (Katalog → Rabatte)

Warenkorbregeln sind PrestaShops Gutschein-Engine, sowohl für Codes, die ein Kunde eingibt, als auch für automatische Rabatte, die still angewendet werden, sobald die Bedingungen erfüllt sind. Sie erstellen eine solche Regel unter Katalog → Rabatte → Neue Warenkorbregel (in PrestaShop 1.6 lautet der Pfad Preisregeln → Warenkorbregeln). Um sie zeitlich zu planen, öffnen Sie den Tab Bedingungen und setzen Gültig ab / Gültig bis:

• Gültig ab. Datum und Uhrzeit, ab der die Regel nutzbar wird. Gespeichert als date_from.
• Gültig bis, Datum und Uhrzeit, zu der sie abläuft. Gespeichert als date_to.

Innerhalb dieses Fensters ist die Regel live; außerhalb davon wird der Code mit "dieser Gutschein ist nicht gültig" abgelehnt, und eine automatische Regel wird schlicht nicht angewendet. Zwei Felder, die viele Händler überspringen, sollten Sie bewusst setzen:

• Insgesamt verfügbar und Insgesamt verfügbar pro Benutzer, Nutzungslimits. Ein geplanter Datumsbereich beantwortet die Frage "wann"; diese Felder beantworten "wie oft", und genau so verhindern Sie, dass ein geleakter Code über das gesamte Fenster missbraucht wird.
• Hervorheben und Teilweise Nutzung, im Tab Aktionen. Hervorheben lenkt den Kunden im Warenkorb auf einen passenden Gutschein hin; teilweise Nutzung entscheidet, ob ein nicht verbrauchter Restbetrag eines Wertgutscheins für die nächste Bestellung erhalten bleibt.

Eine Sache verhindert das Backoffice nicht: "Gültig bis" früher zu setzen als "Gültig ab". Es gibt keine Schutzschiene; die Regel wird einfach nie aktiv, und Sie erfahren es erst, wenn ein Kunde fragt, warum EARLY20 nicht funktioniert. Lesen Sie beide Daten noch einmal gegen, bevor Sie speichern.

Eine Preissenkung für Produkte planen (spezifische Preise)

Warenkorbregeln rabattieren den Warenkorb. Wenn Sie auf der Produktseite selbst einen durchgestrichenen Preis anzeigen möchten, die klassische Angebotsdarstellung, alter Preis durchgestrichen, neuer Preis in Rot, verwenden Sie einen spezifischen Preis, den Sie pro Produkt unter Katalog → Produkte → [Ihr Produkt] → Preise → Spezifische Preise → Spezifischen Preis hinzufügen setzen. Derselbe Dialog erscheint, wenn Sie eine Katalogpreisregel gesammelt unter Katalog → Rabatte → Katalogpreisregeln zuweisen; so planen Sie einen Rabatt für eine ganze Kategorie oder einen Lieferanten auf einmal, statt Produkt für Produkt.

Der Dialog besitzt eigene Datums- und Uhrzeitfelder Von und Bis, dieselben Spalten from/to in der Tabelle ps_specific_price, sowie Steuerungsmöglichkeiten, die Warenkorbregeln nicht haben:

• Für (Kundengruppe), beschränkt den geplanten Preis auf eine Gruppe, sodass "Großhandelswoche, −20% für Wiederverkäufer" im selben Zeitfenster neben normalen Endkundenpreisen bestehen kann.
• Verfügbare Menge / Ab Menge, staffelt den Rabatt nach gekauften Einheiten, geplant auf einen Datumsbereich.
• Datumsfelder leer lassen. Dann ist der spezifische Preis dauerhaft. Die Datumsfelder machen aus einem stehenden Preis eine zeitlich begrenzte Aktion; sie zu leeren ist der Weg, einen Angebotspreis bewusst "haften" zu lassen.

Der sichtbare Unterschied für den Käufer ist der Grund, das eine statt des anderen zu wählen: Ein spezifischer Preis erscheint schon im Katalog und auf der Produktseite, bevor etwas in den Warenkorb gelegt wird, und bewirbt damit das Angebot; eine Warenkorbregel zeigt sich typischerweise erst im Warenkorb. Wenn Sie unsicher sind, welcher Mechanismus zu einer bestimmten Aktion passt, bietet der Vergleich von Warenkorbregeln und spezifischen Preisen den Entscheidungsrahmen.

Geplante Zeitfenster mit einer Abfrage prüfen

Wenn Sie ein ganzes Quartal an Aktionen im Voraus vorbereitet haben, lohnt es sich, sie an einer Stelle auszulesen, statt jedes Produkt einzeln anzuklicken. Das sind reine Leseprüfungen, sie ändern nichts. Um jede Warenkorbregel zu sehen, deren Fenster in der Zukunft beginnt oder gerade live ist (passen Sie das Präfix ps_ an Ihre Installation an):

-- 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;

Und um den klassischen Fehler "Gültig bis früher als Gültig ab" über alle Regeln hinweg zu finden, bevor ein Kunde ihn für Sie entdeckt:

-- 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;

Das Gegenstück für Produktpreissenkungen liest die Tabelle ps_specific_price aus. Die Spalten from und to sind dieselben Planungsfelder, die der Dialog schreibt, und eine Zeile, in der beide auf 0000-00-00 00:00:00 stehen, ist ein dauerhafter (undatierter) Preis, kein geplanter.

Die Zeitzonenfalle, die Ihren Start verschiebt

Das ist die häufigste Ursache dafür, dass ein geplanter Rabatt schiefgeht, und sie bleibt unsichtbar, bis sie zuschlägt. PrestaShop wertet date_from / date_to anhand der konfigurierten Shop-Zeitzone aus, die unter International → Lokalisierung → Zeitzone gesetzt wird (intern gespeichert als PS_TIMEZONE), und diese ist nicht zwingend identisch mit der Systemzeit Ihres Hosting-Servers und fast nie identisch mit der lokalen Zeit eines Kunden aus einem anderen Land.

Der Fehler sieht so aus: Ihre Shop-Zeitzone steht noch auf einem Standard, den der Hoster gewählt hat, oder auf UTC, während Ihr Geschäft und Ihre Kunden nach MEZ arbeiten (UTC+1). Sie setzen den Start der Aktion auf 00:00. Für Ihre Kunden in Mitteleuropa geht sie tatsächlich erst um 01:00 live, und der "Mitternachts-Flash", über den alle per E-Mail informiert wurden, ist in der ersten Stunde tot. Endzeiten verrutschen genauso: Ein "Sonntag 23:59"-Ende in UTC endet lokal um 00:59 am Montag und verschenkt eine zusätzliche Stunde, die Sie nicht geplant hatten.

Bestätigen Sie vor jedem wichtigen Start zuerst die Shop-Zeitzone und lesen Sie Ihre Startzeit dann als "00:00 in dieser Zeitzone", nicht als "00:00 meine Zeit".

Das Detail, das fast alle vergessen: Cache und die visuelle Seite

Zwei Dinge stehen zwischen einem korrekt datierten Rabatt und einem Kunden, der ihn tatsächlich sieht.

Caching. Weil Preise zur Anfragezeit berechnet und danach zwischengespeichert werden, kann ein Shop mit Full-Page-Cache, Smarty-Cache oder CDN nach Ablauf von date_from weiterhin den Vor-Aktionspreis ausliefern, und nach Ende der Aktion weiterhin den Aktionspreis. Für eine Aktion mit hartem Start ist das sichere Muster: Daten normal planen und beim Go-live den Cache leeren (Erweiterte Einstellungen → Leistung → Cache leeren), damit die erste Darstellung den Preis neu berechnet. Wenn Sie einen langen Edge-Cache nutzen, berücksichtigen Sie dessen TTL bei der tatsächlichen Bereinigung.

Wenn die Startzeit Ihrer Aktion wirklich fix ist (ein Mitternachts-Flash), können Sie auch den Menschen aus der Cache-Bereinigung herausnehmen. PrestaShop plant die Rabattaktivierung nicht, aber Ihr Server kann das Cache-Leeren planen, ein einzeiliger Cron, der zum Go-live den Console-Befehl zum Cache-Leeren ausführt, damit die erste Darstellung nach dem Start Preise neu berechnet, ohne dass Sie sich einloggen müssen:

# 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

Das aktiviert den Rabatt nicht, das erledigt das Datumsfenster selbst, sondern stellt nur sicher, dass die zwischengespeicherte Vor-Aktionsseite in dem Moment verschwindet, in dem das Fenster öffnet. Bei einem CDN oder Edge-Cache würden Sie dies mit einer Bereinigung beim jeweiligen Anbieter zur selben Minute kombinieren. Betrachten Sie es als doppelte Absicherung für Aktionen, bei denen die erste Minute zählt, nicht als Pflicht für alltägliche Planungen.

Die visuelle Seite. Der Rabatt ist geplant; der Homepage-Slider sagt aber noch "Summer Sale", während die Herbstaktion live ist, oder das Banner bewirbt den Code noch drei Tage nachdem der Code abgelaufen ist. Preisplanung und Content-Planung sind in PrestaShop getrennte Systeme, und das zweite besitzt im Standard-Slider keine nativen Datumsfelder. Koppeln Sie jeden geplanten Rabatt mit einem geplanten Austausch der Werbemittel, damit Botschaft und Preis in derselben Minute wechseln, unser Banner-Ansatz für Aktionen zeigt, wie Sie diese ohne Designer im Prozess erstellen.

Überlappende Rabatte: Was gewinnt, wenn zwei Regeln kollidieren?

Sobald Sie mehr als eine Aktion planen, können Sie sie versehentlich stapeln. Ein Produkt mit einem spezifischen Preis von 20%, das zusätzlich unter eine automatische Warenkorbregel von 15% fällt, verhält sich nicht immer so, wie ein Kunde (oder Ihre Marge) es erwartet. PrestaShop löst das über Prioritäts- und Kombinationsregeln, nicht indem einfach alles addiert wird:

• Spezifische Preise, wenn mehrere greifen könnten, werden Konflikte über PrestaShops Prioritätsregeln für spezifische Preise und passende Kriterien gelöst (Shop/Währung/Land/Gruppe plus Mengen- und Datumsabgleich); testen Sie den resultierenden Produktpreis.
• Warenkorbregeln haben ihre eigene Priorität und einen regelbezogenen Schalter, der steuert, ob eine Regel mit anderen Gutscheinen im selben Warenkorb kombiniert werden darf.
• Eine Reduktion durch spezifischen Preis und ein Rabatt per Warenkorbregel werden in unterschiedlichen Phasen berechnet (Positionspreis vs. Warenkorbsumme), daher können sie sich verstärken, wenn Sie das nicht beabsichtigen.

Die Logik ist wirklich kleinteilig und taugt wenig für abstrakte Überlegungen. Vor jedem Fenster, in dem sich Aktionen überlappen, gibt es einen Test, der die Sache klärt: Legen Sie eine echte Testbestellung mit aktiven geplanten Rabatten an und lesen Sie den Endbetrag. Ist er höher rabattiert als beabsichtigt, passen Sie Priorität/Kombinierbarkeit der Warenkorbregel, Produktbeschränkungen oder den Ausschluss bereits rabattierter Produkte an und testen Sie erneut. Die tieferen Mechanismen der Rabatt-Schichtung erklären wir im Leitfaden zu Verkaufsstrategien; für Produkte, die von jedem geplanten Rabatt abgeschirmt werden sollen, siehe Rabattausschluss.

Eine Pre-Launch-Checkliste für jede geplante Aktion

Richten Sie jede Aktion ungefähr eine Woche vor ihrem Start ein, damit Sie die Einstellungen in Ruhe prüfen, statt um 23 Uhr unter Druck. Bevor sie live geht, gehen Sie diese Liste durch:

• Daten sind korrekt. "Gültig bis" liegt tatsächlich nach "Gültig ab", und beide Werte sind in Ihrer Shop-Zeitzone, nicht nach Ihrer Wanduhr.
• Geltungsbereich stimmt, eine Regel "20% Rabatt auf Zubehör", die unbemerkt für den ganzen Katalog gilt, ist ein teurer Nachmittag. Prüfen Sie Kategorie-, Gruppen- oder Produktbedingung.
• Nutzungslimits gesetzt, Gesamtlimit und Limit pro Benutzer für jeden Code, der nach außen gelangen könnte.
• Überlappung getestet, eine echte Testbestellung durch die geplanten Rabatte; Endsumme prüfen.
• Cache-Plan, wissen, ob Sie den Cache beim Go-live und beim Ende leeren.
• Werbemittel geplant, Banner, Slider und jede E-Mail auf dasselbe Fenster timen wie den Preis.

Wenn der Kalender größer wird als das Backoffice

Native Datumsfelder handhaben eine einzelne Aktion sauber. Die Belastung entsteht, wenn Sie einen rollierenden Kalender betreiben, aufeinanderfolgende saisonale Verkäufe, wiederkehrende Wochenendangebote, zeitlich begrenzte Flash-Events, und nun Dutzende Warenkorbregeln und spezifische Preise manuell bearbeiten, jeweils mit eigener Zeitzonenlogik und Cache-Bereinigung. Genau diese Arbeit sollen unsere Automatisierungsmodule entfernen. Sales Revolution führt geplante, automatisch auslaufende Flash-Angebote als verwaltete Kampagne statt als Stapel manueller Regeln aus, Sie setzen Fenster, Produkte und Rabatttiefe, und das Modul übernimmt Start und Ende des Angebots; vorgestellt haben wir es in automatisierte Flash-Angebote für PrestaShop. Der Nutzen ist derselbe, um den es in diesem ganzen Artikel geht, nur skaliert: Der Ein-/Ausschalter ist nicht mehr eine Person um Mitternacht. Zur Psychologie ehrlicher zeitlich begrenzter Angebote, echte Countdowns, keine Fake-Reset-Timer, siehe Flash-Sales ohne Manipulation.

Der ganze Reiz geplanter Rabatte ist absichtlich unspektakulär: Sie entscheiden einmal, bei Tageslicht, mit Daten und Geltungsbereich vor Augen, und der Shop setzt sie exakt durch. Zeitzone richtig einstellen, Cache berücksichtigen, Werbemittel parallel zum Preis planen und Überlappungen testen. Dann lassen Sie es laufen. Ihr zukünftiges Ich an einem Donnerstag um 23 Uhr muss darüber gar nicht mehr nachdenken.

Geplante Rabatte: häufige Fragen

Braucht PrestaShop einen Cron-Job, um einen Rabatt zur Startzeit einzuschalten?

Nein. Die Aktivierung ist kein geplanter Job. Es gibt keinen Cron-Task, der Aktionen einschaltet. PrestaShop speichert für jede Warenkorbregel und jeden spezifischen Preis ein date_from/date_to und berechnet den Preis zur Anfragezeit neu, wobei der Rabatt nur berücksichtigt wird, wenn "jetzt" innerhalb des Fensters liegt. Deshalb startet eine auf 00:00 gesetzte Aktion tatsächlich um 00:00, ohne Job, der ausfallen könnte. Ein Cron ist nur für die Cache-Bereinigung beim Go-live nützlich, nicht für den Rabatt selbst.

Das Datum meiner Aktion war erreicht, aber der alte Preis wurde weiter angezeigt, warum?

Caching. Preise werden zur Anfragezeit berechnet und dann zwischengespeichert, daher kann ein Full-Page-Cache, Smarty-Cache oder CDN den Vor-Aktionspreis auch nach Öffnung des Fensters weiter ausliefern. Leeren Sie den Cache beim Go-live (Erweiterte Einstellungen → Leistung → Cache leeren), und wenn Sie einen Edge-Cache oder ein CDN nutzen, bereinigen Sie diesen ebenfalls und berücksichtigen Sie dessen TTL. Bei einer Aktion mit hartem Start planen Sie diese Bereinigung, damit die erste Darstellung nach dem Start die Preise neu berechnet.

Die Aktion ging eine Stunde zu spät live, was ist passiert?

Die Zeitzonenfalle. PrestaShop wertet das Fenster anhand der konfigurierten Zeitzone des Shops aus (PS_TIMEZONE, unter International → Lokalisierung → Zeitzone), nicht anhand der Serveruhr oder der lokalen Zeit des Besuchers. Wenn Ihr Shop auf UTC bleibt, während Ihr Markt nach MEZ läuft, startet ein "00:00"-Beginn für Ihre Kunden um 01:00. Setzen Sie die Shop-Zeitzone auf Ihren Hauptmarkt und lesen Sie jede Aktionszeit als "Mitternacht in dieser Zeitzone".

Kann ich ein Rabattfenster ohne Enddatum setzen?

Ja, lassen Sie das Feld Bis / Gültig bis leer. Bei einem spezifischen Preis macht das Leeren beider Datumsfelder den Preis dauerhaft (eine stehende Preisreduzierung statt einer zeitlich begrenzten Aktion). Bei einer Warenkorbregel bedeutet ein offenes Gültig bis, dass die Regel nutzbar bleibt, bis Sie sie deaktivieren oder ihre Nutzungslimits ausgeschöpft sind. Genau die Datumsfelder machen aus einem stehenden Preis einen zeitlich begrenzten, daher sind leere Felder Absicht, kein Versehen.

Wie verhindere ich, dass sich zwei geplante Rabatte zu einem Verlust stapeln?

Überlegen Sie das nicht abstrakt, testen Sie es. Geben Sie eine echte Bestellung mit beiden aktiven geplanten Rabatten auf und lesen Sie die Endsumme. Wenn der Rabatt tiefer ist als beabsichtigt, sind die Stellhebel: Priorität der Warenkorbregel, der regelbezogene Schalter "mit anderen Gutscheinen kombinieren" und "Rabattierte Produkte ausschließen" bei einer prozentualen Warenkorbregel, damit sie alles ignoriert, was bereits einen spezifischen Preis hat. Anpassen, dann erneut testen. Für SKUs, die niemals von irgendeiner Aktion berührt werden dürfen, siehe Rabattausschluss.