Viele Unternehmen sitzen auf wertvollen Daten, ohne sie zu nutzen. Mit den richtigen Werkzeugen lassen sich daraus Erkenntnisse gewinnen, die direkt in strategische Entscheidungen einfließen.
90 % der Kunden, die einen bestimmten Teelichthalter kauften, bestellten auch eine Etagere.
Diese Information steckte die ganze Zeit in den Daten – aber erst die richtige Analysemethode machte sie sichtbar.
Für dieses Projekt habe ich einen realen Datensatz eines britischen Online-Händlers genommen: rund 540.000 Transaktionen, 4.335 Kunden, 3.660 Produkte. Und ihn bewusst aus drei verschiedenen Perspektiven untersucht – mit drei Datenbank-Technologien, weil jede für andere Fragestellungen optimiert ist:
- PostgreSQL (relational) → Wer sind meine wichtigsten Kunden?
- MongoDB (dokumentbasiert) → Wie sehen typische Warenkörbe aus?
- Neo4j (graphbasiert) → Welche Produkte werden zusammen gekauft?
Alle drei lassen sich in einer zentralen Analyse-Plattform wie KNIME integrieren. Nicht die Daten ändern sich – sondern die Perspektive. Und damit die Erkenntnisse.
Dieser Artikel beschreibt die Modellierungsansätze und Ergebnisse – nicht als Programmier-Tutorial, sondern als Beispiel dafür, was sich aus vorhandenen Daten herausholen lässt, wenn man die richtigen Werkzeuge kennt.
Warum drei Perspektiven statt einer?
Jede Datenbanktechnologie beantwortet andere Fragen besonders gut. Das richtige Werkzeug für die richtige Frage – das ist der Schlüssel zu schnellen Ergebnissen.
Relationale Datenbanken wie PostgreSQL sind stark bei strukturierten Auswertungen: Summen, Rankings, Gruppierungen. Die Frage „Wer sind meine Top-Kunden nach Umsatz?" ist ein Einzeiler.
Dokumentdatenbanken wie MongoDB speichern eine Bestellung als zusammenhängende Einheit statt über mehrere Tabellen verteilt. Ideal für Fragen wie: Wie groß ist ein typischer Warenkorb?
Graphdatenbanken wie Neo4j modellieren Daten als Netzwerk aus Beziehungen. Perfekt für: Kunden, die Produkt A kauften – was kauften sie noch?
Die zentrale These dieses Projekts:
Dieselben Rohdaten liefern je nach Modellierung und Technologie unterschiedliche Erkenntnisse – nicht weil die Daten anders sind, sondern weil das Denkmodell andere Fragen ermöglicht.
Abbildung 1: Derselbe Datensatz, drei Modellierungsansätze – jede Struktur beantwortet andere Fragen.
Vom Rohdatensatz zur Analyse
Datenbereinigung
Vor jeder Analyse steht die Datenqualität. Der Rohdatensatz enthielt mehrere Probleme, die typisch für reale E-Commerce-Daten sind.
Stornierungen und negative Stückzahlen machten rund 2 % der Datensätze aus. Stornierungen waren am „C"-Präfix in der Rechnungsnummer erkennbar. Zusätzlich gab es Transaktionen mit negativen Stückzahlen ohne „C"-Präfix – vermutlich Retouren oder Korrekturen. Beide wurden separiert, um Umsatzkennzahlen nicht zu verfälschen.
Fehlende Kundenzuordnungen betrafen rund 25 % der Transaktionen – vermutlich Gastkäufe. Für RFM-Analyse und Cross-Selling wurden sie herausgefiltert, da diese Methoden eine eindeutige Kundenzuordnung voraussetzen. Für die Warenkorbanalyse blieben sie erhalten, weil dort nur die Bestellung selbst zählt.
Nicht-Produkt-Einträge wie Portokosten oder Bankgebühren hatten eigene Artikelcodes und wurden entfernt – sie repräsentieren keine echten Kaufentscheidungen.
Die gesamte Bereinigung wurde mit KNIME als visueller ETL-Workflow umgesetzt – reproduzierbar und bei neuen Datenlieferungen automatisch wiederholbar.
Abbildung 2: Der KNIME-Workflow zeigt die Bereinigungsschritte und die Aufteilung der Daten für die drei Datenbanken.
Drei Modelle für denselben Datensatz
Der entscheidende methodische Schritt: Wie werden dieselben Rohdaten für die jeweilige Technologie aufbereitet?
Relational (PostgreSQL): Die Daten werden in drei normalisierte Tabellen aufgeteilt – Kunden, Produkte, Transaktionen. Jede Transaktion verweist per Fremdschlüssel auf Kunde und Produkt. Diese Struktur erzwingt Konsistenz und ermöglicht effiziente Aggregationen.
Dokumentbasiert (MongoDB): Die flachen Transaktionszeilen werden zu verschachtelten Dokumenten transformiert. Pro Bestellung entsteht ein Dokument mit allen gekauften Produkten als eingebettete Liste – der Warenkorb als natürliche Einheit, ohne JOINs.
Graphbasiert (Neo4j): Kunden und Produkte werden als Knoten dargestellt, Kaufvorgänge als gerichtete Kanten. Jede Kante trägt Attribute wie Menge und Preis. Beziehungen werden zum Kern der Datenstruktur.
Perspektive 1: Wer sind die wichtigsten Kunden? (PostgreSQL)
RFM-Analyse – die Methode in Kürze
Die RFM-Analyse bewertet jeden Kunden anhand von drei Verhaltensdimensionen:
| Dimension | Fragestellung | Aussage |
|---|---|---|
| Recency | Wann war der letzte Einkauf? | Kürzlich aktive Kunden reagieren eher auf Angebote |
| Frequency | Wie viele Bestellungen insgesamt? | Häufige Käufer sind loyaler |
| Monetary | Wie hoch ist der Gesamtumsatz? | Wirtschaftlich wertvolle Kunden identifizieren |
Jede Dimension wird in fünf Gruppen eingeteilt (Quintile). Aus der Kombination der drei Scores entstehen Kundensegmente.
Warum relational?
Die gesamte RFM-Berechnung – Aggregation, Quintil-Einteilung, Segmentzuweisung – lässt sich in PostgreSQL als eine einzige Abfrage umsetzen. Kein externer Code, keine Zwischenspeicherung, jederzeit reproduzierbar.
Wer strukturierte Transaktionsdaten hat, kommt damit innerhalb von Minuten zu einer vollständigen Kundensegmentierung.
Die Ergebnisse
Die Segmentierung der 4.335 Kunden ergab sechs Gruppen:
Abbildung 3: Kundensegmente und die Zuordnungslogik basierend auf den RFM-Scores.
Abbildung 4: Verteilung der Kundensegmente nach RFM-Analyse.
Die 867 „Sonstige"-Kunden (20 %) haben einen mittleren Recency-Score (R=3) und fallen zwischen die definierten Segmente. In der Praxis würde man diese Lücke durch feinere CASE-Regeln schließen – oder mittels datengetriebener Methoden wie K-Means-Clustering klassifizieren.
Was bedeutet das konkret?
Nur 3 % Neukunden, aber 25 % Inaktive – die aktive Kundenbasis schrumpft.
Der größte Hebel liegt bei den 15 % abwanderungsgefährdeten Kunden. Sie haben bereits eine Kaufhistorie, waren früher häufige Käufer. Gezielte Maßnahmen wie personalisierte Rabatte oder Erinnerungsmails können hier den größten ROI erzielen – weil die Akquisekosten deutlich niedriger sind als bei Neukunden.
Perspektive 2: Was steckt im Warenkorb? (MongoDB)
Der Blickwechsel
Während die RFM-Analyse den Kunden über die Zeit klassifiziert, betrachtet die Warenkorbanalyse die einzelne Bestellung als analytische Einheit: Wie viele Produkte pro Bestellung? Wie hoch der durchschnittliche Bestellwert? Welche Produkte sind Bestseller?
Warum dokumentbasiert?
In einer relationalen Datenbank muss man den Warenkorb bei jeder Abfrage aus Einzelteilen zusammensetzen – Bestellpositionen zusammenführen, Produktinformationen dazuholen. Die Abfragen werden schnell komplex und wartungsintensiv.
MongoDB geht einen anderen Weg: Jede Bestellung wird einmalig als verschachteltes Dokument aufbereitet – alle Produkte, alle Details an einer Stelle. Neue Fragestellungen? Die Dokumentstruktur lässt sich flexibel erweitern, ohne bestehende Analysen anpassen zu müssen.
Die Ergebnisse
| Kennzahl | Wert |
|---|---|
| Durchschnittliche Warenkorbgröße | 26 Artikel |
| Durchschnittlicher Bestellwert | ~514 € |
| Häufigste Warenkorbgröße | 1 Artikel (2.374×) |
| Maximale Warenkorbgröße | 1.114 Artikel |
| Warenkörbe gesamt | 20.728 |
Die Zahlen erzählen eine klare Geschichte: Obwohl der Durchschnitt bei 26 Artikeln liegt, ist die häufigste Warenkorbgröße ein einziger Artikel. Der hohe Durchschnitt wird durch wenige Großbestellungen verzerrt.
Der Händler bedient zwei fundamental verschiedene Kundentypen – Einzelkäufer und Großabnehmer.
Abbildung 5: Die Verteilung der Warenkorbgrößen zeigt zwei deutlich unterschiedliche Kundentypen.
Bei den Bestsellern dominiert der „White Hanging Heart T-Light Holder" mit über 2.200 Bestellungen, gefolgt von mehreren Produkten der RETROSPOT-Linie – ein Muster, das gleich in Perspektive 3 erneut auftaucht.
Perspektive 3: Welche Produkte gehören zusammen? (Neo4j)
Die Cross-Selling-Frage
Das Prinzip ist von Amazon bekannt. Technisch basiert es auf einer Graph-Traversierung: Vom Referenzprodukt über gemeinsame Kunden zu anderen Produkten – ein Zwei-Hop-Pfad.
Warum graphbasiert?
In einer Graphdatenbank sind Kunden und Produkte Knoten, Käufe sind Beziehungen. Die Cross-Selling-Frage wird zu einer natürlichen Traversierung.
In einer relationalen Datenbank bräuchte man dafür einen Self-Join auf der Transaktionstabelle – möglich, aber weder intuitiv noch performant bei wachsenden Datenmengen.
Abbildung 6: Ausschnitt des Produktnetzwerks in Neo4j – jede Verbindung zeigt, wie viele gemeinsame Käufer zwei Produkte haben.
Die Ergebnisse
Ausgehend vom Bestseller (dem Teelichthalter) zeigt die Analyse klare Produktpaare:
| Produktpaar | Gemeinsame Käufer |
|---|---|
| Teelichthalter ↔ Etagere | 3.924 |
| Teelichthalter ↔ RETROSPOT Lunch Bag | 3.780+ |
| Teelichthalter ↔ RETROSPOT Jumbo Bag | 3.700+ |
| Teelichthalter ↔ Bilderrahmen | 3.600+ |
| Teelichthalter ↔ Party-Dekoration | 3.500+ |
Bei 4.335 Kunden insgesamt bedeuten 3.924 gemeinsame Käufer:
Über 90 % aller Kunden, die den Teelichthalter kauften, bestellten auch die Etagere. Das ist kein statistisches Rauschen – das ist ein klares Signal für Produktbündelung.
Das Gesamtbild: Was keine Perspektive allein zeigt
Die eigentliche Erkenntnis liegt in der Kombination:
PostgreSQL beantwortet WER → 950 VIP-Kunden tragen den Umsatz, 1.081 sind inaktiv, 653 drohen abzuwandern.
MongoDB beantwortet WAS → Die meisten Bestellungen sind Einzelkäufe – obwohl der Durchschnitt bei 26 Artikeln liegt.
Neo4j beantwortet WIE Produkte zusammenhängen → Teelichthalter und Etagere bilden das stärkste Produktpaar. Die RETROSPOT-Linie ist über mehrere Cross-Selling-Beziehungen vernetzt.
Die RETROSPOT-Produktlinie zieht sich als roter Faden durch alle drei Perspektiven: Bestseller in der Warenkorbanalyse, Cross-Selling-Partner im Produktnetzwerk, wiederkehrendes Muster bei VIP-Kunden.
Alle drei Analysen entstanden auf Basis desselben bereinigten Datensatzes. Der Vorteil: Datenbanken mit unterschiedlichen Stärken lassen sich in KNIME gemeinsam nutzen – ohne separate Infrastruktur für jede Fragestellung.
Fazit
540.000 Transaktionen. Drei Datenbanken. Konkrete Antworten auf geschäftsrelevante Fragen.
Die Daten waren bereits vorhanden – sie mussten nur richtig ausgewertet werden. Viele Unternehmen scheuen den Aufwand, ihre Daten systematisch zu analysieren. Die richtige Kombination aus Methodik, Werkzeugen und Data-Science-Know-how macht den Unterschied – und die Ergebnisse kommen schneller als erwartet.
Code & Ressourcen
Wenn Sie selbst reinschauen möchten – der komplette Code ist auf GitLab:
🔗 https://git.tellaev.de/stellaev/ecommerce-purchase-analysis
Dort finden Sie:
- Knime – Workflows als Prototyping
- Database – MongoDB, PostgreSQL, NEO4j
- Datensatz – E-Commerce-Daten
Kontakt
Fragen? Feedback? Eigene Erfahrungen teilen? Schreiben Sie mir gerne: