Bei mir funktioniert es: So findest du einen Fehler, der nur einen Teil der Nutzer betrifft

Der Satz „Bei mir funktioniert es“ ist meistens wahr und meistens nutzlos. Die Website funktioniert tatsächlich auf dem Computer der Person, die sie erstellt hat: in einem Browser, den diese Person jede Woche aktualisiert, über eine schnelle Verbindung und mit der Standardschriftgröße. Das Problem ist, dass dies keine typische Besuchssituation ist, sondern nur eine von vielen – und Fehler treten gern in den anderen auf.

In diesem Text geht es nicht um einen Ausfall, nach dem niemand mehr ein Formular absenden kann. So etwas fällt innerhalb einer Stunde auf. Es geht um Fehler, die den Ablauf nur bei einer kleinen Besuchergruppe beeinträchtigen und monatelang bestehen können, weil sie niemand meldet. Im Folgenden erfährst du, wie du solche Fehler erkennst, bevor sich jemand verärgert bei dir meldet.

Wir nennen bewusst keine Marktanteile von Browsern, Betriebssystemen oder Auflösungen. Solche Zahlen unterscheiden sich je nach Branche und Markt. Die Entscheidung, was du prüfen solltest, muss sich aus deinen eigenen Daten ergeben und nicht aus einer Statistik, die du im Internet gefunden hast.

Warum ein solcher Fehler in den Statistiken unsichtbar bleibt

Stell dir vor, der Absenden-Button eines Formulars reagiert bei einer von dreißig Personen nicht mehr. Im Bericht siehst du einen Rückgang der Conversion-Rate um einen Bruchteil eines Prozentpunkts – also genau so viel, wie die Website in einer normalen Woche ohnehin schwankt. Kein Schwellenwert wird überschritten, es gibt keinen Alarm und nicht einmal einen Grund, genauer hinzusehen. Der Fehler geht im Durchschnitt unter.

Die andere Hälfte des Problems ist psychologischer Natur. Eine Person, bei der etwas nicht funktioniert, vermutet nur selten die Website als Ursache. Eher glaubt sie, an der falschen Stelle geklickt zu haben, schlechten Empfang zu haben oder dass das Unternehmen schlicht keine Anfragen beantwortet. Die Seite zu verlassen ist einfacher, als den Fehler zu melden – es dauert eine Sekunde und erfordert keine Erklärung gegenüber einem fremden Unternehmen über das eigene Smartphone. Deshalb beweist das Ausbleiben von Fehlermeldungen nicht, dass alles funktioniert.

Daraus ergibt sich ein unangenehmes Paradox: Je kleiner die betroffene Gruppe ist, desto länger bleibt der Fehler bestehen. Ein Ausfall bei allen Nutzern wird noch am selben Tag behoben. Ein Ausfall bei fünf Prozent der Besucher kann sogar das nächste Redesign überleben. Besonders nach Releases solltest du das im Blick behalten, denn dabei entstehen die meisten solcher Fehler. Wie du die Messkontinuität sicherst, vertiefen wir im Artikel über Website-Relaunch und Messung.

Typische Ursachen von Fehlern, die nur wenige Nutzer betreffen

Die Bedingungen eines Besuchs unterscheiden sich in mehreren wiederkehrenden Punkten von deinen eigenen. Die folgende Tabelle stellt den abweichenden Bedingungen beim Kunden die häufigsten Fehler und eine Methode gegenüber, mit der du das Problem ohne Rätselraten erkennst.

↔ Scrolle die Tabelle seitlich, um alle Spalten zu sehen.

Zwei Punkte behandeln wir hier bewusst nur kurz, weil ihnen eigene Beiträge gewidmet sind. Hürden auf kleinen Bildschirmen beschreiben wir im Artikel über die Conversion auf Mobilgeräten, die Bedienung ohne Maus und mit Screenreader im Leitfaden über barrierefreie Kontaktwege. Hier geht es ausschließlich um die Erkennungsmethode: Was tust du, wenn du noch nicht weißt, wonach du suchst?

Ein wichtiger Hinweis zum Werkzeug: Meetlead erfasst weder JavaScript-Fehler noch Browserprotokolle und ist kein technisches Monitoring-Tool. Es zeigt das Symptom und die betroffene Person: eine Sitzungsaufzeichnung mit vollständigem Besucherprofil, einschließlich Browser, Gerät und aufgerufener URL, sowie Markierungen für Klicks und Adressänderungen. Um die technische Ursache zu ermitteln – etwa einen konkreten Codefehler, eine Serverantwort oder eine Bibliotheksversion –, brauchst du ein separates Werkzeug und eine Person, die den Code prüft.

