0170 598 8648info [at] innosirius [dot] de
Leadgenerierung und Wachstum

Wo Leads im Formular verschwinden — und warum

Innosirius Redaktion··11 Min. Lesezeit
Wo Leads im Formular verschwinden — und warum

Was zwischen Absenden und Eingang passiert

Wenn jemand auf „Absenden" klickt, erscheint eine Bestätigungsmeldung. Diese Meldung sagt: Der Browser hat die Daten übertragen. Sie sagt nichts darüber aus, was danach geschieht.

Der Weg von „abgeschickt" bis „im Postfach" besteht aus mehreren voneinander unabhängigen Schritten. Jeder davon kann scheitern, ohne dass der Absender oder der Empfänger es bemerkt.

Vom Browser zum Formularsystem

Die Daten kommen beim System an, das das Formular betreibt — oft ein externer Anbieter. Dieser Schritt funktioniert meistens. Aber hier enden die Garantien. Was danach kommt, ist ein separater Vorgang, der nach dem Klick und vollständig unabhängig vom Browser des Interessenten abläuft.

Vom Formularsystem zur Weiterleitung

Das System leitet die Daten jetzt irgendwo hin — an eine E-Mail-Adresse, an ein anderes System, an eine Aufgabe in einer Benachrichtigungsreihe. Diese Weiterleitung ist eigenständig. Wenn sie scheitert, sieht der Absender trotzdem die Bestätigungsseite. Das System zählt eine Einsendung. Auf Ihrer Seite erscheint nichts.

Häufige Stellen, an denen dieser Schritt bricht:

  • Die Zieladresse hat sich geändert, die Konfiguration nicht.
  • Der externe Dienst hat ein monatliches Sendekontingent erreicht — und stellt die Weiterleitung still ein, ohne Fehlermeldung.
  • Der empfangende Server hat die Nachricht einmalig abgelehnt; das Wiederholungsfenster lief ab, ohne dass jemand benachrichtigt wurde.
  • Eine Änderung an einem anderen Teil des Systems hat die Verbindung unterbrochen.

E-Mail-Zustellung

Selbst wenn die Weiterleitung gelingt, ist E-Mail kein verlässlicher Zustellweg für automatisiert versendete Nachrichten. Spam-Filter bewerten sie anders als Nachrichten, die von einer echten Adresse kommen — nicht wegen des Inhalts, sondern wegen der technischen Konfiguration des Absenders: Absenderkennung, Versandvolumen, Einträge in DNS-Zonen, die für normalen E-Mail-Verkehr nie eingerichtet werden mussten.

Eine Nachricht kann dabei:

  • im Spam-Ordner landen und dort ungesehen verfallen,
  • vom empfangenden Server zurückgewiesen werden, ohne Rückgabe ans Formularsystem,
  • die Inbox erreichen, aber von einem clientseitigen Filter in einen Ordner verschoben werden, den niemand täglich liest.

Was sichtbar ist — und was nicht

Das eigentliche Problem liegt nicht darin, dass diese Fehler auftreten. Sie treten immer gelegentlich auf. Das Problem ist, dass sie auf der Seite des Formulars unsichtbar bleiben. Die Bestätigungsseite wurde ausgespielt. Die Statistik zählt eine Einsendung. Das Formular-Interface zeigt kein Warnsignal.

Erst wer die Zahl der eingegangenen Einsendungen mit der Zahl der tatsächlich angekommenen Meldungen vergleicht, sieht die Differenz. Dieser Vergleich ist selten automatisiert. Meistens fällt er erst auf, wenn jemand nachfragt — und dann ist die Lücke oft Wochen alt.

Wo Daten tatsächlich verloren gehen

Das Formular ist erreichbar, der Absenden-Button funktioniert, und trotzdem kommt die Anfrage nicht an. Dieser Zustand ist häufiger als er sein sollte — weil die Stellen, an denen Daten abhandenkommen, selten dort liegen, wo man zuerst nachschaut.

Im Moment des Absendens

Viele Formulare prüfen die Eingaben im Browser, bevor sie die Daten an den Server schicken. Solange diese Prüfung anspringt, bekommt die Nutzerin Rückmeldung. Schlägt sie still fehl — weil ein Skript blockiert wird, weil die Internetverbindung im falschen Moment schwächelt, weil das Gerät zu alt ist — schickt das Formular nichts ab, zeigt aber auch keine Fehlermeldung. Die Nutzerin sieht vielleicht nichts, vielleicht einen kurzen Ladeindikator, der sich auflöst. Sie denkt, die Anfrage sei durch.

Das Gleiche passiert, wenn der Server die Anfrage entgegennimmt, aber kein schriftliches Bestätigungssignal zurückschickt. Aus der Nutzerin Sicht: Formular abgeschickt. Aus dem System heraus: nichts angekommen.

