Defekte Schritte und Selektor-Korrektur

Eine Website ändert sich schon zwischen zwei Scans. Ein Button bekommt eine neue Klasse, ein Formular rutscht einen Block nach unten, über der Seite erscheint ein Newsletter-Fenster. Die aufgezeichnete Journey sagt aber weiterhin „hier klicken“. Deshalb versucht die Wiedergabe nicht, um jeden Preis ans Ende zu kommen: Lieber führt sie einen Schritt nicht aus, als irgendwo zu klicken, wo Sie nie geklickt haben. Hier steht, was die einzelnen Zustände bedeuten und was zu tun ist.

Wie die Wiedergabe ein Element findet

Jeder Schritt enthält mehr als eine Beschreibung seines Elements. Die Wiedergabe probiert sie in fester Reihenfolge und nimmt die erste, die auf der Seite ein sichtbares Element findet:

1. den aufgezeichneten Selektor,
2. die bei der Aufnahme gespeicherten Ersatz-Selektoren,
3. den Text des Elements, zuerst exakt, dann als Teilübereinstimmung,
4. weitere aufgezeichnete Eigenschaften des Elements: id, name, das Label für Screenreader (aria-label) und Testattribute wie data-testid,
5. die aufgezeichneten Koordinaten, aber nur, wenn der Schritt sonst nichts enthält, wenn innerhalb eines iframes geklickt wird oder wenn das aufgezeichnete Ziel den ganzen Bildschirm einnahm.

Hat ein Klick-Schritt einen aufgezeichneten Selektor oder Eigenschaften und findet keiner dieser Wege das Element, klickt die Wiedergabe nicht auf die Koordinaten. An dieser Stelle kann jetzt ein ganz anderes Element liegen, und der Klick wäre eine Aktion, die Sie nie aufgezeichnet haben. Der Schritt erhält den Zustand „Ziel des Schritts nicht gefunden“, und die Wiedergabe macht mit dem nächsten Schritt weiter.

Ein Eingabe-Schritt ist anders: Er muss den Cursor in ein Feld setzen. Wird sein Element nicht gefunden, klickt die Wiedergabe an die Stelle, an der sie ein passendes Feld gefunden hat, sonst an die aufgezeichnete Stelle, und tippt nur, wenn das fokussierte Element ein Eingabefeld ist, das zur Aufnahme passt. Ist es das nicht, wird nichts getippt, der Schritt schlägt fehl und die Journey bricht dort ab.

Ein Ersatz-Selektor stammt weiterhin aus Ihrer Aufnahme, ein darüber gefundener Schritt ist also in Ordnung. Wurde ein Schritt aber nur über Text oder Koordinaten gefunden, wird der erwartete Zustand aus diesem Scan nicht aktualisiert. Dasselbe gilt, solange für den Schritt ein Korrekturvorschlag wartet. Wiederholt sich das, zeigt die Journey „Das Monitoring dieser Journey läuft nicht“.

Was die Schrittzustände bedeuten

Sie finden sie im Scan-Detail, im Panel „Monitoring-Integrität“ und bei den einzelnen Schritten.

Solange die Journey durchläuft, sind das Beobachtungen. Das Panel sagt es selbst: Sie erzeugen keine Befunde, ändern die Bewertung nicht und versenden keine Benachrichtigungen.

Durch ein verdecktes Element wird nie geklickt

Verdeckt ein anderes Element das Ziel des Schritts, erzwingt die Wiedergabe den Klick nicht. Ein erzwungener Klick käme nämlich nicht bei Ihrem Button an, sondern bei dem, was darüber liegt: einem Cookie-Banner, einem Newsletter, einem Chat oder einer Produkttour.

Neben dem Zustand sehen Sie Tag, id und Klassen des verdeckenden Elements. „fixed“ heißt, es scrollt nicht weg, „cover“ gibt an, wie viel des Viewports es einnimmt. Daran erkennen Sie meist, worum es geht:

• Cookie-Banner. Die Wiedergabe erteilt nie selbst eine Einwilligung und schließt das Banner nicht. Erscheint das Banner, muss die Journey Ihren aufgezeichneten Klick darauf enthalten. Fehlt dieser Schritt oder hat sich das Banner seit der Aufnahme geändert, nehmen Sie die Journey neu auf.
• Einmalige Kampagne. Verschwindet das Overlay, läuft der nächste Scan durch. Nichts ändern.
• Dauerhaftes Element (Chat, ein neues Panel). Nehmen Sie die Journey so neu auf, dass ein eigener Schritt es schließt.

Wann eine Journey abbricht

Eine Journey bricht ab, wenn ein Schritt fehlschlägt oder wenn mehrere Schritte hintereinander ihr Ziel nicht finden, auf ein Overlay stoßen oder blind klicken. Im Scan-Detail steht dann „Der Ablauf brach bei Schritt N ab“, und das Panel nennt die Ursache unter „Deshalb gilt die Journey als unterbrochen“.

Für Schritte, die der Scan nicht erreicht hat, zeigt der Vergleich „Schritt nicht verifiziert“. Das heißt nicht, dass die Events verschwunden sind. Der Scan konnte sie nur nicht prüfen.

