Click IDs Explained: gclid, fbclid, and First-Party IDs

Copy a link from any Google ad and look at what's riding along: ?gclid=Cj0KCQjw... followed by sixty-odd characters of apparent noise. You didn't put it there. Your agency didn't put it there. Google appended it at the moment of the click, and it did so for a reason that has nothing to do with decorating your URLs.

That string is a receipt. One click, one ID, issued once and never reused. When someone buys from you three days later, that receipt is what lets Google connect the sale back to the exact ad, keyword, and bid that earned it. Without it, the platform is spending your budget blind, and so are you.

If a single parameter carries that much weight, what happens when it gets stripped somewhere between the ad and your checkout page? Because it does get stripped, constantly, by browsers, redirects, and well-meaning link tools.

This page covers the click IDs each platform issues, how they tie a click to a sale, why they go missing, and how a first-party ID you control survives when platform ones don't. It sits inside our broader guide to link tracking, where click IDs are one layer of a larger measurement stack.

What a click ID actually is

Step back from the parameter itself for a moment and think about what an ad platform is actually trying to do. It spent your money showing an ad to one specific person, that person clicked, and three days later someone bought something on your site. The platform's entire business rests on whether that was the same person. Everything about click IDs exists to answer that one question.

A click ID is a unique ticket number for a single click. The instant someone clicks your ad, the platform generates a long random string, appends it to your landing page URL, and files a record on its side saying this ticket belongs to this click, from this ad, on this keyword, at this bid, at this moment. The string itself means nothing to you. You can't decode it, and you're not supposed to. It only means something when it comes back.

That return trip is the whole mechanism. When a conversion happens, your site (or your conversion tracking setup) reports it back to the platform with the ticket attached. The platform looks up the ticket and now knows exactly which ad, which keyword, and which bid earned the sale. Not "some ad in this campaign", but that one impression served to that one person. This is the data that feeds automated bidding, which is why a broken click ID quietly degrades your ad performance long before anyone notices a reporting gap.

So how is this different from the UTM tags you're probably already using? They ride in the same query string and look like cousins, but they answer different questions. UTMs are labels you write yourself, and every click from the same email or campaign carries the same values. They're built for aggregation, for questions like how the newsletter did this month or which channel drives signups. Click IDs go the other way. Every click gets its own value, written by the platform, never repeated. One is a category, the other is a receipt.

UTMs tell you how a crowd behaved. A click ID proves what one person did. You want both. UTMs feed your own analytics and campaign reports, and our complete guide to UTM parameters covers how to set them up without corrupting your data. Click IDs feed the platform's conversion matching, and they only work if the ticket survives the trip from ad to sale intact. Whether it survives is the real problem, and we'll get to it.

The IDs each platform uses

Every major ad platform has its own version of the same idea, and if you run paid traffic on more than one, you'll see several of these stacked on the same URL. Worth knowing each one by name, because when a conversion report looks wrong, the first question is always which ticket went missing.

gclid is Google's click ID. It appears on every click from Google Ads when auto-tagging is on, which it is by default, across Search, Shopping, YouTube, and Display. Google Analytics reads it to attribute the session, and Google Ads conversion tracking matches it when a sale is reported back, whether through the on-site tag or an offline conversion upload. If you import conversions from a CRM, the gclid is the value you're storing and sending back.

gbraid is Google's answer to Apple's tracking restrictions. On iOS, where a full gclid can't always travel with the click, Google appends gbraid instead. It's a privacy-constrained sibling that supports aggregated, campaign-level measurement rather than identifying one click. You don't choose between them; Google decides at click time. Your job is just not to strip either. (You may also see wbraid on web-to-app flows; same family, same rule.)

fbclid comes from Meta, appended to clicks from Facebook and Instagram ads and, notably, to plenty of organic shares too. The Meta Pixel picks it up on your landing page, and the Conversions API can carry it server-side, where Meta stores it inside the fbc parameter for matching. Because it also rides on organic links, don't treat every fbclid as paid traffic in your own reports.

msclkid is Microsoft Advertising's click ID, added when auto-tagging is enabled for ads on Bing and the Microsoft network. The UET tag on your site reads it, and offline conversion imports match against it. Functionally it's the gclid pattern with a different badge.

li_fat_id is LinkedIn's, appended to ad clicks when first-party cookies are enabled in your Insight Tag settings. The name stands for first-party ad tracking, which is also the reason it exists. LinkedIn's older matching relied on third-party cookies, and this is the replacement. The Insight Tag and LinkedIn's Conversions API both consume it.

Notice the pattern across all five. The platform issues the ticket, and the platform's own tag or API is the only thing that can redeem it.

