Eine neue API war nur der Anfang
Als eBay seine Schnittstellen und Anforderungen an Automotive-Angebote weiterentwickelte, musste eine bestehende und umsatzrelevante Systemlandschaft modernisiert werden. Je nach Vertriebskanal mussten rund 40.000 bis 60.000 Produkte verarbeitet werden – mit Fahrzeugkompatibilitäten, unterschiedlichen Beständen, individuellen Preisstrategien und mehreren spezialisierten Sales Channels.
Eine klassische Schnittstelle, die Produktdaten lediglich von A nach B überträgt, reichte dafür nicht mehr aus. Mit eBayBot und eLords | Trader entstand deshalb eine Plattform, die Daten, Regeln und operative Entscheidungen zusammenführte.
Ausgangslage
Ein bestehendes System stößt an seine Grenzen
MAPCO betrieb bereits seit Jahren verschiedene B2C- und B2B-Vertriebskanäle über eBay. Historisch waren zeitweise bis zu elf Sales Channels Teil der Systemlandschaft. Die bestehende Integration basierte auf einem älteren, unter PHP 5.6 entwickelten System und war für die damaligen eBay-Anforderungen ausgelegt.
Mit der Modernisierung änderten sich die Spielregeln. Fahrzeugzuordnungen, Kategorien, Produktinformationen und Angebotsstrukturen wurden komplexer. Gleichzeitig sollte die Channel-Landschaft strategisch reduziert und stärker auf Autopartner24 und SpecialParts im B2C- sowie MOCOM im B2B-Geschäft fokussiert werden.
An den bestehenden Vertriebskanälen hing relevanter Umsatz. Die Aufgabe bestand deshalb nicht darin, irgendwann ein neues System bereitzustellen. Der bestehende Vertrieb musste in eine neue technische Generation überführt werden.
Die Herausforderung
Ein Produkt ist nicht gleich ein Angebot
Ein Automotive-Ersatzteil ist nicht nur durch Artikelnummer, Preis und Bestand beschrieben. Entscheidend ist vor allem: Für welche Fahrzeuge passt dieses Produkt – und unter welchen Einschränkungen?
Das MAPCO-Onlinesystem stellte dafür unter anderem TecDoc-basierte Produkt- und Artikeldaten, KType-Fahrzeugzuordnungen, fahrzeugspezifische Einschränkungen, OE-/OEM-Referenzen, Produktkriterien, Bilder und Beschreibungen bereit. Diese Informationen mussten in das Datenmodell und die Angebotsstruktur von eBay übersetzt werden.
Wenn aus einem Produkt 20 Listings werden
Produkte mit sehr großer Fahrzeugabdeckung konnten nicht immer vollständig innerhalb eines einzelnen Angebots abgebildet werden. Die Kompatibilitäten mussten deshalb auf mehrere Angebote verteilt werden. Im Extremfall entstanden aus einem physischen Produkt rund 20 eBay-Listings.
KTypes · OE/OEM · TecDoc
Diese Angebote waren technisch eigenständig – fachlich gehörten sie weiterhin zu demselben Produkt. Änderungen an Preis, Bestand oder Produktdaten mussten gegebenenfalls koordiniert über eine ganze Gruppe von Listings ausgeführt werden. Auch die Reihenfolge bestimmter Updates spielte eine Rolle. Aus Synchronisation wurde ein Zustands- und Koordinationsproblem.
Die Lösung
eBayBot & eLords | Trader
2022 entstand eine neue Systemgeneration. Der eBayBot bildete die Automatisierungs- und Verarbeitungsebene im Hintergrund. eLords | Trader stellte die operative Oberfläche bereit, über die Angebote und Sales Channels überwacht, konfiguriert und gesteuert werden konnten.
Das MAPCO-Gesamtsystem blieb die führende Datenquelle. Trader übernahm relevante Daten in eine eigene Datenhaltung, reicherte sie für den Marketplace-Betrieb an und übersetzte sie in die für eBay erforderlichen Strukturen.
Das Ziel war nicht, die Datenhoheit in ein weiteres System zu verlagern. Die vorhandenen Daten sollten für einen komplexen digitalen Vertriebsprozess nutzbar gemacht werden.
Von Synchronisation zu Automation
60.000 Produkte lassen sich nicht einzeln steuern. Regeln schon.
Ein zentraler Gedanke hinter Trader war die Steuerung über Sales-Channel-Strategien. Dazu gehörten Angebots- und Update-Strategien, eBay-spezifische Features, Kategorien und Properties, Titel und Untertitel, Preisstrategien, Rabatte, eBayPlus, Galerie- und Zusatzfunktionen sowie die Nutzung des eBay-Produktkatalogs.
Automation bedeutete dabei nicht „alles automatisch machen“. Regeln definieren, Routine automatisieren und Eingriffsmöglichkeiten für Ausnahmen erhalten.
Ein Bot, der den Zustand seiner Angebote kennt
Trader stellte Angebote nicht nur ein, sondern verfolgte ihren weiteren Lebenszyklus: Angebotsstatus, Laufzeit, Verkäufe, Umsatz, Views bzw. Beobachter, Bestand, Preis, Aktualisierungen und Performance über unterschiedliche Zeiträume.
Ein integriertes Effizienz-Management konnte laufende Angebote anhand verschiedener Kriterien wie Verkäufen im Verhältnis zur Laufzeit bewerten. Ineffiziente Angebote konnten beendet und neu eingestellt werden. Der Kreislauf lautete: veröffentlichen → beobachten → bewerten → entscheiden → aktualisieren.
Automation mit menschlicher Kontrolle
TecDoc beziehungsweise das führende MAPCO-System behielt die Hoheit über zentrale Produktinformationen. Gleichzeitig konnten Anwender im Trader eBay-spezifische Eigenschaften beeinflussen – beispielsweise Titel, Untertitel und Marketplace-Features. Angebote konnten bewusst aus der automatisierten Steuerung herausgenommen und manuell weitergeführt werden.
Automation für die Masse. Kontrolle für die Ausnahme.
Preise nicht im Blindflug
Die Preisbildung war abhängig vom jeweiligen Vertriebskanal. Neben berechneten eigenen Preisen und Versandkosten stellte Trader Marktindikatoren direkt am Angebot bereit: Most · Low · Average · Maximum.
Zusätzliche Strategien konnten beispielsweise Rabatte für neue Angebote oder definierte Preisrundungen abbilden. Der Marketplace wurde damit nicht nur technisch synchronisiert, sondern als Vertriebskanal beobachtbar.
Virtuelle Lager und Packstationen
Verkaufbarer Bestand ist mehr als die Summe eines Lagers
Eine reale Packstation konnte verschiedene physische Lager und Bestände unterschiedlicher Mandanten enthalten. Trader bildete daraus virtuelle Lager und virtuelle Packstationen.
Damit ließ sich bestimmen, welche Bestände für einen Vertriebskanal verfügbar sind, in welcher Reihenfolge Lager berücksichtigt werden, welcher Standort bevorzugt wird, welche Versand- und Zahlungsbedingungen gelten und welche Preislogik daraus entsteht. Auch Dropshipping über MAPCO konnte als zusätzliche Bestandsquelle für Autopartner24 berücksichtigt werden.
Die relevante Frage war damit nicht „Wie viele Teile liegen insgesamt im Lager?“, sondern: Wie viele Teile darf dieser Sales Channel unter seinen konkreten Bedingungen tatsächlich verkaufen – und aus welcher Quelle soll geliefert werden?
Engineering für Massendaten
Parallel statt nacheinander
Die Menge der Produkte, Fahrzeugbeziehungen, Listings und laufenden Aktualisierungen erforderte eine Architektur, die viele Aufgaben parallel bearbeiten konnte. Im Kern des eBayBot entstand dafür ein eigener Multiprozessmanager auf Basis von PHP-Sockets. Ein Socket-Stream-Server stellte bidirektionale Kommunikationskanäle zwischen den beteiligten Prozessen bereit.
Worker-Prozesse bearbeiteten Aufgaben asynchron und parallel und synchronisierten sich über die zentrale Kommunikationsschicht. Produktupdates wurden über Queues verarbeitet. Logging und Performance-Monitoring halfen unter anderem bei der Erkennung langsamer Datenbankabfragen.
Zum technischen Umfeld gehörten PHP · Socket Streams · MariaDB · Redis · Queues · Docker · nginx. Die Plattform wurde im weiteren Verlauf auf PHP 8 migriert.
Betrieb gehört zur Lösung
Die Verantwortung endete nicht beim Sourcecode. Auch die für den Betrieb notwendige Server-Infrastruktur wurde konzipiert. Dazu gehörten Wartung und Updates sowie die Absicherung persistenter Daten. Insbesondere MySQL-/MariaDB-Datenbanken und File-Assets mussten regelmäßig gesichert werden.
Ein automatisierter Vertriebskanal ist nur dann eine funktionierende Lösung, wenn er dauerhaft betrieben und im Fehlerfall wiederhergestellt werden kann.
Transparenz für den Vertrieb
Trader besaß nicht nur technische Monitoring-Funktionen. Ein Dashboard stellte unter anderem Umsätze und die Entwicklung der Sales Channels dar. Angebote konnten anhand von Umsatz, Verkäufen, Bestand, Laufzeit und weiteren Informationen betrachtet werden.
Technische Zustände und geschäftliche Auswirkungen kamen damit in derselben Anwendung zusammen.
Historischer Kontext
Ein neues System – aber kein unbekanntes Umfeld
Die technische Verantwortung hinter Lordfox kannte die bestehende MAPCO-Systemlandschaft bereits aus mehreren Jahren interner Tätigkeit: Von 2014 bis 2016 als Senior Full-Stack Developer bei MAPCO, von Ende 2016 bis Anfang 2020 mit Verantwortung für die Online-IT im B2B- und B2C-Bereich.
Die hier beschriebene neue Systemgeneration wurde dagegen 2022 als externer Auftrag über Lordfox von Preußen umgesetzt. Der erste Commit des neuen eBayBot-Repositories stammt vom 10. Januar 2022.
Historische MAPCO-Anstellung und externer Lordfox-Auftrag sind damit klar voneinander getrennt. Die Vorkenntnis machte es möglich, die Zusammenhänge zwischen Produktdaten, Fahrzeugkompatibilitäten, Lagerlogik und Vertrieb als Ganzes zu betrachten.
Weiterführende Zusammenarbeit
Im Zuge der späteren Trennung von MAPCO und Autopartner24 unterstützte Lordfox bei der Extraktion benötigter Daten aus dem zuvor stark verzahnten Online-Ökosystem. Autopartner24 wechselte anschließend auf eine neue Speed4Trade-Systemlandschaft. Die Implementierung dieser neuen Plattform war nicht Bestandteil des Lordfox-Auftrags.
Das Ergebnis
Nicht einfach eine neue eBay-Schnittstelle
Mit eBayBot und eLords | Trader entstand eine Plattform, die große Produktbestände automatisiert verarbeiten, komplexe Automotive-Fahrzeugkompatibilitäten abbilden, mehrere Listings eines Produkts koordinieren und spezialisierte Sales Channels mit eigenen Strategien unterstützen konnte.
Reale und virtuelle Bestände, Dropshipping und Fulfillment-Strukturen, Preise, Marktinformationen, laufende Angebotsüberwachung und regelbasierte Entscheidungen wurden in einem steuerbaren Prozess zusammengeführt. Der Mensch behielt die Kontrolle über Ausnahmen.
Komplexität wurde aus der manuellen Arbeit herausgenommen und in beherrschbare Regeln und Prozesse übersetzt.
Was davon geblieben ist
eLords | Trader ist ein historisches Projekt. Der dahinterliegende Gedanke ist es nicht. Digitale Systeme entfalten ihren Wert nicht dadurch, dass möglichst viele Schnittstellen miteinander verbunden werden. Sie entfalten ihn dann, wenn aus Daten, Regeln und technischen Möglichkeiten ein Prozess entsteht, den Menschen verstehen und steuern können.
Komplexität aus den Prozessen nehmen – damit Menschen über das Geschäft entscheiden können, nicht über Schnittstellen.
Das ist der rote Faden, den eLords heute weiterführt.