Auf dem Weg ins Postfach

Ein Formular, das funktioniert, schickt in der Regel zwei E-Mails: eine Bestätigung an die Absenderin, eine Benachrichtigung an das Team. Beide können im Spam-Filter des Empfängers landen — nicht weil der Inhalt problematisch ist, sondern weil die sendende Adresse keine Prüfinformationen hinterlegt hat, die Mailserver als Vertrauenssignal erwarten. Kein Hinweis auf der Absenderseite, dass etwas fehlt. Tritt das systematisch auf, fehlen nicht einzelne Anfragen, sondern alle. Der Fehler sieht aus wie fehlende Nachfrage.

In der Weiterverarbeitung

Formulare werden selten als Endziel betrieben. Die Daten sollen irgendwo ankommen: im Postfach der richtigen Person, in einem System, das Anfragen verwaltet, in einer Liste, die jemand morgens öffnet. Jeder dieser Schritte ist ein Ort, an dem eine Verbindung nicht aufgebaut wird, ein Feld falsch zugeordnet ist, eine Bedingung nicht greift.

  • Ein Pflichtfeld ist im Formular als optional markiert — die Daten kommen an, aber unvollständig.
  • Das Datumsfeld erwartet ein amerikanisches Format, bekommt ein europäisches — der Eintrag wird gespeichert, aber nicht auffindbar.
  • Der Filter, der Anfragen weiterleitet, prüft eine Spalte, die seit dem letzten Update umbenannt wurde — Anfragen landen nirgendwo.

Keiner dieser Fehler gibt sich zu erkennen. Das Formular meldet Erfolg. Die Bestätigung geht raus. In der Verwaltung fehlt der Eintrag.

Bei mehrstufigen Abläufen

Wenn eine Anfrage mehrere Schritte durchläuft — etwa eine E-Mail-Bestätigung, ein Auswahlschritt, eine Weiterleitung auf eine andere Seite — verliert jeder einzelne Schritt einen Teil der Personen. Nicht durch einen Fehler, sondern durch Unterbrechung: das Gerät wird weggelegt, die Bestätigungsmail kommt nicht durch, der Folgeschritt lädt nicht vollständig. Was am Ende fehlt, ist nicht messbar, wenn man nicht weiß, wie viele am ersten Schritt begonnen haben.

Das ist die Stelle, an der eine Strecke zeigt, was sie tatsächlich leistet — oder eben nicht. Wer nur das Ende misst, sieht eine Zahl, aber keine Lücke.

Was Qualifizierungsstrecken technisch leisten — und was nicht

Eine Qualifizierungsstrecke ist, technisch gesehen, eine geordnete Abfolge von Formulareingaben mit Verzweigungslogik. Wer Frage drei mit „Ja" beantwortet, sieht Frage vier — wer „Nein" antwortet, landet auf einem anderen Ast. Das ist die Leistung: Daten nach Regeln sortieren und an unterschiedliche Stellen weiterleiten.

Was sie nicht leistet: Absicht erkennen. Eine Person, die auf jede Frage die „richtige" Antwort gibt, weil sie die Logik durchschaut, landet im selben Segment wie jemand, der dieselben Antworten meint. Die Strecke unterscheidet nicht zwischen beiden. Sie protokolliert Eingaben, keine Haltungen.

Was hinter den Verzweigungen passiert

Jede Verzweigung ist eine Bedingung: Feldwert gleich X, dann Route A. Mehrere Bedingungen können sich überlagern — dann entscheidet die Reihenfolge, in der sie geprüft werden, nicht die inhaltliche Logik. Ein Datensatz, der zwei Bedingungen gleichzeitig erfüllt, landet in der ersten, die zutrifft. Ob das fachlich sinnvoll ist, sieht die Strecke nicht.

Felder, die nicht abgefragt werden, sind unsichtbar. Wer die Budgetfrage weglässt, weil sie sich unangenehm anfühlt, erhält keine Budgetinformation. Aber es bedeutet auch: die nachgelagerte Sortierung kann diese Dimension nicht nutzen. Eine Strecke, die nach Kaufzeitpunkt fragt, aber nicht nach Eigenkapital, kann nach Dringlichkeit sortieren — nicht nach Finanzierbarkeit.

Wo die Daten stehen — und wo nicht

Die ausgefüllten Felder landen irgendwo: in einem Postfach, in einer Tabelle, in einem angebundenen System. Aber nur die Felder, die explizit übergeben werden. Wenn die Strecke zehn Fragen stellt, die Übergabe aber nur fünf Felder weiterreicht, sind fünf Antworten weg — nicht verloren im üblichen Sinne, sondern nie weitergeleitet. Das passiert nicht durch Fehler, sondern durch Konfiguration.

