Erstellen einer benutzerdefinierten „Empfehlungsmaschine” in 10 Zeilen SQL

Empfehlungsmaschinen basieren nicht immer auf KI oder maschinellem Lernen. In vielen Fällen reichen ein paar gut geschriebene SQL-Abfragen aus, um Produkte zu finden, die Kunden häufig zusammen kaufen. In diesem Artikel erstellen Sie eine einfache Empfehlungsmaschine in etwa 10 Zeilen SQL mit Self-Joins und Aggregation.

Wenn Sie „Empfehlungsmaschine“ hören, denken Sie wahrscheinlich an maschinelles Lernen, Python-Notebooks und komplexe KI-Modelle. Diese Assoziation ist so verbreitet, dass wir oft vergessen, wie viele Empfehlungen in realen Systemen auf viel einfacheren Grundlagen beruhen. In der Praxis beginnt ein großer Teil der E-Commerce- und Marketingempfehlungen mit SQL und einer klaren analytischen Frage.

Einer der gängigsten Ansätze basiert auf Ko-Auftreten. Wenn zwei Produkte häufig genug zusammen in derselben Transaktion auftreten, ist diese Beziehung aus geschäftlicher Sicht bedeutsam. Diese Logik steckt hinter bekannten Mustern wie den Bereichen „Kunden kauften auch“, Produktpaketen, Cross-Selling-Vorschlägen und sogar einigen Marketing-Segmentierungsanalysen. Hier gibt es keine Vorhersagen im Sinne des maschinellen Lernens – es wird lediglich gezählt, verglichen und bewertet, was tatsächlich passiert ist.

SQL eignet sich besonders gut für diese Art von Arbeit. Mit JOIN und GROUP BYkönnen Sie Beziehungen innerhalb von Transaktionsdaten analysieren und rohe Kaufhistorien in umsetzbare Erkenntnisse umwandeln. Wenn Sie mit diesen Konzepten vertraut sind, verfügen Sie bereits über das meiste, was Sie zum Aufbau einer einfachen Empfehlungsmaschine benötigen.

In diesem Artikel erstellen Sie eine einfache Empfehlungsmaschine, die auf einer Idee basiert:
Kunden, die dieses Produkt gekauft haben, haben auch jenes Produkt gekauft.

Wir werden echte Empfehlungen allein mit analytischem SQL erstellen, ohne Python oder KI-Bibliotheken. Diese Art des Denkens ist genau das, was die SQL-Übungen für Fortgeschrittene und Profis auf LearnSQL.de vermitteln sollen.

Die geschäftliche Fragestellung

Lassen Sie uns das Problem konkretisieren.

Stellen Sie sich vor, Sie arbeiten für einen Online-Elektronikshop. Eines Ihrer meistverkauften Produkte sind kabellose Kopfhörer. Sie möchten die Produktseite verbessern, indem Sie den Kunden zeigen, welche anderen Produkte am häufigsten zusammen mit diesen Kopfhörern gekauft werden.

Die Frage lautet nun:

Welche drei anderen Produkte werden am häufigsten zusammen mit dem Produkt „Drahtlose Kopfhörer” gekauft?

Das ist eine einfache, aber sehr praktische Frage. Die Antwort kann direkt auf einer Produktseite, in Cross-Selling-Widgets oder von einem Marketingteam bei der Planung von Bundles und Werbeaktionen verwendet werden. Für einen E-Commerce-Manager oder Produktanalysten ist diese Art von Erkenntnis sofort umsetzbar.

Das Datenmodell

Um das Beispiel realistisch zu halten, nehmen wir an, Sie arbeiten mit einer typischen E-Commerce-Datenbank. Bestellungen, Produkte und gekaufte Artikel werden separat gespeichert, was analytische Abfragen sowohl flexibel als auch skalierbar macht.

Wir verwenden drei Tabellen.

transactions — Diese Tabelle speichert Informationen zu jeder abgeschlossenen Bestellung.

Jede Zeile steht für eine einzelne Transaktion eines Kunden. In realen Systemen enthält diese Tabelle oft den Zahlungsstatus, die Versandart oder die Währung, aber diese Details sind für diese Analyse nicht relevant.

products — Diese Tabelle speichert den Produktkatalog.

