Commerce Observability 

Was nach der Implementierung gemessen werden sollte, um Probleme zu erkennen, bevor der Kunde sie sieht

In vielen E-Commerce-Projekten wird der Moment der Inbetriebnahme der Plattform als Ende der wichtigsten Phase behandelt. Der Shop funktioniert, Bestellungen laufen durch, Zahlungen sind angebunden, Integrationen wurden getestet, und das Team kann zu den nächsten Aktivitäten übergehen: Kampagnen, Angebotsentwicklung, Promotions, SEO, Marktplätze, Automatisierung und Vertriebsoptimierung. Aus geschäftlicher Perspektive bedeutet Go-live daher sehr oft den Übergang vom Projektmodus in den Wachstumsmodus.

In der Praxis beginnt der echte Test der Plattform erst nach dem Start. E-Commerce hört auf, eine vom Projektteam kontrollierte Umgebung zu sein, und beginnt mit realem Traffic, realen Kunden, realen Integrationen, realen Datenfehlern, realen Verzögerungen externer Systeme und realen Konsequenzen jeder Störung zu arbeiten. Genau dann zeigt sich, ob die Plattform nicht nur gut aussieht und den Standard-Kaufpfad unterstützt, sondern ob sie belastbar ist gegenüber Last, Integrationsfehlern, Aufgabenwarteschlangen, API-Timeouts, Zahlungsproblemen, Synchronisationsverzögerungen, fehlerhaften Produktdaten und nicht standardisierten Kaufszenarien.

Genau deshalb gewinnt Commerce Observability immer mehr an Bedeutung, also die Fähigkeit zu verstehen, was im gesamten Vertriebsökosystem wirklich passiert. Es geht nicht nur um klassisches Server-Monitoring, Verfügbarkeit der Website oder Berichte in Google Analytics. Es geht um Sichtbarkeit der Prozesse, die den Vertrieb beeinflussen: vom Einstieg des Nutzers auf die Website über Produktsuche, Hinzufügen zum Warenkorb, Checkout, Zahlung, Speicherung der Bestellung, Übergabe der Daten an ERP, Aktualisierung des Lagerbestands, Versand transaktionaler E-Mails bis hin zur Synchronisation von Dokumenten, Status und After-Sales-Informationen.

OpenTelemetry definiert Observability als die Fähigkeit, den internen Zustand eines Systems anhand seiner externen Signale wie Logs, Metriken und Traces zu verstehen. In der Praxis bedeutet das, dass das System so gestaltet und instrumentiert sein muss, dass es Daten ausgibt, die nicht nur zeigen, dass etwas kaputtgegangen ist, sondern auch wo, warum und welchen Einfluss es auf den Nutzer und das Geschäft hatte.

Für E-Commerce ist diese Unterscheidung sehr wichtig. Wenn ein Unternehmen nur einen Umsatzrückgang sieht, ist es bereits zu spät. Der Kunde hat wahrscheinlich zuvor bereits einen langsam funktionierenden Shop, einen Fehler im Warenkorb, ein Zahlungsproblem, veraltete Lagerbestandsinformationen, einen nicht funktionierenden Rabattcode oder eine fehlende Bestellbestätigung erlebt. Commerce Observability ermöglicht es, solche Probleme zu erkennen, bevor sie in Verkaufsergebnissen, Anfragen an den Kundenservice oder Kundenkommentaren sichtbar werden.

Warum dieses Thema gerade jetzt wichtig wird

Moderner E-Commerce ist keine einzelne Anwendung mehr. Die Verkaufsplattform ist heute Teil einer größeren Umgebung, in der ERP, PIM, WMS, CRM, Zahlungssystem, Kurierdienste, Marktplätze, Marketing-Automation-Tools, Suche, Empfehlungssystem, Analysetools, Data Warehouses, Headless-Frontends, mobile Anwendungen und zunehmend auch KI-Lösungen zusammenarbeiten. Jedes dieser Elemente kann für sich korrekt funktionieren, und dennoch kann der gesamte Verkaufsprozess instabil sein.

Das ist eine der größten Fallen im Management von E-Commerce nach der Implementierung. Der Server kann laufen. Die Startseite kann laden. Das Administrationspanel kann verfügbar sein. Gleichzeitig können Kunden keine Bestellung aufgeben, weil die Zahlungsintegration nur für eine ausgewählte Methode Fehler zurückgibt. Sie können veraltete Lagerbestände sehen, weil die Synchronisation mit WMS verzögert ist. Sie können den Warenkorb verlassen, weil die Lieferberechnung zu lange dauert. Sie können ein Produkt nicht finden, weil der Suchindex nicht korrekt aktualisiert wurde. Sie können keine transaktionale E-Mail erhalten, weil eine Aufgabe in der Queue auf Seite des E-Mail-Systems hängen geblieben ist.

In einer solchen Umgebung ist die klassische Frage „funktioniert der Shop?“ zu einfach. Viel wichtiger ist die Frage: „funktionieren die wichtigsten Verkaufsprozesse so, wie es Kunde und Business erwarten?“. OpenTelemetry weist darauf hin, dass Zuverlässigkeit nicht nur bedeutet, dass ein System verfügbar ist, sondern dass es das tut, was der Nutzer von ihm erwartet. Das Beispiel aus der offiziellen Beschreibung passt sehr gut zum E-Commerce: Ein System kann verfügbar sein, aber wenn ein Klick auf „Add to Cart“ nicht das richtige Produkt in den Warenkorb legt, kann man schwer von echter Zuverlässigkeit sprechen. 

