Blog

Why Your Form Submissions Aren't Tracked as Conversions (and How to Fix It)

Published 2026-07-21

form submission not trackingform conversion not firingcontact form not trackedgtm form submit trigger

"The inquiries are actually coming in, but the conversion count won't budge." This is one of the most common complaints from sites that use a form submission as their goal. The email notification arrives, so the submit clearly succeeded — yet Google Ads and GA4 conversions sit at zero. Hiding here is a set of tracking traps unique to forms.

Does any of this sound familiar?

Inquiry emails arrive, but the form submission specifically isn't tracked as a conversion
After submitting, the page never changes — a "Thanks, we got it" message just appears in place
GTM's "Form Submission" trigger won't fire
The button clicks fine, but there's no sign a measurement event is being sent
On a multi-step form, which step should count as the goal is unclear

This guide organizes why form submissions aren't tracked as conversions into five diagnostic points, then walks through how to check in DevTools and GTM Preview — and the reliable design that fires on the event of a successful submit.

First principle: form tracking depends on how the submit happens

Most form-tracking failures come down to one thing: the tracking side can't catch how the submit is actually being processed. The old assumption — "submitting the form loads a new page" — simply doesn't hold for many of today's forms.

How the submit happens	What tracking can see	What breaks
Page navigation	The completion page load can be the cue	No navigation happens, so no cue arrives
AJAX submit (no navigation)	The page doesn't change, so it looks like "nothing happened"	Load-triggered tags never fire
Event firing	The submit-success event can be caught directly	A missing listener drops the event

The key point: "the button was clicked" and "the submit succeeded" are two completely different events. Diagnostic points 1–5 below are ordered to knock out these "how the submit happens" cases, top to bottom.

Diagnosis 1: An AJAX submit changes nothing, so there's no completion cue

Most contact forms today don't change the page when you press submit. Behind the scenes they send the data asynchronously (AJAX) and show "Thanks for your submission" on the same page. Great for user experience — a real problem for tracking.

Most measurement tags use "a new completion page loaded" as their firing cue. If neither the page nor the URL changes, then as far as the browser is concerned nothing happened, and the tag never fires.

After submit, the URL stays the same and only the completion message swaps in
The completion shows in a modal (popup), and the page itself never navigates
"Submitted" is rendered by JavaScript and nothing more

In this case you need a design that fires on the event of a successful submit, not on a page load. How to build that cue is covered in Diagnosis 5. For the blind spots on the completion-page side, see Why Your Thank-You Page Conversions Aren't Being Tracked.

Common pitfall: if "the completion message shows fine but nothing is tracked," suspect an AJAX submit first. A completion where the URL never changes can't be caught by a load-triggered tag.

Diagnosis 2: No event listener is attached, so the submit is never caught

Even if you've designed things to "track on the submit event," if the listener that waits for that event isn't correctly attached, nothing happens — naturally. This is where the design's intent and the implementation drift apart.

The tracking script runs once, before the form exists on the page, and never attaches to a form injected later
The listener is attached to the wrong element by mistake
The form is generated dynamically (in a popup, or after an SPA screen transition), so the target doesn't exist yet when you try to attach

For forms that appear later, attaching a listener "once on page load" isn't enough. You need to re-attach after the form appears, or catch the event on a parent element (event delegation).

Common pitfall: if "the inquiry on the homepage is tracked but the popup inquiry isn't," it's very likely no listener is attached to the form that appears later.

Diagnosis 3: GTM's "Form Submission" trigger doesn't fire

Google Tag Manager (GTM) has a convenient "Form Submission" trigger, but it's built around plain HTML forms — and it often won't fire on today's JavaScript-controlled forms.

The form calls preventDefault() just before submitting to cancel the native submit and send the data with its own logic (the "submit event" GTM waits for never happens)
Validation pauses the flow first, out of sync with GTM's detection timing
The redirect after submit is too fast, and the screen changes before the trigger can run

So "I placed the Form Submission trigger but it won't fire" is usually not a malfunction — it's that the form's construction and the trigger's assumptions don't match. For isolating GTM-wide failures, see What to Check When GTM Isn't Tracking Conversions.

Common pitfall: on a JavaScript-controlled form, don't rely on the "Form Submission" trigger — switch to sending a custom event on submit success (Diagnosis 5). That's the reliable route.

Diagnosis 4: Mixing up the button "click" with the actual "submit"

As a workaround, people sometimes count the "submit button click" as the goal — but that throws the numbers off. A click and a successful submit are different events.