Diese Tabelle liefert uns lesbare Produktnamen und ermöglicht bei Bedarf eine weitere Filterung nach Kategorie oder Preis.

transaction_items – Diese Tabelle verknüpft Produkte mit Transaktionen und bildet den Kern unserer Analyse.

Jede Zeile steht für ein Produkt, das in einer Transaktion enthalten ist. Wenn ein Kunde mehrere Produkte in einer Bestellung kauft, erscheint die Transaktion in mehreren Zeilen.

Dieses Tabellendesign ist in Produktionsdatenbanken sehr verbreitet und wird auch in vielen Übungen zum LearnSQL.de verwendet. Wenn Sie genau mit dieser Art von Geschäftsdaten – also mit Bestellungen, Produkten und Transaktionsposten – praktisch arbeiten möchten, ist der Kurs „Basic SQL-Praxis: Store“ auf LearnSQL.de der logische nächste Schritt.

Die Kernidee: Selbstverknüpfung

Bevor wir dies auf Produkte anwenden, sehen wir uns ein einfaches Beispiel dafür an, was ein Self-Join eigentlich bewirkt. Ein Self-Join ist eine Verknüpfung einer Tabelle mit sich selbst.

Stellen Sie sich eine Tabelle namens „employees” mit den folgenden Spalten vor: employee_id, employee_name, manager_id. Jeder Mitarbeiter hat einen Vorgesetzten, und dieser Vorgesetzte ist ebenfalls in derselben Tabelle gespeichert. Um Mitarbeiter zusammen mit den Namen ihrer Vorgesetzten anzuzeigen, verbinden Sie keine andere Tabelle – Sie verbinden die Tabelle „employees“ mit sich selbst.

Wenn Sie dieselbe Tabelle zweimal in einer Abfrage verwenden, verlangt SQL, dass jede Kopie einen eigenen Alias hat. Ohne Aliase würde SQL nicht wissen, auf welche Instanz der Tabelle Sie sich beziehen. Am besten wählen Sie Aliase, die die Rolle jeder Kopie in der Abfrage widerspiegeln, und nicht nur kurze technische Bezeichnungen.

In diesem Beispiel:

• e – steht für den Mitarbeiter
• m – den Manager

Hier ist die Abfrage:

SELECT
    e.employee_name,
    m.employee_name AS manager_name
FROM employees e
JOIN employees m
    ON e.manager_id = m.employee_id;

Schauen wir uns an, wie das funktioniert.

SQL liest die employees Tabelle zweimal. Beim ersten Mal behandelt es die Zeilen als Mitarbeiter (e). Beim zweiten Mal behandelt es dieselben Zeilen als Manager (m). Die JOIN Bedingung verbindet die beiden Rollen, indem sie die manager_id mit der des Managers employee_id. Dadurch wird jede Mitarbeiterzeile mit der Zeile gepaart, die ihren Manager darstellt.

Wenn Selbstverknüpfungen Ihnen nicht intuitiv erscheinen, wird genau dieses Muster im Kurs „SQL-JOINs” auf LearnSQL.de ausführlich behandelt, einschließlich eines speziellen Abschnitts über Selbstverknüpfungen.

Anwendung von Self-Joins auf das Empfehlungsproblem

Um Produkte zu finden, die zusammen gekauft wurden, müssen wir Produkte innerhalb derselben Transaktion vergleichen. Das bedeutet, dass wir die transaction_items Tabelle mit sich selbst verknüpfen und jeder Kopie eine klare Rolle zuweisen. Eine Instanz repräsentiert das Produkt, das wir analysieren, und die andere repräsentiert die anderen Produkte, die in derselben Bestellung erscheinen. Das Gemeinsame transaction_id ist das, was sie miteinander verbindet.

Konzeptionell sieht das so aus:

• Die erste Instanz repräsentiert das Produkt, das uns interessiert.
• Die zweite Instanz repräsentiert die anderen Produkte in derselben Transaktion.

Hier kommt ein Self-Join zum Einsatz. Er ermöglicht es SQL, Beziehungen innerhalb desselben Datensatzes zu analysieren, indem dieselbe Tabelle aus zwei verschiedenen Perspektiven betrachtet wird.

Bevor wir die Abfrage schreiben, lassen Sie uns die Logik Schritt für Schritt skizzieren:

