Dynamische Produktempfehlungen in Magento 2: Profile statt starrer Beziehungen

In vielen Magento-2-Projekten beginnt das Thema Produktempfehlungen mit einer einfachen Annahme: Dem Kunden sollen auf der Produktseite, im Warenkorb oder im Checkout einige zusätzliche Produkte angezeigt werden. Das Problem zeigt sich jedoch sehr schnell. Die Standardmechanismen related, upsell und cross-sell in Magento sind nützlich, erweisen sich in der Praxis aber häufig als zu starr für reale Implementierungsanforderungen.

Ein Shop möchte schließlich nicht an jeder Stelle und in jedem Fall dieselben Produkte ausspielen. Für ein simples Produkt wird ein anderes Szenario benötigt als für ein Configurable-Produkt, für eine saisonale Kampagne wiederum ein anderes und noch ein anderes für einen Warenkorb mit mehreren unterschiedlichen Produkten. Aus Sicht von Agenturen und Implementierungsteams bedeutet das meist eines: Es entstehen Ausnahmen, individuelle Bedingungen und weitere Code-Schichten, die immer schwerer zu warten sind.

Kowal_RelatedProductsProfiles wurde genau dafür entwickelt, dieses Problem anders zu lösen. Statt die Logik auf einzelne, manuell verknüpfte Produktbeziehungen aufzubauen, führt das Modul das Konzept eines Empfehlungsprofils ein. Das Profil beschreibt, wo es wirken soll, unter welchen Bedingungen es startet, wie Produkte ausgewählt werden und wie sie gerendert werden. Dadurch werden Empfehlungen zu einer konfigurierbaren Schicht und nicht zu einer weiteren Sammlung einmaliger Sonderfälle im Projektcode.

Das Modul ist hier verfügbar: Automatic related products for Magento 2.

Warum Standardlisten in Magento oft nicht ausreichen

Native related-, upsell- und cross-sell-Listen funktionieren gut in einfachen Shops oder dort, wo das Merchandising vom E-Commerce-Team manuell gepflegt wird. In realen Implementierungen tauchen aber sehr schnell Szenarien auf, die das Standardmodell nicht abdeckt:

• Empfehlungen nur für eine ausgewählte Kundengruppe anzeigen,
• eine bestimmte Liste nur in einem definierten Datumsbereich aktivieren,
• Produkte auf Basis von Katalogattributen statt manueller Beziehungen verknüpfen,
• anderes Verhalten auf der PDP, anderes im Warenkorb und anderes im Checkout,
• eine Liste an einer konkreten Stelle im Theme-Layout einhängen, ohne die ganze View umzuschreiben,
• native Magento-Listen teilweise oder vollständig durch projektbezogene Logik ersetzen.

Für Agenturen bedeutet das normalerweise zwei Probleme. Erstens muss der Standardmechanismus mit zusätzlichen Bedingungen erweitert werden. Zweitens erzeugt jede weitere fachliche Anforderung einen eigenen Sonderfall. Irgendwann entsteht statt eines konsistenten Empfehlungsmechanismus ein Bündel unverbundener Workarounds.

Profile als Schicht der Merchandising-Logik

Die wichtigste Idee hinter dem Modul ist es, sich vom Denken in einzelnen Produktlisten zu lösen und dieses Modell durch ein Empfehlungsprofil zu ersetzen.

Das Profil ist eine eigenständige Konfigurationseinheit. Es definiert:

• wo es wirken soll,
• für welchen Store und welche Kundengruppe es aktiv ist,
• welches Produkt als Kontext dienen soll,
• wann das Profil gestartet werden soll,
• wie Kandidaten ausgewählt werden,
• wie das Ergebnis eingegrenzt wird,
• wie Produkte sortiert werden,
• wie sie angezeigt werden,
• und ob sie zusätzlich die nativen Listen von Magento speisen sollen.

Aus Implementierungssicht ist das ein deutlicher qualitativer Sprung. Statt für jedes Placement eigenen Custom Code vorzubereiten, lässt sich ein Set von Profilen aufbauen, das verschiedene Business-Szenarien abbildet. Dieses Modell ist leichter zu warten, einfacher zu erweitern und deutlich lesbarer für Teams, die nach dem Go-live mit dem Projekt arbeiten.