You're not the customer for these parameters, you're the courier. So what happens when the courier drops the package?

Why platform click IDs get lost

Step back and look at the route a click actually travels. An ad click rarely goes straight from platform to landing page anymore. It passes through a link-in-bio page, a branded short link, a retargeting redirect, maybe a "safe link" wrapper added by a corporate email filter. Every one of those hops is a place where a query string can quietly disappear. And the click ID is nothing but a query string.

Start with the browsers themselves. Safari's tracking prevention and Firefox's enhanced protection both treat known ad-click parameters as tracking identifiers, and in some configurations they strip or truncate them before the page ever loads. Brave removes fbclid outright. The reader clicked your ad, arrived at your page, and the ticket number that would have credited the sale is already gone. Nothing broke. No error fired, the visit just arrived anonymous.

Then there's the plumbing you control, or think you do. A redirect configured to send visitors to a canonical URL will often forward the path and drop everything after the question mark, because whoever set it up was thinking about URLs, not parameters. The mechanics of what survives a hop and what doesn't are worth understanding in detail, and we cover them in how link redirects actually work. Unless a redirect explicitly preserves the query string, it usually won't.

Add URL-cleaning browser extensions, messaging apps that rewrite links for preview cards, and users who copy a link and manually trim the "ugly part" before sharing it, and you have four or five independent chances for the ID to vanish on a single journey.

What does the ad platform see when that happens? Not an error. It sees nothing. The conversion fires on your site, but with no ticket attached there's nothing to match it to, so the sale appears to have come from nowhere. The platform's algorithm concludes that ad, that keyword, that audience produced no revenue, and bids accordingly. Which means lost click IDs aren't a reporting annoyance. They're a signal starving the system that decides where your budget goes.

First-party click IDs: the version you control

Step back and look at the pattern. Every fragile link in that chain, browser filters, redirect hops, URL cleaners, breaks for the same reason. The click ID belongs to someone else. Google mints the gclid, Google's script reads it, and everything in between treats it as a foreign object it's free to discard. You're borrowing infrastructure you don't control, and the borrowing keeps getting more expensive.

So what changes when the ID is yours? A tracking domain you own sits in the click path anyway. Someone clicks your short link, your server receives the request, looks up the destination, and redirects. That moment is the one point in the whole journey where you have full control, before any browser policy or cleanup app has had a chance to touch anything.

If your redirect issues its own click ID right there and appends it to the destination URL, that ID arrives as a first-party parameter on your own site, on a link you built. Nothing upstream can strip what didn't exist yet, and browsers have far less appetite for interfering with a parameter passed between domains you operate.

Think of it as taking your own receipt at the door instead of trusting the courier's tracking number to survive the trip. The platform's ID might make it through. Yours definitely does, because you handed it over yourself at the last possible moment.

This is the shape modern conversion tracking has settled into, and not by accident. When third-party cookies and platform parameters both became unreliable, the answer both times was to move the identifier onto infrastructure the advertiser owns and match conversions server-side. We cover the full mechanics in our guide to conversion tracking without cookies, but the short version is that a first-party click ID is the piece that makes server-side matching possible at all. Without a durable ID on the click, there's nothing to join the sale against.

The tradeoff is honest, though. This only helps if your links actually route through a domain you control. If every ad points straight at your landing page, there's no redirect moment to exploit. But if you're already running tracked links, the ID comes almost free. Acturity issues a first-party click ID on every tracked link automatically, and the same click event feeds the real-time click analytics you're already reading, so the ID isn't extra plumbing. It's the same data, finally durable enough to close the loop.

What to do with all this

Step back for a second. Everything above is really one problem wearing different costumes. A click happens, a sale happens later, and something has to carry the connection between them. Click IDs are that something. Which means your whole job reduces to one principle — protect the ID from click to conversion. Three habits get you there.

First, stop breaking the platform IDs you already get for free. Audit every redirect between the ad and the landing page: shorteners, vanity domains, the "www to non-www" rewrite someone set up in 2019. If any hop drops the query string, gclid and its cousins die there, and your ad platform starts reporting sales from nowhere. Passing parameters through a redirect is a one-line config change. Not making it is a permanent hole in your attribution.

Second, if your links already route through a domain you control, issue your own ID at that moment. It costs nothing extra, and it keeps working when browsers or cleanup apps strip the platform ones. If you don't run tracked links yet, this is the strongest reason to start.

Third, close the loop. An ID that reaches your landing page and then goes nowhere is a ticket stub for a show nobody records. Store it with the signup or purchase, then send it back when you report the conversion. That round trip is the entire point.

None of this is glamorous work. But attribution isn't won with clever models. It's won by not losing the receipt.