Ein Magento Produktkonfigurator ist selten nur „eine schönere Produktseite“. Für Unternehmen mit variantenreichen, erklärungsbedürftigen Produkten ist er ein Teil der Vertriebs- und Angebotsmaschine. Und genau deshalb scheitern viele Projekte nicht am Frontend, sondern an einer falschen Grundsatzentscheidung: Die Produkt- und Preislogik wird dort gebaut, wo sie kurzfristig am bequemsten ist, statt dort, wo sie langfristig kontrollierbar bleibt.

Dieser Artikel richtet sich an Geschäftsführung, Vertrieb und IT. Nicht als Plugin-Ratgeber, sondern als Entscheidungshilfe: Welche Architektur passt zu Ihrer Komplexität, Ihren Prozessen und Ihrer Änderungsfrequenz?

Magento kann viel.
Aber Magento ist nicht automatisch Ihr Regelwerk

Magento (Adobe Commerce) ist ein starkes Commerce- und Transaktionssystem. Es kann komplexe Kataloge abbilden, B2B-Logik unterstützen und ist technisch offen für Integrationen. Aber: Ein Shopsystem ist dafür gebaut, Produkte zu präsentieren, Preise auszuspielen, Bestellungen abzuwickeln. Es ist nicht dafür gebaut, Ihr verdichtetes Produktwissen als dauerhaftes Regelwerk zu tragen.

Sobald Sie echte Konfigurationslogik haben, also Abhängigkeiten, Ausschlüsse, Fertigbarkeit, Angebotsregeln, Preislogik jenseits von Zuschlägen, kommt die Architekturfrage auf den Tisch. Nicht später. Am Anfang.

Drei native Mechaniken, die oft überschätzt werden

Magento bringt Produktmechaniken mit, die viele Teams als „Konfigurator“ interpretieren. Sie sind hilfreich. Aber sie sind kein Ersatz für ein eigenständiges Regel- und Angebotsmodell.

1) Configurable Products: Varianten mit echter Bestandsführung

Das klassische Modell: Ein „Elternprodukt“ bündelt viele Simple Products, jede Variante hat SKU, Bestand, ggf. eigenen Preis. Sauber für Lager und Fulfillment. Gefährlich, wenn Sie in Richtung Kombinations-Explosion laufen (zu viele Varianten, zu viele Kindprodukte). Genau dann kippt Performance und Pflegeaufwand.

2) Bundle Products: Baukästen statt Varianten

Bundles sind gut, wenn Sie Komponenten zu Sets kombinieren wollen. Der Kunde stellt zusammen, Preis ist Summe plus Regeln. Das funktioniert, solange die Abhängigkeiten überschaubar bleiben und die Fertigbarkeit nicht an hundert Regeln hängt.

3) Grouped Products: Liste verwandter Artikel

Praktisch für „kauf das mit“, aber kein Konfigurationsmodell. Keine echte Regel-Engine, keine Abhängigkeiten.

Adobe Commerce B2B: Quotes und kundenspezifische Sicht

Wenn Sie Adobe Commerce (B2B) nutzen, kommen Dinge dazu, die für Konfiguration relevant sind: Verhandlungsangebote („Negotiable Quotes“) und kundenspezifische Katalog- und Preislogik („Shared Catalog“). Das ist für digitale Verhandlung und kundenspezifische Sortimente stark, ersetzt aber keine Regel-Engine für komplexe Produktlogik. (experienceleague.adobe.com)

Die zentrale Architekturfrage für jeden Magento Produktkonfigurator

Die entscheidende Frage ist nicht: „Welcher Konfigurator?“

Die entscheidende Frage ist: Wo liegen Produkt- und Angebotslogik?

Und wer darf sie ändern, wie wird getestet, wie wird versioniert, wie wird sie in Shop, Angebot und Produktion konsistent gehalten?

Wenn Sie diese Frage sauber beantworten, wird die Toolauswahl fast langweilig. Wenn Sie sie überspringen, wird jedes Tool früher oder später zum Problem.

Drei Integrationsmodelle, die Sie auseinanderhalten müssen

Modell 1: Magento-native Abbildung

Beschreibung: Sie bleiben bei Configurable/Bundle/Custom Options und erweitern minimal.

Typisches Szenario: Varianten sind endlich, Regeln sind simpel, Pflege passiert selten, Vertrieb ist nicht auf Angebotsautomatisierung angewiesen.

