WPForms conversion tracking: 3 ways to do it

Are you running ads or putting time into SEO to bring people to your website, but you have no real idea which of those channels and campaigns are actually turning into leads? If that sounds familiar, you are not alone.

When you cannot see which campaigns are generating real leads, and not just clicks and page visits, it is easy to keep spending budget on the things that are not delivering.

The fix is proper conversion tracking, so a conversion gets recorded every time someone submits one of your WPForms forms.

The tricky part is that there is more than one way to do it, and the right one depends on your goal. If you just want to see submissions in Google Analytics, there is a fairly quick route. But if you want those same conversions flowing into Google Ads, Meta Ads, and similar platforms, you need something sturdier, and that is exactly where a lot of DIY setups quietly fall apart.

In this article we will show you three different ways to set up conversion tracking for WPForms and help you work out which one fits your situation. We build form conversion tracking for a living, and WPForms has a couple of genuine quirks of its own (it actually has two entirely different ways of submitting a form), so we will flag the gotchas along the way so you know what to watch for.

Method 1: Use the MonsterInsights Forms addon

Good for: Sending form submission events to Google Analytics 4.

If all you need to do is see form submissions as events in GA4, this is all you need. Google Analytics does not need to know who submitted the form. It just needs to know that a conversion happened.

Unlike some other WordPress form plugins, WPForms does not ship its own dedicated Google Analytics add-on. But WPForms and MonsterInsights are both made by the same company (Awesome Motive), and MonsterInsights ships a Forms addon that is built specifically to track submissions from plugins like WPForms. It is the closest thing WPForms has to an official, plug-and-play path to GA4, and it needs no code and no Google Tag Manager.

The catch is that the Forms addon needs a MonsterInsights Pro license or higher, so this option is off the table if you only run the free version. Here is how to set it up.

Step 1: Connect MonsterInsights to your GA4 property

Install and activate MonsterInsights, then follow its setup wizard to connect your Google account and choose the GA4 property you want your data to land in.

Step 2: Install the Forms addon

Go to Insights, then Addons, find Forms in the list, and select Download and Activate. There is no per-form setup after this. Once the addon is active it tracks submissions across every compatible form plugin on your site, WPForms included, automatically.

Step 3: Test it, then mark it as a Key Event in GA4

Submit a quick test entry, then open the Realtime report in GA4 and look for the generate_lead event in the recent events list. That is the event MonsterInsights fires whenever a form is submitted. Once you can see it coming through, go to Admin, then Events (or Key Events) in GA4, find generate_lead, and mark it as a Key Event. That tells GA4 to treat it as a conversion, so it shows up properly in your acquisition and funnel reports.

Pros and cons

Pros:

• No code and no Google Tag Manager. The whole thing is set up inside MonsterInsights and GA4.
• It is built and maintained by the same company behind WPForms, so it is a well supported option rather than a random third party plugin.
• Zero per-form setup. Turn it on once and every WPForms form on your site is covered, including ones you add later.
• It detects WPForms' submissions for you, so you never have to think about which event to listen for.

Cons:

• It needs a MonsterInsights Pro license, which is a separate paid product on top of WPForms itself.
• It only sends to Google Analytics. It does not push conversions to Google Ads, Meta, or anywhere else, so it does nothing for ad platform optimisation (that is what Methods 2 and 3 are for).
• MonsterInsights' documentation does not describe a dedicated server-side connection for this addon the way Gravity Forms' own add-on offers through the Measurement Protocol, so treat it as running in the visitor's browser, which means ad blockers and privacy browsers can stop it firing.
• Getting a conversion from Google Analytics into Google Ads is possible, but it is not a good approach. Google Ads needs much more data (as you will see if you keep reading) to properly record a conversion.

Method 2: Use Google Tag Manager

Good for: sending Enhanced Conversions to Google Ads.

If you are running paid acquisition, simply counting form submissions like in Method 1 is not enough. Google Ads prefers to match each conversion back to the specific person who clicked your ad, and it can only do that when you send information about the lead (like their name, email and phone number) with each conversion. This is known as Enhanced Conversions.