The button was pressed, but a validation error stopped the submit (click counted, submit failed)
The user clicked the button repeatedly (one inquiry counted several times)
The server-side processing failed, yet only the click was recorded

Counting clicks tends to inflate the number above the real inquiry count. The correct goal is the moment the submit succeeds — and for that you need the design in Diagnosis 5.

Common pitfall: if "the conversion count is clearly higher than the actual inquiries," suspect that you're counting button clicks rather than successful submits.

Diagnosis 5: How to check, and how to track reliably

Everything above can largely be isolated by seeing with your own eyes whether a measurement signal actually fires when you submit. The steps are simple.

Open the contact form and open your browser's DevTools
In the "Network" tab, filter for conversion or collect (GA4)
Actually submit the form and watch whether a measurement request fires at that moment
Also check the "Console" for errors and whether the submit event is happening
If you use GTM, open Preview mode and see whether the trigger fires on form submit

And the foundation of reliable tracking is to explicitly signal the event of a successful submit yourself. Inside the callback that runs when the form's submit succeeds, send a single tracking custom event — this approach sidesteps most of Diagnosis 1–4, whether the form uses AJAX, an SPA, or a modal.

Common pitfall: with an ad blocker or browser tracking protection on, the request itself gets blocked and looks like "it isn't firing." Verify in a clean state with those turned off.

Third-party form tools embedded via iframe

If your form comes from a third-party tool — HubSpot, Typeform, Formstack, or similar — and is embedded on your page inside an iframe, that boundary creates a tracking blind spot. The iframe is a separate browsing context: GTM running on your page cannot see events inside the iframe, so a Form Submission trigger pointed at it will never fire.

