KI-Empfehlungen in Solidus bauen
Solidus ist ein Open-Source eCommerce-Framework auf Ruby on Rails. Es betreibt Shops wie [MeUndies](https://meundies.com), [Ace & Tate](https://aceandtate.com) und [Bonobos](https://bonobos.com) und ist die Grundlage auf der ich eCommerce-Projekte im DACH-Markt baue. Was Solidus nicht mitbringt: Produktempfehlungen. Kein "Kunden die das kauften kauften auch" Engine. Kein "Empfohlen für dich" Bereich. Du bekommst einen soliden eCommerce-Kern — Produkte, Bestellungen, Zahlungen, Versand — aber die Intelligenz-Schicht musst du selbst bauen. Das ist eigentlich gut. Die generischen Empfehlungs-Plugins der meisten Plattformen sind bestenfalls mittelmäßig. Selbst bauen bedeutet du verstehst was es tut, kontrollierst die Daten und kannst es auf dein Geschäft abstimmen. Dieser Post ist ein vollständiger Walkthrough. Drei Ansätze — Collaborative Filtering, Content-Based Filtering und ein Hybrid — mit Python-ML-Skripten und dem Solidus/Rails-Code der alles in deinen Shop integriert.
Die drei Ansätze (und wann jeder funktioniert)
Collaborative Filtering sagt: "Nutzer die sich ähnlich wie du verhalten haben mochten diese Produkte." Es kümmert sich nicht um Produktattribute — nur um Muster im Nutzerverhalten. Stark, aber kann neuen Nutzern nichts empfehlen (Cold Start).
Content-Based Filtering sagt: "Basierend auf Attributen von Produkten die du mochtest, hier sind ähnliche." Nutzt Beschreibungen, Kategorien, Tags, Preise. Funktioniert ab Tag 1, erzeugt aber Filterblasen.
Hybrid kombiniert beide, gewichtet Collaborative höher wenn genug Daten existieren, fällt auf Content-Based zurück wenn nicht.
Schritt 1: Event-Tracking in Solidus
Solidus trackt standardmäßig keine Produktaufrufe oder Suchanfragen — nur abgeschlossene Bestellungen. Der EventTracker erfasst Interaktionen mit gewichteten Signalen: purchase (5.0), add_to_cart (3.0), wishlist_add (2.5), search_click (1.5), product_view (1.0), category_browse (0.5). Hook in ProductsController (Views), OrdersController (Cart Adds), OrderSubscriber (Purchases via Solidus Event Subscriber).
Schritt 2: Collaborative Filtering mit Python
Mindestens 500-1.000 Bestellungen über 50+ Produkte sammeln. implicit Library mit Alternating Least Squares (ALS) — gleicher Algorithmus den Netflix in ihrem frühen Empfehlungssystem nutzte. Sparse Interaktionsmatrix (Nutzer × Produkte), ALS Training, User-Recommendations und Item-Similarity Funktionen.
Warum ALS und nicht SVD oder Deep Learning? ALS funktioniert gut mit implizitem Feedback (Views, Klicks, Käufe) statt expliziten Bewertungen. Deep-Learning-Ansätze können ALS übertreffen aber brauchen deutlich mehr Daten und Rechenleistung — Overkill für die meisten Solidus-Shops.
Schritt 3: Content-Based Filtering mit Python
scikit-learn TF-IDF Vektorisierung kombinierter Textfeatures (Name, Beschreibung, Kategorie, Taxon-Pfad, Marke, Tags). Kosinus-Ähnlichkeit zwischen allen Produkten. Für große Kataloge (10k+) on-demand berechnen statt vorberechnen. Für Nutzer: letzte 10 Views nehmen, ähnliche Produkte akkumulieren, nach Gesamtscore sortieren.
Limitierung: Nur so gut wie deine Produktdaten. "Blaues T-Shirt. Baumwolle. Maschinenwaschbar." reicht nicht. Reichere Daten (Styling-Notizen, Materialien, Anlässe, Passform) = bessere Empfehlungen. Verbindung zum GEO-Optimierungspost.
Schritt 4: Hybrid Combiner
Gewichtete Zusammenführung: Standard 60% Collaborative / 40% Content. Gewichte verschieben sich automatisch: keine Collaborative-Daten → 100% Content. Weniger als 5 Collaborative-Ergebnisse → 30/70.
Schritt 5: Solidus Recommendation Engine
Orchestration: Strategien pro Kontext (product_page → similar_products, cart_page → complementary, homepage → personalised). Cold-Start-Fallback-Hierarchie: Hybrid → Content-Based aus Browsinghistorie → Kategorie-Popularität → globale Popularität.
Caching via Redis: vorberechnete Empfehlungen pro Nutzer/Produkt/Kategorie. Invalidierung bei Modellneutraining und signifikanten Nutzerevents.
Schritt 6: Views und Rendering
ViewHelper der product_recommendations(context:) exponiert. Partial mit Tracking-Daten (strategy, model_version, served_at). Links mit source=recommendation Parameter für Attribution.
Schritt 7: A/B Testing
Deterministische Variantenzuweisung basierend auf User-ID (gleicher Nutzer sieht immer gleiche Variante). Experiments konfigurierbar: control (Popularität, 50%), variant_a (Collaborative, 25%), variant_b (Hybrid, 25%). Conversion-Tracking pro Variante: Impression → Klick → Add-to-Cart → Kauf.
Schritt 8: Training Pipeline
Rake-Task via Cron: Interaktionsdaten exportieren → Produktdaten exportieren → Collaborative Model trainieren → Content Model trainieren → Cache invalidieren → Modellversion aktualisieren. Wöchentlich für die meisten Shops, täglich bei hohem Volumen.
Das Cold-Start-Problem (ehrlich)
Neuer Nutzer ohne Historie: Beliebteste Produkte in der angeklickten Kategorie → kampagnenbezogene Produkte → global beliebt. Keine davon personalisiert.
Neues Produkt ohne Interaktionen: Collaborative kann es buchstäblich nicht empfehlen. Content-Based kann es weil es Produktattribute nutzt. Deshalb ist der Hybrid wichtig.
Kleiner Katalog (unter 100 Produkte): Interaktionsmatrix zu klein für ALS. Handkuratierte Empfehlungen schlagen möglicherweise ML.
Saisonale Kataloge: Historische Daten letzte Saison nutzlos für aktuelle Saison. Content-Based handled das besser.
Fallstricke und Limitierungen
Popularitätsbias: Beliebte Produkte werden mehr empfohlen → mehr Verkäufe → mehr empfohlen. Empfehlungsdiversität aktiv überwachen.
Filterblase: Content-Based empfiehlt nur Ähnliches. Hybrid mildert aber eliminiert es nicht.
Latenz: Python-Modell pro Seitenaufruf = Latenz. Lösung: vorberechnen und aggressiv cachen.
"Alle die Windeln kauften kauften auch Bier"-Problem: Statistische Korrelationen, nicht kausale Zusammenhänge. Regelmäßig Stichprobe der Empfehlungen manuell prüfen.
Evaluation: Offline-Metriken (Precision, Recall) korrelieren nicht immer mit Online-Geschäftsmetriken (CTR, Umsatz). A/B-Test ist essentiell.
DSGVO-Überlegungen
Empfehlungssysteme basierend auf Nutzerverhalten sind Profiling unter DSGVO Artikel 22. Für Solidus-Shops im DACH-Markt: Einwilligung erforderlich (Personalisation-Zweck in CMP), Transparenz in Datenschutzerklärung, Widerspruchsrecht (Toggle in Kontoeinstellungen → Popularitätsbasiert statt personalisiert), Datenminimierung (6-Monate Trainingsfenster, alte Daten aggregieren oder löschen), Recht auf Löschung (InteractionEvent.delete_all, Cache invalidieren).
Verbindung zur Privacy-First Architektur und zum DACH-Compliance-Framework.
Was ich zuerst bauen würde
Woche 1: Event-Tracker deployen. Interaktionsdaten sammeln. Woche 2: Content-Based Model bauen und "Ähnliche Produkte" deployen. Woche 4-6: Collaborative Filtering trainieren und Hybrid deployen. Woche 8: A/B-Testing hinzufügen und Umsatzimpact messen. Laufend: Wöchentlich neutrainieren, Metriken überwachen, Gewichtungsverhältnis tunen.