ACO vs.AIOps und APM.
APM misst Antwortzeiten und Fehlerraten. AIOps korreliert Infrastruktur-Alerts.Agentic Commerce Operations korreliert Handelsdaten mit Kenntnis des Commerce-Systems und misst, was ein Ausfall in CHF kostet. Drei Layer, die zusammenarbeiten, aber nicht dasselbe tun.
Kurzantwort für die Zitier-Zone.
Die Frage, die in fast jedem Erstgespräch kommt: „Haben wir das nicht schon mit Datadog, New Relic oder Pingdom?" Die Antwort in einem Absatz.
Vier Kategorien, vier Fragen.
Jede Kategorie beantwortet genau eine Frage gut. Der Fehler in der Praxis ist nicht das falsche Werkzeug, sondern die Erwartung, ein Werkzeug beantworte alle vier.
Synthetic Monitoring
„Antwortet die URL?"
Ein externer Prüfpunkt ruft in festen Intervallen eine URL oder einen einfachen Klickpfad auf und misst Status-Code und Antwortzeit. Vertreter: Pingdom, UptimeRobot, Checkly.
- Signal: HTTP-Status, TTFB, SSL-Ablauf
- Blind für: Zustand hinter dem HTTP 200
- Rolle im Stack: Sensor
APM
„Wie schnell und wie fehlerfrei?"
Application Performance Monitoring instrumentiert die Anwendung von innen: Traces pro Request, Latenz pro Service, Fehlerraten, Datenbank-Zeiten. Vertreter: Datadog APM, New Relic APM, Dynatrace, Elastic APM.
- Signal: Traces, Metriken, Logs, oft via OpenTelemetry
- Blind für: Bedeutung eines Wertes für den Umsatz
- Rolle im Stack: Telemetrie
AIOps
„Welche Alerts gehören zusammen?"
AIOps, ein von Gartner geprägter Begriff, korreliert Alerts und Events aus vielen Infrastruktur-Quellen zu einem Vorfall, unterdrückt Rauschen und leitet an das richtige Team weiter. Vertreter: PagerDuty AIOps, BigPanda, Moogsoft.
- Signal: Alerts, Events, Topologie
- Blind für: das Commerce-System als Fachdomäne
- Rolle im Stack: Korrelation
Agentic Commerce Operations
„Welche Bestellung geht gerade verloren, warum, und was tun wir im Rahmen der Policy?"
Ein Agent beobachtet den echten Order-Flow und Marktsignale, diagnostiziert am Commerce-System und am Source Code, beziffert den Effekt in CHF und handelt innerhalb der Policies des Betreibers. Jede Aktion steht im Audit-Log. Definition auf Was ist ACO.
- Signal: Order-Flow, Cron, Indexer, Payment, Stock, Search, Markt
- Kennt: Plattform-Internals von Magento bis Shopify
- Rolle im Stack: Handlung
Das Layer-Modell.
Von unten nach oben wächst nicht die Datenmenge, sondern das Domänenwissen. ACO ersetzt die unteren Layer nicht, es nutzt sie als Sensoren und fügt hinzu, was keiner von ihnen hat: Commerce-Wissen und eine Handlung.
- L4ACO
Handlung mit Commerce-Wissen
Agentic Commerce Operations. Liest die Layer darunter plus das Commerce-System selbst. Ergebnis: eine bezifferte Entscheidung im Policy-Rahmen, dokumentiert im Audit-Log.
- L3AIOps
Korrelation
AIOps. Bündelt Alerts aus vielen Quellen zu einem Vorfall, reduziert Rauschen, routet an Teams. Ergebnis: ein priorisiertes Ticket.
- L2APM
Telemetrie
APM und Observability. Misst Latenz, Fehler, Durchsatz und Ressourcen pro Service und Request. Ergebnis: ein Dashboard und Schwellenwert-Alerts.
- L1Uptime
Sensor
Uptime und Synthetic Monitoring. Prüft von aussen, ob eine URL antwortet und wie schnell. Ergebnis: grün oder rot.
Kernsatz: Wer ACO einführt, schaltet Pingdom, Datadog oder PagerDuty nicht ab. Er gibt ihren Signalen einen Empfänger, der weiss, was ein hängender Indexer für die laufende Aktion bedeutet.
Sieben Unterschiede auf einen Blick.
Dieselben sieben Kriterien für drei Kategorien. Synthetic Monitoring ist als Teil des APM-Layers eingeordnet.
| Kriterium | APM | AIOps | ACO |
|---|---|---|---|
| Was gemessen wird | Latenz, Fehlerrate, Durchsatz, Ressourcen | Alert-Volumen, Korrelation, Zeit bis zur Zuweisung | Bestellpfad, Systemzustand, Marktsignale, CHF-Effekt |
| Datenquelle | Agenten in der Anwendung, Traces, Logs | Alerts und Events aus Monitoring-Tools | Order-Flow-Probe, Commerce-System, ERP, Markt, Source Code, optional APM/AIOps |
| Domänenwissen | Generisch, sprach- und framework-bezogen | Generisch, infrastruktur-bezogen | Commerce-vertikal: Cron-Gruppen, Indexer, Payment-Codes, Message-Queues, API-Limits |
| Aktion | Alert an Schwellenwert | Ticket, Routing, Eskalation | Handlung im Policy-Rahmen, sonst Vorschlag mit CHF-Schätzung, Audit-Log |
| Erfolgsmass | MTTR, Verfügbarkeit, p95-Latenz | Weniger Alerts, schnellere Zuweisung | Verhinderter Umsatzverlust und belegter Uplift in CHF |
| Typische Nutzer | Engineering, DevOps, SRE | IT-Operations, NOC | Shop-Betreiber, E-Commerce-Verantwortliche, Agentur |
Drei Ausfälle, die APM grün meldet.
Drei Muster aus dem Shop-Betrieb, erzählt aus der Sicht des Monitoring-Dashboards: was es zeigte, was es nicht zeigen konnte, und welches Signal gefehlt hat.
Preis-Indexer auf invalid
Dashboard: alle Services grün, Latenz normal, keine Fehlerrate. Der Shop antwortet in 280 Millisekunden.
Nicht sichtbar: nach einem Katalog-Import bleibt der Preis-Indexer stundenlang auf invalid. Kategorie-Seiten zeigen alte Preise, die laufende Aktion greift nicht. Kein Request schlägt fehl, also kein Alert.
Fehlendes Signal: Indexer-Status als Fachzustand, verknüpft mit der aktiven Promotion. Auf Shopware entspricht das einem Rückstau in der Message Queue.
Payment-Timeout bei HTTP 200
Dashboard: Checkout-URL grün, Synthetic Check bestanden, p95 leicht erhöht, unter der Schwelle.
Nicht sichtbar: der Payment-Provider antwortet nach 4'800 Millisekunden mit einem Timeout. Die Seite rendert korrekt, der Kunde sieht eine Fehlermeldung und bricht ab. Aus Sicht des Servers ist das eine erfolgreiche Antwort.
Fehlendes Signal: eine Testbestellung durch den echten Pfad bis zur Autorisierung, plus der Anteil dieses Zahlungsmittels am Tagesumsatz. Erst daraus wird aus „p95 leicht erhöht" ein Betrag pro Stunde.
Cron-Gruppe consumers hängt
Dashboard: Bestellungen laufen ein, Datenbank-Last normal, Queue-Länge wird nicht gemessen.
Nicht sichtbar: die Bestellbestätigungen gehen nicht raus, weil die Cron-Gruppe für Consumer steht. Kunden merken es am nächsten Morgen, der Support am Telefon. Auf Shopify wäre die Variante ein stillerAPI-Rate-Limit, das eine Integration ausbremst.
Fehlendes Signal: Last-Success-Timestamp pro Cron-Job und Backlog pro Consumer, gelesen im System, nicht an der Oberfläche. Mit hinterlegter Policy startet ein ACO-Agent den Consumer neu und protokolliert es.
Häufige Fragen.
Fünf Fragen aus Gesprächen mit Teams, die bereits ein Monitoring-Setup betreiben.
- 01
Ersetzt ACO unser APM?
Nein. APM bleibt die Telemetrie-Schicht, die Antwortzeiten, Fehlerraten und Ressourcen pro Service misst. Agentic Commerce Operations sitzt darüber, liest solche Signale als Sensoren und ergänzt, was APM nicht kennt: den Bestellpfad, den Zustand von Cron, Indexer, Payment und Suche im Commerce-System sowie die ökonomische Konsequenz in CHF. Wer Datadog oder New Relic im Einsatz hat, behält beides. Wer keines hat, braucht für ACO auch keines, weil die Referenz-Implementierung XEREBRO ihre Order-Flow-Probe selbst ausführt.
- 02
Ist Commerce Observability dasselbe wie ACO?
Nein. Commerce Observability, etwa Observation for Adobe Commerce mit New Relic, konsolidiert Logs, Metriken und Traces eines Shops in einem Dashboard und zeigt Anomalien an. Das ist ein Signal-Layer. Agentic Commerce Operations ist der Handlungs-Layer darüber: ein Agent interpretiert dieselben Signale mit Kenntnis des Commerce-Systems, beziffert den CHF-Effekt und handelt im Rahmen der Policies des Betreibers. Observability zeigt an, ACO entscheidet und dokumentiert.
- 03
Warum reicht Synthetic Monitoring im Checkout nicht?
Weil ein Ping auf die Startseite oder eine Checkout-URL nur beantwortet, ob der Server antwortet. Er beantwortet nicht, ob ein Kunde eine Bestellung abschliessen kann. Ein Payment-Provider kann nach 4'800 Millisekunden mit einem Timeout aussteigen, während die Seite HTTP 200 liefert. Ein Preis-Indexer kann stundenlang alte Preise ausspielen, ohne dass eine URL fehlschlägt. ACO führt deshalb eine synthetische Testbestellung durch den echten Pfad bis zur Auftragsbestätigung aus und liest zusätzlich den Systemzustand dahinter.
- 04
Was heisst CHF-Konsequenz messen konkret?
Jeder Befund wird mit dem Tagesumsatz des betroffenen Pfades verrechnet. Steht der Preis-Indexer zwei Stunden auf invalid, während eine Aktion läuft, ergibt sich aus Bestellvolumen und nicht ausgespieltem Rabatt ein Betrag in CHF. Bricht der Checkout für ein Zahlungsmittel ab, ergibt sich aus dessen Anteil am Umsatz der Verlust pro Stunde. Diese Zahl steht neben dem Log-Auszug im Befund, mit offen deklarierten Annahmen. Ein APM-Tool kennt Latenz in Millisekunden, kein Umsatz-Modell.
- 05
Kann ein ACO-System Datadog-Daten nutzen?
Ja, als Sensor. Metriken, Traces und Alerts aus APM- oder AIOps-Werkzeugen sind valide Eingangssignale für einen ACO-Agent, genauso wie OpenTelemetry-Daten oder Logs des Shopsystems. Die Kategorie definiert sich nicht über die Herkunft der Signale, sondern über das, was mit ihnen geschieht: Korrelation mit Handelsdaten, Diagnose am Commerce-System, Handlung im Policy-Rahmen mit Audit-Log. Ein Datadog-Alert wird so vom Ereignis zur bezifferten Entscheidung.
Quellen.
Hersteller-Dokumentation und Referenzen, auf die sich die Einordnung stützt. Stand 8. September 2026.
- Wikipedia: Artificial Intelligence for IT Operations (AIOps)
- Datadog Docs: APM und Distributed Tracing
- New Relic Docs: Introduction to APM
- PagerDuty: AIOps-Plattform
- Adobe Experience League: Observation for Adobe Commerce
- OpenTelemetry Documentation
- Adobe Commerce Developer Docs: Indexing
- EU AI Act, Artikel 14: Human Oversight
- Agentic Commerce Operations: Kategorie-Definition, Category Paper v2.0