Magentos natives Produkt-Recommendations-Modul konfigurieren

1. Einordnung: ein Adobe-Commerce-Feature, keine Open-Source-Funktion

Das Product-Recommendations-Modul ist Teil von Adobe Commerce und steht in Magento Open Source nicht zur Verfügung, ein Unterschied, der bei Projektplanungen häufig übersehen wird. Es basiert auf Adobe Sensei, dem Machine-Learning-Dienst von Adobe, der außerhalb der eigenen Infrastruktur läuft und über eine Adobe-I/O-Anbindung mit dem Shop kommuniziert.

Damit unterscheidet sich dieses Feature grundlegend von einer selbstgebauten KI-Empfehlung, wie sie in einem anderen Artikel dieser Reihe behandelt wird, bei der Trainingsdaten, Modell und Infrastruktur vollständig in der eigenen Hand liegen. Hier übernimmt Adobe sowohl das Training als auch die Bereitstellung des Modells, der Shop liefert lediglich Katalog- und Verhaltensdaten und ruft die fertigen Empfehlungen ab.

Für Projekte ohne Adobe-Commerce-Lizenz bleibt dieses Modul irrelevant, für Projekte mit vorhandener Lizenz aber häufig die schnellste Option, um Empfehlungen ohne eigenen Entwicklungsaufwand für Modelltraining bereitzustellen.

2. Architektur und Datenfluss im Überblick

Der Datenfluss läuft in zwei Richtungen. Zum einen exportiert ein Cron-Job regelmäßig einen Katalog-Feed mit Produkt- und Kategoriedaten an Adobe, zum anderen sendet ein im Frontend eingebundenes Tracking-Skript Ereignisse wie Produktansicht, Warenkorb-Hinzufügung und Kauf an Adobe Sensei, damit das Modell aus dem tatsächlichen Nutzerverhalten lernt.

Die eigentliche Ausspielung der Empfehlungen erfolgt clientseitig: Ein Page-Builder-Widget oder ein Layout-Block ruft zur Laufzeit die Adobe-Sensei-API auf und rendert die zurückgelieferten Produkt-IDs als Empfehlungskachel. Der Magento-Server selbst berechnet also keine Empfehlungen, er liefert nur die Rohdaten für das Training und bindet später das Ergebnis ein.

Diese Architektur hat einen direkten Performance-Vorteil gegenüber einer serverseitig berechneten Empfehlung, weil der zusätzliche API-Aufruf asynchron im Browser erfolgt und den eigentlichen Seitenaufbau nicht blockiert, solange das Widget entsprechend eingebunden wird.

3. Katalog-Feed-Export und Cron-Konfiguration

Der Katalog-Feed wird über einen dedizierten Cron-Job generiert und enthält für jedes Produkt Basisdaten wie SKU, Name, Kategoriezuordnung, Preis und Bild-URL. Der Export läuft store-spezifisch, da Sortiment, Preise und Sprache je Store unterschiedlich sein können und Adobe Sensei pro Store ein eigenes Modell trainiert.

In der Praxis lohnt es sich, den Cron-Zeitplan an die tatsächliche Änderungsfrequenz des Katalogs anzupassen. Ein Shop mit mehreren Preis- oder Sortimentsänderungen pro Tag profitiert von einem häufigeren Export, während ein stabiler B2B-Katalog mit seltenen Änderungen auch mit einem täglichen Export gut bedient ist.

<!-- app/etc/crontab.xml (Auszug, Standard-Cron-Group für den Feed-Export) -->
<job name="recommendations_update_feed" instance="Magento\ProductRecommendations\Cron\UpdateFeed" method="execute">
    <schedule>0 */6 * * *</schedule>
</job>

4. Recommendation-Typen im Admin konfigurieren

Im Admin unter Content, Elements, Product Recommendations lassen sich verschiedene Typen anlegen, darunter verwandte Produkte, zuletzt angesehene Produkte, meistverkaufte Produkte, kürzlich hinzugefügte Neuheiten und mehrere weitere, von Adobe Sensei berechnete Varianten wie häufig gemeinsam gekaufte Produkte. Jeder Typ lässt sich unabhängig aktivieren und einer bestimmten Seitenposition zuordnen, etwa der Produktdetailseite oder der Warenkorbseite.

Für jeden Recommendation-Typ lässt sich die Anzahl der angezeigten Produkte sowie ein optionaler Titeltext konfigurieren, der pro Store-View übersetzt werden kann. Wichtig ist, pro Seite nicht zu viele Typen gleichzeitig zu aktivieren, da mehrere Recommendation-Widgets auf derselben Seite jeweils eigene API-Aufrufe auslösen und sich addieren.

query ProductRecommendations($pageType: String!, $sku: String) {
  productRecommendations(pageType: $pageType, sku: $sku) {
    unit_id
    unit_name
    products {
      sku
      name
      image {
        url
      }
    }
  }
}

5. Abgrenzung zu selbstgebauten KI-Empfehlungen

Der wesentliche Unterschied zu einer selbstgebauten KI-Lösung liegt in der Kontrolle über das Modell. Adobe Sensei ist eine Blackbox, es lässt sich weder das Trainingsverfahren noch die genaue Gewichtung einzelner Signale wie Kaufhäufigkeit oder Kategoriezugehörigkeit einsehen oder anpassen, konfigurierbar sind lediglich Typ, Position und Anzeigeanzahl.

