ORAIORAI
Matomo und SAP CAP: Nutzungsanalyse fuer Fiori-Apps ohne App-Aenderung

Matomo und SAP CAP: Nutzungsanalyse für Fiori-Apps, ohne eine einzige App zu ändern

SAP Web Analytics ist seit 2022 abgekündigt, ein Nachfolger kam nicht. Wie Sie Matomo über ein FLP Shell Plugin einbinden und dabei Ihre bestehenden Anwendungen unangetastet lassen.

Bjoern Ostermann
Björn OstermannTechnology Consultant
8/19/2026SAP Consulting

Ihre Fiori-Apps laufen im Produktivbetrieb. Aber wissen Sie, welche Funktionen tatsächlich genutzt werden? An welcher Stelle Anwender abbrechen? Welcher Bereich seit dem Rollout kein einziges Mal geöffnet wurde?

In den meisten Projekten lautet die Antwort: nein. Entwicklungsbudget fließt dann in die Funktion, nach der am lautesten gefragt wurde, nicht in die, die am häufigsten gebraucht wird.

SAP schließt diese Lücke nicht. SAP Web Analytics, der hauseigene Dienst dafür, wurde zum 31. August 2022 abgekündigt. Ein Nachfolger kam nicht. Die gute Nachricht: Matomo lässt sich mit überschaubarem Aufwand einbinden, und zwar so, dass Ihre bestehenden Anwendungen unangetastet bleiben.

Klassische Website gegen Fiori Launchpad: alle Seitenaufrufe gegen einen pro Tag
Im Launchpad meldet ein Standard-Snippet ohne eigenes Zutun nur den ersten Aufruf.

Warum das Standard-Snippet ins Leere läuft

Auf einer klassischen Website zählt der Browser von selbst. Jeder Klick lädt ein neues Dokument, das Analyse-Skript läuft erneut und meldet einen Seitenaufruf. Deshalb ist Web-Tracking dort eine Sache von fünf Minuten.

Das SAP Fiori Launchpad funktioniert anders. Es ist eine Single-Page-Anwendung, also eine Seite, die einmal geladen wird und danach ihre Inhalte per JavaScript austauscht. Der Browser lädt genau ein Dokument, morgens beim Anmelden. Danach werden Apps in den Inhaltsbereich hinein- und wieder herausgetauscht, ohne dass die Seite neu lädt.

Ein eingebautes Standard-Snippet liefert deshalb einen Seitenaufruf pro Anwender und Arbeitstag. Alles danach bleibt unsichtbar.

Ein Baustein für die gesamte Landschaft

Die naheliegende Lösung wäre, Tracking-Code in jede App einzubauen. Bei zwei Anwendungen geht das. Bei zwanzig haben Sie zwanzig Kopien, die auseinanderlaufen, und jede neue App muss daran denken.

Der tragfähige Weg nutzt einen offiziellen Erweiterungspunkt von SAP: ein FLP Shell Plugin. Die Shell, also der Rahmen des Launchpads mit Kopfleiste und Kacheln, ist genau einmal vorhanden und bleibt für die gesamte Sitzung bestehen. Ein Plugin wird beim Start mitgeladen und meldet jeden Wechsel zwischen Anwendungen.

Der Mechanismus dahinter ist ein Nachrichtenkanal in SAPUI5. Die Shell veröffentlicht dort bei jedem App-Wechsel eine Nachricht, das Plugin hört zu. Beide kennen einander nicht. Deshalb werden auch Anwendungen erfasst, die es heute noch gar nicht gibt.

Architektur: Matomo-Plugin in der Launchpad-Shell, Apps werden ausgetauscht
Das Plugin liegt in der Shell und meldet Aufrufe und Verweildauer. Neue Apps werden ohne Anpassung mit erfasst.

Drei Ausbaustufen, sehr unterschiedlicher Aufwand

Stufe 1: Navigation und Verweildauer. Welche Anwendungen werden wie oft geöffnet, wie lange genutzt, in welcher Reihenfolge. Aufwand: rund ein Tag. Das beantwortet die häufigste Frage aus dem Fachbereich bereits vollständig.

Stufe 2: Interaktion. Welche Schaltflächen werden gedrückt, mit Typ und Beschriftung. Hier wird es aufwendiger, weil SAP Build Work Zone die Apps in einem eingebetteten Fenster darstellt. Ein Zuhörer in der Shell sieht Klicks in der App nicht. Jedes App-Fenster muss einzeln angebunden werden.

Stufe 3: Fachliche Vorgänge. Nach welchen Feldern wird gefiltert, was wird angelegt, geändert, gelöscht. Technisch die anspruchsvollste Stufe: OData bündelt Lesezugriffe in einer Sammelanfrage, und die Filterkriterien stehen im Nachrichtenrumpf, nicht in der Adresse.