Diese Denkweise ist besonders im B2B wichtig. Im Großhandel endet ein technisches Problem selten nur mit dem Verlust eines Warenkorbs. Wenn ein Geschäftskunde nicht den richtigen Preis sieht, keine Bestellung innerhalb seines Limits aufgeben kann, kein Dokument erhält, keinen Zugriff auf die Bestellhistorie hat oder die Integration mit seinem Einkaufssystem nicht funktioniert, kann er zu E-Mail, Telefon oder direktem Kontakt mit dem Vertriebsmitarbeiter zurückkehren. Dann entlastet die B2B-Plattform das Team nicht mehr, sondern schafft zusätzliche Arbeit.

Deshalb werden in den nächsten Jahren nicht nur die Unternehmen im Vorteil sein, die eine moderne E-Commerce-Plattform implementieren, sondern diejenigen, die sie nach dem Start bewusst beobachten, messen und weiterentwickeln können. In einer Welt von Integrationen, Automatisierung, Headless Commerce, KI und Agentic Commerce wird fehlende Prozesssichtbarkeit zu einem der größten operativen Risiken.

Monitoring, Analytik und Observability sind nicht dasselbe

In vielen Unternehmen wird Monitoring damit gleichgesetzt, dass jemand die Verfügbarkeit der Website, Serverlast, Speichernutzung, 500-Fehler oder Antwortzeit der Anwendung prüft. Das sind wichtige Elemente, aber sie reichen für das Management von modernem Commerce nicht aus. Monitoring sagt, dass etwas einen bestimmten Schwellenwert überschritten hat. Observability ermöglicht zu verstehen, was im gesamten Prozess passiert und wie einzelne Ereignisse miteinander verbunden sind.

E-Commerce-Analytik ist ebenfalls nicht dasselbe wie Observability. GA4, Verkaufsberichte, Kampagnen-Dashboards und Conversion-Daten zeigen Effekte des Kundenverhaltens und Geschäftsergebnisse. Sie sind notwendig, zeigen ein Problem aber häufig erst dann, wenn es den Umsatz bereits beeinflusst hat. Wenn die Conversion sinkt, sieht das Business ein Symptom. Commerce Observability sollte helfen zu verstehen, ob dieses Symptom aus einem langsamen Checkout, einem Zahlungsfehler, einem nicht funktionierenden Rabattcode, einem Warenkorbproblem, veralteten Lagerbeständen, Suchfehlern oder einer Verzögerung auf Seite eines externen Systems resultiert.

Google betont in SRE-Materialien, dass wirksames Monitoring sich vor allem auf Symptome konzentrieren sollte, die vom Nutzer wahrgenommen werden, und erst danach auf Ursachen, die zum Debugging dienen. Das ist ein sehr wichtiger Ansatz für E-Commerce, weil es aus Kundensicht keine Rolle spielt, ob das Problem aus Datenbank, Cache, Queue, Zahlungs-API oder ERP entsteht. Der Kunde sieht einfach, dass der Shop langsam ist, der Warenkorb nicht funktioniert oder die Bestellung nicht durchgeht.

Commerce Observability sollte daher drei Ebenen verbinden. Die erste ist die Ebene des Kundenerlebnisses: ob der Nutzer ein Produkt finden, es in den Warenkorb legen und eine Bestellung aufgeben kann. Die zweite ist die Ebene der Geschäftsprozesse: ob Preis, Verfügbarkeit, Zahlung, Lieferung, Dokumente und Status korrekt sind. Die dritte ist die technische Ebene: ob Anwendung, API, Queues, Cache, Datenbank, Suche und Integrationen stabil funktionieren.

Wenn ein Unternehmen nur die technische Ebene sieht, kann es Geschäftsprobleme übersehen. Wenn es nur Verkaufsanalytik sieht, kann es zu spät reagieren. Wenn es nur Kundenmeldungen sieht, handelt es erst dann, wenn das Problem bereits nach außen sichtbar ist. Observability verbindet diese Perspektiven und ermöglicht, E-Commerce als geschäftskritisches System zu verstehen.

Der größte Fehler: nur das zu messen, was leicht zu messen ist

Der häufigste Fehler besteht darin, dass ein Unternehmen misst, was am einfachsten verfügbar ist, und nicht das, was den Vertrieb wirklich beeinflusst. Es ist leicht, die allgemeine Verfügbarkeit der Website, die Zahl der Sessions, die durchschnittliche Ladezeit, die Zahl der Bestellungen, Umsatz und Conversion zu messen. Schwieriger ist zu messen, wie oft die Lieferberechnung für eine bestimmte Kundengruppe nicht funktioniert hat, wie viele Bestellungen vor der Übergabe an ERP hängen geblieben sind, wie viele Produkte inkonsistente Lagerbestände hatten, wie viele Zahlungen nicht korrekt bestätigt wurden oder wie oft ein Nutzer wegen eines Validierungsfehlers vom Checkout zum Warenkorb zurückgekehrt ist.