Wo das Modul in Implementierungen echten Mehrwert liefert

Der naheliegendste Einsatzort ist die Produktseite. Genau dort möchte man am häufigsten Produkte aus derselben Kollektion, mit ähnlichem Stil oder aus derselben Kommunikationslinie zeigen. In der Praxis ist die PDP aber nur selten der einzige Ort, an dem Empfehlungen sinnvoll sind.

Der Warenkorb eröffnet ein ganz anderes Szenario. Hier geht es nicht mehr um Inspiration, sondern darum, den Warenkorbwert zu erhöhen. In diesem Bereich funktionieren Profile gut, die Zubehör, Ergänzungen, günstigere Add-ons oder Produkte aus einer anderen Sortimentsbasis vorschlagen, die aber weiterhin zu dem passen, was der Kunde bereits ausgewählt hat.

Der Checkout ist eine weitere Phase, die mit Vorsicht behandelt werden sollte. Nicht jeder Shop möchte dort Merchandising ausbauen, doch für manche Implementierungen kann das ein guter Ort für eine kurze, einfache Produktliste zur Unterstützung des AOV sein, vorausgesetzt Logik und Rendering bleiben streng kontrolliert.

Damit enden die Möglichkeiten des Moduls nicht. Ein Profil kann zusätzlich die nativen Magento-Blöcke speisen:

• Related Products,
• Upsell Products,
• Crosssell Products.

Wichtig ist, dass sich die Integration nicht auf ein einfaches Ersetzen der Liste beschränkt. Für jeden dieser Mechanismen kann entschieden werden, ob die Profilergebnisse zu den nativen Produkten hinzugefügt (append) oder vollständig an deren Stelle gesetzt (replace) werden sollen. Für Agenturen ist das sehr praktisch, weil sich Logik schrittweise einführen lässt, ohne sofort das gesamte Einkaufserlebnis umzuschreiben.

Wie die Modul-Logik funktioniert

Obwohl das Profilformular recht umfangreich ist, lässt sich das Wirkmodell selbst ziemlich klar beschreiben. Das Modul durchläuft jedes Mal mehrere aufeinanderfolgende Schritte.

Zuerst wird das Placement bestimmt, also der Ort, an dem das Profil ausgeführt wird. Auf der Produktseite greift eine andere Logik als im Warenkorb. Danach wird das Kontextprodukt ausgewählt. Auf der PDP ist das meist das aktuelle Produkt, während im Warenkorb und im Checkout festgelegt werden muss, welches Produkt aus der Quote zum Bezugspunkt wird.

Sobald das Modul den Kontext kennt, prüft es die Aktivierungsbedingungen. Das ist der erste Filter, der die Frage beantwortet: Soll dieses Profil in der aktuellen Situation überhaupt ausgeführt werden?

Wenn die Bedingungen erfüllt sind, wechselt das Modul zu den Matching Rules. Dort findet die eigentliche Zuordnung statt. Attribute des Kontextprodukts werden auf Attribute potenzieller Zielprodukte abgebildet, um Produkte aus derselben Kollektion, Serie, Grafik, Kategorie oder einer anderen fachlich relevanten Eigenschaft zu finden.

Nach dem Matching kann das Ergebnis noch mit statischen Ziel-Filtern eingegrenzt werden. Das ist ein bequemer Ort, um die Liste auf bestimmte Produkttypen, Sichtbarkeiten, Statuswerte oder sogar ausgewählte Produktbasen zu begrenzen.

Am Ende werden die Produkte sortiert, auf das Limit gekürzt und entweder an einer separaten Stelle im Layout oder in nativen Magento-Blöcken gerendert.

In der Praxis bedeutet das, dass sich das Modul nicht auf eine einzelne Produkt-zu-Produkt-Beziehung stützt, sondern auf eine Abfolge von Entscheidungen, die sich aus dem Adminpanel steuern lassen.