So for Google Ads, it is not enough to send an event that just says a conversion happened. You need to capture the visitor's name, email and phone when they submit the form, hash it (Google Ads requires it), and send it over to Google Ads.

One way to do this is with Google Tag Manager, and here are the steps.

Step 1: Set up a Custom HTML tag with the form listening code

In GTM, create a new Custom HTML tag, paste in the snippet below, and set it to fire on the All Pages trigger, with the tag firing option set to Once per event.

The above code does a bunch of things:

• Detects both of WPForms' submission modes. WPForms can submit two completely different ways depending on how a form is configured. Most forms submit over AJAX in the background with no page reload, and the code catches that by listening for WPForms' own wpformsAjaxSubmitSuccess event. But some forms use the older "Page Reload" behaviour instead, where the browser does a full page POST and navigates to a new page, and there is no equivalent success event to listen for in that case. The code handles this second mode too, which we will get to below.
• Extracts the email, first name, last name and phone. WPForms names its fields by position, like wpforms[fields][1], which tells you nothing about what is inside. So instead of trusting the name, the code reads the visible label sitting next to each field on the page (things like Email Address, First Name, Phone). Everything else on the form is ignored on purpose.
• Skips sensitive fields before reading anything. Passwords, card numbers, CVV fields, one-time codes and similar are checked and dropped before the code ever reads a value, going by the field type, the autocomplete hint, and the field's name and visible label. This means a payment field can never end up in the dataLayer, deliberately.
• Sends the data once WPForms confirms success. On the AJAX path, the code reads the values as soon as the success event fires, since WPForms leaves the fields populated at that point. On the Page Reload path there is no equivalent moment, so the code snapshots the values the instant the form is submitted, carries them across the page reload, and only pushes them to the dataLayer once it can see a genuine confirmation message on the next page. If the submission was rejected instead, nothing gets sent.

The design of this snippet gets around two things that trip up almost every homemade WPForms tracking script.

Catch 1: a form set to "Page Reload" mode never fires the event a naive script listens for. Most public WPForms and GTM tutorials only hook the AJAX success event, which works fine for WPForms' default behaviour. But Page Reload is a real, commonly used per-form setting, and on those forms the browser does a full page navigation instead. A script that only listens for the AJAX event silently loses tracking on every one of those forms, with no error or warning anywhere. This snippet catches both modes.

Catch 2: on the Page Reload path, the page you land on has no idea who just submitted. By the time the new page loads, the original form and its filled-in values are gone. The snippet works around this by snapshotting the lead's details the moment the form is submitted (before the page has a chance to navigate away) and stashing them in the browser's sessionStorage. When the next page loads, the snippet checks that page for WPForms' own success or error markers to decide whether the submission actually went through, and only then does it push the stashed data to the dataLayer.

As you can probably tell, this is not a snippet we threw together for this article. It is ported from the same detection logic Converly uses in production to track WPForms, and it has been tested against a real WPForms install (WPForms Lite, driven by a real browser) covering both submission modes, a deliberately included sensitive CVV field, and both valid and invalid submissions. One genuinely surprising edge case turned up during that testing. WPForms has a built in "Did you mean...?" email suggestion feature (it flags likely typos like gmial.com), and it happens to reuse the same error styling as a real validation failure. The first version of this logic misread that suggestion as a rejected submission and silently dropped a valid lead. It has since been fixed so that suggestion is correctly ignored, and a submission with a flagged (but not actually invalid) email now fires exactly like any other successful one. You can paste this snippet in with confidence.

Step 2: Create Data Layer Variables for the captured data

To make sense of this step, it helps to know what the dataLayer is, because the rest of the steps rely on it.

Think of the dataLayer as a messenger between your website and Google Tag Manager. Your website can send messages to it (someone just submitted a form, and here is their email and name) and GTM sits there reading every message that comes through.