Gerade diese schwierigeren Metriken zeigen jedoch häufig den tatsächlichen Zustand der Plattform am besten. E-Commerce kann eine hohe technische Verfügbarkeit haben und gleichzeitig Umsatz durch Probleme verlieren, die zwischen Systemen verteilt sind. Der Checkout kann für die meisten Kunden funktionieren, aber nicht für jene, die eine bestimmte Zahlungsmethode nutzen. Die Integration mit ERP kann den größten Teil des Tages funktionieren, aber in Spitzenzeiten Verzögerungen haben. PIM kann Produktdaten synchronisieren, aber einen Teil der Attribute auslassen, die für Filter oder Marktplätze erforderlich sind. WMS kann Lagerbestände zurückgeben, aber mit einer Verzögerung, die den Verkauf nicht verfügbarer Produkte verursacht.

Genau deshalb reicht es in Commerce Observability nicht aus, Durchschnittswerte zu messen. Die durchschnittliche Antwortzeit kann gut aussehen, während der wichtigste Kaufpfad langsam ist. Die durchschnittliche Fehlerrate kann niedrig sein, aber die Fehler können die wertvollsten B2B-Kunden betreffen. Die durchschnittliche Conversion kann nur leicht sinken, aber der Verlust kann einen bestimmten Markt, Kanal, eine Liefermethode oder Promotion betreffen.

Gute Observability sollte präzisere Fragen ermöglichen. Betrifft das Problem alle Kunden oder nur eingeloggte Nutzer? Tritt es im B2B oder B2C auf? Betrifft es einen bestimmten Sales Channel? Erscheint es nur bei einer bestimmten Liefermethode? Liegt der Fehler auf Seite der Plattform, Integration, Zahlung, ERP, WMS oder des Frontends? Ist das Problem technisch, produktdatenbezogen, eine Konfiguration von Geschäftsregeln oder Kommunikation mit einem externen Anbieter?

Ohne solche Sichtbarkeit handelt das Unternehmen reaktiv. Es sieht Auswirkungen, versteht aber die Ursachen nicht. Das Business-Team meldet einen Umsatzrückgang, das technische Team prüft Logs, der Kundenservice sammelt Meldungen, und Integratoren suchen das Problem in ihren Systemen. Jeder schaut auf einen Ausschnitt. Commerce Observability sollte ein gemeinsames Bild liefern.

Was nach der Implementierung von E-Commerce wirklich gemessen werden sollte

Nach der Implementierung einer Plattform lohnt es sich, nicht nur Infrastruktur zu messen, sondern vor allem die wichtigsten Verkaufsprozesse. In der Praxis sind die Elemente am wichtigsten, die direkt die Möglichkeit zur Bestellung, die Korrektheit von Daten und die Qualität der Kundenerfahrung beeinflussen.

Der erste Bereich ist Verfügbarkeit und Performance kritischer Pfade. Es reicht nicht zu wissen, dass die Website antwortet. Man muss wissen, wie Kategorieseite, Produktseite, Suche, Warenkorb, Checkout, Kundenlogin, Registrierung, B2B-Konto, Dokumentendownload und Zahlungsfinalisierung funktionieren. Es lohnt sich, Antwortzeit, Fehlerzahl, erfolgreiche Übergänge zwischen Schritten sowie Unterschiede zwischen Märkten, Geräten, Kanälen und Kundengruppen zu messen.

Der zweite Bereich ist der Checkout. Das ist der Ort, an dem technische Fehler sehr schnell zu Umsatzverlust werden. Es lohnt sich, die Zahl der Versuche zum Übergang zur Zahlung, Validierungsfehler, fehlgeschlagene Zahlungen, Timeouts, Fehler bei Liefermethoden, nicht funktionierende Rabattcodes, Login-Probleme, abgebrochene Sessions und Bestellungen zu messen, die begonnen, aber nicht korrekt gespeichert wurden. Im B2B sind zusätzlich Limits, Rollen, Freigaben, individuelle Preise, Produktverfügbarkeit für den Kunden und Übereinstimmung der Bestellung mit Handelsbedingungen wichtig.

Der dritte Bereich sind Integrationen. Es muss nicht nur gemessen werden, ob eine Integration „funktioniert“, sondern auch Verzögerungen, Fehlerzahl, Retries, Duplikate, verlorene Nachrichten, Bestandsunterschiede, Mappingfehler und Verarbeitungszeit. Besonders wichtig sind Integrationen mit ERP, PIM, WMS, CRM, Zahlungen, Kurierdiensten, Marktplätzen und Marketing-Automation-Tools. Sie entscheiden sehr häufig darüber, ob die Plattform nur ein schöner Frontend ist oder ein tatsächlich funktionierendes Vertriebssystem.

Der vierte Bereich sind Produktdaten und Katalog. Es lohnt sich, Vollständigkeit von Attributen, PIM-Synchronisationsfehler, Produkte ohne Bilder, Produkte ohne erforderliche Daten, Variantenfehler, Indexierungsprobleme, nicht funktionierende Filter, veraltete Preise, fehlende Übersetzungen und Abweichungen zwischen Kanälen zu messen. Im modernen E-Commerce beeinflusst die Katalogqualität nicht nur UX, sondern auch SEO, Marktplätze, KI, Personalisierung, Digital Product Passport und B2B-Vertrieb.

Der fünfte Bereich sind asynchrone Prozesse. In Shopware werden viele Aufgaben asynchron in einer Queue verarbeitet, sodass sie unabhängig von Timeouts oder Ausfällen ausgeführt werden können. Beispielhafte Aufgaben umfassen den Versand von E-Mails, die Indexierung von Produkten oder die Generierung von Sitemaps. Das bedeutet, dass ein Klick im Panel oder die Ausführung einer Aktion nicht immer bedeutet, dass der gesamte Prozess bereits abgeschlossen wurde.

