CF7, Gravity Forms, WPForms: Which Sends the Best Lead Data?

Which WordPress form plugin sends the most complete lead data to ad platforms?

Gravity Forms sends the most complete lead data because its gform_after_submission hook exposes every field value in a structured array — including the email address Google needs for enhanced conversions and the phone number Meta uses for match quality. Contact Form 7 and WPForms both fire submission hooks, but CF7’s wpcf7_mail_sent returns a flat posted-data array that requires field-name mapping, while WPForms’ wpforms_process_complete exposes a nested fields array with IDs rather than labels.

This matters because ad platform optimization depends on the quality of the data in the event, not just the fact that an event fired. A lead event that carries hashed email, phone, name, and a user-agent string gives Google’s Smart Bidding and Meta’s delivery algorithm significantly more signal than a bare “form submitted” ping. The plugin that makes this data easiest to extract at the hook level gives your tracking the least friction — and that is Gravity Forms, with WPForms close behind and CF7 requiring the most custom work.

Enhanced conversions for leads uses hashed first-party data — email addresses — instead of GCLID for attribution, making what your form plugin exposes at the hook level the determining factor in lead tracking quality (Google / Stape, 2026).

Every form plugin comparison on the market evaluates UX, templates, conditional logic, and pricing. None of them compare what happens after the submit button — which hook fires, what data it carries, and how easily that data reaches your ad platforms. That is the comparison that actually affects your cost per lead.

How do you track Contact Form 7 submissions server-side?

You track CF7 submissions server-side by hooking into wpcf7_mail_sent at the PHP level, extracting the submitted field values from $contact_form->get_posted_data(), and forwarding them to your tracking endpoint as a lead event. Plugin-based tracking misses 15–40% of form submissions due to ad blockers and privacy tools (MD Niamul / industry consensus, 2026) — server-side tracking bypasses this entirely because it runs at the PHP layer, not in the browser.

The challenge with CF7 is that get_posted_data() returns raw POST values keyed by field names you defined in the form editor — there is no standardized “email” or “phone” key. If your email field is named your-email in one form and email-address in another, your tracking code needs to know both. Gravity Forms and WPForms both solve this with field-type metadata (a field typed as “email” is always identifiable), but CF7 treats every field as a text string.

The practical fix: standardize your CF7 field names across all forms (your-email, your-name, your-phone) and map them once in your server-side tracking configuration. After that, every CF7 submission fires a lead event with the right data in the right slots — the initial setup just takes more work than it does with Gravity Forms or WPForms.

Related: Qualified Future Conversions: What WooCommerce Store Owners Need to Change

What lead event data does Google enhanced conversions for leads need from a form submission?

Google enhanced conversions for leads needs, at minimum, a SHA-256 hashed email address attached to the conversion event — and from April 2026, Google accepts this data from tags, Data Manager, and API simultaneously (GTM4WP, 2026), so your form plugin’s hook output feeds whichever ingestion path you use. Optional but valuable: hashed phone number, first name, last name, and address for higher match rates.

The hashing happens before the data leaves your server. Google does not want the raw email — it wants the normalized, lowercase, trimmed, SHA-256 hashed version. Your tracking layer reads the email from the form hook, normalizes it, hashes it, and sends it as part of the user_data object on the conversion event. The same applies to phone numbers (E.164 format, then hashed).

Here is the thing… the “enhanced” in enhanced conversions is entirely about this user data. A standard conversion event says “someone converted.” An enhanced conversion event says “this specific person converted” — and Google can then match that hashed identity back to the ad click, even when cookies are gone or the conversion happened on a different device. The quality of your form plugin’s hook output directly determines whether Google can make that match.

Plugin	Hook	Email Access	Field Typing
Contact Form 7	wpcf7_mail_sent	Raw POST keyed by custom name	None — all text
Gravity Forms	gform_after_submission	Structured array with field type	Email, phone, name typed
WPForms	wpforms_process_complete	Nested fields array by ID	Email, phone typed

Can Gravity Forms and WPForms send hashed email data for enhanced conversions?

Neither Gravity Forms nor WPForms sends hashed email data to Google or Meta on its own — but both expose the email in their submission hooks in a way that makes server-side hashing and forwarding straightforward. Gravity Forms identifies email fields by type in the entry object, and WPForms tags them with a type attribute in the fields array, so your tracking layer can extract the email without guessing which field contains it.

The hashing-and-sending step sits outside the form plugin entirely. The plugin’s job is to capture the form data and make it available at a WordPress hook. Your server-side tracking — whether that is a custom integration, GTM server-side, or a managed solution — picks up the data from the hook, hashes the PII fields, and sends the conversion event to Google’s Measurement Protocol or Meta’s Conversions API.

This division matters because form plugin reviews almost never mention it. A review that says “Gravity Forms integrates with Google Analytics” means it fires a client-side JavaScript event — which is blocked by ad blockers and does not carry hashed user data. The server-side path, where the actual enhanced conversion signal lives, depends on what the hook exposes, not what the plugin’s settings page offers.

Related: Five GA4 Volume Thresholds Your WooCommerce Store Fails

Why does plugin-based form tracking miss submissions?