Datensignale, die einen schwer sichtbaren Fehler verraten

Du kannst nicht vorhersagen, wo etwas kaputtgehen wird. Du kannst aber lernen, die Spuren zu erkennen, die ein Fehler in den Daten hinterlässt. Die folgenden vier Muster reichen in der Praxis aus, um eine plausible Hypothese aufzustellen.

• Segment ohne jede ConversionEin Browser, ein Betriebssystem oder ein Bereich von Bildschirmbreiten verzeichnet Traffic, aber im gesamten Monat keine einzige Anfrage.
• Klicks ohne WirkungWiederholte Klicks auf dieselbe Stelle, auf die weder eine Adressänderung noch ein weiteres Ereignis folgt.
• Gemeinsamer AusstiegspunktSitzungen aus unterschiedlichen Quellen enden an genau derselben Stelle im Ablauf, obwohl dort nichts zum Abbruch verleitet.
• Besuch ohne erwartete EreignisseEin Besucher scrollt durch die Unterseite und bleibt lange dort, doch Ereignisse, die auf dieser Seite sonst immer auftreten, fehlen.

Beim ersten Signal ist Vorsicht geboten: In kleinen Segmenten kann eine Conversion-Rate von null reiner Zufall sein. Nimm das Signal erst ernst, wenn das Segment eine aussagekräftige Zahl von Besuchen aufweist und andere vergleichbare Segmente normal konvertieren. Das zweite Signal ist das stärkste und am einfachsten zu prüfen: Ein wiederholter Klick auf dieselbe Stelle ist die in Daten festgehaltene Botschaft „Ich klicke, aber nichts passiert“. Anhand des Klickereignisses für ein bestimmtes Element kannst du anschließend prüfen, ob der betreffende Button in allen Segmenten Interaktionen verzeichnet oder nur in einigen.

Werte Klick- und Scroll-Heatmaps für Smartphones und Computer getrennt aus. In der Gesamtsicht können sie ein Muster verdecken, das nur in einer Gruppe auftritt. Wie du Heatmaps richtig auswertest, erklären wir im Ratgeber Heatmaps richtig lesen.

So bestätigst du deine Hypothese mit einer Aufzeichnung

Quantitative Daten zeigen, dass etwas nicht stimmt, und grenzen die betroffene Gruppe ein. Die Aufzeichnung zeigt den Ablauf: was der Besucher versucht hat und an welcher Stelle er aufgegeben hat. Allgemeine Grundsätze für die Auswahl des Materials erklären wir im Artikel Sitzungsaufzeichnungen richtig analysieren. Bei der Suche nach einem Fehler in einer kleinen Nutzergruppe musst du jedoch anders filtern.

1. Filtere nach Profil, nicht nach Datum.Wähle Sitzungen mit dem verdächtigen Browser, Betriebssystem oder Gerät aus, statt die neuesten Besuche der Reihe nach anzusehen.
2. Nimm Besuche, die weit gekommen sind und nichts bewirkt haben.Ein Besucher, der drei Schritte durchlaufen hat und beim vierten verschwunden ist, hatte ein Ziel und ist auf ein Hindernis gestoßen.
3. Beginne an der Entscheidungsstelle.Springe zu der Stelle, an der ein Klick oder Übergang stattfinden sollte, und beobachte, was unmittelbar davor geschieht.
4. Achte auf drei Symptome.Wiederholte Klicks auf dieselbe Stelle, einen plötzlichen Stillstand nach zuvor zügigem Vorgehen und einen Schritt zurück.
5. Mach eine Kontrollprobe.Sieh dir einige Sitzungen mit einem gängigen Browser auf derselben Unterseite an. Läuft dort alles reibungslos, erhärtet sich deine Hypothese.
6. Stell die Bedingung selbst nach.Vergrößerte Schrift, Dunkelmodus, langsamere Verbindung oder ein aktivierter Inhaltsblocker – erst dadurch wird aus der Hypothese ein Fehler, der behoben werden kann.

Der letzte Schritt wird am leichtesten vergessen. Die Aufzeichnung zeigt, dass der Button nicht funktioniert hat, aber nicht, warum. Wenn du die Bedingung selbst nachstellst, wird aus der Beobachtung eine Fehlermeldung, mit der ein Entwickler arbeiten kann. Lässt sie sich nicht reproduzieren, weißt du zumindest, bei wem und auf welchem Gerät du genauer hinsehen musst.

