You’re spending money on Facebook Ads. The leads come in. But when you look at your form submissions, you have no idea which ad, audience, or campaign generated each one. Meta Ads Manager says you got 30 conversions this week — your inbox has 30 enquiries and zero attribution data.
The missing link is the fbclid — a Facebook Click Identifier that Meta attaches to every ad click. Most WordPress advice tells you to strip it from your URLs. That’s exactly backwards. Here’s how to capture it instead and connect every form submission to the Facebook ad that drove it.
What Is fbclid — and Why Most Advice Gets It Wrong
When someone clicks a link on Facebook or Instagram — whether it’s a paid ad or an organic post — Meta appends a unique fbclid parameter to the destination URL. A typical landing page URL looks like this:
https://yoursite.com/landing-page/?fbclid=IwAR3x8kLmN2pQ7rT...
That long string after fbclid= is a unique click identifier. It’s generated fresh for every single click, and it encodes which campaign, ad set, and creative the visitor interacted with.
Search for “fbclid WordPress” and you’ll find dozens of forum threads and blog posts explaining how to remove it. The reason? fbclid can cause caching issues, inflate Google Analytics page counts, and trigger 404 errors on misconfigured sites. So the default advice became: strip it out.
But if you’re running Facebook Ads to generate leads, removing fbclid throws away the one piece of data that ties a form submission back to a specific ad click. Instead of removing it, you should be capturing it.
How fbclid Powers Meta Ads Conversion Tracking
Here’s the business case in one sentence: when you capture the fbclid and send it back to Meta, your ad costs go down because Meta can see which clicks actually turn into leads.
Without fbclid data, Meta’s ad algorithm optimises based on page views and pixel events. It knows someone clicked your ad and loaded a page, but it doesn’t know whether that click turned into a qualified lead, a sales call, or a closed deal. With fbclid, you close that loop.
The process works like this:
- A visitor clicks your Facebook ad. Meta appends a unique
fbclidto the URL. - Your website captures the fbclid and stores it (in a cookie, hidden field, or database).
- The visitor submits a form. The fbclid is recorded alongside their contact details.
- You send that conversion event back to Meta via the Conversions API, including the fbclid.
- Meta matches the conversion to the original click and optimises future ad delivery.
This is particularly valuable for offline conversions — leads that turn into phone calls, appointments, or sales days or weeks after the initial click. Without the fbclid, Meta has to rely on probabilistic matching (email address, phone number), which typically achieves around 50% match rates. With the fbclid, match rates approach 100% because it’s a direct, deterministic link between click and conversion.
Meta’s Event Match Quality (EMQ) score — which directly affects your ad performance — ranks fbclid as one of the highest-priority parameters. Including it in your Conversions API events improves attribution accuracy and gives Meta’s algorithm better data to work with.
fbclid vs UTM Parameters: You Need Both
If you’re already adding UTM parameters to your Facebook ad URLs (like utm_source=facebook&utm_medium=cpc), you might wonder why fbclid matters. The short answer: they serve different systems and you need both.
| Feature | fbclid | UTM Parameters |
|---|---|---|
| Added by | Meta (automatic) | You (manual) |
| Unique per click | Yes — every click gets a different ID | No — same tags across all clicks |
| Read by GA4 | No — GA4 ignores fbclid | Yes — powers campaign reports |
| Read by Meta | Yes — core to conversion tracking | Not used by Meta |
| Purpose | Click-level attribution within Meta | Channel-level reporting in analytics |
Without UTM parameters, your Facebook traffic shows up as generic “Organic Social” or “Referral” in Google Analytics — you lose all campaign-level insights. Without fbclid, Meta can’t accurately attribute conversions back to specific ad clicks — your ad optimisation suffers.
The takeaway: UTM parameters tell your analytics which campaign brought the visitor. fbclid tells Meta which click turned into a customer. If you’re serious about Facebook Ads ROI, capture both. (If you’re also running Google Ads, you’ll want to capture the gclid as well.)
Three Ways to Capture fbclid in WordPress Form Submissions
The core challenge: fbclid only exists in the URL of the landing page. The moment the visitor clicks to another page on your site, the parameter is gone. If your form is on a different page — or the visitor browses around before submitting — you need a way to persist the fbclid across page navigations.
Here are three approaches, from most manual to fully automatic.
Method 1 — JavaScript Snippet + Cookie Storage
This approach uses a small JavaScript snippet that reads the fbclid from the URL on the landing page and saves it in a browser cookie. The cookie persists as the visitor navigates your site, making the fbclid available whenever a form is submitted.
What this code does: It checks if the current URL contains an fbclid parameter. If it does, the script saves the value in a first-party cookie that lasts for 7 days. On any page with a form, a second snippet reads the cookie and populates a hidden field.
// Save fbclid from URL to cookie (add to your theme header or a code snippets plugin)
(function() {
var params = new URLSearchParams(window.location.search);
var fbclid = params.get('fbclid');
if (fbclid) {
var expires = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000).toUTCString();
document.cookie = 'lsp_fbclid=' + encodeURIComponent(fbclid) + ';expires=' + expires + ';path=/;SameSite=Lax';
}
})();
Then, on the page with your form, add a hidden field and populate it from the cookie:
// Read fbclid cookie and populate a hidden form field
document.addEventListener('DOMContentLoaded', function() {
var match = document.cookie.match('(^|;)\\s*lsp_fbclid=([^;]+)');
if (match) {
var field = document.querySelector('input[name="fbclid"]');
if (field) field.value = decodeURIComponent(match[2]);
}
});
Limitations: You need to add a hidden field to every form individually. If you use multiple form plugins, you’re maintaining separate configurations for each. Safari’s Intelligent Tracking Prevention caps JavaScript-set cookies to 7 days — and just 24 hours when the URL contains tracking parameters like fbclid. And if you forget to add the snippet to a new page, that traffic goes untracked.
Method 2 — Hidden Form Fields per Plugin
Most WordPress form plugins support hidden fields that can be pre-populated with URL parameters or cookie values. The process varies by plugin:
- WPForms: Add a Hidden Field, set the default value to
{query_var key="fbclid"} - Gravity Forms: Add a Hidden field, enable “Allow field to be populated dynamically” and set the parameter name to
fbclid - Contact Form 7: Add
[hidden fbclid default:get]to your form template - Fluent Forms: Add a Hidden Field and set the default value to
{get.fbclid}
This works on the landing page itself, but it has the same cross-page problem as Method 1. If the visitor lands on Page A (with the fbclid in the URL) and submits a form on Page B, the hidden field pulls from the current URL — where the fbclid no longer exists. You still need the JavaScript cookie snippet from Method 1 to bridge the gap.
For a detailed walkthrough of setting up hidden fields across seven form plugins, see our guide on populating hidden form fields with UTM parameters. The same technique applies to fbclid.
Method 3 — LeadSourcePro Plugin (Automatic)
LeadSourcePro handles fbclid capture automatically across all supported form plugins — no hidden fields, no JavaScript snippets, no per-form configuration.
When a visitor lands on your site, a lightweight vanilla JavaScript snippet (no jQuery) reads the fbclid from the URL and stores it in a first-party cookie. When the visitor submits any form — whether it’s Contact Form 7, WPForms, Gravity Forms, Ninja Forms, Formidable Forms, Fluent Forms, or Elementor Pro Forms — the plugin reads the cookie server-side via PHP and records the fbclid alongside the form submission data.
Alongside fbclid, LeadSourcePro also captures:
- Other click IDs: gclid (Google Ads), msclkid (Microsoft Ads), li_fat_id (LinkedIn), ttclid (TikTok)
- UTM parameters: source, medium, campaign, term, content
- Auto-detected traffic source: labelled as “Meta Ads,” “Google Ads,” “Organic Search,” etc.
- Landing page URL and referrer
Everything is stored in your WordPress database. No data leaves your server. The free version includes all tracking features and integrations — limited to the 10 most recent entries on a rolling basis. Pro plans unlock unlimited entries and email notifications.
Why fbclid Disappears — and How to Fix It
Even if you set up fbclid tracking correctly, several common WordPress configurations can silently break it. Here are the four most frequent culprits and their fixes.
Safari ITP Limits fbclid Cookies to 24 Hours
Safari’s Intelligent Tracking Prevention (ITP) maintains a list of domains with “cross-site tracking capabilities.” Facebook is on that list. When someone clicks a Facebook ad and lands on your site with ?fbclid=... in the URL, Safari caps all JavaScript-set cookies on that page to 24 hours.
Even without the fbclid parameter, Safari caps JavaScript cookies to 7 days. Here’s how different browsers handle cookie persistence:
| Scenario | Cookie Lifetime |
|---|---|
| Safari — JS cookie with fbclid in URL | 24 hours |
| Safari — JS cookie without fbclid | 7 days |
| Safari — server-set cookie (matching IP) | Up to 400 days |
| Chrome — any cookie | Up to 400 days |
This matters because Safari holds roughly 24% of global browser market share — and every browser on iOS (including Chrome on iPhone) uses Safari’s WebKit engine, inheriting these same restrictions.
The fix: Set cookies server-side via HTTP headers (PHP’s setcookie()) rather than JavaScript’s document.cookie. Server-set cookies from your own domain bypass ITP’s 7-day and 24-hour limits. LeadSourcePro uses this approach — the fbclid is captured via JavaScript on the frontend but the cookie is read and processed server-side via PHP, ensuring the data persists reliably across browsers.
404 Errors from fbclid Query Strings
Some WordPress configurations treat URLs with unknown query parameters as invalid. When Facebook appends ?fbclid=IwAR3... to your page URL, the server may return a 404 instead of your landing page. This is especially common with:
- Custom
.htaccessrules that don’t account for query strings - The Redirection plugin not matching URLs with appended parameters
- WP Cerber Security’s Traffic Inspector blocking URLs with
?fbclid=
Fixes: If you use the Redirection plugin, enable regex matching and append \?.* to your source URLs. For .htaccess issues, ensure your rewrite rules don’t strip or reject query parameters. If WP Cerber is blocking Facebook traffic, whitelist the fbclid parameter in Traffic Inspector settings.
Caching Plugin Conflicts
Caching plugins can interfere with fbclid tracking in two ways. First, they may create separate cached versions for every unique fbclid value, wasting storage and reducing cache hit rates. Second, they may serve a stale cached page that doesn’t execute the JavaScript needed to capture the fbclid.
Fixes by plugin:
- WP Rocket: WP Rocket ignores
fbclidas a query string by default and serves the cached page normally. No configuration needed. If you’re using a Meta Pixel plugin like PixelYourSite, add_fbcand_fbpto the “Never Cache Cookies” list so the pixel can update the fbclid cookie on each visit - Cloudflare / Cloudflare APO: Create a Cache Rule to ignore
fbclidquery strings, serving the same cached page regardless of the parameter value. If you use Cloudflare APO, verify it’s not stripping query parameters before they reach your tracking scripts
Redirect Chains Stripping Parameters
If your landing page URL passes through redirects — HTTP to HTTPS, www to non-www, link shorteners, or tracking intermediaries — the fbclid parameter can be silently dropped at any hop. This is the same issue that causes UTM parameters to disappear in WordPress.
Fix: Test your actual ad URLs end-to-end. Click the ad, check the final URL in the browser address bar, and confirm the fbclid parameter is still present. Eliminate unnecessary redirects between the ad click and your landing page.
fbclid and the Meta Conversions API
If you’re sending conversion events back to Meta via the Conversions API (CAPI), the fbclid becomes even more valuable. Meta expects the fbclid to be formatted as an fbc parameter in a specific format:
fb.1.1672531200000.IwAR3x8kLmN2pQ7rT...
The structure is: fb.1.[timestamp_in_milliseconds].[fbclid_value]. The timestamp records when the click occurred. Meta uses this to validate the freshness of the click data — fbclid values older than 90 days are flagged as expired.
Important: Meta phased out the separate Offline Conversions API in May 2025. All offline conversion events — in-store purchases, phone sales, qualified leads — now go through the unified Conversions API. If you were using the old offline event sets, you need to migrate to CAPI with the action_source parameter set to physical_store or system_generated.
For most WordPress site owners, you don’t need to implement CAPI yourself. Plugins like PixelYourSite or the official Facebook for WordPress plugin handle the server-side event transmission. What matters on your end is that the fbclid is captured and stored when the visitor arrives — the CAPI plugin can then include it in the events it sends to Meta.
fbclid Tracking Checklist
Use this checklist to verify your fbclid tracking is working end-to-end:
- Confirm fbclid reaches your landing page. Click your Facebook ad, check the browser address bar, and verify the
?fbclid=parameter is present in the URL. - Check for redirect stripping. If your URL redirects (HTTP → HTTPS, short URL → full URL), confirm the fbclid survives every hop.
- Verify cookie storage. Open your browser’s developer tools → Application → Cookies. Look for a cookie containing the fbclid value after the page loads.
- Test cross-page persistence. Navigate from the landing page to your form page. Confirm the fbclid cookie is still present.
- Submit a test form. Fill out your form and check whether the fbclid appears in the submission data (your email notification, CRM entry, or WordPress dashboard).
- Test in Safari. Open a private Safari window, click your ad link, wait 5 minutes, then submit a test form. Confirm the fbclid is captured despite ITP restrictions.
- Check for 404 errors. Append
?fbclid=test123to several pages on your site and confirm they load normally rather than returning a 404. - Verify caching compatibility. Clear your site cache, visit a page with
?fbclid=test123, then visit it again. Confirm the page loads correctly and the fbclid is captured both times.
Frequently Asked Questions
Does fbclid tracking work with my specific form plugin?
The JavaScript cookie method (Method 1) works with any form that supports hidden fields — the form plugin doesn’t matter as long as you can add a hidden input. LeadSourcePro integrates natively with Contact Form 7, WPForms, Gravity Forms, Ninja Forms, Formidable Forms, Fluent Forms, and Elementor Pro Forms, requiring no hidden fields or form modifications.
Is storing the fbclid a privacy concern under GDPR?
The fbclid is an anonymised click identifier — it doesn’t contain personal information, post IDs, campaign names, or user data. However, it is stored in a cookie, which means your privacy policy should disclose cookie usage for analytics and marketing attribution. LeadSourcePro includes recommended privacy policy language in its setup wizard, and all stored IP addresses are automatically anonymised (last octet removed).
Does fbclid appear on organic Facebook traffic (not just ads)?
Yes. Meta appends fbclid to all outbound clicks from Facebook, including organic posts, shared links, and Messenger messages — not just paid ads. If a visitor arrives via an organic Facebook share, the fbclid will be present but won’t be tied to any ad campaign. LeadSourcePro differentiates between these by checking for UTM parameters and click IDs: traffic with fbclid but no UTM parameters is labelled as a Facebook referral rather than Meta Ads.
Will fbclid tracking conflict with my existing Meta Pixel?
No. The Meta Pixel and fbclid capture via cookies or form fields operate independently. The Pixel fires events on the browser side, while form-based fbclid capture stores the click ID for lead attribution. They’re complementary — the Pixel handles real-time event tracking (page views, add-to-cart), while the stored fbclid connects form submissions to specific clicks for offline or delayed conversions.
How long does the fbclid remain valid?
Meta’s Events Manager flags fbclid values older than 90 days with a data quality warning — the event may still be accepted but with reduced match accuracy. For lead attribution purposes, the fbclid is most useful within the same session or within a few days of the click. LeadSourcePro offers three conversion window options: same session (recommended — clears when the browser closes), 1 day, or 7 days.
Start Capturing fbclid from Your Facebook Ads
Every form submission without a traffic source is a gap in your reporting. You’re left guessing which Facebook campaigns drive real leads versus which ones just generate clicks. fbclid tracking closes that gap — and on WordPress, you can set it up in under two minutes.
LeadSourcePro captures fbclid, gclid, msclkid, and UTM parameters automatically across seven form plugins. No hidden fields. No JavaScript to maintain. No form modifications.
See how it works — or install the free version and start tracking your next form submission.

Leave a Reply