Vorteile: Wenig Systembrüche, niedrige Einstiegshürde, Bestände/Preise bleiben „im Shop“.

Grenzen: Bei hoher Änderungsfrequenz, echten Regelnetzen, komplexer Preislogik oder wenn Vertrieb/Produktion mehr brauchen als „Warenkorb + Bestellung“.

Modell 2: Shop-nahe Erweiterungen (Module/Extensions)

Beschreibung: Logik bleibt im Magento-Ökosystem, wird aber durch Module deutlich erweitert.

Typisches Szenario: Sie brauchen Abhängigkeiten, bessere UX, Preisdynamik, ggf. Web-to-Print, aber keine industrielle Regel- und Angebotsmaschine.

Vorteile: Schnell implementierbar, Magento bleibt die führende Oberfläche, oft gutes Kosten-Nutzen-Verhältnis.

Grenzen: Updates, Kompatibilität, langfristige Wartung. Und: Je mehr Regeln Sie im Shopkern verankern, desto teurer wird später jeder Plattformwechsel und jede Architekturmodernisierung.

Modell 3: Stand-Alone Konfigurator/CPQ mit Magento-Anbindung

Beschreibung: Magento bleibt Commerce-Frontend. Konfiguration, Regelwerk, ggf. Visualisierung, Angebot, Stückliste laufen in einem separaten System.

Typisches Szenario: Viele Regeln, hohe Änderungsfrequenz, Vertrieb braucht Angebote, Engineering/Produktion braucht Ergebnisse, Omnichannel ist relevant.

Vorteile: Entkopplung. Skalierung. Regelwerk als eigenes Produktwissen. Wiederverwendbar über Kanäle.

Grenzen: Integrationsaufwand. Governance-Fragen (wer pflegt was). Datenmodellierung muss ernst genommen werden.

Wenn Sie Produktlogik in Magento „verstecken“,
bezahlen Sie später doppelt

Produktlogik ist verdichtetes Unternehmenswissen. Da steckt Machbarkeit drin, Preislogik, Ausnahmen, Erfahrungswerte, manchmal sogar Vertragslogik. Wenn diese Logik dauerhaft in Shopmodulen oder Shopcode landet, passiert fast zwangsläufig Folgendes:

• Änderungen werden riskant, weil niemand mehr genau weiß, welche Regel wo wirkt.

• Tests fehlen oder sind manuell, weil es „nur Shoplogik“ ist.

• Fehler tauchen im Livebetrieb auf, weil die Absicherung nicht systematisch ist.

• Ein Shop-Relaunch wird zur Operation am offenen Herzen, weil Logik und Frontend untrennbar geworden sind.

Typische Fehlentscheidungen, die ich immer wieder sehe

• Plugin-Reflex: „Wir haben Magento, also nehmen wir ein Magento-Modul.“ Das ist kein Auswahlprozess, das ist Bequemlichkeit als Strategie.

• Toolauswahl nach Bestandssystem: Der Shop ist da, also muss die Logik da rein. Falsch herum gedacht.

• Nachträgliche Kopplung: Erst Frontend, dann Regeln, dann Angebot, dann ERP. Das endet fast immer in Workarounds.

• Pflege unterschätzt: Regeln ändern sich. Preise ändern sich. Sortimente ändern sich. Wenn das nicht von Anfang an als Prozess gedacht wird, wird der Konfigurator zum Dauerfeuer im Tagesgeschäft.

Klare Rollentrennung: Shop-Konfigurator vs Angebots-/CPQ-Konfigurator

Ein Shop-Konfigurator unterstützt Auswahl und Kauf. Er endet im Checkout.

Ein Angebots- oder CPQ-Konfigurator sichert Machbarkeit, Preise, Regeln. Er ist Teil des Vertriebsprozesses, oft mit Output wie Angebot, Spezifikation, Stückliste.

Wenn Sie diese Rollen vermischen, entsteht Instabilität: Der Shop soll plötzlich Dinge leisten, die eigentlich in Vertrieb, Kalkulation, Engineering oder Produktion verankert sind.

Marktübersicht: Plugins und Stand-Alone-Systeme im Vergleich

