Connecting Gravity Forms to Meta Conversions API
Gravity Forms stores the entry in your own WordPress database, which makes it one of the easier sources to join correctly. Meta's pixel loses a large share of conversions to Safari, ad blockers and iOS, and the Conversions API exists because of it. The join between them succeeds or fails on one thing: whether the fbc and fbp values reaches the Gravity Forms entry before the conversion happens, because Meta can only match a conversion it can tie back to a click it recognizes.
Free30 minutesNo obligation
Specific to this pair
Gravity Forms to Meta CAPI: one event_id for AJAX and server
Fill a hidden field with a random event_id from JavaScript at render, then use it on both the pixel Lead, fired on gform_confirmation_loaded or a redirect page, and the server Lead from gform_after_submission. Send _fbc, _fbp, IP, user agent and hashed name, email, phone and address sub-inputs. Never send health or case-detail fields.
The deduplication key has to exist before the form submits, because the browser and the server need to share it. Add a hidden field, fill it with a random ID from JavaScript when the form renders (JavaScript runs in the visitor's browser, so page caching cannot freeze it), and use that value as event_id in both places. The pixel's Lead fires on the gform_confirmation_loaded event for AJAX forms or on the confirmation page for redirect forms; the server's Lead fires from gform_after_submission reading the same field.
The same POST request gives you most of what Meta's match quality depends on: the _fbc and _fbp cookies, the visitor's IP address and user agent, and whatever the form collected. Send hashed email, phone, first and last name, and, if the form has an address field, city, state and ZIP. Gravity Forms' name and address fields store their parts as separate inputs, so map each sub-input rather than the combined value.
Healthcare and legal sites use Gravity Forms heavily. If the form asks about symptoms, conditions, case details or anything similar, none of those fields go to Meta, and on a HIPAA-covered site you should confirm with counsel whether sending even the Lead event from that page is allowed.
Gravity Forms → Meta · what breaks
Why this join usually fails — Gravity Forms → Meta
- 01
The fbc and fbp values never reaches Gravity Forms
The identifier must be written into a hidden field with dynamic population enabled, and that only works if the parameter is on the URL when the page renders. Page caching serves a cached render to the visitor, so the dynamic population never runs — the same caching problem that breaks WooCommerce.
- 02
Dynamic population fails silently under page caching
The field is configured correctly and still arrives empty, because the visitor was served a cached page rendered for someone else. This is the most common Gravity Forms failure and it looks like nothing is wrong.
- 03
Double counting from broken deduplication
Server and browser both fire, the event_id does not match, and Meta counts two purchases. Reported ROAS goes up, the business does not, and it can run for months before anyone reconciles against the store.
- 04
Nothing reconciles afterwards
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
Gravity Forms → Meta · the fix
What working looks like — Gravity Forms → Meta
The fbc and fbp values on every entry
Conversions arriving in Meta
Events appear in Events Manager with an Event Match Quality score, deduplicated against the pixel, and become usable for optimization and attribution.
Reconciled against the source
Gravity Forms → Meta · architecture
How Gravity Forms and Meta actually connect
- 1
Gravity Forms holds the truth
The entry lives in your database with every field value attached. You can query it, back it up and reconcile against it without depending on any third party, which is a real advantage over hosted form tools.
- 2
Meta Conversions API needs a click to match
Meta matches server events to people using whatever identifiers you send, hashed with SHA-256 where required. There is no single mandatory key, which is why quality varies so much between implementations — a poorly matched event is accepted, reported, and worth much less than it appears.
- 3
The identifier is the bridge
The fbc and fbp values, captured at the visit and carried into the Gravity Forms entry.
- 4
The event source decides reliability
Fire server-side from the PHP hook. This runs regardless of caching, AJAX submission, or what the confirmation page does.
- 5
Deduplication at the destination
Meta deduplicates on the pair of event_name and event_id. The browser pixel and the server event must send the same event_id for the same conversion, within the deduplication window. Get this wrong and every purchase counts twice — which is by far the most common Conversions API failure and it inflates reported ROAS rather than reducing it.
Gravity Forms → Meta · normal or broken
Working vs. broken, side by side — Gravity Forms → Meta
Normal, not a fault
The fbc and fbp values present on the entry
Sent from the gform_after_submission hook
Deduplicated correctly
Meta deduplicates on the pair of event_name and event_id. The browser pixel and the server event must send the same event_id for the same conversion, within the deduplication window. Get this wrong and every purchase counts twice — which is by far the most common Conversions API failure and it inflates reported ROAS rather than reducing it.
Reconciles with the source
Actually broken
The fbc and fbp values missing on most records
The identifier must be written into a hidden field with dynamic population enabled, and that only works if the parameter is on the URL when the page renders. Page caching serves a cached render to the visitor, so the dynamic population never runs — the same caching problem that breaks WooCommerce.
Sent from the browser
The field is configured correctly and still arrives empty, because the visitor was served a cached page rendered for someone else. This is the most common Gravity Forms failure and it looks like nothing is wrong.
Counted twice, or not at all
Server and browser both fire, the event_id does not match, and Meta counts two purchases. Reported ROAS goes up, the business does not, and it can run for months before anyone reconciles against the store.
Nobody has reconciled it
Gravity Forms → Meta · diagnose
Diagnostic order — Gravity Forms → Meta
- 01
Count entrys carrying the fbc and fbp values
- 02
Follow one real conversion end to end
- 03
Submit a test entry through a cached page
Not through a logged-in admin session, which bypasses the cache. If the hidden field is empty on the cached path and populated on the admin path, caching is your cause.
- 04
Read Event Match Quality and the deduplication indicator
In Events Manager, open the event and check both. A low match quality means weak identifiers; a missing deduplication indicator means your event_id pairing is broken.
- 05
Read the match rate, not the success message
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
Gravity Forms → Meta · prove
How it gets proven — Gravity Forms → Meta
Source of truth
The Gravity Forms entries list for the same window, or the wp_gf_entry table directly.
- The fbc and fbp values confirmed present on a live entry.
- Deduplication confirmed in Events Manager on a real purchase, with the browser and server events visibly paired rather than counted twice.
- Entry meta confirmed populated on a submission made from a fully cached page as an anonymous visitor.
Gravity Forms → Meta · free audit
What we check in the free audit
- Count entrys carrying the fbc and fbp values
- Follow one real conversion end to end
- Submit a test entry through a cached page
- Read Event Match Quality and the deduplication indicator
- Read the match rate, not the success message
Checked against
The Gravity Forms entries list for the same window, or the wp_gf_entry table directly.
Free30 minutesNo obligation
Gravity Forms → Meta · when not to buy
When you don't need this — Gravity Forms → Meta
- Measure identifier coverage yourself first — pull your last hundred entrys and count how many carry the fbc and fbp values.
- If your site has no caching layer and one form, a developer can wire this in an afternoon. Worth trying before hiring anyone.
- If you are not running Meta ads at meaningful spend, the Conversions API is effort without payoff. It earns its cost when the optimization signal is worth improving.
Gravity Forms → Meta · what we deliver
What gets built — Gravity Forms → Meta
Identifier capture into Gravity Forms
Hidden field with 'allow field to be populated dynamically' enabled and a parameter name set, plus a cookie fallback via a gform filter so the identifier survives a visitor who browsed several pages before converting.
Event source: the gform_after_submission hook
Fire server-side from the PHP hook. This runs regardless of caching, AJAX submission, or what the confirmation page does.
Dispatch to Meta
Server-side events to the Conversions API with the event_id matched to the pixel, action_source set correctly, and customer data hashed before it leaves your infrastructure.
Reversals where they exist
Nothing to reverse, though entries marked spam should be excluded from the send.
Written guarantee
95%+ tracking accuracy
Measured against The Gravity Forms entries list for the same window, or the wp_gf_entry table directly.. Miss it and we keep working at no cost.
From $400 · See packages
FAQ
Gravity Forms → Meta questions, answered
Generate an event_id in the browser into a hidden field when the form loads, fire the pixel Lead with it on confirmation, and send the same value from gform_after_submission on the server.
Send hashed contact fields (email, phone, name, address parts) for matching. Never send free-text answers, health details, or case information.
Almost always because the fbc and fbp values never reached the Gravity Forms entry. The identifier must be written into a hidden field with dynamic population enabled, and that only works if the parameter is on the URL when the page renders. Page caching serves a cached render to the visitor, so the dynamic population never runs — the same caching problem that breaks WooCommerce. Measure coverage before debugging the dispatch.
Two things. The _fbc cookie, derived from the fbclid parameter on the landing URL in the format fb.1.<timestamp>.<fbclid>, is the click identifier. The _fbp cookie is the browser identifier. Beyond those, Meta matches on hashed customer information — email, phone, name, city, country — and every additional field raises the Event Match Quality score. Unlike Google, Meta does not need a click ID at all if the customer data is good, but match quality drops noticeably without it.
The gform_after_submission hook. Fire server-side from the PHP hook. This runs regardless of caching, AJAX submission, or what the confirmation page does.
Events Manager shows received events, the deduplication state and an Event Match Quality score per event. Events arriving is not the test — deduplicated, well-matched events arriving is. Compare Meta's reported purchases against your store's order count for the same window.
More on Gravity Forms → Meta
- Gravity Forms + Meta CAPIMeta Conversions API setup for Gravity Forms
- Gravity Forms → Google AdsConnecting Gravity Forms to Google Ads
- Gravity Forms → GA4Connecting Gravity Forms to GA4
RELATED GUIDES
Where Gravity Forms → Meta fits in the rest of your tracking
- Meta · Home servicesMeta Ads conversion tracking for home service businesses
- Meta · Law firmsMeta Ads conversion tracking for law firms
- Meta × CRM DealsHow to reconcile Meta Ads against your CRM's closed-won deals
- Meta · Lead magnet → saleHow to track lead magnet to sale for Meta Ads
- Jotform → MetaConnecting Jotform to Meta Conversions API
- Gravity Forms → X AdsConnecting Gravity Forms to X Ads
- Law firmsConversion tracking for law firms, without sending case details anywhere
- Fluent Forms → MetaConnecting Fluent Forms to Meta Conversions API
Free · 30 min
Get Gravity Forms and Meta joined properly
WhatsAppFree30 minutesNo obligation