Teilabbrüche sind ein eigenes Thema. Wer die Strecke auf Schritt drei verlässt, hinterlässt in vielen Systemen keine Spur. Es sei denn, das System ist so eingerichtet, dass es bereits beantwortete Felder zwischenspeichert. Das ist keine Standardeinstellung — es muss explizit so gebaut worden sein.

Was die Logik nicht sieht

Strecken funktionieren gut, wenn die Bedingungen zur echten Nachfrage passen. Passt die Kategorisierung nicht mehr zur Realität — weil sich der Markt verschoben hat, weil eine neue Nutzergruppe hinzukommt, weil sich Produktkategorien geändert haben —, sortiert die Strecke weiter, aber falsch. Sie zeigt keinen Fehler. Die Daten kommen an, sie kommen nur in den falschen Gruppen an. Das fällt in der Regel nicht am nächsten Tag auf.

Die Strecke sieht auch nicht, was eine Person nicht eingibt. Wer den Bereich „Budget unter 200.000 Euro" wählt, weil es keinen Bereich „ich weiß es noch nicht" gibt, hat nicht gelogen — er hat die nächstliegende verfügbare Option gewählt. Die Kategorie enthält dann zwei verschiedene Gruppen, und kein System trennt sie nachträglich.

  • Verzweigungen reagieren auf Eingaben, nicht auf Motive.
  • Felder, die nicht abgefragt werden, existieren für die Strecke nicht.
  • Falsch angelegte Kategorien produzieren saubere Daten mit falschen Schlüssen.
  • Teilabbrüche sind nur dann sichtbar, wenn das System ausdrücklich dafür gebaut wurde.

Das sind keine Schwächen, die sich beheben lassen. Es sind die Grenzen des Werkzeugs — und sie gelten unabhängig davon, wie aufwendig die Oberfläche aussieht oder wie viele Schritte die Strecke hat.

Wie man erkennt, ob eine Strecke funktioniert

Dass ein Formular abgeschickt werden kann, ist kein Beweis dafür, dass es funktioniert. Das ist der Unterschied zwischen dem, was die Oberfläche zeigt, und dem, was tatsächlich passiert: Eine Abschlussseite, ein „Danke"-Text, ein Ladesymbol, das verschwindet — keines davon sagt etwas darüber aus, ob die Daten dort ankamen, wo sie ankommen sollten.

Wer erkennen will, ob eine Qualifizierungsstrecke tatsächlich funktioniert, muss sie von beiden Enden prüfen: Was wurde abgeschickt, und was ist angekommen? Dazwischen liegt ein Bereich, der für die absendende Person vollständig unsichtbar ist.

Der Testdurchlauf als Messinstrument

Die einfachste Methode ist ein vollständiger Testdurchlauf mit echten, erkennbaren Daten — einem Namen oder einer Mailadresse, die sich im Ziel eindeutig identifizieren lässt. Wenn dieser Testdatensatz nach dem Absenden dort auftaucht, wo er auftauchen soll, so wie er ankommen soll, ist das ein Beweis für den Stand im Moment des Tests. Nicht mehr.

Was dabei oft fehlt: der Abgleich der Felder. Das Formular hat zwölf Felder. Im Ziel sind zehn befüllt. Welche fehlen, und warum? Nicht selten liegt es daran, dass ein Feld im Formular einen anderen internen Namen trägt als das entsprechende Feld im Ziel — und die Zuordnung irgendwann still gebrochen ist, ohne dass irgendjemand es bemerkt hat.

Mengenverhältnisse als Hinweis

Ein zweiter Ansatz: Wie viele Einträge gehen ein, verglichen mit dem, was das Formular selbst zählt? Wenn ein Formular an einem Tag zwanzig Mal abgeschickt wurde, aber nur achtzehn Einträge ankamen, sind zwei Einträge irgendwo verschwunden. Das kann viele Ursachen haben — unterbrochene Übertragungen, abgebrochene Verbindungen, Filterregeln im Ziel — aber die Abweichung als solche ist erkennbar, wenn beide Zahlen vorliegen.

Das Problem: Viele Strecken erheben nur eine dieser Zahlen. Das Formular zählt Absendungen. Das Ziel zählt Ankünfte. Beide Zahlen für sich sagen nichts. Erst der Vergleich ergibt einen Befund.

Was eine regelmäßige Prüfung bedeutet

Ein Testdurchlauf zum Zeitpunkt der Einrichtung reicht nicht. Strecken können nach Monaten brechen, ohne dass jemand aktiv etwas geändert hat: ein Update des genutzten Dienstes, ein abgelaufenes Passwort, ein Zertifikat, das nicht mehr gültig ist. Wer seine Strecke nur einmal geprüft hat, weiß nur, dass sie einmal funktioniert hat.

