Inserats-Matching optimiert – 72 % Zeitersparnis bei Änderungen erzielt
Finex
Kurz gesagt, was wir erreicht haben
Vorher – 4,5 Stunden für die Implementierung einer neuen Regel
Nachher – 15 Minuten – ohne Code-Änderungen
Ergebnis – +18 % erfolgreiche Abschlüsse und -40 % Supportanfragen
Technologie – Statt "Spaghetti-Code" – eine Kette unabhängiger Schritte (Pipeline)
Drei Jahre lang wuchs die Plattform parallel zum Geschäft: Käufer fanden die benötigten Anzeigen mit nur wenigen Klicks. Doch je mehr Anforderungen hinzukamen, desto mehr „wühlten“ wir uns durch den Code. Jede neue Bedingung zog Dutzende Änderungen und wochenlange Tests nach sich.
Wir beschlossen, diesen Engpass ein für alle Mal zu beseitigen. Das Ziel war einfach, aber ehrgeizig: das System so flexibel zu gestalten, dass jeder neue Filter oder jede neue Regel in Minutenschnelle aktiviert werden kann – ohne Beteiligung von Entwicklern und ohne Verzögerungen für das Geschäft.
Systembeschreibung
Vorher – Ein schwerfälliges Programm, bei dem jede neue Regel einen "Faden" von Änderungen durch den gesamten Code zog.
Nachher – Eine Kette unabhängiger Schritte – wie ein Fließband, bei dem jeder Block nur für seine eigene Operation verantwortlich ist.
- Verfügbarkeitsfilter: Sortiert Anzeigen aus, bei denen das Produkt nicht auf Lager ist. Der Service zeigt keine leeren Anzeigen an, was die Benutzererfahrung deutlich verbessert.
- Preisprüfung: Vergleich mit dem durchschnittlichen Marktpreis. Überteuerte Angebote werden entfernt, um die Konversionsrate zu steigern.
Prinzipien der neuen Architektur
- Pipeline (Fließband): Ein Prozess aus „Blöcken“ (Pipes), die strikt nacheinander ablaufen. Die Logik kann neu angeordnet, ein- oder ausgeschaltet werden, ohne dass eine Neukompilierung erforderlich ist.
- SRP (Single-Responsibility-Prinzip): Eine Aufgabe = eine Pipe. Wird ein neuer Markenfilter benötigt, erstellen wir ein separates Modul, anstatt im alten Code zu wühlen.
- DIP (Dependency-Inversion-Prinzip): Unabhängigkeit vom „Innenleben“. Pipes kommunizieren über gemeinsame Schnittstellen; Änderungen an einer Implementierung bleiben für die anderen Pipes unbemerkt.
- OCP (Open/Closed-Prinzip): „Geschlossen“ für Änderungen, „offen“ für Erweiterungen. Funktionalität wird durch neue Module ergänzt, ohne bestehende Module zu verändern.
- Factory Method: Das System „stellt“ den benötigten Satz an Pipes basierend auf den Datenbank-Einstellungen zusammen. Beispiel: Das Marketing fügt ein neues Kriterium hinzu → die Plattform übernimmt es „on the fly“.
Jetzt kann das Business-Team die Matching-Regeln über eine Admin-Oberfläche ändern, ohne Jira-Tickets für Entwickler zu erstellen. Änderungen gelangen in Minutenschnelle in die Produktion und spiegeln sich sofort in den Verkaufsstatistiken wider.
Problem: Begrenzte Flexibilität und komplexe Updates
Das Business-Team fügte ständig Filter und Koeffizienten hinzu, und der alte Mechanismus konnte nicht Schritt halten:
- eine neue Bedingung → Dutzende von Code-Änderungen;
- Releases verzögerten sich, Tests zogen sich in die Länge, Kunden beschwerten sich.
Wir mussten eine Struktur schaffen, die es ermöglicht, neue Filterregeln zu implementieren, ohne den bestehenden Code zu beeinträchtigen.
Lösung
Flexible Pipeline
Eine Kette unabhängiger Filter. Jeder Schritt kann mit einem Klick aktiviert oder deaktiviert werden, ohne neues Release.
Regelverwaltung aus der Datenbank
Ein Manager ändert das JSON-Profil ohne Entwickler. Neue Regeln werden in Minutenschnelle aktiviert.
Modulare Tests
Jede Pipe ist durch Tests abgedeckt. Der Service bleibt auch bei häufigen Änderungen stabil.
Caching häufiger Anfragen
Reduziert die Last auf der Datenbank und beschleunigt den Prozess der Anzeigenauswahl.
Ergebnisse
- Flexibilität und Anpassungsgeschwindigkeit – neue Geschäftsregeln werden sofort umgesetzt, ohne dass Codeänderungen erforderlich sind.
- Konversion „Ansicht → Abschluss“ – eine präzisere Anzeigenauswahl führte zu mehr erfolgreichen Abschlüssen.
- Geringere Belastung des Supports – es ist jetzt nachvollziehbar, warum eine Anzeige die Filterung nicht bestanden hat, was die Anzahl der Supportanfragen reduziert.
- Gesteigerte Verarbeitungsgeschwindigkeit – Caching und Optimierung der Code-Struktur beschleunigen den Auswahlprozess.
- Transparenz und Kontrolle – es ist leicht nachzuvollziehen, welche Pipe eine Anzeige abgelehnt hat, was Analyse und Debugging vereinfacht.
Was dies dem Unternehmen brachte
Was kommt als Nächstes?
Wir haben die Anzeigenauswahl in einen Baukasten verwandelt, der sich in Minutenschnelle an den Markt anpasst. Der nächste Schritt ist die Integration einer A/B-Testing-Engine direkt in die Pipeline, sodass das Business neue Regeln „on the fly“ testen und sofort erkennen kann, welche den Umsatz tatsächlich steigern.