That is exactly what the code in Step 1 does. When a form is submitted successfully, it drops a note onto the dataLayer called wpforms_form_submitted, and on that note are the values it captured, the email, first name, last name and phone.

But GTM will not automatically pull those individual values out for you. You have to tell it which ones you want, and that is what a Data Layer Variable does.

To set this up, navigate to the Variables section of Google Tag Manager, select New under User-Defined Variables, choose Data Layer Variable as the type, and give it a name.

The details for each of the four variables are below.

Variable 1:

• Name: Email
• Variable Type: Data Layer Variable
• Data Layer Variable Name: email

Variable 2:

• Name: First Name
• Variable Type: Data Layer Variable
• Data Layer Variable Name: first_name

Variable 3:

• Name: Last Name
• Variable Type: Data Layer Variable
• Data Layer Variable Name: last_name

Variable 4:

• Name: Phone
• Variable Type: Data Layer Variable
• Data Layer Variable Name: phone

Step 3: Create a Custom Event trigger

Information sitting in the dataLayer does not do anything by itself. You need to tell GTM to watch for it and treat it as the cue to fire your conversion, and in GTM that cue is called a trigger.

Navigate to the Triggers section, click New, choose the Custom Event type, and set the event name to wpforms_form_submitted. It has to match what the code pushes exactly. This is the trigger your Google Ads tag will fire on in the next step.

Step 4: Turn on Enhanced Conversions in Google Ads

Jump over to your Google Ads account, go to Goals, then Conversions, then Settings, and turn on Enhanced Conversions.

When it asks how you want to implement it, choose Google Tag Manager. This is what gives Google Ads permission to receive and use the customer data you are about to send.

Step 5: Create your Google Ads conversion tag and map the data

Back in GTM, navigate to Tags, select New, choose Google Ads User Provided Data Event as the tag type, and map the variables you set up earlier to the data points it asks for.

Then set it to fire on the Custom Event trigger you created in Step 3.

When that is done, publish your GTM container. To check it is working, submit a test entry in GTM Preview mode and confirm the wpforms_form_submitted event arrives with the email and name filled in, and try it with both an AJAX form and a Page Reload form if you have one of each. Then watch the Enhanced Conversions diagnostics on the conversion action in Google Ads over the next day or two to see whether the data is being received and matched.

Pros and cons

Pros:

• It is free, and uses GTM, which you may already have installed on your site.
• It captures the email, name and phone, which is the minimum Google Ads Enhanced Conversions needs to start matching conversions back to clicks.
• The capture logic handles both of WPForms' submission modes, so you are not quietly missing tracking on every Page Reload form.
• It only counts real, completed submissions, because it waits for a genuine WPForms success signal on both paths.

Cons:

• There are a lot of moving parts. Between the GTM tag, the trigger, four variables, the Google Ads settings and the conversion tag, there is plenty to misconfigure, and a wrong mapping tends to fail silently.
• You own and maintain it. A WPForms update, a theme change, or an unusual form layout can break the capture, and you will not get an error, just empty data flowing through.
• It depends on sessionStorage to carry data across a Page Reload submission. If a visitor's browser blocks it (some locked down or private browsing situations), that particular submission will not be tracked.
• It still runs in the browser, so ad blockers and privacy browsers can stop it firing.
• Even done perfectly, it misses the data Google values most. It only captures what is in the form, not the click identifiers Google rewards, like the Google click ID (GCLID), the IP address, or the user agent. A dataLayer setup cannot easily assemble or deliver those.

That last point is the one that pushes a lot of people to Method 3.

Method 3: Use Converly

Best for: sending proper, server-side conversions to Google Ads, Meta Ads, LinkedIn Ads, GA4, and more, without having to do complicated configuration in Google Tag Manager.

Converly is a dedicated conversion tracking tool built to make it simple to send proper, server-side conversions to Google Ads, Meta Ads, LinkedIn Ads, and more, every time someone submits a WPForms form on your site.

