Formularverfolgung im Jahr 2026: Warum Ihre Zahlen nie mit denen Ihres CRM übereinstimmen (und wie Sie das beheben können)

Verfasst von

Josh Silverbauer

Veröffentlicht 10. Juni 2026 Kommentare

Formular-Tracking sollte eigentlich eine ganz einfache Sache sein. Man fügt einen GTM-Trigger ein, richtet ihn auf „Formularabsendung“, sieht eine Zahl in GA4 auftauchen und macht mit seinem Leben weiter. Einfach. Erledigt. Zeit zum Feiern.

Und dann, sechs Monate später, fragt dein Kunde, warum sein CRM 412 Leads anzeigt, in GA4 aber 600. Oder 250. Oder eine andere Zahl, die keinen Sinn ergibt.

Formulare sind das A und O für die meisten Lead-Generierungsunternehmen. Das Formular ist die Conversion. Es ist der Moment, in dem der anonyme Nutzer zum Lead wird, zur Pipeline wird und (hoffentlich) schließlich zum Umsatz. Und wir tracken diesen entscheidenden Moment mit einer Methode, die im Jahr 2026 genauso versagt wie Raygun.

Lass uns darüber sprechen, warum.

Was du denkst, was passiert, vs. was tatsächlich passiert

Hier ist, was die meisten Leute annehmen, was beim Formular-Tracking passiert:

Der Nutzer füllt das Formular aus → der Nutzer klickt auf „Absenden“ → GTM registriert das Absenden → die Conversion wird ausgelöst → alle sind zufrieden.

Was tatsächlich in erschreckend vielen Fällen passiert, ist Folgendes:

Der Nutzer füllt das Formular aus → Das Formular befindet sich in einem Iframe, den GTM nicht erkennen kann → Das „Submit“-Ereignis wird nicht weitergeleitet → GTM erhält keine Informationen → Die Conversion wird nicht ausgelöst → Das CRM füllt sich mit Leads, die in der Analyse nicht vollständig erfasst werden.

ODER

Der Nutzer füllt das Formular aus → das Formular-Absende-Ereignis wird aufgrund eines seltsamen JavaScript-Ereignisses zehnmal ausgelöst → GTM löst die Formular-Konversion zehnmal aus → das Formular-Absende-Ereignis wird auch beim Absenden der Suche ausgelöst → die Anzahl der Leads im CRM wird um das Zehnfache überzählt.

In der Kluft zwischen diesen beiden Szenarien geht die Zuordnung unter. Und diese Kluft wird immer größer statt kleiner, denn das moderne Web steht der Funktionsweise clientseitiger Listener aktiv feindlich gegenüber.

Schauen wir uns also einmal genauer an, inwiefern sie dich im Stich gelassen haben.

Fünf Fälle, in denen clientseitige Listener dich im Stich lassen

1. Eingebettete Formulare sind eine Black Box

Das ist ein wichtiger Punkt. Viele der Formulare, die dir wirklich wichtig sind – HubSpot, Marketo, Pardot, Calendly, Typeform, dein schickes Buchungs-Widget – werden in einem Cross-Origin-Iframe geladen. Und Browser lassen GTM – ganz höflich – nicht in den Iframe eines anderen hineinsehen. Das ist eine Sicherheitsfunktion, kein Fehler.

Dein GTM-Trigger „Formularübermittlung“ wartet also darauf, dass ein Ereignis eintritt, das aus seiner Sicht niemals eintreten wird. Der Nutzer sendet das Formular ab, der Lead landet in HubSpot, und Ihr Trigger bleibt sich selig unbewusst, dass überhaupt etwas passiert ist. Die Formularanbieter stellen in der Regel ihre eigenen Ereignisse bereit, HubSpot löst ein message Ereignis aus, auf das Sie achten können, Calendly sendet event_scheduled aus, aber man muss wissen, dass man danach suchen muss. Meistens findet man das erst an einem trüben Nachmittag heraus, während man Zahlen abgleicht.

Eine ganze Generation der Formularverfolgung basiert auf einer schönen, aber trügerischen Annahme: „Der Nutzer landet auf /thank-you, also zähle ich die Seitenaufrufe der Dankesseite.“

Ach, wenn es doch nur so einfach wäre. Wenn die Website auf React basiert, wird die „Seite“ nie neu geladen. Die URL kann sich clientseitig ändern oder auch nicht, die Abfrageparameter können entfernt werden, und deine auf Seitenaufrufen basierende Conversion wird entweder inkonsistent oder gar nicht ausgelöst. Schlimmer noch: Nutzer setzen Lesezeichenfür Dankesseiten und aktualisieren diese, was deine Zahlen in die andere Richtung aufbläht. Jetzt zählst du sowohl zu wenig als auch zu viel. Herzlichen Glückwunsch, du hast das Maximum an Falschheit erreicht.

3. Der native „Submit“-Trigger zählt auch Formulare mit, die nicht tatsächlich abgeschickt wurden

