Unser Webdesign-Konfigurator führt Interessenten durch mehrere Schritte — Paketwahl, Zusatzleistungen, Mengen-Einstellungen. Bis vor kurzem war dieser Trichter für unser Analytics-Tool praktisch unsichtbar.

Auf den Punkt: Der Konfigurator ist rein JavaScript-getrieben — es gibt keine Seitenwechsel, an denen sich Standard-Tracking-Attribute festmachen ließen. Wir haben deshalb gezielt neue Events aus dem JavaScript heraus ausgelöst und dabei gleich zwei bestehende Ungenauigkeiten im Tracking behoben.

Das Problem: unsichtbare Abbrüche

Ohne Event-Tracking wussten wir zwar, wie viele Besucher auf der Konfigurator-Seite landen und wie viele am Ende eine Anfrage abschicken — aber nicht, an welcher Stelle dazwischen jemand abspringt. Genau das ist aber die Information, die zeigt, wo sich der Konfigurator noch verbessern lässt.

Was wir konkret ergänzt haben

  • webdesign-wizard-step — feuert bei jeder Schritt-Navigation im Konfigurator (Tab-Klick, "Weiter", "Zurück") und erfasst dabei Schritt, Herkunft und Navigationsmethode. Das ist die einzige Stelle, an der sich Drop-off im Konfigurationsprozess überhaupt beobachten lässt.
  • webdesign-addon-stepper — erfasst Klicks auf die Mengen-Stepper, etwa bei "Zusätzliche Unterseiten" oder "Lokale Städteseiten".

Zwei Bugs, die nebenbei aufgefallen sind

Bei der Arbeit an den neuen Events sind uns zwei bestehende Ungenauigkeiten aufgefallen, die wir gleich mitbehoben haben:

  • Calendly-Klicks feuerten doppelt — einmal über ein eigenes Event, einmal über einen generischen Fallback für ausgehende Links. Der Fallback überspringt jetzt Elemente, die bereits ein eigenes Tracking-Attribut mitbringen — das behebt das Problem site-weit, nicht nur für Calendly.
  • Formular-Submits feuerten doppelt — ein Button-Klick-Event unabhängig vom Ergebnis der Validierung, plus ein generischer Versuchs-Listener unabhängig vom tatsächlichen Ausgang. Jetzt feuert das Submit-Event nur bei clientseitig validen Versuchen, gefolgt von einem separaten Erfolgs- oder Fehler-Event je nach echtem Ergebnis des Server-Requests.

Wie wir es geprüft haben

Verifiziert haben wir das per direkter Browser-Interaktion: alle drei Wege durch den Konfigurator-Wizard, die Mengen-Stepper, den Outbound-Link-Schutz (Calendly feuert nicht mehr doppelt, andere externe Links weiterhin normal) sowie Formular-Erfolg, -Fehler und blockierte Validierung. Der komplette Produktions-Build lief anschließend mit 67 Seiten fehlerfrei durch.