Sinnvoller ist eine Prüfung, die in regelmäßigen Abständen wiederholt wird — und deren Ergebnis nicht „kein Fehler" lautet, sondern: Testdatensatz X ist angekommen, alle Felder vollständig, Zeitstempel Y. Das ist ein nachvollziehbarer Befund. „Kein Fehler" ist keiner.

  • Testdurchlauf mit erkennbaren Daten: Was kam an, was fehlte?
  • Feldabgleich: Stimmen die Bezeichnungen überein, stimmt die Zuordnung?
  • Mengenvergleich: Wie viele Absendungen, wie viele Ankünfte?
  • Zeitstempel prüfen: Wie lang ist der Weg zwischen Absenden und Eintreffen?
  • Wiederholte Tests: nicht nur bei der Einrichtung, sondern nach Änderungen und regelmäßig dazwischen.

Wer diese Prüfungen nicht durchführt, arbeitet mit einem Glaubenssatz: dass die Strecke noch funktioniert, weil sie einmal funktioniert hat. Das ist kein belastbarer Befund. Es ist eine Annahme, die sich erst dann auflöst, wenn jemand fragt, warum eine bestimmte Anfrage nie eingegangen ist.

Was bleibt, wenn der Fehler unsichtbar ist

Das Tückische an einem stillen Fehler ist nicht der Fehler selbst. Es ist die Schlussfolgerung, die man daraus zieht, ohne zu wissen, dass man zieht.

Wenn eine Anfrage ankommt, zählt man sie. Wenn sie nicht ankommt, nimmt man an, dass sie nie gestellt wurde. Und weil diese Annahme in den meisten Wochen stimmt, bleibt kein Verdacht übrig.

Die Entscheidung, die auf falschen Zahlen aufbaut

Angenommen, ein Maklerbüro bekommt laut Posteingang vier Anfragen pro Woche. Eine davon entwickelt sich zum Auftrag. Die Quote klingt normal. Niemand ahnt, dass in derselben Woche drei weitere Anfragen abgeschickt wurden und nie ankamen.

Auf dieser Basis wird entschieden: kein zweiter Mitarbeiter notwendig, das Werbebudget bleibt, die Seite mit dem Kontaktformular braucht keine Aufmerksamkeit. All das wäre vielleicht anders gelaufen, wenn man gewusst hätte, dass ein Teil der Anfragen still verschwand.

Zahlen, die fehlen, fehlen still. Sie erzeugen kein Rauschen, keinen Alarm, keinen Hinweis darauf, dass etwas nicht stimmt.

Was besonders lange unentdeckt bleibt

Nicht jede Anfrageseite wird regelmäßig auf ihre Funktion geprüft. Für eine Seite, die vor drei Jahren aufgesetzt wurde und seitdem läuft, wird das selten gemacht. Das Formular sieht aus wie immer, die Bestätigungsseite erscheint, nichts deutet auf ein Problem hin.

Dann ändert sich etwas — ein Update, ein Serverumzug, eine neue E-Mail-Adresse im Hintergrund — und von diesem Moment an kommen keine Nachrichten mehr an. Nicht weniger. Keine.

In der ersten Woche fällt das nicht auf. In der zweiten auch nicht. Es gibt gerade weniger Anfragen, denkt man sich, das gibt es. Im dritten Monat fragt jemand, warum das Formular so wenig bringt — und beginnt, das Formular zu überarbeiten, obwohl das Formular nicht das Problem ist.

Worin sich der Schaden zeigt

  • Entscheidungen über Werbebudgets, die auf einem zu niedrigen Eindrucksniveau basieren
  • Interessentinnen und Interessenten, die sich woanders gemeldet haben, weil sie keine Antwort bekamen
  • Kapazitätsplanung, die einen ruhigeren Markt annimmt als tatsächlich vorhanden
  • Kampagnenoptimierungen, die auf Zahlen aufbauen, die nie vollständig waren

Das Besondere an dieser Art von Schaden: Er lässt sich im Nachhinein kaum mehr nachweisen. Wer wann ein Formular abgeschickt hat und nie eine Antwort bekam, ist nicht mehr rekonstruierbar. Die Person ist weitergegangen. Das Formular schweigt.

Was bleibt, ist eine stille Verzerrung der eigenen Wahrnehmung — eine, die sich über Monate hinweg einschreibt und am Ende wie die Wirklichkeit aussieht. Nicht weil jemand nachlässig war, sondern weil es keinen Moment gab, in dem der Fehler sichtbar wurde.

Passende LeistungNeukundengewinnung von Innosirius→

Weitere Beiträge

Beratung anfragen

Bereit für Ihr nächstes Projekt?

Sprechen wir über Ihre Anforderungen und wie individuelle Software Ihr Unternehmen voranbringt.

Kostenlos & unverbindlich Individuelle Analyse DSGVO-konform