Der sechste Bereich ist die Qualität der After-Sales-Betreuung. Bestellbestätigungen, Rechnungen, Lieferstatus, Retouren, Reklamationen, E-Mail-Kommunikation, Aktualisierungen im Kundenkonto und Verfügbarkeit von Dokumenten beeinflussen möglicherweise nicht direkt den Moment des Kaufs, aber sie beeinflussen Vertrauen und operative Effizienz. Wenn der Kunde nach dem Bestellstatus fragen muss, weil das System keine Information gesendet hat, wird ein technisches Problem zu Servicekosten.

Checkout als wichtigster Beobachtungspunkt

Wenn ein Unternehmen einen Prozess auswählen muss, den es besonders genau beobachten sollte, sollte es der Checkout sein. Hier treffen Frontend, Warenkorb, Preise, Promotions, Steuern, Lieferung, Zahlungen, Kundendaten, Produktverfügbarkeit, Validierung, Integrationen und Bestellspeicherung aufeinander. Im B2B kommen individuelle Preislisten, Limits, Nutzerrollen, Freigabeprozesse, Kundeneinkaufsnummern, Vertragsbedingungen und häufig die Integration mit ERP hinzu.

Der Checkout ist ein Ort, an dem ein kleiner Fehler einen sehr konkreten Preis haben kann. Wenn eine Zahlungsmethode eine Stunde lang nicht funktioniert, verliert das Unternehmen Bestellungen. Wenn Lieferung für eine bestimmte Postleitzahl nicht berechnet wird, schließt der Kunde den Kauf nicht ab. Wenn der Preis im Warenkorb vom Preis auf der Produktseite abweicht, sinkt Vertrauen. Wenn ein B2B-Kunde ein falsches Limit oder falsche Bedingungen sieht, kehrt er zum Vertriebsmitarbeiter zurück. Wenn eine Bestellung bezahlt wurde, aber nicht an ERP gelangt ist, verlagert sich das Problem vom Frontend in die Operations.

Commerce Observability sollte den Checkout daher als Prozess behandeln und nicht als eine einzelne Seite. Es lohnt sich zu sehen, wie viele Personen in den Warenkorb gegangen sind, wie viele zum nächsten Schritt übergegangen sind, wie viele versucht haben, Lieferung auszuwählen, wie viele Zahlung gewählt haben, wie viele die Transaktion gestartet haben, wie viele mit einem Fehler zurückgekehrt sind und wie viele Bestellungen korrekt in der Plattform gespeichert und weitergegeben wurden. Erst ein solches Bild zeigt, wo das Problem tatsächlich entsteht.

Sehr wichtig ist auch die Unterscheidung zwischen technischen Fehlern und Geschäftsfehlern. Ein technischer Fehler ist zum Beispiel ein Zahlungs-Timeout oder eine Anwendungsausnahme. Ein Geschäftsfehler ist eine Situation, in der eine Lieferregel keine Option zurückgibt, eine Promotion die Bedingungen nicht erfüllt, der Kunde keine Berechtigungen hat, ein Produkt nicht verfügbar ist oder ein Limit überschritten wurde. Für den Nutzer können beide Fehlertypen ähnlich aussehen: Der Kauf ist fehlgeschlagen. Für das Team, das die Plattform verwaltet, ist der Unterschied entscheidend.

In einem gut gestalteten E-Commerce sollte der Checkout eigene Metriken, Alerts und Ursachenanalyse haben. Nicht, weil Technologie wichtiger als Marketing ist, sondern weil Marketing keinen Prozess repariert, der dem Kunden den Kauf nicht ermöglicht.

Integrationen als häufigste Quelle versteckter Probleme

Im modernen E-Commerce entstehen sehr viele Probleme nicht in der Plattform selbst, sondern an den Schnittstellen zwischen Systemen. Die Integration mit ERP verzögert die Speicherung der Bestellung. PIM sendet keine vollständigen Produktdaten. WMS gibt Lagerbestände verzögert zurück. CRM erhält keine Kundenaktualisierung. Das Zahlungssystem bestätigt die Transaktion, aber der Webhook wird nicht korrekt verarbeitet. Der Marktplatz nimmt das Angebot an, lehnt aber einen Teil der Produkte wegen fehlerhafter Attribute ab. Der Kurier gibt für eine bestimmte Adresse keine verfügbaren Liefermethoden zurück.

Das sind Probleme, die sich nur schwer durch klassisches Anwendungsmonitoring erkennen lassen. Der Server funktioniert, die Anwendung funktioniert, aber der Geschäftsprozess ist unterbrochen. Deshalb sollten Integrationen eine eigene Observability-Schicht haben: Kommunikationsstatus, Antwortzeit, Fehlerzahl, Queues, Retries, Duplikate, fehlgeschlagene Mappings, Datenabweichungen und Berichte über nicht zugestellte Nachrichten.

Besonders wichtig ist das Monitoring von Verzögerungen. Im E-Commerce ist nicht jeder Fehler ein sofortiger Ausfall. Manchmal ist das größere Problem, dass ein Prozess funktioniert, aber verzögert. Lagerbestände aktualisieren sich nach einer Stunde. Bestellungen gelangen nach mehreren Minuten ins ERP. Produktdaten synchronisieren sich einmal täglich, obwohl das Team Änderungen nahezu in Echtzeit erwartet. Ein B2B-Kunde sieht einen alten Preis, weil die Preisliste nicht verarbeitet wurde. Solche Probleme sind tückisch, weil das System formal funktioniert, das Business aber mit veralteten Daten arbeitet.

