This is a guest post by Jude Nwachukwu Onyejekwe. He is a prolific content creator, and he curates the DumbData portal, which is full of great, free resources for measurement enthusiasts.

In this article, he shares some useful learnings for working with click identifiers.

Click IDs are URL parameters used by ad platforms. They are attached to outgoing links (ad clicks), so that when the user lands on a website, the URL would include this identifier. Pixels and scripts that then run on the landing page can take this identifier and forward it to the vendor, who can then correlate behavior on the landing page with the ad that was clicked.

Read carefully through these tips, as incorrectly managed click IDs can lead to attribution loss or general decline in data quality.

X

The Simmer Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!

What are click identifiers? #

When a user clicks on your ads, whether from Google Ads, TikTok Ads, or X (formerly Twitter), a unique click identifier is often generated by the media platform and added as a query parameter to the landing page URL.

These identifiers, such as gclid for Google or ttclid for TikTok, play a crucial role in accurately attributing conversions, especially offline ones that happen after a form submission, for example.

Click ID Parameter Platform / vendor
gclid Google Ads
gclsrc Google Ads
wbraid Google Ads
gbraid Google Ads
li_fat_id LinkedIn
fbclid Meta
msclkid Microsoft Ads
ttclid TikTok
twclid X
ScCid SnapChat
Obclid Taboola
dclid Floodlight

Note! This is not an exhaustive list. However, it is a decent sample of the most common click identifiers you might come across.

Capturing these identifiers correctly is essential for a reliable measurement setup. However, there are a few common pitfalls that can cause you to lose valuable data or misattribute conversions.

In this guide, I’ll walk you through the top mistakes marketers, analysts, and developers make when working with click identifiers, regardless of the ad platform, and how to avoid them.

  1. Altering the click identifier during URL transformation
  2. Click identifiers stripped by the website
  3. Only relying on URL parameters
  4. Misconfiguring click identifier cookies
  5. Using the wrong case format for query parameters
  6. Not using a secondary storage backup (beyond cookies)

Altering the click identifier during URL transformation #

Click identifier values are case-sensitive. Case-sensitivity means that values that differ solely by case are treated as differently as if they’d differ by actual values, too. In a case-sensitive context, abc123XYZ is not the same as abc123xyz.

When working with gclid, for example, Google’s documentation clearly states that the gclid query parameter value should not be normalized at any point of data capture. If you change it to all-lowercase or all-uppercase, the value will change and attribution will be broken.

Image source: https://support.google.com/analytics/answer/2938246

This principle is likely to apply most advertising platforms. It’s a good rule of thumb to keep the identifier value as it was in the original request.

Click identifiers stripped by the website #

Sometimes, the problem isn’t in your tags and scripts in Google Tag Manager, but with how your website handles unfamiliar parameters in the page URLs.

Even if you’ve correctly implemented click identifier value retrieval tracking in Google Tag Manager (or hardcoded it), your website might automatically strip out click identifiers from the URL unless they have been allowlisted first.

This can prevent the generated click identifier’s value from being captured at the moment of conversion (e.g. form submission).

To prevent this, always test your landing pages. Simulate a typical ad click with a final destination URL that contains a click identifier for the ad platform you are working on, and then reload the page. If the identifier disappears from the URL, it will create a problem for your offline conversion tracking or click identifier value capturing, and this is something your engineering team should address.

Only relying on URL parameters #

Grabbing the click identifier directly from the URL and auto-filling a hidden form field at the point of user form submission is a valid approach, but only in certain situations.

This works well if the form is on the same landing page where the user first arrives after clicking the ad.

But what if the user browses to other pages before submitting the form? In that case, the click identifier URL parameter is no longer available, and you lose the attribution.

Browser cookies are the standard in these scenarios, even though modern browsers are working to reduce their longevity.

Storing the click identifier in a cookie ensures it persists as users navigate your site.

It’s important to note that most advertising vendor libraries automatically store the click ID in a cookie as long as their native pixel is running on the landing page that the user visits. However, do note that these cookies are still subject to browsers’ tracking protection mechanisms.

Misconfiguring click identifier cookies #

