fbclid Lost After Redirect: Keep Meta Click Data Intact
Updated
A redirect, shortener or URL-cleaning script removes fbclid before the landing page can store it in the _fbc cookie. Click a real ad, follow every hop with Preserve log on, and add fbclid to the allow-list of the first rule that drops it.
Find the exact hop that drops the Meta click identifier and confirm the landing page can still read it.
When someone clicks a Meta ad, the destination URL usually receives an fbclid parameter. The Pixel can store that value as click information in the _fbc first-party cookie, and a server integration can pass the same value with Conversions API events. If a redirect, shortener or routing rule removes fbclid before the landing page loads, that click context may never be stored. The page still returns 200 and looks healthy, so the gap is easy to miss. Trace the real route hop by hop instead of guessing.
What to check
1. Capture a real click URL
Click your own live ad, or use the ad preview link with a clearly named QA campaign, and copy the first URL the browser opens. Confirm it contains fbclid alongside your UTM parameters. Testing a clean destination URL you typed yourself skips the redirect rules most likely to cause the problem. Record the entry URL, device and time as the first line of evidence.
2. Follow every hop with Preserve log enabled
Open the Network panel, enable Preserve log and load the captured URL. Record each document request and its status: 301, 302, 307 and 308 responses, then any JavaScript or meta-refresh navigation after a page loads. Server-side redirect tracers miss browser-driven routing, so use a real browser for at least one test. Note the full query string after every hop.
3. Identify the first hop that drops fbclid
Compare the query string before and after each transition. Illustrative example: https://go.example.com/offer?utm_source=facebook&fbclid=TEST forwarding to https://www.example.com/offer?utm_source=facebook has dropped the click identifier while keeping the UTM. The rule responsible is the one that produced that first stripped URL. These domains are placeholders, not AdVault endpoints.
4. Review allow-lists and parameter rewriting
Many redirect tools forward only a fixed list of known parameters, such as the UTM set, and discard everything else. Others rebuild the destination URL from a template. Check shorteners, affiliate trackers, CDN rules, server rewrite rules and CMS redirect plugins. If a rule uses an allow-list, add fbclid deliberately instead of switching to forwarding every parameter, which can leak unrelated or sensitive values.
5. Check geo, language and consent routing
Locale and country redirects often send visitors to a different path and forget the original query string. Consent-management or bot-protection interstitials can do the same when they reload the page. Test from the locales and devices your campaign actually targets. A route that keeps fbclid on desktop can still drop it on a mobile or language-specific variant.
6. Watch for client-side URL cleaning
Some sites remove tracking parameters from the address bar with JavaScript to make URLs look tidy. If that runs before the Pixel reads the URL, the click identifier is lost even though no redirect touched it. Compare the URL in the first document request with the address bar after the page finishes loading. Any cleaning code should run after measurement tags have had a chance to read the parameters.
7. Confirm the Pixel stored the click information
On the final landing page, open the browser’s storage view and look for the _fbc cookie after a test click. Its value should include the fbclid from your test URL. If fbclid reached the page but no _fbc cookie appears, check consent state, cookie restrictions and whether the base Pixel loaded at all. Record which consent choice was active, and never force cookies over a user’s refusal.
8. Pass click data to server events where you use them
If you send Conversions API events, include the click information your server received or stored, using the fbc field in user data, and the browser ID fbp where available. A server that never sees fbclid cannot reconstruct it later. When the conversion happens on another domain or after a later visit, store the value at entry and carry it to the conversion step through your own systems.
9. Handle cross-domain journeys explicitly
If the visitor moves from your landing page to a checkout or registration provider on another domain, a cookie on the first domain is not readable on the second. Decide whether the second domain needs its own Pixel, receives the click identifier through an approved parameter, or reports conversions server-side. Treat this as a measurement design decision with the owners of both domains.
10. Retest the real route and keep a baseline
After fixing the responsible rule, repeat the full test from a fresh Meta click. Save a redacted entry URL, hop-by-hop trace, final URL, _fbc presence, consent state and date. Repeat the check after changes to shorteners, redirects, consent tools or site code, since any of them can strip the identifier again without changing how the page looks.
Before you call it fixed
- Real ad click URL captured with fbclid
- HTTP and browser redirects traced
- First hop that drops fbclid identified
- Allow-lists updated deliberately, not opened to everything
- Geo, language and consent routes tested
- Client-side URL cleaning ordered after tags
- _fbc cookie observed under permitted consent
- fbc and fbp passed with server events where used
- Cross-domain journey owner agreed
- Known-good route saved as baseline
Check the production URL
A correct configuration on paper can still fail after redirects, deployment or consent logic. Use the exact URL your campaign will send traffic to.
Check a campaign URLVerify the signal directly
Related troubleshooting guides
Technical references
Scan the full campaign route.
See where the click lands, what survives the redirect chain and which supported tracking signals are visible on the final page.