Genau deshalb sollten Integrationen in E-Commerce-Projekten nicht als einmalige Verbindungen behandelt werden. Sie sollten als Prozesse gestaltet werden, die beobachtet, diagnostiziert und weiterentwickelt werden können. Shopware stellt die Admin API für Backend-Operationen wie Produkte, Bestellungen, Kunden und Massenverarbeitung über die Sync API sowie die Store API für Storefront-Interaktionen wie Headless-Frontends, mobile Anwendungen, Warenkörbe, Checkout und Zugriff auf den Sales Channel bereit. Das gibt eine solide Grundlage für Integrationen, aber die reine Verfügbarkeit einer API ersetzt nicht das Monitoring von Datenflüssen.

In der Praxis sollte jede wichtige Integration mehrere Fragen beantworten. Wurden die Daten gesendet? Wurden sie empfangen? Wurden sie korrekt gemappt? Wurden sie verarbeitet? Ist das Ergebnis des Prozesses zur Plattform zurückgekehrt? Gab es einen Retry? Wurde der Fehler automatisch behandelt oder erfordert er menschliches Eingreifen? Ohne diese Informationen arbeitet das Unternehmen auf Vertrauen, nicht auf Kontrolle.

Produktdaten benötigen ebenfalls Observability

Produktdaten werden sehr häufig als Thema von PIM, Kategorie oder Merchandising behandelt. Im modernen E-Commerce ist der Produktkatalog jedoch eines der wichtigsten Elemente der Vertriebsinfrastruktur. Wenn Produktdaten unvollständig, inkonsistent oder verzögert sind, treten Probleme an vielen Stellen gleichzeitig auf: in Suche, Filtern, SEO, Marktplätzen, Empfehlungen, Kampagnen, KI, Kundenservice und B2B.

Commerce Observability sollte daher auch die Qualität von Produktdaten umfassen. Es lohnt sich zu wissen, welche Produkte nicht die erforderlichen Attribute haben, welche nicht korrekt indexiert wurden, welche fehlerhafte Varianten haben, welche keine Übersetzungen haben, welche keine Bilder haben, welche die Marktplatzvalidierung nicht bestanden haben, welche eine Abweichung zwischen PIM und E-Commerce-Plattform aufweisen und welche trotz fehlender verkaufsrelevanter kritischer Daten veröffentlicht wurden.

Im B2B ist dieses Thema noch wichtiger, weil Produktdaten häufig mit technischer Dokumentation, Zertifikaten, Ersatzteilen, Beziehungen zwischen Produkten, Kompatibilität, Maßeinheiten und individuellen Verkaufsbedingungen verbunden sind. Wenn ein Geschäftskunde ein Produkt nicht finden kann oder den Parametern nicht vertraut, meldet er nicht immer einen Fehler. Häufig kehrt er einfach zum Kontakt mit dem Vertriebsmitarbeiter zurück oder wählt einen anderen Lieferanten.

Observability von Produktdaten sollte mit dem Veröffentlichungsprozess verbunden sein. Ein Produkt sollte nicht nur deshalb als fertig gelten, weil es im System existiert. Es sollte bestimmte Qualitätsanforderungen für den jeweiligen Kanal, Markt und Kundentyp erfüllen. Andere Anforderungen kann ein Marktplatz haben, andere ein B2C-Shop, andere ein B2B-Portal, andere ein technischer Katalog und wieder andere künftige Schichten im Zusammenhang mit KI oder Digital Product Passport.

In diesem Sinne betrifft Observability nicht nur technische Fehler. Sie betrifft auch die Frage, ob die Daten, auf denen der Vertrieb basiert, gut genug sind, damit die Plattform ohne manuelle Unterstützung des Teams funktionieren kann.

Performance: nicht nur Geschwindigkeit der Website, sondern Geschwindigkeit des Prozesses

E-Commerce-Performance wird häufig auf die Ladezeit der Seite reduziert. Das ist ein wichtiger Indikator, aber nicht ausreichend. Ein Kunde kann eine schnell ladende Seite betreten und dann in einer langsamen Suche, im Warenkorb, bei der Lieferberechnung oder Zahlung stecken bleiben. In Commerce Observability muss die Geschwindigkeit ganzer Prozesse gemessen werden, nicht nur einzelner Ansichten.

In Shopware kann Performance unter anderem von Cache, Suche, Indexierung, Datenbank, Queues, Serverkonfiguration, Integrationen und der Funktionsweise des Frontends abhängen. Die offizielle Shopware-Dokumentation weist darauf hin, dass HTTP Cache das Caching von Systemantworten ermöglicht, sodass bei einer nächsten identischen Anfrage die Antwort schneller zurückgegeben werden kann, und die Performance-Dokumentation betont, dass HTTP Cache ein wichtiger Bestandteil von Produktionssystemen ist.

Für Shops mit großem Katalog haben Suche und Indexierung ebenfalls besondere Bedeutung. Shopware dokumentiert die Elasticsearch-Integration als Möglichkeit zur Verbesserung der Performance der Produkt- und Kategoriesuche, und die Hosting-Dokumentation verweist im Kontext von Search und Indexing auch auf die Nutzung von OpenSearch oder Elasticsearch.

