Dynamische Preisgestaltung für otto.de

Stellen wir uns vor, es ist Anfang Juni. Wir haben noch 230 Stück eines schönen geblümten Sommerkleides auf Lager. Alle müssen bis Ende Juli verkauft werden, weil wir diese Lagerkapazität für das kommende Herbst-Winter-Sortiment benötigen. Die Frage ist nun, welcher Preis gewährleistet, dass wir weder zu früh ausverkauft sind noch Ende Juli unverkaufte Ware übrig haben? Die Markdown Pricing Services adressieren genau diese Frage.

Wir verwenden Modelle des maschinellen Lernens wie OLS Regression, XGBoost und LightGBM, um die Anzahl der Artikel zu prognostizieren, die innerhalb der verbleibenden Zeitspanne zu verschiedenen Preisen verkauft werden können. Wir füttern diese Modelle mit historischen Daten über Preise und Bestellmengen. Da auch andere Faktoren wie Preise von Mitbewerbern oder Marketingkampagnen einen großen Einfluss auf das Bestellvolumen haben können, lassen wir auch diese Informationen in die Modelle einfließen. Die Einbeziehung dieser Merkmale hilft uns, bessere Nachfragevorhersagen zu treffen und die Nachfrageänderungen genauer zu bestimmen, die wahrscheinlich ausschließlich auf Preisänderungen zurückzuführen sind. Mit einem präzisen Vorhersagemodell ist es ein Leichtes, den optimalen Preis für die übrig gebliebenen Sommerkleider zu ermitteln.

Neben Markdown Pricing haben wir eine weitere Anwendung für Dynamic Pricing: Portfolio-Optimierung. Nehmen wir an, wir verkaufen 200 verschiedene Arten von Kühlschränken. Um die Rentabilität zu gewährleisten, muss die Gesamtmarge für die Kühlschränke mindestens 15 Prozent betragen. Fällt sie unter diesen Wert, bleibt kein Geld mehr auf dem Tisch, um die Kosten von OTTO zu decken - unser Ziel ist es also, unser Verkaufsvolumen zu maximieren, ohne unter den kritischen Margenwert zu fallen.

Auch hier helfen uns die Nachfrageprognosemodelle: Sie unterscheiden zwischen Artikeln, die stark auf Preisänderungen reagieren (elastische Artikel) und solchen, die das nicht tun (unelastische Artikel). Wir können also die Preise für elastische Artikel senken, da dies einen erheblichen Anstieg der Nachfrage auslösen wird. Dies hilft uns, den Gesamtabsatz zu maximieren, indem wir unseren Kunden attraktive Preise anbieten. Andererseits sollten wir die Preise für unelastische Artikel nicht senken, denn eine Preissenkung ohne Erhöhung des Bestellvolumens ist ein Verlustgeschäft - etwas, das ein Einzelhändler nicht schätzt.

Abbildung 2 zeigt die Portfolio-Optimierung bei der Arbeit. Nach der Markteinführung wurden die Preise gesenkt, um das Verkaufsvolumen zu maximieren. Infolgedessen sinkt die Gesamtmarge des Sortiments - gerade auf das Zielniveau, aber im Durchschnitt nicht darunter. Prima! Unsere Kunden sind glücklich, weil sie von attraktiveren Preisen auf otto.de profitieren, OTTO ist glücklich, weil der Absatz deutlich wächst und die Gewinnmarge immer noch über der kritischen Schwelle liegt. Leider ist unsere glücksverteilende Portfolio-Optimierung rechnerisch sehr aufwendig. Die technischen Herausforderungen, die sich daraus ergeben, werden im nächsten Abschnitt diskutiert.

Im Jahr 2019 umfassten unsere Abschriften- und Portfolio-Optimierungsdienste drei Sortimente. Wir lieferten etwa 200.000 Preise pro Woche. Zu diesem Zeitpunkt betrieb OTTO einen der größten Hadoop-Cluster in Europa. Dennoch knarrten die Maschinen unter der Belastung der Preisoptimierung. Während der "Cluster-Happy Hours", wenn sich unser Dienst den Maschinenpool mit vielen anderen leistungshungrigen Anwendungen teilte, waren die verfügbaren Worker Nodes in kürzester Zeit aufgebraucht. Zu dieser Zeit stand im allgemeinen Protokoll: "Anwendung gestartet... Optimierung fast abgeschlossen... Tut mir leid, Sie wurden überrannt... Neustart der Anwendung". Mit anderen Worten: Da wir uns auf gemeinsam genutzte Ressourcen verließen, war unsere Pipeline weder robust noch skalierbar.