Die folgende Übersicht dient der Orientierung, nicht der Vollständigkeit. Entscheidend ist meist nicht der Anbietername, sondern die Systemklasse. Und: Ohne strukturierten Auswahlprozess kaufen Sie sonst eine Oberfläche, aber nicht die passende Architektur.

Systemklasse A:
Shop-nahe Konfiguratoren und Plugins für Magento

MageWorx – Advanced Product Options

• Beschreibung: Erweiterte Optionslogik innerhalb von Magento, deutlich stärker als Standard-Custom-Options.

• Wichtigste Funktionen: Abhängigkeiten, Options-Templates, zusätzliche Darstellungsformen, Option-Management.

• Hersteller + Link: MageWorx. (www.mageworx.com/magento-2-advanced-product-options-suite.html)

Amasty – Configurable Preselect / Custom Options

• Beschreibung: Module zur UX-Optimierung bei konfigurierbaren Produkten und zur Erweiterung von Optionslogik.

• Wichtigste Funktionen: Preselect-Mechanik für konfigurierte Startzustände, Options-Erweiterungen je nach Modul.

• Hersteller + Link: Amasty. (amasty.com/configurable-preselect.html)

Aitoc – Magento 2 Extensions (Web-to-Print/Designer-Ansätze)

• Beschreibung: Erweiterungen für Personalisierung und Design-Workflows im Magento-Kontext.

• Wichtigste Funktionen: Personalisierungs- und Designer-Workflows, Upload/Design je nach Modulkonfiguration.

• Hersteller + Link: Aitoc. (www.aitoc.com/magento-2-custom-product-designer.html)

B2B Matrix/Grid Bestellungen (Beispiel aus Adobe Marketplace)

• Beschreibung: Matrix-/Grid-Darstellungen beschleunigen Variantenbestellungen, v. a. im B2B.

• Wichtigste Funktionen: Mengen über Variantenmatrix erfassen, schneller Warenkorbaufbau.

• Hersteller + Link: Hersteller abhängig vom konkreten Modul (hier: FME Extension Listing im Adobe Marketplace). (commercemarketplace.adobe.com/ulmod-module-productmatrix.html)

Systemklasse B:
Stand-Alone Produktkonfigurator- und CPQ-Systeme mit Magento-Anbindung

Threekit

• Beschreibung: Visual-Commerce-Plattform für 3D/AR und visuelle Konfiguration.

• Wichtigste Funktionen: 3D-Konfiguration, AR, Virtual Photography, Asset-orientierter Ansatz.

• Hersteller + Link: Threekit. (www.threekit.com/ecommerce-platform-integration/magento-product-configurator)

Zakeke

• Beschreibung: Cloud-Plattform für Visual Customization inkl. Virtual Try-On.