Selbst die beste Performance-Konfiguration reicht jedoch nicht aus, wenn das Unternehmen nicht beobachtet, wie das System unter realer Last funktioniert. Es lohnt sich, nicht nur die durchschnittliche Antwortzeit zu messen, sondern auch Perzentile, Zeiten für die langsamsten Nutzer, Unterschiede zwischen Kanälen, Einfluss von Promotions, Last zu Spitzenzeiten, Suchzeit, Verarbeitungszeit des Warenkorbs, Zeit der Lieferberechnung und Zeit des Durchlaufens des Checkouts.

Im E-Commerce ist Verlangsamung selten nur ein technisches Problem. Ein langsamer Kaufprozess kann Conversion-Verlust bedeuten. Langsame Datensynchronisation kann fehlerhafte Lagerbestände bedeuten. Ein langsames Administrationspanel kann geringere Effizienz des Teams bedeuten. Langsame Queue-Verarbeitung kann Verzögerungen bei E-Mails, Indizes und After-Sales-Prozessen bedeuten. Performance ist daher Teil der Kundenerfahrung und operativen Effizienz.

Alerts, die helfen und keinen Lärm erzeugen

Viele Unternehmen haben Monitoring, das zu viele Alerts erzeugt oder auf die falschen Dinge alertet. Wenn das Team täglich Dutzende Benachrichtigungen erhält, von denen die meisten keine Handlung erfordern, hört es sehr schnell auf, sie ernst zu nehmen. Andererseits führt fehlendes Alerting für kritische Prozesse dazu, dass das Unternehmen erst vom Kunden, Kundenservice oder Vertrieb von einem Problem erfährt.

Gute Alerts im E-Commerce sollten mit dem Einfluss auf Nutzer und Business verbunden sein. Dieser Ansatz stimmt mit dem SRE-Denken überein, bei dem Alerting sich vor allem auf Symptome konzentrieren sollte, die aus Nutzersicht relevant sind, und nicht ausschließlich auf technische Ursachen.

Das bedeutet, dass nicht jeder Anstieg der CPU-Nutzung das Team nachts wecken muss, die fehlende Möglichkeit zur Bestellung jedoch schon. Nicht jeder einzelne Integrationsfehler erfordert einen Alarm, aber eine wachsende Zahl von Bestellungen, die nicht an ERP übergeben wurden, sollte schnell erkannt werden. Nicht jede Verzögerung in der Queue ist kritisch, aber eine Verzögerung, die transaktionale E-Mails, Produktindexierung oder Aktualisierung der Verfügbarkeit beeinflusst, kann realen Einfluss auf Vertrieb und Kundenservice haben.

Die besten Alerts sind verständlich. Sie sollten nicht nur sagen, dass etwas passiert ist, sondern auch, welcher Prozess betroffen ist, welcher potenzielle geschäftliche Einfluss besteht und wo die Diagnose beginnen sollte. Ein Alert „Anstieg von API-Fehlern“ ist weniger nützlich als die Information, dass die Zahl der Fehler bei der Lieferberechnung für einen bestimmten Sales Channel wächst. Ein Alert „Queue wächst“ ist weniger nützlich als die Information, dass eine Queue-Verzögerung die Produktindexierung und Veröffentlichung eines neuen Angebots beeinflusst.

Commerce Observability besteht also nicht darin, alles zu messen und über alles zu alarmieren. Sie besteht darin, ein Sichtbarkeitsmodell aufzubauen, das dem Team hilft, Prioritäten schneller zu verstehen. Im E-Commerce lautet die wichtigste Frage nicht nur „was ist kaputtgegangen?“, sondern „kann der Kunde kaufen, wird die Bestellung bearbeitet und kann das Business ohne manuelle Umgehung des Problems funktionieren?“.

Observability im B2B-E-Commerce

Im B2B hat Observability besondere Bedeutung, weil Verkaufsprozesse komplexer und Probleme weniger offensichtlich sind als im B2C. Ein Geschäftskunde kann individuelle Preise, Lieferbedingungen, Nutzerrollen, Limits, Freigabeprozesse, Zugriff auf ausgewählte Produkte, Bestellhistorie, Dokumente, wiederkehrende Warenkörbe, Angebote und Integration mit seinem Einkaufssystem haben. Wenn eines dieser Elemente nicht funktioniert, erfüllt die Plattform ihre Rolle nicht.

Im B2B muss daher nicht nur die allgemeine Conversion beobachtet werden, sondern auch die Korrektheit des Kundenkontexts. Sieht der Kunde nach dem Login die richtigen Produkte? Sind Preise mit ERP konsistent? Sind Limits aktuell? Funktionieren Freigaben? Haben Personen mit verschiedenen Rollen die richtigen Berechtigungen? Funktionieren Schnellbestellungen und Einkaufslisten korrekt? Sind Dokumente verfügbar? Gelangen Bestellungen mit korrekten Nummern, Bedingungen und Vertragsdaten in das operative System?