• Nehmen Sie alle Produkte aus einer Transaktion
• Ordnen Sie jedes Produkt anderen Produkten aus derselben Transaktion zu
• Schließen Sie die Zuordnung eines Produkts zu sich selbst aus
• Zählen Sie, wie oft jedes Produktpaar vorkommt
• Sortieren Sie die Ergebnisse nach Häufigkeit
• Geben Sie die besten Ergebnisse zurück

Diese schrittweise Aufschlüsselung entspricht genau der Vorgehensweise, die bei analytischen SQL-Problemen angewendet werden sollte. Die Syntax kommt zuletzt. Das Denken kommt zuerst.

Die Abfrage

Hier ist eine vollständige Abfrage, die alle oben genannten Schritte in etwa zehn Zeilen SQL ausführt:

SELECT
    t1.product_id AS base_product,
    t2.product_id AS recommended_product,
    COUNT(*) AS times_bought_together
FROM transaction_items t1
JOIN transaction_items t2
    ON t1.transaction_id = t2.transaction_id
   AND t1.product_id <> t2.product_id
WHERE t1.product_id = 101
GROUP BY t1.product_id, t2.product_id
ORDER BY times_bought_together DESC
LIMIT 3;

Diese Abfrage findet die drei Produkte, die am häufigsten zusammen mit dem Produkt gekauft werden 101.

Lassen Sie uns Schritt für Schritt analysieren, was hier geschieht.

Die Abfrage beginnt mit dem zweimaligen Lesen der transaction_items Tabelle zweimal. Die erste Kopie, t1, stellt das Basisprodukt dar, das wir analysieren. Die zweite Kopie, t2, die anderen Produkte, die in derselben Transaktion vorkommen. Indem wir jeder Kopie einen eindeutigen Alias geben, machen wir ihre Rollen klar und halten die Abfrage lesbar.

Die JOIN Bedingung verbindet Zeilen aus beiden Kopien mithilfe von transaction_id. Dadurch wird sichergestellt, dass nur Produkte verglichen werden, die in derselben Bestellung gekauft wurden. Die zusätzliche Bedingung t1.product_id <> t2.product_id verhindert, dass ein Produkt mit sich selbst abgeglichen wird, was zu sinnlosen Paaren in den Ergebnissen führen würde.

Die WHERE Klausel beschränkt die Analyse auf ein bestimmtes Produkt. In diesem Fall t1.product_id = 101 bedeutet dies, dass wir fragen: Wenn das Produkt 101 in einer Transaktion auftaucht, welche anderen Produkte erscheinen dann daneben? Dadurch wird aus einer allgemeinen Co-Occurrence-Abfrage eine konkrete Empfehlungsmaschine für ein einzelnes Produkt.

Als Nächstes GROUP BY die Ergebnisse nach Produktpaaren: dem Basisprodukt und dem empfohlenen Produkt. Für jedes einzelne Paar COUNT(*) wie oft diese Kombination in allen Transaktionen vorkommt. Diese Zahl steht für die Stärke der Beziehung zwischen den beiden Produkten.

Die ORDER BY Klausel sortiert diese Paare vom häufigsten zum seltensten, und die LIMIT behält nur die drei besten Ergebnisse. Dies sind die drei Produkte, die am häufigsten zusammen mit dem Produkt 101.

Das Ergebnis ist einfach, aber leistungsstark: eine Rangliste verwandter Produkte, die vollständig auf dem tatsächlichen Kaufverhalten basiert. Keine Vorhersagen, keine Modelle – nur SQL, das eine klare analytische Idee ausdrückt. Das ist Ihre Empfehlungsmaschine.

So lesen Sie das Ergebnis

Die Ausgabe der Abfrage sieht wie folgt aus:

Jede Zeile stellt eine Empfehlung für das Basisprodukt dar.

In diesem Beispiel wurde Produkt 101 (kabellose Kopfhörer) am häufigsten zusammen mit Produkt 102 (Handyhülle) gekauft. Der Wert in times_bought_together zeigt, wie viele Transaktionen beide Produkte enthielten. Je höher die Zahl, desto stärker ist die Beziehung zwischen den beiden Produkten.