Der in GTM integrierte Trigger für das Absenden von Formularen greift auf das submit-Ereignis des Browsers zurück. Klingt gut. Das Problem? Dieses Ereignis kann noch bevor die Validierung läuft, ausgelöst werden. Wenn ein Nutzer also seine E-Mail-Adresse falsch eingibt, gibt das Formular die Fehlermeldung „Bitte geben Sie eine gültige E-Mail-Adresse ein“ aus, die Übermittlung findet nie statt, und Ihr Trigger hat dies bereits als Conversion gezählt.

Multiplizieren Sie das mit jeder fehlenden Telefonnummer, und Sie erhalten eine Conversion-Zahl, die still und leise, aber stetig aufgebläht wird. Der CPA Ihres Kunden sieht besser aus, als er tatsächlich ist. Der Finanzvorstand Ihres Kunden wird das irgendwann herausfinden. Das ist keine Überraschung, über die man sich freut.

4. Der native „Submit“-Trigger zählt Formulare mit, die er nicht zählen sollte

Und dann löst plötzlich das Absenden von GTM-Formularen bei Formularen wie Suchanfragen und Karten-/Wegbeschreibungen aus. Das ist ja toll, wenn man eigentlich nur wertvolle Formulare nachverfolgen will.

5. Dynamische DOMs führen dazu, dass deine Selektoren nicht mehr funktionieren

Du hast einen tollen Trigger geschrieben, der auf #contact-form-submit abgestimmt war. Er hat super funktioniert. Dann hat das Entwicklerteam ein Redesign veröffentlicht, der Button heißt nun .btn-primary--v3, das Formular wird nach dem Laden der Seite durch ein Skript eingefügt, das auslöst, wann immer es ihm gerade passt, und dein sorgfältig ausgearbeiteter CSS-Selektor verweist nun auf ein Element, das gar nicht mehr existiert.

Clientseitiges Tracking, das von der Struktur der Seite abhängt, setzt voraus, dass sich die Seite niemals ändert. Seiten ändern sich jedoch ständig. IMMER.

6. Der Nutzer verlässt die Seite, bevor Ihr Tag fertig ist

Selbst wenn alles glatt läuft, bist du in einem Wettlauf. Das Formular wird abgeschickt, die Seite leitet weiter, und dein Conversion-Tag hat nur wenige hundert Millisekunden Zeit, seine Anfrage auszulösen, bevor der Browser die Seite schließt und weitermacht. Bei einer langsamen Verbindung, einem ressourcenintensiven Tag oder einer etwas zu eifrigen Weiterleitung verliert das Tag den Wettlauf. Der Lead ist entstanden. Das Tracking hat versagt.

Und das noch bevor wir überhaupt zu Werbeblockern, ITP und Consent Gating kommen, die gtm.js still und leise außer Gefecht setzen,sodass der Listener gar nicht erst geladen wird. Safaris 7-Tage-Cookie-Limit und der stetige Vormarsch der Tracking-Verhinderung bedeuten, dass ein beträchtlicher Teil Ihrer Nutzer bereits mit deaktiviertem clientseitigem Tracking unterwegs ist.

Die Lösung, Teil eins: Hör auf zu schnüffeln, fang an, auf die Wahrheit zu hören

Als Erstes solltest du aufhören, durch Beobachtung des DOMs zu schleifen, ob eine Übermittlung stattgefunden hat, und stattdessen das Formular so einrichten, dass es dir mitteilt, wenn die Übermittlung tatsächlich erfolgreich war.

Das bedeutet, dass ein dataLayer-Eintrag im eigentlichen Erfolgs-Callback des Formulars gesetzt wird. Nicht beim Klick. Nicht beim Absenden. Sondern in dem Moment, in dem der Code des Formulars selbst bestätigt, dass die Übermittlung erfolgreich war:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'form_success',
  form_id: 'contact_main',
  form_location: 'pricing_page'
});

Bei eingebetteten Formularen bedeutet das, das eigentliche Ereignis des Anbieters zu verknüpfen. HubSpot stellt beispielsweise ein globales Absendeereignis zur Verfügung, das man einbinden und in einen sauberen dataLayer-Push umwandeln kann. Der Punkt ist derselbe: Das Formular weiß, wann es erfolgreich war. Frage es, nicht den Browser.

Diese eine Änderung behebt das Problem mit den Validierungsfehlern, das SPA-Problem und den Großteil des Selektor-Problems auf einen Schlag. Das ist der Unterschied zwischen Messen und Raten.

Die Lösung, Teil 2: Die eigentliche Quelle der Wahrheit befindet sich auf dem Server

Das Problem ist jedoch folgendes: Selbst ein einwandfreier dataLayer-Push findet immer noch im Browser statt, was bedeutet, dass er nach wie vor von Werbeblockern betroffen ist, nach wie vor der Einwilligungsabfrage unterliegt, nach wie vor davon betroffen ist, dass der Nutzer den Tab eine halbe Sekunde zu früh schließt, und nach wie vor von all den browserbasierten Macken betroffen ist, über die wir uns gerade in 800 Wörtern beschwert haben.

