DE 
EnglishStandard
Українська
Polski🏷️ Dynamische Preisengine — Nachfrageelastizität in Echtzeit
Beobachten Sie, wie eine Preisoptimierungs-Engine die Nachfrageelastizität eines Einzelhandelsartikels erkundet und den Preis in Echtzeit anpasst, wobei Umsatz gegen Lagerabverkauf abgewogen wird.
Über die dynamische Preisengine
Einzelhändler kennen ihre Nachfragekurve selten — sie beobachten nur, wie viele Einheiten zu welchem verlangten Preis verkauft werden. Diese Simulation verbirgt eine Nachfragekurve mit konstanter Elastizität, Nachfrage = k·Preis^(−ε), hinter einem verrauschten, durch Lagerbestand begrenzten Verkaufssignal und lässt eine Preisengine sie live entdecken. An jedem simulierten Tag nutzt die Engine entweder ihre aktuell beste Preisschätzung aus oder erkundet einen nahegelegenen Preis, um weiterzulernen — genau wie ein Mehrarmiger-Bandit, der Ausnutzung gegen Informationsgewinn abwägt.
Darunter gewinnt eine gleitende log-log-lineare Regression über die letzten 30 (Preis, verkaufte Einheiten)-Beobachtungen eine Schätzung von ε und der Nachfrageskala k. Eine Rastersuche über den erlaubten Preisbereich bewertet dann jeden Kandidatenpreis nach erwartetem Umsatz abzüglich einer Strafe fürs Abweichen vom Tempo, das nötig ist, um den verbleibenden Lagerbestand bis zum Ende des Horizonts zu verkaufen — eine vereinfachte Version des Endbestands-Revenue-Management-Problems, das Fluggesellschaften und Einzelhändler jeden Tag lösen. Beobachten Sie, wie Nachfragekurve, Umsatzkurve, Abverkaufsanzeige und Preisanpassungsprotokoll gemeinsam aktualisiert werden, während die Engine zum wahren Optimum konvergiert (oder davon abgebracht wird).
Häufig gestellte Fragen
Was ist Nachfrageelastizität, und wie schätzt die Engine sie, ohne sie je zu sehen?
Die Preiselastizität der Nachfrage ε misst, wie stark die nachgefragte Menge auf den Preis reagiert: Ein Preisanstieg um 1 % schrumpft die Nachfrage um etwa ε %. Diese Simulation erzeugt die wahre tägliche Nachfrage aus einer Kurve konstanter Elastizität, Nachfrage = k·Preis^(−ε), aber der Engine werden weder k noch ε mitgeteilt — sie beobachtet nur die verrauschten, durch den Lagerbestand begrenzten tatsächlich verkauften Einheiten zum jeweils verlangten Preis. Durch Logarithmieren wird ln(Nachfrage) = ln(k) − ε·ln(Preis) zu einer Geraden, sodass eine gewöhnliche Kleinste-Quadrate-Regression über die letzten 30 (Preis, verkauft)-Paare Schätzungen von k und ε direkt aus Steigung und Achsenabschnitt gewinnt.
Warum „erkundet“ die Engine nahegelegene Preise, statt direkt zum Optimum zu springen?
Eine Regression, die auf einer engen Preisgruppe angepasst wird, ist unzuverlässig — liegen alle Beobachtungen nahe 38–42 €, schränkt die Steigungsschätzung ε außerhalb dieses Bereichs kaum ein, und die geschätzte Umsatzkurve kann bei Extrapolation stark danebenliegen. Die Engine verhält sich daher wie ein Mehrarmiger-Bandit: An den meisten Tagen nutzt sie den Preis aus, den ihr aktuelles Modell für den besten hält, doch mit der Wahrscheinlichkeit ε-Bandit (der Erkundungsraten-Regler) schiebt sie den Preis stattdessen auf ein zufälliges nahegelegenes Niveau, rein um einen informativeren Datenpunkt zu sammeln. Dieser Erkundungs-/Ausnutzungs-Kompromiss ist derselbe, der in echten Online-Preisgestaltungs- und Anzeigen-Auktionssystemen verwendet wird.
Warum gibt es manchmal keinen inneren Preis, der den Umsatz maximiert?
Der Umsatz bei konstanter Elastizität ist R(p) = p·k·p^(−ε) = k·p^(1−ε). Ist ε > 1 (elastische Nachfrage), ist der Exponent 1−ε negativ, sodass R(p) streng fallend in p ist — der Umsatz wird durch den niedrigsten erlaubten Preis maximiert, und das Volumen kompensiert die geringere Marge mehr als. Ist ε < 1 (unelastische Nachfrage), ist 1−ε positiv, und der Umsatz steigt mit dem Preis weiter, sodass der beste Preis der höchste erlaubte ist. Nur der Fall ε = 1 macht den Umsatz flach. Deshalb erzwingt dieser Simulator stets ausdrückliche Preisunter- und -obergrenzenregler — echte „optimale Preis“-Probleme sind meist Optimierungen gegen eine Grenze, kein glattes inneres Maximum.
Was ist die Lagertempo-Strafe, und warum nicht einfach jeden Tag den Umsatz maximieren?
Den geschätzten Tagesumsatz isoliert zu maximieren kann den Bestand viel zu schnell verkaufen (und Geld liegen lassen, das Kunden bereit gewesen wären mehr zu zahlen) oder viel zu langsam (und die Saison mit unverkauftem, auf null herabgesetztem Bestand beenden). Die Engine berechnet ein Zieltempo — verbleibender Bestand geteilt durch verbleibende Tage — und bewertet jeden Kandidatenpreis als geschätzten Umsatz minus λ·(geschätzte Nachfrage bei diesem Preis − Zieltempo)², wobei λ der Tempogewichts-Regler ist. Ein höheres λ zieht den gewählten Preis dahin, den Abverkauf im Plan zu halten; ein niedrigeres λ lässt die Engine reinem Umsatz nachjagen und riskiert, mit Überbestand oder Fehlbestand zu enden.
Was ist der Unterschied zwischen Erkundung und Ausnutzung in dieser banditartigen Engine?
Ausnutzung bedeutet, den Preis zu verlangen, den das aktuell beste Modell der Engine als den tempoangepassten Umsatzwert maximierend ansieht — sie nutzt bereits Gelerntes. Erkundung bedeutet, absichtlich einen anderen, nahegelegenen Preis auszuprobieren, obwohl das Modell ihn derzeit nicht für optimal hält, rein um zu beobachten, wie die Nachfrage dort reagiert, und die Elastizitätsschätzung zu verfeinern. Zu wenig Erkundung, und die Engine kann bei einem lokal ordentlichen Preis hängenbleiben, während ein viel besserer anderswo auf der Kurve übersehen wird; zu viel Erkundung, und sie verschwendet Tage mit schlechten Preisen. Der Erkundungsraten-Regler steuert direkt, wie oft ein zufälliger Testpreis statt der Modellempfehlung verwendet wird.
Warum ist die beobachtete Nachfrage „zensiert“, sobald der Bestand knapp wird?
Die wahre Nachfragekurve des Simulators kann an einem Tag zum Beispiel 220 Einheiten verlangen, doch wenn nur noch 40 Einheiten auf Lager sind, werden nur 40 Einheiten tatsächlich verkauft und beobachtet. Die Regression der Engine sieht nur verkaufte Einheiten, nicht die wahre unbeschränkte Nachfrage, sodass die beobachtete Nachfrage die reale Kurve systematisch unterschätzt, je näher der Bestand an null rückt — eine bekannte Verzerrung in Einzelhandelsdaten namens Nachfragezensierung. Das ist einer der Gründe, warum reale Revenue-Management-Systeme versuchen, Rabatte zu stoppen, bevor der Bestand kritisch niedrig wird, statt null Verkäufe als „keine Nachfrage“ zu lesen.
Welche realen Techniken spiegelt diese Simulation?
Die Gesamtform — eine verborgene Kurve konstanter Elastizität, Preisexperimente, die verrauschte Verkaufsdaten erzeugen, eine Online-Regression, die die Kurve wiedergewinnt, und eine Tempobeschränkung gegen einen festen Horizont — spiegelt Revenue-Management bei Fluggesellschaften und Hotels, Einzelhandels-Rabattoptimierung und die „kontextuellen Preis-Banditen“ mancher E-Commerce-Plattformen. Reale Systeme fügen weit mehr hinzu (Konkurrenzpreise, Kannibalisierung zwischen Artikeln, Kundensegmente, reichhaltigere Erkundungsstrategien wie Thompson-Sampling), doch die Kernschleife aus Testen → Schätzen → Optimieren → Tempo halten ist dieselbe wie hier.