Form submission tracking is the most important event in your GA4 setup. When it works, you can measure exactly which pages and channels drive demo requests and signups. When it breaks — and it breaks more often than most teams realize — GA4 silently reports zero conversions while your sales team is fielding real inquiries. The disconnect can go undetected for days or weeks, corrupting the data you use to make budget and content decisions. Before you can fix the problem, you need to understand why it happens.
Why GA4 does not show form submissions
GA4 records a form submission only when a tracking event fires, reaches the GA4 measurement protocol endpoint, and matches a configured key event. Every link in this chain is a potential break point. The most common failure scenarios: the event fires in Google Tag Manager but never reaches GA4, the event reaches GA4 but is blocked by consent mode, the event name does not match the key event configured in your property, or the page redirect fires so quickly that the GA4 request is abandoned before it completes. Understanding which of these applies to your setup is the first step toward a fix.
The five most common causes
The most frequent cause is a mismatch between the GTM trigger and how your form submits. Enhanced Measurement in GA4 can auto-detect form_submit events, but only when the form uses a standard submit action that triggers a full page reload. Single-page applications that handle submissions via JavaScript and prevent the default reload behavior will not trigger Enhanced Measurement's form_submit detection — if your thank-you message appears without a URL change, GA4 probably never sees the submission. A second common cause is consent mode blocking: if a visitor declined analytics cookies and your site honors that preference, GA4 events will not fire for that session. A third cause is the event arriving in GA4 but not matching any configured key event — in GA4, events only appear in conversion reports when you explicitly mark them as key events under Admin, Conversions. Fourth, race conditions: if a redirect fires within a few hundred milliseconds of form submit, the GA4 request may be abandoned before it completes. Fifth, tag pausing: GTM tags can be paused without anyone noticing, leaving the trigger active but the tag silent.
How to diagnose the problem step by step
Start in GTM Preview mode. Navigate to tagmanager.google.com, click Preview, enter your site URL, and submit the form. Check whether the GA4 event tag fires on the form submission trigger. If the tag fires in GTM Preview but the event does not appear in GA4 DebugView, the issue is between GTM and GA4: verify that the Measurement ID in your tag matches your GA4 property exactly and that the event name is spelled correctly. If the tag does not fire at all in GTM Preview, the trigger is the problem — check whether it listens for the right condition such as a form ID, CSS class, or the built-in form_submit trigger. For single-page apps that prevent the default form reload, you need a custom trigger that listens to a JavaScript event your form library emits on successful submission, then fires the GA4 tag at that moment. If GTM and GA4 both show the event but it does not appear in conversion reports, go to Admin and confirm the event is marked as a key event. Each of these checks takes less than five minutes and isolates the break point without writing code.
The step-by-step fix for each cause
For standard HTML forms, confirm Enhanced Measurement is enabled in your GA4 data stream settings, then open GTM Preview and verify the form_submit trigger fires on submission. If the trigger does not fire, check whether the form uses a real submit button or a JavaScript onClick handler that calls event.preventDefault(). For JavaScript-handled forms, create a Custom Event trigger in GTM that fires when your form library emits its success event. Name the event descriptively — for example, demo_request_submitted — then add a GA4 Event tag that fires on that trigger. Once confirmed in GTM Preview and GA4 DebugView, mark the event as a key event in GA4 under Admin, Conversions. For race conditions on fast redirects, introduce a 200 to 300 millisecond delay before the redirect fires, or move to server-side tagging so the GA4 hit is independent of browser navigation. For the consent mode scenario, test in an incognito browser that has not previously declined consent — if events appear in incognito but not in your regular browser, consent settings are working correctly and the missing events are expected behavior.
When recurring breaks signal a structural problem
If you fix form tracking today and it breaks again after the next site update, the pattern signals a structural problem rather than a one-off configuration error. GTM triggers tied to specific CSS class names break whenever a developer renames a component. Enhanced Measurement form detection fails whenever a front-end framework update changes how form events propagate through the DOM. Manually auditing tracking after every site change is not sustainable for a marketing team managing campaigns and content simultaneously. ClimbPast's tracking health feature at /features/tracking-health monitors your GA4 property continuously and alerts your team the moment a key event stops firing — catching breaks before they compound into weeks of missing conversion data. If your form submission event drops below its expected weekly baseline, you receive an alert within hours rather than discovering the gap during your next reporting cycle. For teams that want reliable conversion data without recurring manual debugging, /google-analytics-alternative explains how ClimbPast handles tracking health monitoring as part of its broader analytics platform, and /features/automated-alerts shows how threshold-based monitoring works across all your key GA4 events.