Most WordPress sites can tell you how many people visited last month. Far fewer can tell you which of those visits turned into an actual enquiry \u2014 and that second number is the one that pays the bills. If your contact form is the main way people reach you, “how many submissions came from organic search versus that newsletter versus the ad you’re paying for?” is the most useful question your analytics can answer.<\/p>\n
Google Analytics 4 can answer it, but the setup is fiddly on WordPress and the “easy” option quietly under-reports on most sites. Here’s how form conversion tracking actually works in GA4 as it stands in 2026, three ways to implement it, and the pitfalls that make people’s numbers wrong without them noticing.<\/p>\n
If you’re following an older tutorial, one thing trips you up immediately: GA4 no longer calls them conversions. In March 2024 Google renamed conversions<\/em> to key events<\/strong> across the entire interface \u2014 every toggle, report column, and API field. “Conversion” now means specifically a key event imported into Google Ads. The mechanics didn’t change: you send an event, then flag it as important. But when a guide says “mark the event as a conversion,” the toggle you’re hunting for reads Mark as key event<\/strong>.<\/p>\n None of that works if the underlying event is unreliable, which brings us to the three ways of firing it.<\/p>\n GA4 ships with Enhanced Measurement, toggled per web data stream in The listener hooks into the browser’s native form submission \u2014 a standard HTML Our honest take: leave form interactions on<\/em> \u2014 The oldest trick in the book is still the sturdiest. Configure your form to redirect to a dedicated confirmation page<\/strong> after a successful submission \u2014 something like The trade-off is UX: you lose the smooth inline success message, and some plugins make redirect-after-submit awkward for multi-step or popup forms. Usually worth it, and a thank-you page is prime real estate anyway \u2014 we cover what to put on it in our guide to contact page best practices<\/a>.<\/p>\n If you want inline success messages and<\/em> reliable tracking, fire your own event at the exact moment the plugin says the submission succeeded. Nearly every WordPress form plugin exposes a JavaScript event or callback for this \u2014 Contact Form 7 has Push a named event with a little context \u2014 which form, which page \u2014 so you can segment later instead of staring at one undifferentiated number.<\/p><\/blockquote>\n If you use Google Tag Manager, push to the data layer and let a Custom Event trigger fire your GA4 tag. An illustrative snippet, using Contact Form 7’s success event:<\/p>\n Then in GTM: a Custom Event<\/strong> trigger matching Two details that save pain later: register Why bother tracking form conversions at all<\/h2>\n
\n
Method 1: GA4 Enhanced Measurement (easiest, least reliable)<\/h2>\n
Admin > Data streams<\/code>. Alongside scroll depth and outbound clicks it includes form interactions<\/strong>, collecting two events automatically: form_start<\/code> when a visitor first touches a field, and form_submit<\/code> on submission. No code, no tag manager. So why isn’t this the end of the article?<\/p>\nWhy it misses most WordPress forms<\/h3>\n
<form><\/code> doing a standard submit. Most WordPress form plugins don’t do that. They intercept the submit, send data over AJAX, and swap in a success message without reloading, so the event GA4 waits for either never fires or gets cancelled first. Two more wrinkles:<\/p>\n\n
form_start<\/code> is genuinely useful for spotting forms people begin and abandon \u2014 but don’t build your reporting on form_submit<\/code> without verifying it fires on your specific form.<\/p>\nMethod 2: the thank-you page (most reliable, small trade-off)<\/h2>\n
\/thank-you\/<\/code> \u2014 and count views of that page as the conversion. It doesn’t depend on JavaScript listeners or plugin internals; a page_view<\/code> on a URL is about the most robustly tracked thing in analytics. And because the redirect only happens after server-side validation passes, you’re counting successes rather than attempts. To set it up:<\/p>\n\n
noindex<\/code>, so strangers can’t find it in search and inflate your numbers.<\/li>\nAdmin > Events > Create event<\/code> and build a custom event \u2014 call it generate_lead<\/code> \u2014 that fires when event_name<\/code> equals page_view<\/code> and<\/em> page_location<\/code> contains \/thank-you\/<\/code>.<\/li>\nMethod 3: a custom event on the success hook (most flexible)<\/h2>\n
wpcf7mailsent<\/code>, others emit custom DOM events.<\/p>\ndocument.addEventListener('wpcf7mailsent', function (e) { window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: 'form_success', form_name: 'contact-main', form_id: e.detail.contactFormId }); });<\/code><\/p>\nform_success<\/code>, attached to a GA4 Event tag sending generate_lead<\/code> with form_name<\/code> as a parameter. Without GTM, if gtag.js is on the page, skip the data layer and call gtag('event', 'generate_lead', { form_name: 'contact-main' })<\/code> in the same listener.<\/p>\nform_name<\/code> as a custom dimension<\/strong> under Admin > Custom definitions<\/code> or the parameter never shows up in reports, and prefer a recommended event name like generate_lead<\/code> over an invented one, since Google’s reporting and Ads integrations understand it.<\/p>\nComparing the three<\/h2>\n