As you can see above, setting it up is genuinely simple. You choose a trigger (like a WPForms submission on your site) and then add one or more actions, such as sending a conversion to Google Ads, sending a conversion to Meta Ads, or sending an event to GA4. That is the entire setup. No custom code, and no wrangling Google Tag Manager triggers and variables.

You then install Converly on your website, and it takes care of the rest. It listens for WPForms submissions on both the AJAX path and the Page Reload path, pulls out the name, email and phone, and sends it to Converly's own servers, which relay it to Google Ads, Meta Ads, and beyond. Because that happens server side, it cannot be blocked by ad blockers or privacy restrictions in browsers like Safari.

Here is the part that really matters if you are running paid campaigns. Alongside the name, email and phone, Converly also captures the Google and Meta click IDs (GCLID and fbclid), Meta's browser cookies, the visitor's IP address, their user agent, and more, and sends all of it over to Google Ads, Meta Ads, and the rest with every conversion. These are precisely the signals Google and Meta reward, and having all of them is what takes your match quality from weak to strong (on Meta, that can take your Event Match Quality score from around 3 up to a 9 or 10).

Converly also gives you a full conversion log, where you can see every lead that came through WPForms, what data was captured, what was sent to each ad platform, and whether it was received.

The other big advantage is reach. One setup in Converly can send the same conversion to Google Ads, Meta Ads, LinkedIn Ads, GA4, and plenty of other tools at once. Start advertising on a new platform next month and you just add it as another action to your existing flow. No new snippet, no new GTM tag, no rebuild.

Oh, and did we mention we provide full support for it as well? Good luck getting help from Google if your conversions are not firing in Google Tag Manager.

Pros and cons

Pros:

• No code to write or maintain. One snippet, then a visual builder.
• Handles every WPForms gotcha automatically, including both submission modes, so nothing silently breaks when WPForms updates or you add a new form.
• Captures the click IDs, cookies, IP and user agent that boost match quality, which a dataLayer setup cannot easily reach.
• Sends server side, so ad blockers and privacy browsers do not stop your conversions.
• One setup sends to Google Ads, Meta Ads, LinkedIn Ads, GA4, and more.
• Supports conditional logic, so you can send specific conversions when certain forms are completed on your site (for example only send a conversion when the Quote Request form is submitted, and not the newsletter signup form).
• Lets you log in to Google Ads, Meta Ads, and so on and just pick the conversion you want to fire, without digging around for account IDs and conversion IDs.
• Gives you a full conversion log where you can see every lead that submitted your WPForms form, what data was captured, whether it was successfully sent to your ad platforms, and more.
• You get support from a team of experts who will happily help you get set up and troubleshoot any issues. You have no chance of getting help from Google if you use GTM.

Cons:

• It is a paid tool after the free trial. Plans start at $19 per month (but you would probably make that back in both the time saved setting up conversion tracking manually, plus the reduced cost per lead you will get when you have proper conversion tracking working in Google Ads, Meta Ads, and so on).

What not to do

So far we have covered the three best approaches for conversion tracking in WPForms and when each one is best. It is also worth knowing which approaches to avoid, because some of the most common ways people try to track WPForms conversions quietly produce bad data. Here are the ones to stay away from.

Tracking thank-you page visits

This is the single most common DIY approach, and it is the one we would steer you away from most. The idea is to send people to a dedicated thank you page after they submit, then count visits to that page as conversions. It sounds clean, but there are so many ways it goes wrong.

It fires for people who never submitted anything. A thank you page is just a URL, and a URL can be reached without ever touching your form. People bookmark it, land on it from their history or autocomplete, get sent the link by someone else, or find it in Google if it ever gets indexed. Your own team hits it while testing. Every one of those gets counted as a conversion, even though no form was submitted.

It can double count real submissions. Refresh the thank you page and you get a second conversion. Hit the back button and return, or revisit it later from history, and you get more. A single lead can rack up several conversions, which inflates your numbers and means Google and Meta are optimising your ads against incorrect data.