Before discussing cookie misconfiguration issues, it’s essential to note that in the European Union, website visitors must provide consent before you can store any (non-essential) information in their browsers, and this includes click identifiers.

Make sure you have a functioning consent banner and a well-configured consent management system in place.

Here are the most common misconfigurations when it comes to storing click identifiers in browser cookies.

Let’s say a user lands on a subdomain create.example.com, and your cookie is configured only to be set for that subdomain. If the form is on www.example.com, for example, the cookie won’t be available, and the identifier will be lost.

Similarly, if you set the cookie at a specific page path, such as /laundry-service, but the form is on the page /quote, the cookie will not be accessible on the form page because it was written to a different page.

Recommended fix: Always set cookies on the root path (/) and the naked domain name (example.com) so that the cookie is accessible site-wide.

2. Storing cookies when the identifier is not available #

Make sure the cookie is only set when the click identifier is actually present in the URL. Storing undefined or null as a value can cause errors when retrieving the value for passing it to the vendor.

If you’re using a Google Tag Manager tag to set the cookie, ensure it only fires when the identifier is available. My Smart Cookie Setter Tag Template is a helpful tool for this.

Recommended fix: Make sure the cookie is only saved if the URL has the given parameter. Avoid saving non-existent or placeholder values.

If a user first visits your site via a YouTube ad and later returns through a Google Search ad, you should update the stored click identifier to reflect the latest one.

Failing to do this can result in incorrect attribution, especially in offline conversion tracking.

Recommended fix: Make sure the cookie is updated whenever the URL has the given click identifier.

Using the wrong case format for query parameters #

Just like the click identifier value is case-sensitive, the URL parameter name itself is case-sensitive, too. &GCLID is not the same as &gclid.

Consult the table at the beginning of this article. As you can see, for example, Snapchat uses ScCid as its click ID. However, if your implementation in Google Tag Manager tries to look for sccid, it won’t find anything.

This is because Google Tag Manager’s built-in URL variable is case-sensitive.

As you can see in the screenshot below, you’ll notice that the correct Snapchat click identifier SsCid returns a value, whereas the lowercase sscid does not.

This highlights the importance of identifying how each ad platform appends its click identifier, including the exact case format. While you could choose to transform the case to match what you’re expecting, keep in mind that modifying the URL’s case can cause the same issues mentioned earlier, especially since many platforms treat click identifiers as case-sensitive.

The recommended approach is to always match the case format used by the ad vendor to ensure you’re retrieving the correct values.

Not using a secondary storage backup (beyond cookies) #

While cookies are useful, they’re not foolproof. Tracking protections in browsers like Safari may shorten their lifespan or block them entirely.

It’s helpful to have a backup like localStorage. Unlike sessionStorage, it persits even after a user closes their browser.

As an API, it’s also much easier to use than cookies. Also, localStorage is a browser-only feature, so it doesn’t add weight to the HTTP requests like the Cookie header does.

Be mindful that localStorage is not impervious to browser tracking protections. If browsers or browser extensions place limitations on cookies, they will most likely do so on other browser storage mechanisms, too.

Remember that although “cookies” is the word most often used with privacy regulations, all the same stipulations apply to localStorage and other storage mechanisms, too.

Beyond browser storage mechanisms, you could build your own identity graph server-side, bridging click identifiers with more permanent identifiers (such as hashed email addresses). However, that’s beyond the scope of this article.

Summary by Simo #

This is a solid list of things to keep in mind when working with click identifiers. Thank you, Jude!

As third-party cookies are on the decline, the success of attribution measurement relies almost solely on the ability to link an ad impression or ad click with actions taken on the advertiser’s site.

The gclid, fbclid, and other identifiers all seek to attribute advertiser conversions to a meaningful interaction on the source platform. URL decoration like this hasn’t yet been aggressively limited by browsers, but there are mechanisms in place (in Safari/WebKit, for example), which indicate that click identifiers are under close scrutiny.

Jude has created a number of useful Google Tag Manager templates for managing click identifiers (among other things). Take a look at his bountiful GitHub repositories here, and don’t forget to give him a follow on LinkedIn.

As always, if you have questions or comments, leave them below!