Da wir wussten, dass wir derzeit nur für drei Sortimente Preise lieferten, während zehn andere noch darauf warteten, an Bord zu kommen, hatten wir zwei Möglichkeiten: den rechenintensiven Teil unserer Anwendung in eine Cloud zu verlagern oder zu versuchen, unsere Kollegen von den gemeinsam genutzten Ressourcen abzuschrecken. Da wir ein kleines Team von eher schwachen Entwicklern waren, die weder willens noch in der Lage waren, jemanden zu verschrecken, entschieden wir uns für die erste Option. Mit anfänglicher Unterstützung durch ein Team erfahrener Cloud-Entwickler begannen wir, unsere Cloud-Infrastruktur in Terraform zu programmieren. Ungefähr 6 Monate später war die gesamte Cloud-Pipeline bereit, in Betrieb zu gehen.

Wir sammelten unsere Eingabedaten immer noch von lokalen Systemen, aber die Rechenarbeit fand jetzt in der Cloud statt. Wir verwenden Dataproc, um unsere maschinellen Lernmodelle zu trainieren und die Preisoptimierung auf verteilte Weise durchzuführen. Gleichzeitig sind bis zu 2.500 Kerne damit beschäftigt, ML-Modellen beizubringen, wie man aus Preisen Verkäufe vorhersagen kann oder die besten Preise für rund eine Million Artikel pro Tag zu ermitteln. Neben dem Modelltraining und der Preisoptimierung sind alle Kernkomponenten unserer Anwendung (z. B. Dienste, die die Preisergebnisse in Datenbanken einspeisen oder Preis-Upload-Daten für otto.de bereitstellen) als containerisierte Docker-Microservices aufgebaut. ETL-Prozesse, Modelltraining, Preisoptimierung, Preisupload und alle anderen Microservices werden von einem Jenkins-Server orchestriert, der selbst in einem Docker-Container auf einer Cloud-VM lebt. Unsere Anwendung besteht also hauptsächlich aus einem Jenkins-Docker, auf dem gedockte Microservices laufen - und dazwischen Dataproc-Jobs für Modelltraining und Preisoptimierung.

Heute liefert unser Service bis zu 4,7 Millionen Preise pro Woche. Das sind etwa 24 Mal mehr Preise als wir geliefert haben, als wir die Grenzen unserer On-Premise-Ressourcen erreicht hatten. Und der Dienst läuft jetzt reibungslos. Nun, nicht immer. Aber ziemlich oft. Wir arbeiten weiter daran...

Hast du schon einmal gehört, dass sich die Data Scientists eines Teams fragen, warum "die ETL-Leute eine ganze Woche brauchen, um zwei winzige neue Spalten zum Mart hinzuzufügen"? Nun, die Data Scientists sind wahrscheinlich noch nie in den Schuhen ihrer Kollegen gelaufen. Andernfalls wüssten sie, dass es (je nach Qualität und Dokumentation der Quelle) sehr wohl ein mühsames und langwieriges Verfahren sein kann, diese neuen Spalten hinzuzufügen. In einem funktionsübergreifenden Team, in dem die Data Scientists ihre Arbeitshandschuhe anziehen und die Datenverarbeitung selbst durchführen, wird dies nicht vorkommen. Es wird auch nicht vorkommen, dass ETL-Ingenieure das Gefühl haben, gestrandet zu sein, wenn die Pipeline bricht, während die DevOps-Spezialisten im Urlaub sind, da sie in der Lage sein werden, das Problem allein oder vielleicht zusammen mit einem Data Scientist zu beheben.

Wir glauben, dass eine gute und effektive Teamarbeit durch eine funktionsübergreifende Struktur stark unterstützt wird. Jeder in unserem Team versteht und schätzt die Arbeit des anderen, weil wir um die Feinheiten und Herausforderungen wissen, die mit jeder Rolle im Team einhergehen. Und jeder im Team kann - zumindest bis zu einem gewissen Grad - für den anderen einspringen. Der Data Scientist ist krankgeschrieben? Kein Problem, die DevOps können das Vorhersagemodell erstellen. Das hat eine entspannende Wirkung auf beide.