Neues Profil anlegen: wie die Arbeit mit dem Formular aussieht

Die größte Stärke des Moduls zeigt sich erst dann, wenn man das Profilformular nicht als Liste einzelner Felder betrachtet, sondern als Werkzeug zur Modellierung eines Merchandising-Szenarios.

Der Prozess beginnt mit dem allgemeinen Bereich. Name ist die administrative Bezeichnung, die dem Team hilft, das Profil im Backend zu finden. Code ist der technische Identifikator. Genau dieser Wert sollte in Logs, in der Projektkommunikation und in der Implementierungsdokumentation verwendet werden. Enabled erlaubt es, ein Profil schnell zu deaktivieren, ohne die Konfiguration zu löschen, und Sort Order entscheidet über die Reihenfolge, in der Profile innerhalb desselben Placements ausgewertet werden.

Der zweite Bereich betrifft den Geltungsbereich. Hier werden Placements, Store Views und Kundengruppen ausgewählt. Aus Implementierungssicht ist das sehr wichtig, weil sich damit ein Mechanismus beibehalten und gleichzeitig das Verhalten zwischen Shops, Sprachen oder Kundensegmenten unterscheiden lässt.

Besonders wichtig ist das Feld Context Strategy. Auf der Produktseite ist die Sache einfach, weil das Modul mit dem aktuellen Produkt arbeitet. Im Warenkorb und im Checkout muss jedoch festgelegt werden, welcher Quote-Eintrag den Kontext bildet. In der Praxis kann das das erste Produkt, das zuletzt hinzugefügte Produkt oder das teuerste Produkt sein. Dieses scheinbar kleine Feld hat einen sehr großen Einfluss auf das Endergebnis, besonders in Warenkörben mit mehreren unterschiedlichen Positionen.

Die Felder From Date und To Date erlauben es, ein Profil auf ein bestimmtes Zeitfenster zu begrenzen. Dadurch kann dasselbe Modul auch saisonale Kampagnen und kurzfristige Verkaufsaktionen abbilden, ohne dass separate Schalter eingebaut werden müssen.

Activation Conditions, Matching Rules und Target Product Filters

Genau diese drei Bereiche sind für die fachliche Logik des Moduls verantwortlich.

Activation Conditions sollten als Einstiegsschicht verstanden werden. Hier definieren wir, wann ein Profil überhaupt aktiv werden soll. Wenn ein Profil zum Beispiel nur für Produkte aus einer bestimmten Basis, Marke oder mit einer konkreten Katalogsichtbarkeit gelten soll, dann gehören diese Bedingungen genau hierhin.

Matching Rules sind das Herzstück des gesamten Mechanismus. Sie übertragen Eigenschaften des Kontextprodukts auf die Zielprodukte. Praktisch bedeutet das, dass man dem Modul sagen kann: Finde Produkte mit derselben Grafik, derselben Kollektion, derselben Kategorie oder einem anderen Attribut, das fachlich sinnvoll ist.

Besonders wichtig sind hier zwei Felder: Required und Empty Value Policy.

Required entscheidet, ob eine Regel verpflichtend ist. Wenn sie aktiviert ist, verwirft ein fehlendes Match den Kandidaten. Wenn sie deaktiviert ist, arbeitet die Regel eher als zusätzliche Eingrenzung, aber ein Mismatch blockiert nicht das gesamte Ergebnis. In der Praxis ist das besonders wichtig bei Projekten, in denen der Kontext auf der PDP und im Warenkorb unterschiedlich aussehen kann, etwa bei einem Configurable Parent auf der Produktseite und einem Simple Child in der Quote.

Empty Value Policy sagt dem Modul, was passieren soll, wenn das Kontextprodukt im Quellattribut keinen Wert besitzt. Die Regel kann übersprungen, als fehlgeschlagen gewertet oder mit einem Standardwert ausgeführt werden. Dieses Feld entscheidet oft darüber, ob ein Profil in einem komplexen Katalog mit verschiedenen Produkttypen stabil bleibt.

