Ach, Bahn, Teil 2: Maustracking ist Quatsch

Screenshot: Blockiertes Javascript auf bahn.de

F12 in den üblichen Browsern führt auf verschiedene Sorten von „Web-Inspektoren“. In deren „Network“-Tabs könnt ihr die Flügel'sche Metrik bestimmen: Wie viele Dateien von wie vielen Hosts zieht so eine Seite? Die Bahn-Seite schneidet dabei nicht gut ab, nicht zuletzt aufgrund des nutzerInnenfeindlichen Javascripts, das der Screenshot zeigt.

Wieder mal habe ich auf bahn.de eine Fahrkarte gekauft, und wieder hakte es an vielen Ecken. Immer noch hat der Server darauf bestanden, ich sei eingeloggt (und hat mir nicht die Möglichkeit gegeben, mich einzuloggen), hat mir aber nicht meine Buchungs-Voreinstellungen („eine Person mit Bahncard 50“) angeboten, hat wieder ganze Seiten mit je nur einer einzelnen Frage ausgeliefert, hat kaputte Zahlungsoptionen angeboten, quittierte einen Browser-Reload mit hartem Ausloggen („fang einfach nochmal an“) und verlangte von mir ein Login beim Kartenkauf, obwohl es mich ja die ganze Zeit schon als eingeloggt geführt hat. Immerhin – niemand soll sagen, ich würde nur motzen – war das Captcha vom letzten Herbst endlich weg (eine Reaktion auf meine diesbezüglichen Mails aus dem Herbst-Blogpost habe ich natürlich nie bekommen).

Jedenfalls reichen eigentlich ein, zwei Transaktionen auf bahn.de locker, um einige (modulo Ökonomie) leicht zu behebende Usability-Schwächen zu finden. Aber gut: Gerade bei Webseiten bin ich ja schon froh, wenn sie wenigestens ihre Quirks behalten und nicht alle paar Wochen wieder was anders (zumeist: anders kaputt) ist. Ich erwähne das alles überhaupt nur, weil bahn.de in meinem Browser mal wieder so hakelig war, dass ich nachgesehen habe, wessen Javascript mir die Bahn neben ihrem eigenen (das dürfen sie ausführen) noch andrehen will. Unter den geblockten Quellen befand sich ein Laden namens m-pathy.com. Dessen Homepage (kleines Lob am Rande: das geht, ohne Code von m-pathy.com auf der lokalen Maschine laufen zu lassen) radebrecht mit Deppen-Leerzeichen:

m-pathy UX Insight G4 macht sichtbar, was Ihre Kunden erleben.

Unsere Analyse Lösung ermöglicht die Auswertung tausender feingranularer Interaktionsdaten aus Mausspuren, Touch-Gesten, Klicks und Formularinteraktionen.

Das Ergebnis sind belegbare und priorisierbare Handlungsempfehlungen für die Optimierung Ihrer klassischen oder mobilen Webseite.

Also: Die Bahn sammelt und verarbeitet Daten über meine Mausbewegungen (na ja, natürlich nicht über meine, weil das Javascript dieser Leute bei mir nicht läuft, aber von fast allen anderen ihrer KundInnen), um so zu tun, als würde sie ihre Webseite „optimieren“.

Da die Usability der Webseite zumindest in meinem „Erleben“ spürbar abgenommen hat – vor allem wohl wegen der Förderung von „Partnerangeboten“ und anderen Marktingkrams, aber seis drum –, würde ich schließen, dass „m-pathy UX Insight G4“ schlicht nicht funktioniert. Ok: Kann sein, dass die hautnahe Bespitzelung der NutzerInnen durch die Bahn funktioniert und sich eben nur niemand um „belegbare und priorisierbare Handlungsempfehlungen“ kümmert. Dann könnte die Bespitzelung aber auch unterbleiben, oder? Oder sind die Zwecke der Bahn ganz andere als die bei m-pathy angegebenen? Allein, mir würden da nicht viele einfallen. Was bitte soll aus meinen Mausbewegungen über der Bahn-Webseite für die Bahn schon folgen?

Einfach mal offen (also: ohne Fragebogen) mit 10 oder 50 NutzerInnen der Webseite reden und ihnen zuhören wäre ganz klar gigantisch viel datensparsamer und, so bin ich sicher, auch erheblich wirksamer, wenn die Bahn die Seite wirklich verbessern wollte.

Liebe Bahn, darf ich euch noch einen Neujahrsvorsatz vorschlagen? Es wäre: Buchen ohne Javascript, vielleicht sogar mit einem lokalen, Debian-paketierbaren Programm, das auf einer wohldokumentierten API aufsetzt.

Zitiert in: Bahnauskuft auf antiken Geräten – und auf Codeberg Ach Bahn, Teil 4: Werbschleicher

Kriegsfieber aktuell

Bar-plot in
    		Tönen von Oliv
(Erklärung)