Eine selbstgebaute Lösung, etwa auf Basis eines eigenen Recommendation-Service mit vollständiger Kontrolle über Features und Trainingsdaten, lohnt sich vor allem dann, wenn spezifische Geschäftsregeln in die Empfehlung einfließen müssen, die Adobe Sensei nicht abbildet, etwa Lagerbestandspriorisierung oder Margensteuerung. Für den Standardfall verwandter Produkte oder meistverkaufter Artikel liefert das native Modul dagegen ohne Entwicklungsaufwand vergleichbare Ergebnisse.

In der Praxis schließen sich beide Ansätze nicht aus: Manche Projekte nutzen das native Modul für generische Empfehlungstypen und ergänzen gezielt einzelne, geschäftskritische Platzierungen durch eine eigene Logik.

6. Datenschutz-Implikationen des Tracking-Skripts

Da das Tracking-Skript Nutzerverhalten an einen Adobe-Dienst außerhalb der eigenen Infrastruktur überträgt, handelt es sich um eine Datenverarbeitung durch einen Drittanbieter im Sinne der DSGVO, für die eine Einwilligung des Nutzers erforderlich ist, sofern personenbezogene oder personenbeziehbare Daten wie IP-Adresse oder eine eindeutige Nutzer-ID übertragen werden.

In der Praxis bedeutet das, das Tracking-Skript muss an das bestehende Cookie-Consent-Management gekoppelt werden und darf erst nach erteilter Einwilligung geladen werden, nicht bereits beim ersten Seitenaufruf. Eine rein serverseitige, anonymisierte Auswertung ohne individuelles Tracking ist mit diesem Modul nicht vorgesehen, da Adobe Sensei auf individuelles Verhalten für das Modelltraining angewiesen ist.

Zusätzlich sollte ein Auftragsverarbeitungsvertrag mit Adobe vorliegen und in der Datenschutzerklärung des Shops explizit auf die Übertragung an Adobe-Server hingewiesen werden, inklusive des Übertragungsorts, da Adobe-I/O-Dienste teilweise außerhalb der EU verarbeitet werden können.

7. Performance und Caching der Empfehlungs-Widgets

Da die Empfehlungen clientseitig per API-Aufruf geladen werden, laufen sie unabhängig vom Full-Page-Cache und können ohne Cache-Invalidierungsprobleme auf statisch gecachten Seiten platziert werden, ein klarer Vorteil gegenüber serverseitig berechneten, personalisierten Inhalten wie Dynamic Blocks.

Der zusätzliche API-Aufruf sollte dennoch asynchron und möglichst spät im Ladeprozess erfolgen, etwa erst nachdem der sichtbare Bereich der Seite gerendert ist, um die Time to Interactive nicht zu verzögern. Ein zu früh und blockierend eingebundenes Recommendation-Widget kann trotz asynchroner Architektur die gefühlte Ladezeit spürbar verschlechtern, wenn es fälschlich synchron im kritischen Rendering-Pfad platziert wird.

8. Monitoring der Klickrate und Abgrenzung zum internen Analytics

Adobe Sensei liefert im eigenen Reporting nur aggregierte Kennzahlen zur Wirksamkeit der Empfehlungen, für eine feingranulare Auswertung im eigenen Analytics-System sollte deshalb jeder Klick auf ein empfohlenes Produkt zusätzlich als eigenes Event getrackt werden, getrennt von den Adobe-eigenen Interaktionsereignissen, die für das Modelltraining an Sensei gesendet werden.

Ein sinnvoller Ansatz ist ein Data-Layer-Event pro Klick, das die Recommendation-Unit-ID, den angeklickten Produkt-SKU und die Position innerhalb der Empfehlungsliste enthält. Damit lässt sich im eigenen Analytics-Tool auswerten, welche Recommendation-Typen tatsächlich zu Klicks und Käufen führen, unabhängig davon, was Adobe intern als Erfolg definiert, und ohne zusätzliche Kosten für ein separates Adobe-Reporting-Paket.

In der Praxis zeigt sich häufig, dass die Recommendation-Typen Meistverkauft und Häufig gemeinsam gekauft deutlich unterschiedliche Klickraten je nach Platzierung erzielen, weshalb sich ein einfaches A/B-Testing der Positionierung lohnt, bevor ein Typ dauerhaft an prominenter Stelle wie direkt unter dem Kaufen-Button verankert wird.

9. Fallstricke aus der Praxis

Ein häufiger Fehler ist ein zu selten laufender Feed-Export bei Shops mit häufigen Preisänderungen, wodurch die Empfehlungen veraltete Preise anzeigen können, bis der nächste Export durchgelaufen ist. Der Feed-Export sollte deshalb bewusst an die Änderungsfrequenz des Katalogs angepasst und nicht unreflektiert auf dem Standardwert belassen werden.

Ein zweiter Fallstrick betrifft neue Produkte ohne Interaktionshistorie, das sogenannte Cold-Start-Problem. Adobe Sensei benötigt eine gewisse Menge an Tracking-Daten, bevor produktspezifische Empfehlungstypen wie häufig gemeinsam gekaufte Produkte sinnvolle Ergebnisse liefern, weshalb neue Produkte in den ersten Wochen häufig nur in generischeren Typen wie Neuheiten erscheinen.

10. Zusammenfassung

11. FAQ: Recommendations-Modul