Das sind Metriken, die im klassischen Monitoring unsichtbar sein können. Die Plattform funktioniert, aber der B2B-Kunde sieht einen falschen Preis. Der Checkout funktioniert, respektiert aber den Freigabeprozess nicht. Die Integration funktioniert, übergibt aber die Bestellnummer des Kunden nicht. Das Kundenkonto funktioniert, zeigt aber nicht die aktuelle Dokumentenhistorie. Für das Business sind das keine kleinen Fehler. Das sind Situationen, die entscheiden, ob der Kunde die Plattform nutzt oder zu traditionellen Kanälen zurückkehrt.

Im B2B ist auch besonders wichtig zu beobachten, ob die Plattform das Team wirklich entlastet. Wenn die Plattform die Zahl der Anfragen an Vertriebsmitarbeiter reduzieren sollte, lohnt es sich zu messen, ob das tatsächlich passiert ist. Wenn das Customer Portal Fragen zu Status und Dokumenten begrenzen sollte, muss geprüft werden, ob Kunden es nutzen und ob Prozesse korrekt funktionieren. Wenn Schnellbestellungen den Einkaufsprozess verkürzen sollten, lohnt es sich zu messen, ob Geschäftskunden Bestellungen tatsächlich selbstständig abschließen.

Commerce Observability im B2B ist daher nicht nur ein technisches Thema. Sie ist eine Methode zu prüfen, ob die Plattform den Verkaufs- und Kundenserviceprozess tatsächlich in den digitalen Kanal überträgt.

Die Rolle von Shopware beim Aufbau eines sichtbaren und kontrollierten Ökosystems

Shopware passt gut zu einem Ansatz, in dem E-Commerce Teil eines größeren Ökosystems aus Daten, Kanälen und Integrationen ist. Offizielle Shopware-Materialien betonen die offene API-first-Architektur und die Möglichkeit zur Integration mit Systemen, von denen das Geschäft abhängt. Das ist wichtig, weil Observability nicht nur eine leistungsfähige Plattform erfordert, sondern auch die Möglichkeit, Flüsse zwischen Systemen zu verfolgen.

API-first bedeutet nicht automatisch Observability, erleichtert aber die Gestaltung einer Umgebung, in der Daten und Prozesse kontrolliert verfügbar sind. Wenn die Plattform über gut gestaltete APIs mit ERP, PIM, WMS, CRM, Headless-Frontend und externen Tools kommuniziert, kann man Antwortzeit, Fehler, Volumen, Verzögerungen und Prozesseffektivität bewusst messen. Wenn Integrationen zufällig, manuell oder undokumentiert sind, wird Observability deutlich schwieriger.

Shopware besitzt außerdem Elemente, die in größeren Implementierungen natürlich beobachtet werden müssen: Message Queues, Scheduled Tasks, Indexierung, Cache, Suche, Sales Channels, API, Checkout, Integrationen und Erweiterungen. Die Shopware-Dokumentation weist darauf hin, dass Scheduled Tasks zur Planung von Aufgaben in der Queue dienen und die Queues selbst die Hintergrundverarbeitung von Aufgaben wie E-Mail-Versand, Produktindexierung oder Sitemap-Generierung ermöglichen.

Das bedeutet, dass man in einer gut gestalteten Shopware-Implementierung nicht nur über Funktionen nachdenken muss, sondern auch über Sichtbarkeit ihrer Funktionsweise. Werden Queues verarbeitet? Stauen sich Aufgaben nicht? Funktioniert der Cache korrekt? Sind Indizes aktuell? Antwortet die Store API stabil? Unterstützt die Admin API Integrationen korrekt? Funktioniert der Checkout für alle Sales Channels? Beeinflussen Erweiterungen die Performance negativ?

Shopware gibt eine solide Grundlage, aber die endgültige Qualität von Observability hängt von der Implementierungsarchitektur ab. Die Plattform kann offen und skalierbar sein, aber wenn das Unternehmen Prozesse nicht misst, Integrationen nicht dokumentiert und keine Alerts gestaltet, wird es weiterhin reaktiv arbeiten.

Wie CREHLER Commerce Observability betrachtet

Bei CREHLER betrachten wir E-Commerce nicht nur als Implementierungsprojekt, sondern als Vertriebssystem, das nach dem Start stabil funktionieren muss. Deshalb sollte Observability von Anfang an Teil der Architekturdiskussion sein und kein Zusatz, der erst dann implementiert wird, wenn die ersten Probleme auftreten.

In der Praxis bedeutet das, dass bereits in der Designphase festgelegt werden sollte, welche Prozesse für das Business kritisch sind. In einem Projekt werden das Checkout und Zahlungen sein. In einem anderen die Synchronisation von Lagerbeständen. In einem weiteren die Integration mit ERP, B2B-Kundenservice, Import von Produktdaten aus PIM, Suche, Marktplatz oder Angebotsprozess. Erst wenn diese Prioritäten bekannt sind, können passende Metriken, Logs, Traces, Alerts und Dashboards gestaltet werden.

In Shopware-Projekten ist uns besonders wichtig, die technische und geschäftliche Perspektive zu verbinden. Es reicht nicht zu wissen, dass die API einen Fehler zurückgegeben hat. Man muss wissen, ob dieser Fehler eine Bestellung, ein Produkt, einen Kunden, eine Zahlung, Lieferung, einen Preis, ein Dokument oder eine Synchronisation betraf. Es reicht nicht zu wissen, dass die Queue wächst. Man muss wissen, ob sie E-Mails, Indexierung, Status, Integrationen oder Angebotsveröffentlichung beeinflusst. Es reicht nicht zu wissen, dass der Checkout langsamer funktioniert. Man muss wissen, ob Warenkorb, Lieferung, Zahlung, Validierung, Bestellspeicherung oder Kommunikation mit ERP langsamer sind.