You would get terrible match rates. A page visit has no idea who submitted the form, so it cannot pass the name, email, phone, GCLID, and so on that Google Ads Enhanced Conversions or Meta CAPI needs. So even though you are sending conversions to these platforms, they would largely do nothing.

It also misses conversions of its own. WPForms shows its confirmation message inline by default rather than redirecting anywhere, so unless you go out of your way to configure a thank you page redirect on every single form, this approach never even gets a chance to fire. Set up the redirect and you still lose submissions where the visitor closes the tab early or the page gets served from a cache.

The root problem is that a thank you page visit is a proxy for a conversion, not the conversion itself. The three methods above all fire on WPForms' actual confirmed submission, so they stay tied to what really happened.

Relying on the default form submit trigger in Google Tag Manager

When people set up tracking in GTM, the obvious first move is GTM's built-in Form Submission trigger, which listens for the browser's native form submit event. On a WPForms form using the default AJAX behaviour, it records nothing, because that behaviour never fires the browser's native submission event at all.

Point it at a form using the older Page Reload behaviour instead and the native event does fire, but only the instant the Submit button is pressed, before WPForms has decided whether to accept the entry. A rejected submission (a bad email, a failed spam check) fires the trigger exactly the same as an accepted one, so a broken form can rack up conversions just as easily as a working one. Always listen for a genuine WPForms success signal instead, like the snippets above do.

Using GA4's automatic form tracking (Enhanced Measurement)

GA4 has a built-in Enhanced Measurement feature that claims to track form submissions automatically with no setup.

It runs into the same trouble as the Form Submission trigger above. Its form detection relies on the browser's standard form submission event, which WPForms' default AJAX behaviour never fires, so those submissions go uncounted entirely. And on the forms where it does fire, it cannot distinguish a genuine success from a rejected attempt, so failed submissions get counted right alongside real ones.

If you want submissions recorded in GA4, use the MonsterInsights Forms addon from Method 1, or use Converly.

Firing the conversion on the submit button click

Some setups we have seen fire the conversion when someone clicks the submit button, usually with a click trigger in GTM on the button. The trouble is that a click is not a submission. The visitor might have left a required field blank, entered their email in the wrong format, or tripped spam protection. Every one of those clicks gets counted, and then when they fix the error and click submit again it gets counted a second time.

This matters more than it sounds, because the bad data does not just mislead your reports. When you send those inflated conversions back to Google Ads or Meta, you are training their smart bidding to serve your ads to people who were not actually leads. Always fire on the confirmed submission, never on the click.

So which method should I use?

Here is the quick version:

• If you only need conversions in Google Analytics, Method 1 (the MonsterInsights Forms addon) is the cleanest option, as long as you are willing to pay for MonsterInsights Pro.
• If you are running Google Ads, Meta Ads, LinkedIn Ads, and the like, and you want the best possible conversion tracking system with the easiest possible setup, use a tool like Converly.
• If you only need to send conversions to Google Ads, do not mind some complicated configuration, and do not have budget to pay for a tool, then Method 2 (Enhanced Conversions through Google Tag Manager) is probably your best bet. Just note that it only sends name, email and phone, and does not send the other signals Google uses for matching, like the GCLID, IP address, and user agent.

Wrap up

Conversion tracking is one of those things that quietly decides how well your advertising performs, especially once you are feeding conversions into Google Ads, Meta Ads, and similar platforms. Get it right and their algorithms have accurate data to optimise against. Get it wrong and you are steering blind.

The upside is real, and both platforms have put numbers on it. Google reports that moving to proper server-side conversion tracking lifts conversions by an average of 19%. Meta puts the average lift on their own platform at 23%.

A tool like Converly gets you there without the fiddly parts. You choose a trigger (a WPForms submission, say), pick the platforms you want the conversions sent to, drop one snippet on your site, and that is it.

And there is no real barrier to trying it. Converly is free to get started, and most people are up and running in under 10 minutes. Start your 14-day free trial today.