Kundenfragen als günstigster Fehlerdetektor

Bevor irgendein Diagramm einen Rückgang zeigt, schreibt jemand im Chat einen Satz, der leicht übersehen wird. Das ist das günstigste Fehlererkennungssystem, das dir zur Verfügung steht, und das einzige, das vom ersten Tag an funktioniert. Eine Voraussetzung gibt es: Dein Team muss solche Sätze als technische Fehlermeldung behandeln und nicht als Bedienfehler des Nutzers.

• „Ich kann nicht darauf klicken“ – das Element wirkt aktiv, reagiert aber nicht oder wird von etwas anderem verdeckt.
• „Es passiert nichts“ – die Aktion wurde ausgeführt, doch die Seite gibt keinerlei Rückmeldung.
• „Ich sehe diesen Button nicht“ – das Element liegt außerhalb des sichtbaren Bereichs oder verschmilzt mit dem Hintergrund.
• „Das Formular akzeptiert meine Nummer nicht“ – die Validierung lehnt ein korrektes Format ab oder die automatische Vervollständigung hat die Daten in das falsche Feld eingetragen.
• „Die Seite ist bei mir völlig verschoben“ – das Layout bricht bei dieser Auflösung oder mit vergrößerter Schrift auseinander.
• „Ich musste das am Computer öffnen“ – der Ablauf auf dem Smartphone ist unvollständig, und der Kunde hat das Problem selbst umgangen.

Die Antwort „Bei uns funktioniert es“ beendet das Gespräch und vernichtet den einzigen verfügbaren Beleg. Stell stattdessen drei Fragen: Welches Gerät verwendet der Kunde, was genau hat er getan und was hat er gesehen? Ein Live-Chat hilft dabei doppelt, weil der Mitarbeiter die aktuelle Seite des Gesprächspartners sieht und nicht nach der Adresse fragen muss. Wird das Gespräch später mit seinem Verlauf in ein Ticket übernommen, ist ein ähnlicher Satz von einer anderen Person keine Anekdote mehr, sondern ein Muster. Die Auswahl der Felder und Hinweise im Formular beschreiben wir separat im Artikel über das Kontaktformular auf der Website.

Wenn ein Problem mehrere mögliche Ursachen hat, hilft der Leitfaden: Fehlerbehebungsanleitung: Entscheidungsbaum statt zufälliger Versuche.

Prüfroutine nach jeder Änderung

Die meisten Fehler, die nur kleine Nutzergruppen betreffen, entstehen bei einem Release und nicht von selbst. Am günstigsten lassen sie sich deshalb einige Tage nach der Änderung erkennen, wenn noch klar ist, was genau angefasst wurde. Die folgende Liste kostet dich eine Viertelstunde und deckt überraschend viele Probleme auf.

• Durchlaufe den gesamten Weg bis zur Kontaktaufnahme in einem anderen Browser als dem, den du täglich verwendest.
• Wiederhole den Ablauf mit vergrößerter Seite und aktiviertem Dunkelmodus des Betriebssystems.
• Prüfe die Website auf einem älteren Smartphone, das im Unternehmen verfügbar ist, und über eine echte Mobilfunkverbindung.
• Öffne die Website mit aktiviertem Inhaltsblocker und prüfe, ob das Formular und eingebettete Elemente angezeigt werden.
• Vergleiche die nach Browsern und Geräten aufgeschlüsselte Conversion-Rate mit der Woche vor dem Release.
• Prüfe die Klick-Heatmap der wichtigsten Unterseite auf wiederholte Klicks an derselben Stelle.
• Lies die Gespräche und Tickets aus den ersten Tagen nach der Änderung und suche nach Hinweisen, dass etwas nicht funktioniert.

Der letzte Punkt ist oft am ergiebigsten: Er dauert nur wenige Minuten und erfordert kein anderes Werkzeug als den Gesprächsverlauf. Wenn daraus eine Routine statt einer einmaligen Aktion werden soll, nimm diese sieben Punkte in deine Release-Checkliste auf – neben den Tests, die dein Team ohnehin durchführt. Ein Fehler, den du in der Release-Woche findest, kostet eine Korrektur. Derselbe Fehler, den du erst nach einem Quartal findest, kostet dich ein Quartal voller Anfragen.