5 min read

fbclid + Google Analytics

Ryan Bradley

If you’ve logged into Google Analytics recently you may have noticed the appearance of a pesky “fbclid” query parameter that is being automatically added to your URLs (aka pagepaths) making it look something like this:

Where is fbclid coming from and what is it for?

In mid-October last year, Facebook implemented the Facebook Click Identifier (fbclid).

Whenever someone on Facebook clicks a link back to your site, it automatically generates a unique fbclid and appends it to the URL (like the example above).

The reason Facebook is doing this, we can safely assume, is that this helps overcome conversion tracking issues created by people who are using ad-blockers, especially those on sites also carrying the Facebook tracking pixel.

So, while fbclid might be helping Facebook overcome measurement issues on their end, it is creating measurement headaches for everyone else!

For example, you’ve probably noticed in Google Analytics that traffic to your top performing pagepaths is looking pathetically low.

Worse, fbclid may even be costing you a lot money and you don’t even know it yet!

How exactly does fbclid affect my Google Analytics?

Google Analytics like most web analytics tools, out of the box, collect and report on metrics at a URL or pagepath level.

With fbclid, when users come to your site via a referral from Facebook, the destination pagepath will get this unique fbclid query parameter added to it. Annoyingly, Google Analytics then thinks that each click from Facebook to this link is actually a completely different pagepath. In other words, traffic that used to get attributed to a single pagepath in the past is now being split – rather, shredded – across hundreds, thousands or even millions of unique pagepaths, if the article is hugely popular!

From our clients’ data we have seen cases where up to 95% of traffic for a single pagetitle has been shredded across thousands of pagepaths with each variation clocking up single pageviews.

Most of the out-of-the-box content reporting in Google Analytics is now, effectively, useless.

With metrics now shredded across thousands of variations of the same pagepath, how can we determine what is the top performing content? A ranking report for top pagepaths will now grossly underreport the ‘true’ picture.

Reporting by pagetitle instead can sometimes overcome this, but it too can get messy if you frequently vary or optimize pagetitles. And conversely, if the same pagetitle is being reused for frequently updated content, for example, you may have a page along the lines of “weekly news” where the content changes weekly but the pagetitle remains the same.

Even using the Google Analytics API doesn’t overcome this issue. For example, let’s say you posted an article which received 10,000 referrals from Facebook. This has the potential to translate to 10,000 unique URLs where the only difference is the fbclid. As a result the API would return 10,000 rows for what is, in effect, a single piece of content. This is a major problem as there are restrictions on the API based on the number of calls-per-day and the number of rows that can be returned at a time. On a larger scale over multiple articles, this has the potential to blow out your API restrictions extremely quickly. If you are an agency and you are doing something like this over multiple clients, good luck!

Not only can the Facebook Click Identifier cost you in API calls and quotas, it can also cost you financially in terms of platform fees. Many companies resort to using caching solutions – such as the Cloudflare Content Delivery Network – to help improve the loading time of their website by serving a pre-cached version. If your website uses query parameters normally to help render content to visitors, caching solutions are generally configured to preserve query parameters, resulting in a cached version for each query parameter. Again, you can see how each click from your Facebook audience can quickly increase the number of caches being generated, all of which your company needs to pay for!

So how do I stop tracking the fbclid parameter?

There are a few different ways you can try to reduce the impact of the Facebook Click Identifier, but it really does come down to what is applicable to you. For Google Analytics, there is a way to simply ignore the fbclid parameter. In the Admin console of Google Analytics, navigate to the View you would like to ignore the fbclid parameter. In the “View Settings” section, you will see a section to ignore query parameters based on their name. Simply adding “fbclid” in this section will ensure that moving forward, Google Analytics will ignore the fbclid parameter for that view.

There are a few downsides to this solution. You will need to ensure that you add this query parameter filter to every single Google Analytics View that you need to individually. Once the filter has been applied, Google Analytics will only ignore the fbclid moving forward and your old data will not be cleaned up. Also, if Facebook were to change the name of the parameter, you will manually have to go back through and update each View again.

Thankfully for our clients here at, we have a long-standing and unique approach that completely overcomes the fbclid issue by “stitching” together all the metrics and tieing them back to the rightful pagepath without the need for any changes to Google Analytics or changes on site.

Written by
Ryan Bradley
Data and Software Engineer

Ryan utilises his approx. 7 years of experience at the intersection of computer science, enterprise-grade software engineering, and data science to gain an understanding of the world from many knowledge-domains and industries. He not only builds innovative scalable insights based on consumer and user behaviour, but also manages, educates and consults teams and business as a whole on data, best practices, and how these behaviours can have an effect on the user/individual, business objectives, growth and culture.