What a Proper Form-Tracking Setup Actually Captures
"We track form submits" usually means one event that fires on click. A form is a funnel with its own drop-off points, and most of them are invisible if that's all you're measuring.
A complete form-tracking setup separates at least three distinct events - the submit attempt, validation failures, and the backend-confirmed successful submission - and, for anything longer than two or three fields, adds field-level engagement tracking so drop-off inside the form is visible, not just whether the form was ever submitted. Reporting a "submit click" as a lead count is the single most common form-tracking error, because it counts attempts, not results.
The three events a form actually needs
- Submit attempt - the visitor clicked submit (or pressed Enter). This proves intent, not success, and should never be reported as a conversion count on its own.
- Validation failure - the form rejected the attempt (a required field, a malformed email, a failed captcha). Tracked with which field failed and why, this is one of the highest-value signals a form produces, because it tells you exactly what to fix - and it's the event most setups skip entirely.
- Confirmed success - the backend actually accepted the submission (a 200-status response from the form handler, a redirect to a genuine thank-you page the backend controls, or a confirmation event the server itself fires). This, not the submit click, is your real lead or conversion count.
Why the gap between "submitted" and "confirmed" matters
A submit click can be followed by a network failure, a server-side validation rejection the client never saw, a spam filter silently dropping the lead, or a redirect that happens to load the thank-you page even when the backend actually failed. Any setup that counts the click as the conversion will over-report leads by exactly the size of that gap - invisible until someone in sales notices the CRM has fewer real leads than the dashboard claims, and by then the discrepancy has usually been "true" for months.
Handling forms that don't exist yet when the page loads
Single-page apps, forms rendered behind a modal trigger, and forms injected by a third-party embed all share the same trap: a tracking listener attached directly to the form element at page-load time never fires, because the element didn't exist yet when the listener was attached. The fix is event delegation - attaching one listener to a stable ancestor (or the document) and checking, at the moment the event actually fires, which specific form or field triggered it. This pattern works regardless of when the form is added to the page.
Field-level engagement: the diagnostic layer most setups skip
For any form longer than two or three fields, tracking which field a visitor reaches - and which one they abandon on - turns "our form converts poorly" into "visitors consistently stall on the phone-number field." That's the difference between a vague hypothesis and a specific, fixable design problem, and it typically costs one additional event type (a field-focus or field-blur listener) to capture.
Form tracking - common questions
▸Is "form submit" the same event as a successful lead?
No, and treating them as the same is one of the most common lead-count inflation bugs we see. A submit click only proves the visitor pressed the button. A validated, backend-confirmed submission proves a lead actually reached your CRM or inbox. Track both, and never report the click count as your lead count.
▸How do I track forms that are injected by JavaScript after page load?
Use event delegation - attach one listener to a stable parent element (or the document itself) and check which specific form triggered it - instead of attaching a listener directly to the form element. A direct listener attached before the form exists in the DOM will never fire.
▸Should abandonment tracking fire on every field, or just at the end?
Field-level engagement (which field a visitor reaches, and which one they stop at) is far more diagnostic than a single all-or-nothing abandonment event. It tells you exactly where the form is losing people - a long address block, an unclear phone-format requirement - rather than just that they left.
Not sure if your "leads" are submits or confirmed successes?
A data audit checks that specific gap against your actual CRM records, not a dashboard assumption.