• Wichtigste Funktionen: 3D-Produktkonfiguration, AR, Virtual Try-On. (

• Hersteller + Link: Zakeke. (www.zakeke.com/adobe-commerce/)

Zoovu

• Beschreibung: Guided Selling und Produktfindung über semantische Modelle.

• Wichtigste Funktionen: Guided Experiences, semantische Übersetzung technischer Daten in verständliche Bedarfssprache.

• Hersteller + Link: Zoovu. (zoovu.com/de/visual-product-configurator)

Tacton

• Beschreibung: CPQ-Plattform für regelbasierte, komplexe Konfiguration und Integrationen in Systemlandschaften.

• Wichtigste Funktionen: CPQ, Integrations-/Connector-Ansatz, Einbindung in ERP/CRM/Commerce-Stacks.

• Hersteller + Link: Tacton. (global.tacton.com/de/)

Expivi

• Beschreibung: 3D-Konfigurator/CPQ mit expliziter Magento-Integration.

• Wichtigste Funktionen: Magento-Integration, CPQ-Brücke zwischen Shop und 3D-Konfigurator.

• Hersteller + Link: Expivi. (https://www.expivi.com/integration/magento/)

Combeenation

• Beschreibung: Konfigurator-Ansatz, Einbettung z. B. via iFrame möglich.

• Wichtigste Funktionen: Konfiguration, Angebots-/Quote-Unterstützung je nach Setup, iFrame-Einbettung.

• Hersteller + Link: Combeenation. (www.combeenation.com/integration/magento-konfigurator/)

Simplio3D

• Beschreibung: 3D-Konfigurator mit Fokus auf schnelle Erstellung und Einbindung in E-Commerce-Umgebungen.

• Wichtigste Funktionen: 3D-Konfiguration, Einbindung in Commerce-Plattformen, Baukastenansatz (laut Anbieter).

• Hersteller + Link: Simplio3D. (www.simplio3d.com/de/ecommerce-product-configurator/)

VividWorks

• Beschreibung: 3D-Konfiguration, stark im Möbelumfeld, inklusive Commerce-Anbindung.

• Wichtigste Funktionen: 3D/AR-Produktdarstellung, Guided Configuration (laut Anbieter).

• Hersteller + Link: VividWorks. (www.vividworks.com/de/integrationen/magento-konfigurator)

CanvasLogic

• Beschreibung: 3D/AR-Konfiguration und CPQ-Ansätze, enterprise-orientiert.

• Wichtigste Funktionen: 3D/AR-Konfiguration, CPQ-Funktionalität, Guided Selling (laut Anbieter).

• Hersteller + Link: CanvasLogic. (canvaslogic.de/magento-produktkonfigurator/)

Kickflip

• Beschreibung: Visual Customizer für individualisierte Produkte.

• Wichtigste Funktionen: Text/Bild-Upload, Variantenwechsel, Live-Preview, dynamische Preise (laut Anbieter).

• Hersteller + Link: Kickflip. (gokickflip.com/blog/magento-2-configurable-product)

Integration: Zwei Wege, die in Projekten wirklich relevant sind

iFrame-Einbettung

Der Konfigurator läuft als geschlossene Einheit auf der Produktseite, Kommunikation über Events zwischen Konfigurator und Magento. Das ist oft der schnellste Weg, wenn ein bestehendes Theme weiter genutzt werden soll und schnell live gegangen werden muss. Risiko: UX-Brüche, Tracking/SEO-Fragen, und häufig unterschätzte Konsistenz von Preis und Warenkorb.

Headless/API-Ansatz

Magento liefert Commerce-Funktionalität, der Konfigurator liefert Konfigurationsdaten und Ergebnisse über APIs. Das ist meist die sauberere Zielarchitektur, wenn Performance, Integrationsfähigkeit und langfristige Flexibilität im Vordergrund stehen. Voraussetzung ist allerdings eine höhere Engineering-Reife.

Preislogik und Warenkorb:
der Moment, in dem Vertrauen gewonnen oder verloren wird

In Konfigurator-Projekten gibt es eine Stelle, an der Kunden extrem empfindlich reagieren: Preis stimmt im Konfigurator, aber im Warenkorb ist er anders. Dann ist das Vertrauen beschädigt.

Wenn Preislogik im Stand-Alone-System berechnet wird, muss Magento diesen Preis übernehmen können. Wenn Preislogik in Magento liegt, muss der Konfigurator sie exakt spiegeln. Beides ist machbar. Entscheidend ist, dass diese Entscheidung früh getroffen und technisch abgesichert wird.

Beratung vor Software, ohne Verkaufsfolie

Nur weil Magento im Einsatz ist, ist eine shopnahe Lösung nicht automatisch richtig. Produkte, Prozesse und Organisation bestimmen die Architektur. Die vorgelagerte Analyse muss drei Fragen beantworten:

1. Benötigen Sie einen Shop-Konfigurator, einen Angebots-/CPQ-Konfigurator, oder beides mit klarer Trennung?

2. Wo soll das Regelwerk liegen, wer pflegt es, wie wird es getestet?

3. Welche Systeme sind führend für Produktdaten, Preise, Kundenlogik, Angebot und Produktion?

Wenn das geklärt ist, wird die Auswahl rational. Und der Magento Produktkonfigurator wird zu einem Baustein Ihrer Vertriebsarchitektur, nicht zum dauernden Sonderfall.

Fazit:
Eine Frage, die Sie vor jeder Tool-Entscheidung stellen sollten

Wenn Sie nur eine Frage mitnehmen, dann diese:

Soll Magento das Regelwerk sein, oder soll Magento das Ergebnis aus einem Regelwerk verkaufen?

Das ist die Linie zwischen „wir bauen eine Oberfläche“ und „wir bauen ein System, das Vertrieb und Betrieb dauerhaft aushalten“. Genau dort entscheidet sich, ob ein Magento Produktkonfigurator später ein Hebel ist oder ein Fass ohne Boden.