Dieser Ansatz ist besonders wichtig für Unternehmen, die B2B-, Cross-Border- oder Headless-E-Commerce entwickeln. Je mehr Kanäle, Systeme und Prozesse, desto größer das Risiko, dass ein Problem zwischen Schichten verborgen liegt. Observability verkürzt die Diagnosezeit und reduziert die Zahl der Situationen, in denen der Kunde das Problem zuerst sieht.

CREHLER hilft Unternehmen, E-Commerce-Plattformen so zu gestalten, dass sie nicht nur skalierbar, sondern auch wartbar, messbar und entwicklungsfähig sind. Gut gestaltete Shopware-Architektur, Integrationen mit ERP, PIM, WMS und CRM, Kontrolle asynchroner Prozesse, Checkout-Monitoring und Beobachtung der Produktdatenqualität sind Elemente, die darüber entscheiden, ob die Plattform nach der Implementierung Wachstum unterstützt oder ständiges Feuerlöschen erfordert.

Vom Feuerlöschen zur vorhersehbaren Entwicklung

Fehlende Observability sorgt dafür, dass das Unternehmen reaktiv arbeitet. Das Problem erscheint zuerst beim Kunden, gelangt dann zum Kundenservice, dann zum E-Commerce-Manager, dann zur IT, dann zum Technologiepartner, und erst danach beginnt die Diagnose. Jeder weitere Schritt bedeutet Zeit, Frustration und Kosten. Im schlimmsten Fall weiß das Unternehmen nicht einmal, wie viele Kunden das Problem erlebt haben, wie viele Bestellungen nicht aufgegeben wurden und welchen realen Einfluss es auf den Umsatz hatte.

Gute Commerce Observability verändert dieses Modell. Das Team sieht, dass die Zahl der Zahlungsfehler steigt. Es sieht, dass eine bestimmte Integration Verzögerungen hat. Es sieht, dass Bestellungen aus einem Sales Channel nicht ins ERP gelangen. Es sieht, dass die Aufgabenqueue beginnt, die Produktindexierung zu beeinflussen. Es sieht, dass der Checkout für B2B-Kunden nach einer Änderung der Preisregeln langsamer funktioniert. Es sieht, dass Produktdaten aus PIM die Validierung für einen Teil des Katalogs nicht bestehen. Dadurch kann es früher reagieren, bevor das Problem breit sichtbar wird.

Das ist der Unterschied zwischen Wartung der Plattform und Management ihrer Qualität. Wartung beantwortet die Frage, ob das System funktioniert. Observability beantwortet die Frage, ob das System den Vertrieb vorhersehbar unterstützt. Im E-Commerce hat dieser Unterschied direkte Bedeutung für Umsatz, Servicekosten, Kundenvertrauen und Entwicklungstempo.

Unternehmen, die in Observability investieren, treffen Entwicklungsentscheidungen leichter. Sie wissen, welche Prozesse stabil sind, welche Optimierung benötigen, welche Integrationen riskant sind, welche Kanäle Probleme erzeugen und welche Elemente der Plattform den größten Einfluss auf Kundenerfahrung haben. Dadurch basiert die Weiterentwicklung des E-Commerce nicht mehr nur auf Meinungen und Meldungen, sondern auf Daten über das tatsächliche Funktionieren des Systems.

Unternehmen, die mehr sehen, skalieren E-Commerce schneller

Im modernen E-Commerce reicht es nicht, eine Plattform zu starten und Verkäufe zu messen. Man muss verstehen, wie das gesamte Ökosystem funktioniert, das diese Verkäufe ermöglicht. Produktdaten, Checkout, Zahlungen, Integrationen, Queues, Cache, Suche, Bestellstatus, B2B-Konten, Dokumente, Automatisierungen und After-Sales-Prozesse bilden ein System. Wenn das Unternehmen dessen Funktionsweise nicht sieht, kann es es nicht bewusst steuern.

Commerce Observability ist daher kein technologischer Luxus. Sie ist ein Element der E-Commerce-Reife. Je größer die Verkaufsskala, je mehr Integrationen, je komplexer das B2B-Modell, je mehr Märkte und Kanäle, desto größer ist die Bedeutung der Fähigkeit, Probleme schnell zu erkennen und ihren Einfluss auf das Business zu verstehen.

Den größten Vorteil werden jene Organisationen haben, die nicht warten, bis der Kunde ein Problem meldet. Sie werden Signale früher sehen: in Metriken, Logs, Traces, Alerts, Integrationsprozessen und operativen Daten. Sie werden schneller diagnostizieren, schneller reparieren und Entwicklung besser planen können.

Bei CREHLER helfen wir Unternehmen, skalierbare E-Commerce-Plattformen auf Basis von Shopware zu gestalten und weiterzuentwickeln, die nicht nur für den Start, sondern auch für stabile Entwicklung nach der Implementierung bereit sind. Wenn Sie prüfen möchten, ob Ihre Plattform Probleme erkennen kann, bevor der Kunde sie sieht, lohnt es sich, mit einem Gespräch über Architektur, Integrationen, Daten und Observability zu beginnen. Genau dort beginnt der Unterschied zwischen E-Commerce, der nur funktioniert, und E-Commerce, den man wirklich kontrollieren kann.