Drei Ausbaustufen: Navigation, Interaktion, fachliche Vorgaenge mit Aufwand
Aufwandsangaben aus eigenen Projekten. Stufe 1 beantwortet die häufigste Frage bereits.

Was CAP dazu beiträgt

Der Konfigurationsendpunkt. Adresse des Analyse-Servers, Kennnummer der Website und die Nummern der Auswertungsdimensionen gehören nicht fest in den Plugin-Code. Sonst brauchen Sie ein eigenes Artefakt je Umgebung. Ein kleiner Endpunkt im CAP-Service liefert diese Werte zur Laufzeit, gespeist aus Umgebungsvariablen. Wichtig: Er wird über die Bootstrap-Phase am Express-Server registriert, nicht als CAP-Service. CAP sichert standardmäßig alle Endpunkte ab, und das Plugin lädt seine Konfiguration, bevor überhaupt eine Anmeldung stattgefunden hat.

Die serverseitige Ergänzung. Matomo hat eine Schnittstelle, die Sie direkt aus der Anwendungslogik ansprechen können. Ein Handler in CAP meldet fachliche Ereignisse, ohne dass im Browser etwas passiert. Das ist unempfindlich gegen Werbeblocker und braucht weder Plugin noch Freigabe in Work Zone. Sie sehen damit, welche Vorgänge ausgeführt werden, aber keine Navigation und keine Verweildauer. In der Praxis ist die Kombination die belastbarste Lösung.

Ehrlich eingeordnet

Die SAP-Bordmittel sind nicht nutzlos, sie beantworten nur eine andere Frage. @cap-js/telemetry und SAP Cloud Logging liefern Betriebsdaten: Antwortzeiten, Fehlerraten, Auslastung. Wenn Sie wissen wollen, ob ein Service stabil läuft, sind sie das richtige Werkzeug. Die Nutzungsstatistiken von SAP Build Work Zone wiederum messen die Site, also Kacheln und Bereiche. Sobald jemand eine Kachel anklickt, endet ihre Sicht.

Matomo hat ebenfalls Grenzen. Es sieht nur, was im Browser passiert. Hintergrundverarbeitung, Schnittstellen und Batch-Läufe bleiben außen vor. Dafür brauchen Sie die serverseitige Variante oder weiterhin Ihr Logging.

Uebertragen werden Feldnamen und Bedienelemente, nicht Feldwerte und Zeileninhalte
Übertragen werden Strukturangaben, keine Feldwerte und keine Personenbezüge.

Datenschutz ist kein Nachgedanke

Bei Anwendungen für eigene Beschäftigte ist die Einführung nach § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig. Ausschlaggebend ist nicht Ihre Absicht, sondern die Eignung zur Verhaltenskontrolle. Ohne Betriebsvereinbarung kann der Betriebsrat den Betrieb untersagen lassen.

Der Aufbau lässt sich so wählen, dass er dieser Prüfung standhält: keine Benutzerkennung, Betrieb ohne Cookies, gekürzte IP-Adressen, abgeschaltetes Besucherprotokoll, Löschung der Rohdaten nach 90 Tagen. Übertragen werden ausschließlich Strukturangaben, also Feldnamen und Bezeichnungen von Bedienelementen. Nie Feldwerte, nie Zeileninhalte. Bei einem Filter auf "Jahr gleich 2026" geht das Feld hinaus, nicht der Wert.

Diese Punkte sollten dem Betriebsrat als konkrete technische Zusage vorliegen. Eine offene Absichtserklärung verlängert die Abstimmung erfahrungsgemäß um Monate.

Ablauf in fuenf Stationen, parallel dazu Betriebsrat und Datenschutz
Der technische Strang dauert rund eine Woche, die Abstimmung bestimmt den Termin.

Fazit

Die technische Umsetzung für Stufe 1 liegt bei rund einer Woche. Ihre bestehenden Anwendungen werden dabei nicht angefasst, künftige sind automatisch erfasst. Der bestimmende Faktor ist die Abstimmung mit Betriebsrat und Datenschutz. Starten Sie diesen Strang parallel zur Entwicklung, nicht danach.

Die nützlichste Frage vorab: Welche Entscheidung wollen Sie mit den Daten treffen? Wer das vorher benennt, bekommt eine deutlich brauchbarere Auswertung. Häufig zeigt sich dabei, dass Stufe 1 längst ausreicht.

Termin buchen

Nutzungsdaten für Ihre Fiori-Landschaft?

Wir haben diesen Weg vollständig durchgespielt, vom Shell Plugin über die Registrierung in Work Zone bis zur Vorlage für den Betriebsrat.

  • 30 Minuten
  • unverbindlich
Termin buchen

Bereit zu starten?

Schreib uns oder buche direkt ein kurzes Meeting.

Kontakt aufnehmen