Target Product Filters bilden die letzte Eingrenzungsschicht. Sie arbeiten nicht mehr auf der Beziehung Kontext-Kandidat, sondern direkt auf den Zielprodukten. Das ist ein guter Ort, um Status, Sichtbarkeit, Produkttyp oder die Einschränkung auf ausgewählte Sortimentsfamilien durchzusetzen.

Sortierung und Präsentation

Aus Implementierungssicht ist nicht nur wichtig, welche Produkte gefunden werden, sondern auch in welcher Reihenfolge und in welcher Form sie angezeigt werden.

Das Modul erlaubt die Definition eines primären und eines sekundären Sortierattributs. Dadurch lassen sich besser vorhersagbare Listen aufbauen, statt sich ausschließlich auf das Standardverhalten der Collection zu verlassen.

Auf der Präsentationsseite stehen verschiedene Rendering-Varianten zur Verfügung, darunter grid, slider und compact. So lässt sich eine Liste an den verfügbaren Platz auf der Seite anpassen, ohne eigene Profiltypen nur für geändertes Markup oder Layout bauen zu müssen.

Wichtig ist auch, dass das Profil Elemente wie die folgenden unabhängig steuern kann:

• Preis,
• regulärer Preis,
• In-den-Warenkorb-Button,
• Produktname,
• Kurzbeschreibung,
• Bildrolle.

In der Praxis bedeutet das, dass dieselbe Empfehlungs-Engine sowohl für umfangreichere Bereiche auf der PDP als auch für kompaktere Listen im Warenkorb oder Checkout verwendet werden kann.

Einspeisung nativer Magento-Listen

Eine der interessanteren Funktionen des Moduls ist die Möglichkeit, native Magento-Blöcke zu speisen. Das ist besonders wichtig für Agenturen, die das bestehende Frontend nicht sofort umbauen möchten oder an Projekten arbeiten, bei denen ein Teil des Shops weiterhin auf klassischen related-, upsell- und crosssell-Listen basiert.

In einem solchen Szenario muss das Profil nicht als eigener Block gerendert werden. Es kann an die native Liste angebunden werden und in einem von zwei Modi arbeiten.

Der Modus append belässt die nativen Produkte und ergänzt sie um die Ergebnisse des Profils. Das ist eine gute Lösung für Setups, in denen das E-Commerce-Team weiterhin einen Teil der manuell gepflegten Beziehungen behalten möchte, gleichzeitig aber eine zusätzliche Automatisierungsschicht braucht.

Der Modus replace geht einen Schritt weiter und ersetzt die native Liste vollständig durch die Profilergebnisse. Das ist besonders interessant für Shops, die Beziehungen nicht mehr manuell verwalten wollen und erwarten, dass die Profillogik zum zentralen Empfehlungsmechanismus wird.

Diese Architektur bietet viel Flexibilität in der Implementierung. Man kann das Modul schrittweise einführen, zunächst native Listen erweitern und erst später die volle Kontrolle über sie übernehmen.

XML als Schicht für flexible Einbindung

Aus Sicht der Implementierung ist wichtig, dass das Modul nicht bei der Logik zur Produktauswahl endet. Genauso wichtig ist die Kontrolle darüber, an welcher Stelle die Produkte gerendert werden.

Genau deshalb besitzt das Profil XML-Felder, die einzelnen Placements zugeordnet sind. Sie erlauben es, das Profilergebnis in einen konkreten Container oder unter einen bestimmten Layout-Block einzubetten, ohne ein separates Modul nur für die Platzierung der Liste bauen zu müssen.

In der Praxis ist das besonders wichtig bei der Arbeit mit individuellen Themes. Jedes Frontend hat seine eigene Layout-Struktur. Manche Themes verschieben die Produktbeschreibung in einen anderen Parent, andere bauen eigene Wrapper, wieder andere gestalten native Produktblöcke von Magento fast vollständig um. Die Möglichkeit, das Placement über XML zu steuern, ist hier ein großer Vorteil.

Genau diese Schicht macht das Modul nicht nur zu einer Empfehlungs-Engine, sondern auch zu einem Integrationstool. Für Agenturen ist das eine echte Zeitersparnis, weil sich die Einbindungsart an ein konkretes Projekt anpassen lässt, ohne die Kernlogik anzutasten.