Dieses Ergebnis kann direkt in Dashboards, Berichten oder Anwendungslogik verwendet werden, beispielsweise um einen Abschnitt „Kunden kauften auch“ auf einer Produktseite zu erstellen oder um einem Marketingteam bei der Entscheidung zu helfen, welche Produkte gebündelt werden sollen.

So erweitern Sie dies mit mehr SQL

Sobald Sie dieses Muster verstanden haben, müssen Sie nur noch bessere Fragen stellen, um es zu erweitern, und müssen keine neuen Tools erlernen. Die Kernlogik bleibt dieselbe; Sie verfeinern lediglich, welche Transaktionen Sie betrachten und wie Sie die Ergebnisse interpretieren.

Ein häufiger erster Schritt ist das Filtern von Transaktionen nach Zeit. Möglicherweise möchten Sie Empfehlungen, die nur auf den letzten 30 Tagen oder der aktuellen Saison basieren, anstatt auf allen historischen Daten. Durch Hinzufügen einer Datumsbedingung können Sie Empfehlungen an das aktuelle Kaufverhalten anpassen, was für Marketing- und Merchandising-Entscheidungen oft relevanter ist.

Sie können die Analyse auch auf bestimmte Kundensegmente beschränken. Beispielsweise möchten Sie vielleicht sehen, welche Produkte häufig zusammen von Stammkunden, hochwertigen Kunden oder Kunden aus einer bestimmten Region gekauft werden. Dadurch wird eine allgemeine Empfehlung zu einer gezielteren, ohne die Gesamtstruktur der Abfrage zu ändern.

Das Ranking ist eine weitere natürliche Erweiterung. Anstatt sich nur auf ORDER BY und LIMITzu verlassen, können Sie Fensterfunktionen verwenden, um Empfehlungen nach Produkt oder Segment zu ordnen. Dies ist besonders nützlich, wenn Sie Empfehlungen für viele Produkte gleichzeitig generieren möchten, anstatt ein Produkt nach dem anderen zu analysieren.

Schließlich lohnt es sich oft, Produkte mit geringem Volumen auszuschließen. Produkte, die nur ein- oder zweimal zusammen gekauft wurden, stellen möglicherweise keine aussagekräftige Beziehung dar. Durch Hinzufügen eines Mindestschwellenwerts wird sichergestellt, dass Empfehlungen auf konsistenten Mustern und nicht auf zufälligen Übereinstimmungen basieren.

Alle diese Erweiterungen basieren auf analytischen SQL-Techniken: JOINs, Aggregationen, Filterung und Fensterfunktionen. Genau diese Fähigkeiten werden in den Kursen „LearnSQL.de“ für Fortgeschrittene und Profis vermittelt, in denen ähnliche Muster in realistischen Geschäftsszenarien immer wieder vorkommen.

SQL ist oft die erste Empfehlungsmaschine

Bevor Sie zu Python- oder KI-Tools greifen, lohnt es sich, inne zu halten und eine einfachere Frage zu stellen: Kann SQL dieses Problem bereits lösen? Wie dieses Beispiel zeigt, lautet die Antwort in vielen realen Geschäftsszenarien „Ja“. Mit einer klaren Fragestellung und einem soliden Verständnis von JOIN und Aggregationen reicht SQL aus, um rohe Transaktionsdaten in praktische Empfehlungen umzuwandeln.

Deshalb sind solide SQL-Grundlagen so wichtig. Wenn Sie Datenbeziehungen verstehen und diese Logik klar in SQL ausdrücken können, können Sie Lösungen entwickeln, die einen echten geschäftlichen Mehrwert bieten, ohne unnötig komplex zu sein. Um dieses Selbstvertrauen zu entwickeln, braucht es Übung in vielen realistischen Szenarien – nicht nur in einer einzigen Abfrage.

Wenn Sie noch weiter gehen möchten, erhalten Sie mit dem „Alle für immer“ SQL Plan auf LearnSQL.de Zugang zu allen aktuellen SQL-Kursen und allen neuen Kursen, die in Zukunft hinzugefügt werden. Auf diese Weise können Sie genau die in diesem Artikel behandelten Fähigkeiten aufbauen und kontinuierlich erweitern: analytisches Denken, Arbeiten mit realen Datensätzen und Umwandeln von Geschäftsfragen in klare, effektive SQL-Abfragen.