The form lives in the iframe's own document, and cross-origin restrictions prevent your page's scripts from reading or listening to its events
Some tools (e.g., HubSpot's JavaScript embed) fire a callback on the parent page when a form is submitted — but only if you use their script-based embed, not the raw iframe
Redirect-based completion pages inside the iframe don't trigger a page-load event on your outer page

The fix depends on the tool. Check whether your form provider offers a JavaScript callback or event on successful submission (HubSpot's onFormSubmitted, for example). If it does, push a dataLayer event from that callback and trigger your conversion tag on it. If the tool only provides an iframe with no parent-page hooks, consider switching to its script-based embed or using a server-side approach that listens for the submission on the backend.

Common pitfall: "I set up GTM tracking but nothing fires" on a HubSpot or Typeform embed is almost always an iframe boundary issue. Verify which embed method you're using before debugging the tag itself.

Cookie consent and privacy restrictions silently drop conversions

Even when your form tracking is technically correct, cookie consent and browser privacy restrictions can prevent the conversion from ever being recorded. This is a different category of failure from Diagnosis 1–5 — the tag fires, but the data doesn't arrive.

Visitors who decline the cookie consent banner (or never interact with it) won't have ad cookies written, so conversion pings become cookieless or are blocked entirely
Safari's Intelligent Tracking Prevention (ITP) and Firefox's Enhanced Tracking Protection restrict or delete tracking cookies by default, affecting roughly 35–40 % of web traffic
With Consent Mode V2, when ad_storage is denied, Google receives only anonymized pings — conversions are modeled, not directly measured, which can reduce reported volume

The result: your form fires correctly and inquiries arrive, yet Google Ads shows fewer conversions than you actually have. The gap tends to be larger in regions with strict privacy regulation (EU/EEA, UK) or on sites with high Safari/mobile-Safari traffic.

To recover lost attribution, enable Consent Mode so Google can model denied-consent conversions, and set up Enhanced Conversions (see below) to match conversions using first-party data instead of cookies. For a deeper look at Safari-specific loss, see Safari ITP and Conversion Loss.

Common pitfall: if your conversion count drops every time you update or tighten your cookie banner, the cause isn't a tracking bug — it's consent-related data loss.

Enhanced Conversions: recovering attribution that cookies lose

Forms have a natural advantage over many other conversion types: they collect first-party data — email addresses, phone numbers, names — at the exact moment the conversion happens. Enhanced Conversions uses this data to recover attribution that cookie restrictions would otherwise erase.

How it works: when the form submits successfully, the conversion tag hashes the user-provided data (email, phone, address) with SHA-256 and sends it alongside the conversion ping. Google matches the hash against signed-in user data to attribute the conversion back to the ad click — no third-party cookie required.

To set it up in GTM:

Enable Enhanced Conversions at the account level in Google Ads (Conversions → Settings)
Edit your Google Ads Conversion Tracking tag in GTM and enable "Include user-provided data from your website"
Map the form fields (email is the minimum; phone and name improve match rates) to the corresponding variables
Publish and wait 48–72 hours, then verify the tag health in the Diagnostics tab

For forms, Enhanced Conversions typically recovers 5–25 % of otherwise-lost conversions, with the exact gain depending on how many of your visitors are signed into Google. Combined with Consent Mode modeling, this closes most of the gap between "inquiries received" and "conversions reported." For verification steps, see Enhanced Conversions Verification.

Common pitfall: if Enhanced Conversions is enabled but the user-provided data variables aren't mapped to the correct form fields, the hashes will be empty and match rates will be zero. Always verify that the email variable actually captures a value in GTM Preview mode.

What checking on your own machine can't tell you

Submitting the form yourself to watch it fire is useful, but checking once on your own machine has two structural limits.

Your environment isn't your visitors' environment. You've consented to the cookie banner, and your extensions and office-IP conditions differ. It may fire fine on submit for you, yet for a visitor in a different environment the listener isn't attached or the tag is dropped.
Conversions involving an ad click are hard to verify. To properly see "does it really track when someone who arrived via an ad submits the form," you'd need to click a live ad to recreate the path — which carries the risk of an ad-policy violation as a self-click.

Judging "it fires on my submit, so it's fine" tends to miss the problem of data going missing on the real path your visitors take.

Checklist: verifying form submission tracking

Frequently asked questions

Q. Inquiry emails arrive, but conversions aren't tracked. A. The email notification is server-side processing in your form tool; the conversion is a browser-side measurement tag — different paths. Typically the AJAX submit causes no navigation and nothing fires (Diagnosis 1), or no listener is attached to catch the submit (Diagnosis 2). Submit for real and confirm firing.

Q. I placed GTM's "Form Submission" trigger but it won't fire. A. On JavaScript-controlled forms, preventDefault() or validation often puts things out of sync with GTM's detection, so it won't fire (Diagnosis 3). Switch to sending a custom event on submit success — that's the reliable route.

Q. Why is nothing tracked even though the completion message shows? A. It's very likely an AJAX submit or modal where the URL never changes, so the tag's firing cue (a page load) never happens (Diagnosis 1). You need a design that fires on the submit-success event.

Q. My conversion count is higher than the actual number of inquiries. A. You may be counting button clicks rather than successful submits (Diagnosis 4). Repeated clicks and failed submits get counted too, inflating the number. Make the goal the moment the submit succeeds.

Q. I'm using a HubSpot (or Typeform) embed and nothing tracks. A. If the form is embedded as an iframe, GTM on your page can't see events inside it — cross-origin restrictions block access. Switch to the provider's script-based embed and use their JavaScript callback (e.g., HubSpot's onFormSubmitted) to push a dataLayer event that your conversion tag triggers on.

Q. Form tracking works on my machine but Google Ads shows fewer conversions than actual inquiries. A. Cookie consent and browser privacy restrictions are the most likely cause. Visitors who decline cookies or use Safari/Firefox may submit the form successfully while the conversion ping is blocked or cookieless. Enable Consent Mode and Enhanced Conversions to recover the gap.

Q. On a multi-step form, which point should be the goal? A. As a rule, the success of the final submit. Firing on an intermediate "Next" counts people who later drop off, inflating the number. If you want to see each step's completion, track those as separate events, kept distinct from the goal.

Conclusion: track forms on the event of a successful submit

Form submissions go untracked for a handful of reasons: ① an AJAX submit with no navigation, ② a missing listener, ③ GTM's Form Submission trigger not firing, ④ mixing up the click and the submit, and ⑤ ambiguity about the goal on multi-step forms. All of them are solved by leaving the old "page load" cue behind and adopting a design that explicitly signals the event of a successful submit yourself. For the full picture on verification, use the Conversion Tracking Verification Checklist.

But firing checks on your own machine have limits. Going further — confirming the form submission is actually recorded, on the real path your visitors take, including visitors in different environments, in production — is what "it's tracking" truly means. For the diagnostic entry point, see No Conversions in Google Ads? A Step-by-Step Diagnostic Guide.

ConversionOK runs your live page in an independent, isolated browser and intercepts the measurement requests actually sent when the form is submitted, then verifies them — with no need to click your own ad and no interference from your office environment. Start with a free static check to confirm the entry point of your measurement.