Beispielhafte Implementierungsszenarien

Das einfachste Szenario ist die klassische Empfehlung "gleiche Kollektion, andere Basis". Ein Profil kann sich für ein Produkt aus einer bestimmten Basis aktivieren und auf Grundlage von Matching Rules Produkte mit derselben Grafik finden, die jedoch bereits zu einer anderen Sortimentsfamilie gehören. So kann der Shop Sets promoten oder den Kauf um weitere Produkttypen erweitern, ohne manuelle Beziehungen aufzubauen.

Das zweite Szenario sind Zubehör- oder Ergänzungsprodukte im Warenkorb. In diesem Fall kann der Kontext das erste oder das teuerste Produkt aus der Quote sein, während Target Filters das Endergebnis auf Produkte eingrenzen, die als Erweiterung des Einkaufs sinnvoll sind. Das ist besonders nützlich dort, wo das Standard-Cross-Sell von Magento nicht genug Kontrolle bietet.

Das dritte Szenario sind saisonale Kampagnen. Ein Profil kann nur in einem ausgewählten Datumsbereich, nur für bestimmte Store Views und nur für ausgewählte Kundengruppen laufen. Aus Sicht des Implementierungsteams bedeutet das, dass sich die Kampagne innerhalb desselben Mechanismus umsetzen lässt, ohne ein separates Promotionsmodul zu bauen.

Das vierte Szenario ist die teilweise oder vollständige Ersetzung nativer Upsells. Das ist besonders interessant für Shops mit großem Sortiment, vielen Katalogmerkmalen und dem Wunsch, keine manuellen Produktbeziehungen pflegen zu müssen.

Warum dieser Ansatz in der Projektwartung gut skaliert

Für Agenturen lautet die wichtigste Frage nicht nur "funktioniert es", sondern auch "lässt es sich in einem halben Jahr noch gut warten"?

Genau hier hat der profilbasierte Ansatz seinen größten Vorteil. Die Logik ist nicht über separate Observer, Plugins und dedizierte Klassen für einzelne Fälle verstreut. Stattdessen gibt es ein Konfigurationsmodell und eine Empfehlungs-Engine, die sich schichtweise weiterentwickeln lassen.

Dieses Setup bringt mehrere Vorteile:

• die Übergabe des Projekts in die Wartung ist einfacher,
• neue Szenarien lassen sich leichter ergänzen, ohne bestehende umzuschreiben,
• das Verhalten von Profilen lässt sich leichter diagnostizieren, weil die Logik an einer Stelle konzentriert ist,
• dank der XML-Schicht ist die Arbeit mit individuellen Frontends einfacher,
• fachliche Entscheidungen lassen sich leichter von Implementierungsdetails trennen.

In der Praxis bedeutet das, dass das Modul einer Agentur nicht nur neue Möglichkeiten in der Implementierungsphase gibt, sondern auch eine sinnvolle Basis für die weitere Entwicklung des Projekts schafft.

Zusammenfassung

Kowal_RelatedProductsProfiles ist nicht nur ein Mechanismus, um auf einer Seite eine weitere Produktliste anzuzeigen. Es ist ein Werkzeug zur Gestaltung von Empfehlungsszenarien in Magento 2.

Für Implementierungsteams und Agenturen sind vor allem drei Dinge wichtig. Erstens erlaubt das Modul, Empfehlungslogik auf Profilen statt auf einmaligen Sonderfällen aufzubauen. Zweitens gibt es Kontrolle über Placement, Kontext, Produktauswahl und Rendering. Drittens passt es gut zu realen Projektbedingungen, in denen Business-Erwartungen, Theme-Einschränkungen und die Notwendigkeit weiterer Shop-Entwicklung miteinander in Einklang gebracht werden müssen.

Wenn ein Projekt mehr verlangt als einfache, manuell verknüpfte Produktbeziehungen, bietet dieses Modell deutlich mehr Freiheit als die Standardmechanismen von Magento. Und genau darin liegt sein größter Wert.