OXID-Monitoring vom Artikel bis zur Kasse
XICTRAQ prüft Startseite, Warenkorb, Kassenweg und Admin-Anmeldung Ihres OXID-Shops von außen und bemerkt, wenn OXID statt des Shops seine Offline-Seite oder, mit einem Stichwort, den Hinweis auf ein verbliebenes Setup-Verzeichnis ausliefert. Der cookielose Tracker liest Produktansichten und Warenkorb-Klicks auf Artikelseiten aus dem OXID-Markup, Kassenschritte und Umsatz ergänzen Sie mit Aufrufen im Template.
Diese OXID-Seiten zuerst prüfen
- Uptime-MonitoringStartseite mit Stichwort aus dem Seiteninhalt
/ - API-MonitoringWarenkorb: Status und fester Seitentext
/index.php?cl=basket - Browser-MonitoringVom Artikel über den Warenkorb in die Kasse
/index.php?cl=user - Browser-MonitoringAnmeldung mit einem Testkunden
/index.php?cl=account - Uptime-MonitoringAdmin-Anmeldung als Unterseite
/admin/
Warum bei OXID die Startseite nicht reicht
Ein OXID eShop steuert seine Seiten über den Parameter cl: index.php?cl=details für Artikel, cl=basket für den Warenkorb, cl=user, cl=payment und cl=order für die Schritte der Kasse, cl=thankyou für die Bestellbestätigung. Sind SEO-Adressen aktiv, leitet OXID eine solche Standardadresse auf die hinterlegte SEO-Adresse weiter, sofern es eine gibt. Module und Theme greifen in all diese Seiten ein. Die Startseite kann deshalb mit HTTP 200 antworten, während der Warenkorb einen Fehler zeigt oder der Button „In den Warenkorb“ nicht mehr reagiert.
Dazu kommen zwei Seiten, die OXID selbst anstelle des Shops ausliefert. Bei einem Datenbankfehler oder einem nicht abgefangenen Fehler zeigt OXID außerhalb des Debug-Modus die Datei offline.html mit dem Titel „Maintenance mode / Wartungsarbeiten“ und sendet dazu HTTP 500. Und liegt im Produktivmodus noch das Verzeichnis Setup im Shop, sehen Besucher statt der aufgerufenen Seite einen Hinweis, dieses Verzeichnis zu löschen.
XICTRAQ verteilt die Prüfung deshalb auf mehrere Module: Uptime-Monitoring mit Stichwort und Unterseiten für Startseite und Admin-Anmeldung, API-Checks mit Textprüfung für den Warenkorb, Browser-Checks für Kassenweg und Kundenkonto, Benachrichtigungen, die nicht vom Shopserver verschickt werden, und der Security-Scan für offen abrufbare Dateien.
Uptime-, API- und Browser-Checks behandeln einen OXID-Shop wie jede andere Website: Was geprüft wird, bestimmen die Pfade, Stichworte und Schritte, die Sie anlegen. Lassen Sie Browser-Checks vor dem Absenden der Bestellung auf cl=order enden, damit keine echten Bestellungen entstehen.
Was in OXID-Shops ausfallen kann
Seite „Wartungsarbeiten“ mit HTTP 500
Bei einem Datenbankfehler oder einem nicht abgefangenen Fehler liefert OXID außerhalb des Debug-Modus die Datei offline.html aus, Titel „Maintenance mode / Wartungsarbeiten“, Statuscode 500. Trotz des Titels verbucht XICTRAQ das nicht als Wartung, denn als Wartung gilt nur eine Antwort mit HTTP 503: Die Uptime-Prüfung zählt die Antwort als Ausfall, die automatische Wartungspause für Alarme greift nicht. Ersetzt ein Shop die Seite durch eine eigene, entscheiden deren Statuscode und Text.
Die eigene Warnmail von OXID bleibt aus
OXID kann bei einer gestörten Datenbankverbindung eine Mail „Offline warning!“ verschicken, aber nur an die Adresse in sAdminEmail aus der config.inc.php, die in der Vorlage leer ist, höchstens einmal je offlineWarningInterval und über die PHP-Mailfunktion des Shopservers. Nicht jeder Fehler, der zur Offline-Seite führt, löst sie aus. Die Uptime-Prüfung von XICTRAQ bemerkt die Antwort mit HTTP 500 von außen und benachrichtigt Sie über die Wege, die Sie eingerichtet haben, unabhängig vom Mailversand des Shops.
Verbliebenes Setup-Verzeichnis sperrt den Shop
Liegt im Produktivmodus noch das Verzeichnis Setup im Shop, zeigt OXID Besuchern statt der aufgerufenen Seite den Hinweis, dieses Verzeichnis zu löschen. Einen Fehlerstatus setzt OXID dabei nicht, eine reine Erreichbarkeitsprüfung kann die Seite deshalb für einen funktionierenden Shop halten. Die Stichwortprüfung der Uptime-Überwachung schlägt an, wenn ein hinterlegtes Wort auf der Startseite fehlt. Die Hinweisseite nutzt das Grundgerüst des Themes mit Seitentitel, aber ohne Kopf- und Fußzeile, wählen Sie deshalb ein Wort aus dem sichtbaren Inhalt der Startseite, nicht den Shopnamen.
Warenkorb liefert Fehler oder leere Seite
Nach Updates von Modulen oder Theme kann der Warenkorb Fehler zeigen, während Startseite und Artikelseiten weiter laden. Ein API-Check ruft index.php?cl=basket auf, folgt Weiterleitungen, etwa auf eine hinterlegte SEO-Adresse, und prüft einen Statuscode und einen Text, die Sie als Zusicherung festlegen, etwa die Überschrift der Seite. Kommt ein Fehlerstatus oder fehlt der Text, meldet XICTRAQ den fehlgeschlagenen Check.
Button „In den Warenkorb“ reagiert nicht
Ein Fehler in Theme oder Modul kann den Button „In den Warenkorb“ lahmlegen, obwohl jede Seite mit HTTP 200 antwortet. Ein Browser-Check öffnet eine Artikelseite, klickt den Button, in den Themes Flow und APEX das Element #toBasket, ruft den Warenkorb auf und prüft per Text, ob der Artikel dort steht. Scheitert ein Schritt, meldet XICTRAQ den Lauf als fehlgeschlagen und hält, sofern die Aufnahme gelingt, ein Bildschirmfoto dieses Schritts fest.
Datenbanksicherung offen im Webverzeichnis
Bei Umzügen, Updates oder Fehlersuche bleiben mitunter Dateien wie dump.sql, backup.sql, phpinfo.php oder adminer.php im Hauptverzeichnis liegen. Der Security-Scan fragt eine feste Liste solcher Dateinamen im Hauptverzeichnis des Shops ab, darunter auch .env und .git/config, und führt gefundene Dateien mit Schweregrad im Bericht auf. Antwortet der Shop auf jede unbekannte Adresse mit HTTP 200, prüft der Scan nur Dateien, deren Inhalt er erkennen kann, etwa .git/config oder phpinfo.php, nicht aber dump.sql. Dateien unter anderen Namen oder in Unterverzeichnissen findet diese Probe nicht.
Woran XICTRAQ OXID erkennt
OXID erkennen zwei Stellen unabhängig voneinander: der Tracker im Browser des Besuchers und der Scan der Website. Uptime-, API- und Browser-Checks unterscheiden OXID nicht, sie prüfen, was Sie hinterlegen.
- Der Tracker schaltet seinen OXID-Zweig ein, wenn die Seite die Klasse cl-details trägt, die die Themes Flow und APEX auf Artikelseiten an den body setzen, oder ein Artikelformular form.js-oxProductForm enthält. Auf Warenkorb- und Kassenseiten fehlen diese Merkmale in der Regel, dort greift der Zweig nicht.
- Ohne diese Merkmale greifen nur die allgemeinen Erkennungen des Trackers. Kasse und Bestellabschluss erkennen sie am Pfad der Adresse; bei Adressen wie index.php?cl=payment lautet der Pfad /index.php, der Kassenschritt steht im Parameter.
- Der Scan führt OXID eShop als Shopsystem, wenn das HTML Spuren wie /oxseo.php oder die Zeichenfolge oxidesale enthält. Fehlen sie, bleibt das Feld leer, auch wenn der Shop mit OXID läuft.
- Der Prüfdienst selbst erkennt OXID nicht. Damit ein späterer Technik-Check das Ergebnis nicht löscht, bleibt das im Scan erkannte Shopsystem stehen.
- Die Überwachung hängt nicht an der Erkennung: Uptime-, API- und Browser-Checks prüfen die Pfade, Stichworte und Schritte, die Sie anlegen, auch wenn das Theme keine OXID-Merkmale trägt.
Was der Tracker in OXID erfasst
Findet der Tracker OXID-Merkmale im Markup, liest er auf Artikelseiten Produktansicht und Warenkorb-Klick direkt aus den Seiten des Shops. Kassenschritte und Umsatz liest er aus dem OXID-Markup in der Regel nicht. Er setzt dafür keine Cookies.
Erfasst der Tracker von selbst
- Seitenaufrufe mit Herkunft und UTM-Parametern, dazu Web Vitals wie LCP, CLS und INP.
- Produktansichten auf Artikelseiten mit Name, Preis und der Artikel-ID aus dem Feld aid, soweit das Theme sie wie Flow und APEX ausgibt.
- Klicks auf „In den Warenkorb“ auf Artikelseiten, etwa auf #toBasket, mit Artikel-ID, Name, Preis und der Menge aus dem Feld am.
- Kassenbeginn und Käufe mit Betrag und, soweit angegeben, Bestellnummer, wenn der Shop sie als begin_checkout und purchase mit einem ecommerce-Objekt in den dataLayer schreibt, etwa über ein Modul.
- JavaScript-Fehler aus echten Besuchen mit Meldung, Datei und Zeile.
Nicht automatisch erfasst
- Kassenbeginn und Bestellabschluss aus dem OXID-Markup: Der OXID-Zweig greift auf den Kassenseiten in der Regel nicht, und die allgemeine Erkennung sieht bei Adressen wie index.php?cl=order nur den Pfad /index.php.
- Den Umsatz: Den Betrag erhält die Auswertung nur, wenn Sie ihn übergeben oder der Shop einen Kauf mit Wert in den dataLayer schreibt. Steuer und Versandkosten kommen nur über Ihren Aufruf an, nicht aus dem dataLayer, und die Positionen einer Bestellung speichert XICTRAQ aus diesem Aufruf nicht.
- Angemeldete Kunden: Einen OXID-eigenen Weg zur Zuordnung hat der Tracker nicht, ohne Anpassung am Template bleiben sie anonym.
- Entfernen von Artikeln und Mengenänderungen im Warenkorb: Die Warenkorbzeilen von Flow und APEX tragen keine der Kennungen, auf die die Warenkorbbeobachtung des Trackers achtet.
- Klicks auf „In den Warenkorb“ in Kategorie- und Suchlisten: In APEX und in den Kachelansichten von Flow erfasst der Tracker sie in der Regel nicht, in der Zeilenansicht von Flow liest der OXID-Zweig Artikel-ID und Menge aus dem ersten Artikelformular der Seite, nicht aus dem angeklickten.
- Ob ein Artikel tatsächlich im Warenkorb gelandet ist: Gezählt wird der Klick auf den Button.
- Stornos, Erstattungen und Bestellungen, die in der Shopverwaltung entstehen. Dafür gibt es kein automatisches Ereignis.
Fehlende Werte übergeben Sie über die JavaScript-API, aufgerufen nach DOMContentLoaded, weil der Tracker verzögert lädt: xictraq.checkout("begin") im Template des ersten Kassenschritts, xictraq.revenue(betrag, "EUR", bestellnummer, { tax: steuer, shipping: versand }) im Template der Bestellbestätigung (page/checkout/thankyou), Beträge in Euro. Angemeldete Kunden ordnen Sie mit <meta name="xictraq:user-id" content="KUNDENNUMMER"> oder xictraq.identify(kundennummer, { type: kundengruppe }) zu, Erstattungen mit xictraq.refund(bestellnummer, betrag, "EUR"). Prüfen Sie nach dem Einbau die ersten Bestellungen in der Auswertung auf doppelte oder leere Käufe.
Die passenden Module für OXID eShop
Häufige Fragen
Erkennt XICTRAQ meinen Shop als OXID eShop?
An zwei Stellen, sofern der Shop die passenden Merkmale trägt. Der Tracker erkennt OXID an der Klasse cl-details auf Artikelseiten oder an Artikelformularen mit der Klasse js-oxProductForm, der Scan an Spuren wie /oxseo.php oder der Zeichenfolge oxidesale im HTML. Uptime-, API- und Browser-Checks unterscheiden OXID nicht, sie prüfen die Pfade und Stichworte, die Sie hinterlegen.
Warum fehlen bei OXID-Bestellungen Kassenbeginn und Umsatz in der Auswertung?
Der OXID-Zweig des Trackers liest Produktansicht und Warenkorb-Klick auf Artikelseiten, auf den Kassenseiten und der Bestellbestätigung greift er in der Regel nicht. Rufen Sie deshalb im ersten Kassenschritt xictraq.checkout("begin") und in der Bestellbestätigung xictraq.revenue(betrag, "EUR", bestellnummer) auf. Schreibt Ihr Shop bereits ein purchase-Ereignis mit Wert in den dataLayer, übernimmt der Tracker Betrag und, soweit vorhanden, Bestellnummer von dort.
Was meldet XICTRAQ, wenn OXID die Seite „Wartungsarbeiten“ zeigt?
Die Standardseite offline.html kommt mit HTTP 500, auch wenn ihr Titel „Wartungsarbeiten“ lautet. XICTRAQ verbucht sie deshalb als Ausfall, denn als Wartung gilt nur eine Antwort mit HTTP 503 und einem Wartungshinweis in Adresse, Titel oder Text. Für geplante Arbeiten legen Sie in XICTRAQ ein Wartungsfenster an, in dem Alarme für die Website pausieren.
Kann ein Browser-Check den Kaufweg in OXID prüfen, ohne dass eine Bestellung entsteht?
Ja. Ein Browser-Check kann Seiten öffnen, klicken, Felder ausfüllen, auf Elemente warten und Texte, Adressen oder Statuscodes prüfen. Lassen Sie ihn vor dem Absenden der Bestellung enden, etwa auf der Zahlungsauswahl cl=payment oder auf der Bestellübersicht cl=order ohne den letzten Klick. Für die Anmeldung unter cl=account nutzen Sie einen eigenen Testkunden statt eines echten Kundenkontos.
Wie ordne ich angemeldete OXID-Kunden zu?
Ein OXID-eigener Weg dafür ist im Tracker nicht eingebaut. Geben Sie im Template für angemeldete Kunden <meta name="xictraq:user-id" content="KUNDENNUMMER"> aus oder rufen Sie xictraq.identify(kundennummer, { type: kundengruppe }) auf. Übergeben Sie dabei eine Kundennummer, keine E-Mail-Adresse und keinen Klarnamen.
Warum reicht es bei OXID nicht, nur die Startseite zu überwachen?
Warenkorb, Kasse und Kundenkonto laufen in OXID über eigene Seiten wie cl=basket, cl=payment und cl=account. Fällt eine davon aus, kann die Startseite weiter normal laden. Zudem zeigt OXID bei einem verbliebenen Setup-Verzeichnis einen Hinweis ohne Fehlerstatus, den eine reine Erreichbarkeitsprüfung nicht bemerkt. Prüfen Sie diese Seiten deshalb einzeln und hinterlegen Sie ein Stichwort für die Startseite.