Fix guide · Framer · medium · about 30 min

Click ID from Meta ads is not stored on Framer

For the finding “Click ID from Meta ads is not stored”. Not on Framer? See the general guide.

What this means

When someone clicks a Meta ad, Meta adds ?fbclid=... to the link. The Meta Pixel on your Framer site should save it in the first-party cookie _fbc, so later events (a form submission, a booking) can be tied back to the ad click. On your site, the click ID did not end up in _fbc.

Why it costs you money:

How to confirm it yourself

Our check opens your page on a mobile-sized browser in the EU with a test click ID (fbclid=TRACKCHECK_TEST_FBCLID), accepts the cookie banner and looks for _fbc. If our report shows a redirect chain, start there.

  1. Open a private (incognito) window, open developer tools (F12) on Network, and tick Preserve log.
  2. Open the exact URL your ads use, with a made-up click ID added: https://yourdomain.com/landing?fbclid=test123.
  3. If the first request is a redirect (301, 302, 307, 308), check its Location header. Does the new address still contain ?fbclid=test123?
  4. Accept the cookie banner, wait a few seconds, then go to Application > Cookies (Chrome) and look for _fbc. It should look like fb.1.<timestamp>.test123. You should also see _fbp.

How to fix

  1. Point your ads at the final address. A Framer site with a custom domain has one primary domain, set in the domain settings of your Framer site, and the other version (with or without www) redirects to it. Framer also redirects http to https and removes a trailing slash from page addresses. In our tests on Framer-hosted sites, these redirects kept the query string, including fbclid. Still use the exact final address (primary domain, https, path without trailing slash) in every ad URL, so the visitor lands without a redirect.
  2. Check Framer redirects. Redirects you set up yourself are under Site Settings > Hosting > Redirects. In our test on a Framer site, these also kept the query string. Test each redirect your ads go through with ?fbclid=test123 as described above, and if one drops it, link your ads to the destination page directly.
  3. Check any redirects outside Framer, such as a domain registrar’s forwarding, a link shortener, or a campaign link tool in front of the site. These commonly drop the query string.
  4. Make sure the pixel runs on the landing page after consent. _fbc is written by the pixel. If you use Framer’s Cookie Banner component with GTM, the Meta tag has to fire on the same page after the visitor accepts; if it only fires on the next page, fbclid is no longer in the address and _fbc is never written. See “Meta Pixel does not fire after cookie consent on Framer”.
  5. Check the pixel is set up to use first-party cookies. In Meta Events Manager, open Data sources, select your pixel and open Settings. Under Cookie settings, Cookie usage shows whether first-party cookies are on (they are on by default). If they were turned off, click Edit, turn First-party cookies on and save. Without first-party cookies the pixel does not write _fbp and _fbc on your domain.
  6. If you use a tracking plugin (for example Pixelary or PixelFlow), check in its documentation how it stores the click ID and whether it waits for the Framer Cookie Banner. Pixelary is built by the same team as IsPixelWorking; the check below works the same for every tool.
  7. Publish the site after any change.

Common causes

How to verify the fix

  1. Repeat the test above using the exact ad URL: no redirect drops ?fbclid=test123, and after accepting cookies _fbc ends with test123.
  2. Open another page of the site: _fbc is still there.
  3. Re-run the check on IsPixelWorking. The issue should be gone.

Sources