Die Schaltfläche „Ab Schritt N neu aufnehmen“ öffnet die Aufnahme dieser Journey. Sie können den defekten Schritt mit „Schritt entfernen“ löschen und im Modus „An die gespeicherten Schritte anknüpfen“ die funktionierenden Schritte abspielen lassen und danach weitermachen. Oder Sie wählen „Alle Schritte ersetzen“ und nehmen die ganze Journey neu auf. Wartet bereits ein Korrekturvorschlag, bietet das Verdikt zuerst „Vorgeschlagene Korrektur prüfen“ an.

Der vorgeschlagene Selektor-Fix

Einen neuen Selektor schlägt die Wiedergabe nur für einen Eingabe-Schritt vor: Sein Feld wurde über den aufgezeichneten Selektor nicht gefunden, die Wiedergabe hat aber eindeutig ein Eingabefeld mit denselben Eigenschaften (Typ, Label, name, Testattribut) erkannt und danach verifiziert, dass das Feld den eingegebenen Text enthält. Für einen Klick-Schritt, der über seine weiteren Eigenschaften gefunden wurde, schlägt sie nie einen neuen Selektor vor, höchstens eine geänderte Eigenschaft (siehe unten). Ein über seinen Text gefundener Schritt führt zu keinem Vorschlag. Einen Vorschlag speichert die Wiedergabe nie selbst. Der Vorschlag wartet im Scan-Detail hinter der Schaltfläche „Drifts prüfen“ oder im Verdikt als „Vorgeschlagene Korrektur prüfen“ auf Ihre Entscheidung. Entscheiden können Editoren, Admins und der Projektinhaber.

Prüfen Sie vor dem Übernehmen zwei Dinge:

1. Es ist dasselbe Element. Öffnen Sie den Screenshot des Schritts. Der Selektor muss auf das Feld oder den Button zeigen, den Sie aufgezeichnet haben, nicht auf den daneben.
2. Der Selektor hält. data-testid, name oder eine sprechende id überstehen ein Redesign. Eine Position im Seitenbaum oder eine generierte Klasse nicht.

Übernehmen speichert den vorgeschlagenen Selektor als primär und behält den ursprünglichen als Fallback. Der erwartete Analytics-Zustand ändert sich nicht: Der Schritt wird weiter mit dem verglichen, was Sie schon kennen, und das Monitoring läuft mit dem nächsten Scan weiter.

Ablehnen ändert an der Journey nichts. Der Schritt wird weiter über einen Ersatzweg gefunden, und der erwartete Zustand wird daraus nicht aktualisiert. Meist ist dann eine neue Aufnahme sinnvoll.

Schreibt der Dialog, dass kein eindeutiger stabiler Selektor gefunden wurde, ist der Vorschlag nur informativ. Der Scan hat das Element zur Laufzeit gefunden und die Aktion verifiziert, hat aber nichts, was er speichern könnte. Mit dem Übernehmen halten Sie Ihre Entscheidung fest, die Journey bleibt gleich. Wiederholt sich das bei einem Schritt, nehmen Sie ihn neu auf.

Der Dialog kennt noch eine zweite Art von Vorschlag: eine geänderte Eigenschaft des Elements, etwa den Text eines Buttons. Die Tabelle zeigt dann den ursprünglichen und den neuen Wert. Mit dem Übernehmen erklären Sie die Änderung für diesen Schritt als erwartet, und diese Eigenschaft wird hier nicht erneut gemeldet. Der Selektor ändert sich nicht.

Wann eine neue Aufnahme besser ist

• Das Element, auf das der Schritt zielt, gibt es auf der Website nicht mehr.
• Der Ablauf selbst hat sich geändert, zum Beispiel hat der Checkout einen neuen Schritt oder ein Schritt landet auf einer anderen Seite als üblich.
• Der Korrekturvorschlag zeigt auf ein anderes Element oder bleibt wiederholt nur informativ.
• Das Monitoring läuft nicht, weil Schritte nur über Text oder Koordinaten gefunden werden.

Eine neue Aufnahme kostet mehr als ein übernommener Fix. Der erwartete Zustand bleibt nur erhalten, wenn jeder bisher gespeicherte Schritt mit gleicher Adresse, Aktion und gleichem Selektor noch da ist. Hat sich auch nur einer davon geändert oder fehlt er, wird der erwartete Zustand der ganzen Journey aus den nächsten Scans neu aufgebaut. Es lohnt sich also, einen richtigen Vorschlag zu übernehmen und nur dort neu aufzunehmen, wo sich der Ablauf selbst geändert hat.

Ein Tipp, der die meiste Arbeit spart: Die Aufnahme wählt Selektoren zuerst aus Testattributen (data-testid und ähnliche), dann aus einer nicht generierten id, dem Label für Screenreader und name. Wenn Ihre Entwickler data-testid an die Buttons und Felder Ihres Conversion-Pfads setzen, überstehen die Selektoren auch ein Redesign. Vorher aufgezeichnete Schritte kennen die neuen Attribute aber nicht, nehmen Sie sie nach dem Release also neu auf.