Das System, das tatsächlich und zweifelsfrei weiß, dass ein echter Lead eingegangen ist, ist nicht der Browser. Es ist das Backend Ihres Formulars. Ihr CRM. Der Webhook, der die Übermittlung abfängt. Dieses System rät nicht – es hat den Lead erhalten. Es kann ihn validieren, Duplikate entfernen, Bots aussortieren und bestätigen, dass er echt ist, noch bevor überhaupt eine Conversion ausgelöst wird.

Starten Sie die Konvertierung also von dort aus.

Hier spielt serverseitiges GTM seine Stärken aus. Anstatt sich darauf zu verlassen, dass der Browser die Daten selbst übermittelt, lassen Sie Ihr Backend (oder einen Make.com-Workflow oder Ihr CRM über eine der Stape-CRM-Apps) die validierten Daten über das Measurement Protocol oder einen Webhook an Ihren Server-Container senden. Der Server-Container leitet diese Daten dann an GA4, Google Ads, Meta CAPI oder wo auch immer weiter – mit einer Nutzlast, die Sie vollständig kontrollieren.

Die Siege häufen sich schnell:

Es werden nur echte Leads gezählt. Die Validierung erfolgte vor dem Auslösen des Ereignisses, sodass keine Phantom-Conversions mehr aufgrund von E-Mail-Adressen mit Tippfehlern auftreten.
Keine Bots, keine Duplikate. Ihr Backend kann Daten deduplizieren und filtern, bevor sie in Ihre Berichte oder auf Ihre Werbeplattformen gelangen.
Ad-Blocker und ITP spielen für Ihre wichtigste Conversion keine Rolle mehr. Das Ereignis wird serverseitig ausgelöst. Es gibt kein Browserskript, das ein Ad-Blocker blockieren könnte.
Es spielt keine Rolle, ob der Nutzer die Seite verlässt. Die Übermittlung ist bereits auf Ihrem Server eingegangen. Ob der Nutzer den Tab schließt, hat nun keinen Einfluss mehr darauf, ob die Konversion erfasst wird.
Sie können den Kreis schließen. Da das Ereignis mit einem echten CRM-Datensatz verknüpft ist, zählen Sie nicht nur ausgefüllte Formulare, sondern können letztendlich qualifizierte Leads, abgeschlossene Geschäfte und echtes Geld erfassen. Das ist der größte Vorteil, und mit clientseitigem Tracking lässt sich das nicht erreichen.

Und wenn du schon dabei bist: Lass Stape's Cookie Keeper deine First-Party-Cookies über die 7-Tage-Frist von Safari hinaus verlängern und den Custom Loader dein Tracking aus dem Fadenkreuz der Werbeblocker halten, damit die clientseitige Hälfte des Ganzen (die für die gesamte Customer Journey nach wie vor wichtig ist) so intakt wie möglich bleibt. Denk einfach daran: Wenn ein Nutzer über die Einwilligungsfunktion widerspricht, respektierst du das. Die Suche nach der Wahrheit ist kein Freibrief, um Personen zu tracken, die Nein gesagt haben.

Fazit

Clientseitige Formular-Listener wurden für ein Web entwickelt, das es heute nicht mehr gibt – ein Web mit vollständigen Seitenneuladungen, einfachen HTML-Formularen, ohne Iframes, ohne Werbeblocker und mit einem Browser, der nicht aktiv versuchte, Nutzer vor Tracking zu schützen. Dieses Web gibt es nicht mehr. Doch leider hat die Welt noch nicht aufgeholt.

Im Jahr 2026 erfolgt der Umzug in mehreren Schritten:

1.
Stelle sicher, dass der dataLayer erst bei tatsächlichem Erfolg aktualisiert wird. Hör auf, anhand des DOM zu raten.
2.
Achte stattdessen auf die tatsächlichen Ereignisse der eingebetteten Formulare, anstatt zu versuchen, einen Iframe nachzuverfolgen, in den du keinen Einblick hast.
3.
Senden Sie die Konvertierung vom Server, Ihrem Backend oder CRM, wo der Lead tatsächlich und nachweisbar vorhanden ist, über einen serverseitigen Container.

Ihre Formulare sind das Wichtigste, was Sie messen. In diesem Moment entsteht der eigentliche Wert. Es lohnt sich, sie ernsthaft zu überwachen – und nicht nur mit einem browserbasierten Listener, der die Daumen drückt und hofft, dass das „submit“-Ereignis heute funktioniert.

Und jetzt mach dich daran, deine Formulare zu überarbeiten, du großartiger Zahlenfreak. Die Abstimmungs-Tabelle deines Finanzchefs zählt auf dich, und dieses Mal wird es tatsächlich alles aufgehen. Viel Spaß beim Nachverfolgen!

Möchtest du dich dem Server anschließen?

Kostenlos testen