Einen Produktkonfigurator in eine Magento-Storefront einbauen, ohne das Frontend aufzublähenEinen Pr…
Conversational Commerce: was das für die Frontend-Architektur bedeutet
Conversational Commerce: was das für die Frontend-Architektur bedeutet
Wenn in Projekt-Kickoffs „Conversational Commerce" fällt, landet die Diskussion fast reflexartig bei einem Chat-Widget rechts unten auf der Seite. Das ist der falsche Startpunkt. Ein aufgesetzter Chatbot, der Fragen beantwortet und bei Bedarf an den Support weiterleitet, ist UI-Kosmetik. Conversational Commerce, wie es 2026 tatsächlich relevant wird, ist eine Architektur-Frage: Wo sitzt der Dialog-Layer im Stack, wer besitzt den Konversations-State über eine Session hinweg, und wie kommt ein Agent tatsächlich an Produktdaten und Aktionen heran, statt nur Text zu produzieren. Dieser Beitrag klärt diese drei Fragen, bevor über ein konkretes Tool gesprochen wird.
Warum das Chat-Widget die falsche Ebene ist
Ein klassisches Chat-Widget ist ein Overlay: Es lebt neben der eigentlichen Storefront, greift bestenfalls über eine schmale API auf ein paar Produktdaten zu und hat keinen strukturierten Zugriff auf den Zustand der Seite, auf der der Nutzer gerade steht. Es weiß nicht, welches Produkt gerade in der PDP offen ist, welche Filter in der PLP aktiv sind oder welche Artikel im Warenkorb liegen, es sei denn, jemand hat das mühsam nachgebaut. Damit bleibt der Dialog immer eine Zusatzschicht, kein integraler Teil der Experience.
Conversational Commerce mit Substanz kehrt das um: Der Dialog ist eine Interaktionsform innerhalb der Storefront-Architektur, nicht daneben. Das bedeutet, der Agent braucht denselben Zugriff auf Component-State, Produktdaten und Aktionen, den auch ein Klick auf einen Button hätte. Genau hier beginnt die eigentliche Architektur-Entscheidung.
Frage 1: Wo sitzt der Dialog-Layer?
Es gibt im Wesentlichen drei Orte, an denen der Dialog-Layer technisch verankert werden kann:
Serverseitig, als eigener Backend-Service. Der Chat läuft komplett getrennt vom Frontend, kommuniziert nur über eine schmale API mit der Storefront. Vorteil: einfache Integration in bestehende Systeme. Nachteil: Der Agent hat keinen echten Blick auf das, was der Nutzer im Frontend gerade sieht oder tut, ohne dass diese Informationen explizit synchronisiert werden.
Im Frontend, als eigenständige Komponente ohne Anbindung an den Component-Tree. Häufigste Umsetzung heutiger Chat-Widgets. Der Dialog läuft im Browser, aber isoliert von den übrigen Komponenten der Seite. Das erklärt, warum viele Chatbots Produktfragen beantworten können, aber keine Aktion im Warenkorb auslösen.
Im Frontend, als integraler Teil der Component-Architektur. Der Dialog-Layer ist an dieselbe Zustandsverwaltung angebunden wie PDP, PLP und Checkout. Ein Agent kann hier lesen, was im aktuellen Component-State liegt, und Aktionen auslösen, die derselben Logik folgen wie ein UI-Klick. Das ist die Voraussetzung dafür, dass ein Nutzer im Dialog sagen kann „leg das in Größe M in den Warenkorb" und das tatsächlich passiert, statt nur eine Textantwort zu bekommen.
Für Enterprise-Dev-Teams heißt das konkret: Die Entscheidung für Conversational Commerce ist keine Tool-Auswahl, sondern eine Entscheidung über die Frontend-Architektur selbst, im Composable Headless Frontend getroffen, nicht nachträglich per Script-Tag ergänzt.
Frage 2: Wer besitzt State und Kontext?
Ein Dialog, der über mehrere Nachrichten hinweg funktioniert, braucht Kontext: Was wurde bereits gesagt, welches Produkt wird gerade besprochen, welche Präferenzen hat der Nutzer in dieser Session genannt. Die Frage, wer diesen State besitzt, hat direkte Konsequenzen.
Backend-seitiger Session-State ist robust bei Seiten-Reloads und über Geräte hinweg, verlangt aber eine saubere Synchronisation mit dem, was im Frontend sichtbar ist. Ohne diese Synchronisation entsteht schnell eine Situation, in der der Agent von etwas spricht, das die Storefront-UI längst nicht mehr zeigt.
Frontend-seitiger State, direkt im selben State-Management wie der Rest der Komponenten, hält Dialog und UI konsistent, muss aber bei Page-Reloads oder Multi-Device-Sessions entweder verworfen oder gegen ein Backend gespiegelt werden.
Die belastbare Antwort ist meist eine Kombination: Kurzlebiger UI-Kontext (was gerade auf dem Bildschirm sichtbar ist) lebt im Frontend-State, langlebiger Nutzerkontext (Präferenzen, vorherige Anfragen) wird gegen ein Backend synchronisiert. Wer diese Trennung nicht bewusst trifft, baut entweder einen Agenten, der bei jedem Reload amnestisch wird, oder einen, der beliebig aus dem Takt mit der sichtbaren UI gerät.
Frage 3: Wie kommt der Agent an Produktdaten und Aktionen?
Der dritte und praktisch entscheidende Punkt: Ein Agent, der nur Text generiert, ist ein Chatbot. Ein Agent, der Produktdaten strukturiert lesen und definierte Aktionen sicher ausführen kann, ist Conversational Commerce im eigentlichen Sinn. Das setzt zwei Dinge voraus:
Strukturierter, maschinenlesbarer Zugriff auf Produktdaten. Der Agent braucht keine gescrapten HTML-Fragmente, sondern denselben strukturierten Datenzugriff, den auch die Storefront-Komponenten nutzen, inklusive Verfügbarkeit, Varianten und Preislogik direkt aus dem angebundenen Commerce-Backend.
Definierte, kontrollierte Aktionsgrenzen. Der Agent sollte nicht beliebigen Code ausführen, sondern über klar definierte Aktionen verfügen: Produkt zum Warenkorb hinzufügen, Variante wechseln, Checkout starten. Diese Aktionen laufen über dieselben Schnittstellen, die auch reguläre UI-Interaktionen auslösen, mit denselben Validierungen und denselben Berechtigungsgrenzen. Genau dieses Muster beschreiben wir ausführlicher in unserem Beitrag zu Model Context Protocol für Commerce-Frontends und in der Einordnung, wo Agenten handeln: im Browser, direkt am Component-State, oder serverseitig gegen die API.
Abgrenzung zum aufgesetzten Chatbot
Damit lässt sich die Abgrenzung klar ziehen. Ein aufgesetzter Chatbot beantwortet Fragen mit generiertem Text und verweist bei komplexeren Anliegen auf Support oder Suche. Conversational Commerce mit Architektur-Substanz liest den tatsächlichen Zustand der Storefront, kennt das Produktsortiment strukturiert und kann Aktionen auslösen, die exakt denselben Regeln folgen wie ein Klick im UI. Der Unterschied liegt nicht in der Qualität der Sprachmodelle, sondern darin, ob der Dialog-Layer architektonisch angebunden ist oder nur oberflächlich aufgesetzt wurde.
Unsere Einschätzung
Conversational Commerce wird 2026 oft als reine Produktentscheidung verkauft: "Welches Chat-Tool integrieren wir." Das unterschätzt, dass die eigentliche Arbeit im Frontend-Layer passiert. Wer den Dialog als Interaktionsform in die bestehende Component-Architektur einbettet, statt ihn als Overlay zu ergänzen, kann Agenten bauen, die tatsächlich handeln, nicht nur antworten. Das betrifft in erster Linie Enterprise-Dev-Teams, die die technische Grundentscheidung treffen, hat aber direkte Konsequenzen für Product- und Marketing-Owner, die am Ende definieren, welche Aktionen ein Agent im Namen eines Nutzers ausführen darf. Wer diese Fragen früh klärt, vermeidet, dass Conversational Commerce am Ende ein Chat-Widget bleibt, das niemand ernsthaft nutzt, weil es nichts wirklich kann.
Häufige Fragen
Reicht ein bestehendes Chat-Tool nicht aus, um Conversational Commerce umzusetzen?
Für einfache Q&A-Anwendungsfälle ja. Sobald der Agent Produktdaten kennen und Aktionen wie Warenkorb-Änderungen auslösen soll, braucht es eine echte Anbindung an den Frontend-State und die Commerce-API, nicht nur ein Chat-Widget on top.
Muss der Dialog-Layer im Frontend oder im Backend liegen?
Beides in Kombination: kurzlebiger UI-Kontext im Frontend-State, langlebiger Nutzerkontext synchronisiert gegen ein Backend. Eine reine Backend-Lösung ohne Frontend-Anbindung verliert den Bezug zum sichtbaren Zustand der Seite.
Welche Rolle spielt das Commerce-Backend dabei?
Das Backend bleibt die Quelle für Produktdaten, Preislogik und Bestellabwicklung. Der Dialog-Layer im Frontend liest diese Daten strukturiert und löst Aktionen über dieselben Schnittstellen aus, die auch die reguläre Storefront-UI nutzt.
Ist das nur für B2C-Storefronts relevant?
Nein. Gerade im B2B-Kontext, mit komplexen Sortimenten und Staffelpreisen, kann ein Dialog, der strukturiert auf Produktdaten und Konfigurationslogik zugreift, den Weg zur Bestellung deutlich verkürzen.
Nächste Schritte
Wenn ihr gerade entscheidet, wie Conversational Commerce in eure Frontend-Architektur passt, buche eine 30-Minuten-Demo und wir zeigen, wie ein Dialog-Layer aussieht, der direkt an Component-State und Produktdaten angebunden ist.
Weitere Themen aus der Laioutr-Plattform
Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich täglich mit der Frage, wie Frontend-Architektur Agenten befähigt, echte Aktionen auszulösen, statt nur Text zu produzieren.