Plugin-based form tracking misses submissions because it relies on client-side JavaScript to fire the tracking event, and ad blockers, browser privacy features, and consent rejection prevent that JavaScript from executing on 15–40% of sessions (MD Niamul / industry consensus, 2026). The form submission still completes — the user’s data reaches the server and the email sends — but the tracking event never fires.

This creates a gap between actual conversions and reported conversions that makes every downstream metric wrong. Your cost per lead looks higher than it is. Your conversion rate looks lower. Google’s Smart Bidding optimizes against incomplete data, so it bids less aggressively on the audience segments that are actually converting but not being tracked — the privacy-conscious, technically literate users who are often the highest-value leads.

Server-side tracking routes form submission data through a first-party subdomain, bypassing ad blockers entirely (MD Niamul, 2026). The event fires from your server, not from the visitor’s browser, so there is nothing for an ad blocker to intercept. The form plugin captures the submission, the WordPress hook fires, and your server-side tracking picks it up and forwards it — all at the PHP level, invisible to any client-side blocking.

How does the enhanced conversions web and leads merge change form tracking?

The merge means form submissions on lead-gen sites now feed the same optimization loop as purchase events on ecommerce sites — from June 2026, Google treats enhanced conversion data from leads and web identically in its bidding algorithms (GTM4WP, 2026). Before the merge, enhanced conversions for leads was a separate feature with its own setup, separate reporting, and different data requirements. Now it is one unified system.

For WordPress lead-gen sites, this raises the stakes on form tracking. The unified system means the hashed email from your form submission is weighted the same way as a hashed email from a WooCommerce purchase. If your form plugin’s hook does not expose the email cleanly, or your tracking does not hash and forward it properly, you are leaving optimization signal on the table that Google now explicitly knows how to use.

The practical implication: form tracking is no longer a “nice to have” analytics feature. It is a bidding signal, the same way purchase tracking is for ecommerce stores. And like purchase tracking, the server-side path produces better data than the client-side path because it does not lose submissions to ad blockers.

What Meta CAPI parameters should a form submission event include?

A Meta CAPI Lead event from a form submission should include hashed email (em), hashed phone (ph), client IP address (client_ip_address), user agent (client_user_agent), and the fbc click ID if available — these are the match keys Meta uses to attribute the lead back to the ad that drove it. Without them, the event still counts as a conversion but Meta cannot match it to a specific ad impression, so it does not improve delivery optimization.

The fbc parameter is particularly important. It carries the Facebook click ID from the initial ad click, and on a lead-gen site where the form submission may happen on a different page from the landing page, you need to persist it through the session. Server-side tracking captures the fbc cookie on the first page load and attaches it to the form submission event automatically — client-side tracking often loses it to cookie expiration or cross-page navigation.

The form plugin’s role here is the same as with Google: expose the email and phone at the hook level so the server-side tracking can hash them and include them in the CAPI event. Gravity Forms does this most cleanly, WPForms requires a field-ID lookup, and CF7 needs manual field-name mapping.

Which form plugin is easiest to connect to server-side tracking?

Gravity Forms is the easiest to connect to server-side tracking because its gform_after_submission hook passes the full entry object with typed fields — email, phone, and name fields are identifiable by type rather than by arbitrary field names. A single hook callback can extract every PII field without per-form configuration.

WPForms is a close second. Its wpforms_process_complete hook passes the fields array with type metadata, so email fields are identifiable — the extra step is that fields are keyed by numeric ID rather than semantic name, so you need one lookup layer to map field IDs to tracking parameters.

CF7 requires the most setup. Every form can use different field names, and there is no type metadata — you either standardize your naming convention across all forms or build a per-form mapping. For a site with three forms this is manageable; for a site with thirty, it is a maintenance burden. Transmute Engine handles all three plugins at the WordPress hook level, normalizing each plugin’s data structure into a consistent lead event with hashed PII before forwarding to Google and Meta server-side — so the tracking output is identical regardless of which form plugin generated the submission.

Server-side tracking routes form submission data through a first-party subdomain, bypassing ad blockers — and from June 2026, that lead data feeds the same unified enhanced conversions system as purchase events (GTM4WP, 2026; MD Niamul, 2026).

Key Takeaways

• Gravity Forms exposes the most complete data: its hook passes typed fields including email and phone, making server-side tracking integration the simplest.
• Contact Form 7 needs manual field mapping: it treats every field as plain text, so your tracking layer must know each form’s naming convention.
• Plugin-based tracking misses 15–40% of submissions: ad blockers prevent client-side events from firing, but server-side tracking at the PHP level captures every submission.
• Enhanced conversions need hashed email: Google’s unified system uses SHA-256 hashed email to match leads to ad clicks — the form plugin determines how easily you extract it.
• Meta CAPI needs em, ph, fbc, IP, and user agent: without these match keys, the lead event counts but does not improve delivery optimization.
• The June 2026 merge raises the stakes: form submission data now feeds the same bidding algorithm as purchase data — lead tracking is a bidding signal, not an analytics feature.

References

1. GTM4WP (2026). Enhanced Conversions for Google Ads with WooCommerce — How to Setup. Source
2. Google (2026). Google Ads API — Conversions Overview. Source
3. Meta (2026). Conversions API Documentation. Source
4. MD Niamul (2026). GA4 WooCommerce Tracking — Fix Missing Purchases. Source
5. Google / Stape (2026). Google Ads Conversions Tracking with Data Manager API. Source