GCLID, GBRAID and WBRAID: what they are and when each appears

You export last month’s leads from WordPress, open the Google Ads upload screen, and the gclid column is empty for a third of the rows. Nobody broke the form. The ID simply never made it from the ad click to the database, and a conversion with no click ID cannot be matched to an ad.

This guide explains what each of Google’s click IDs is, which traffic produces which, what the upload rules say, how WordPress setups lose the parameter, and how to capture it reliably. At the end there is a short map of the equivalent IDs on Meta, TikTok, Snapchat, Pinterest and LinkedIn. Facts come from Google’s and the platforms’ own documentation, fetched in October 2026. Where the documentation is silent, I say so rather than guess.

What a click ID is

When someone clicks an ad, the ad platform needs a way to recognise that click later, when a form is submitted or an order is paid, possibly days afterwards and possibly on a different system. The standard trick is to append a unique token to the landing-page URL. Your site, or a tool on your behalf, keeps the token and hands it back with the conversion. The platform matches token to click and credits the campaign.

Google’s help page on auto-tagging describes the mechanism: after a click, auto-tagging adds a parameter called GCLID (Google Click Identifier) to the URL, for example www.example.com/?gclid=123xyz (Google Ads Help, About auto-tagging).

GCLID: the default

gclid is the Google Click Identifier. Google’s Ads API documentation describes GCLIDs as identifiers captured from URL parameters when someone clicks your ad and goes to your website (Google Ads API, Upload click conversions). Some behaviour worth knowing, all from the auto-tagging help page:

• It only appears if auto-tagging is on. You control that under Admin, Account settings, Auto-tagging, with the option “Tag the URL that people click through from my ad”.
• Sometimes the GCLID is created at impression time rather than click time, and if the same user clicks the same ad again, the same GCLID is used.
• If your site uses redirects, Google says it is important to make sure the GCLID is passed to the final landing page.
• A small percentage of websites do not allow arbitrary URL parameters and serve an error page when auto-tagging is turned on. If your ad landing pages suddenly 404 after switching it on, that is the suspect.

GBRAID and WBRAID: the iOS pair

These two exist because of Apple’s App Tracking Transparency (ATT) rules. Google’s help page on iOS 14 measurement says that since ATT took effect on 26 April 2021, Google no longer sends the GCLID for iOS 14 traffic coming from ads on a handful of Google apps; for that traffic the gclid parameter is not appended and the ValueTrack {gclid} is empty (Google Ads Help, Updates to iOS 14 measurement). The replacements:

• wbraid (&wbraid={WBRAID}) is the parameter that helps attribute website conversions back to ads on iOS and works with conversion modeling, according to that page.
• gbraid is the parameter that helps measure app conversions driven by ad campaigns on iOS. Google notes it currently applies to Search, Shopping, Display and Performance Max campaigns only.

The Ads API documentation states the direction of travel more precisely than the help page does. A gbraid is present when a user clicks an ad on the web and is directed to your iOS app. A wbraid is present when a user clicks an ad in an iOS app and is directed to your webpage (Google Ads API, Upload click conversions). For a WordPress site, the one you will meet in your own landing-page URLs is wbraid: the click came from an ad inside an iOS app and landed on your site.

Two more things Google says that matter in practice. The offline-import help page describes GBRAIDs as “used for aggregate measurement on iOS and Safari” (Google Ads Help, Offline conversion imports), so expect less granular reporting than with a GCLID.

Which traffic produces which

Many blog posts present a tidy matrix, such as “iPhone Safari gets gbraid”. Google’s own pages state the two directional definitions above and the no-GCLID rule for iOS 14 traffic from ads on a handful of Google apps. They do not publish a rule for an iPhone user who clicks a search ad in Safari and lands on your website. I could not verify that case, so I won’t assert one.

Measure it instead: take the landing-page URLs of your ad traffic from analytics or server logs, split by device and browser, and count how many carry gclid, gbraid, wbraid or none.

Google’s Analytics help also says the GCLID is no longer used without user consent on iOS 14+ (Analytics Help). So make your capture code accept all three IDs.

Lifetimes: what is and is not documented

• The browser cookie. Google’s ads-cookie reference lists _gcl_aw, _gcl_ag and _gcl_gb with a duration of 90 days (Google, How Google uses cookies in advertising). That page lists the cookie names, not which identifier each holds. Third-party guides say they hold the gclid, gbraid and wbraid respectively, which fits the naming, but I could not confirm it on a Google page.
• The upload window. The pages I fetched do not state a number of days for how old a click may be. The API’s error list says an upload fails with EXPIRED_EVENT when the click occurred before the conversion action’s click-through window, so the limit depends on how that conversion action is configured (Google Ads API v22, conversion_upload_error.proto). Check your own conversion action rather than relying on a figure from a blog.

The upload rules that trip people up

If you send offline conversions (our guide to Google Ads offline conversions for WordPress leads covers the whole flow, including the Data Manager API that new integrations must use from 15 June 2026), these are the click ID rules in the Google Ads API.

One of gbraid and wbraid, never both

The API’s error list contains GBRAID_WBRAID_BOTH_SET: “Can’t use both gbraid and wbraid parameters. Use only 1 and try again.” Altered values fail too, with UNPARSEABLE_GBRAID and UNPARSEABLE_WBRAID pointing you to check the parameter “was not modified”.

When you have a gclid and a gbraid

You will see advice elsewhere that a conversion takes exactly one of the three IDs. Google’s current upload guide is more nuanced: “In some cases you may be able to associate both a gclid and a gbraid with a conversion,” and in that case Google recommends setting both on the conversion in your import request. It also recommends including GCLIDs wherever possible, even if you have the Google tag set up for enhanced conversions for leads. So the safe rule is: never both braids; if you hold a gclid and a gbraid for the same visit, follow Google’s guide and send both; if the upload errors, the response tells you which field it rejected. If you rely on a third-party tool that insists on exactly one, that is the tool’s rule rather than Google’s.

Other restrictions on braid conversions

• Google Ads does not support custom conversion variables combined with wbraid or gbraid.
• Conversion actions that use one-per-click counting cannot be used with braid parameters (error ONE_PER_CLICK_CONVERSION_ACTION_NOT_PERMITTED_WITH_BRAID).

Two errors point back to capture: UNPARSEABLE_GCLID (the value could not be decoded, often because it was truncated or edited) and CLICK_NOT_FOUND (the click may not have come from a Google Ads campaign, which Google says you can often ignore).

Where WordPress loses the parameter

The click ID lives in the query string, and a lot of things between the visitor and your database treat query strings as disposable:

• Redirects. HTTP to HTTPS, non-www to www, a trailing-slash rule or a “pretty link” plugin. If the redirect does not forward the query string, the ID is gone before WordPress runs. Google’s own help page warns about this.
• Page caching and CDNs. A cached page is served without running PHP, so any PHP that reads $_GET['gclid'] never fires. Some setups also ignore or strip tracking parameters when building the cache key. Whether yours does depends on its settings; check them.
• Firewalls and security plugins. A WAF rule that blocks or rewrites unknown parameters can drop it or return an error (the case Google mentions for sites that reject arbitrary parameters).
• Second pages and cleaners. The ID is only in the landing-page URL, so a form on another page loses it unless you stored it. Plugins or extensions that strip tracking parameters can remove it before your code runs.

This is the same family of failure described in why your WordPress analytics data goes missing, and it is a good reason to understand the client-side versus server-side split: capture happens in the browser’s request, the upload happens on a server, and the ID has to survive in between.

Capture it reliably

There is no single required method. Here are the options, roughly from most to least robust, with the honest caveats.

1. Server-side capture on the first request

If the landing page is not served from a full-page cache, read the query string in PHP and set a first-party cookie. This is a minimal, illustrative example; adapt it and test it:

add_action( 'init', function () {
  foreach ( array( 'gclid', 'gbraid', 'wbraid' ) as $key ) {
    if ( ! empty( $_GET[ $key ] ) ) {
      setcookie( 'tr_' . $key,
        sanitize_text_field( wp_unslash( $_GET[ $key ] ) ),
        array( 'expires' => time() + 90 * DAY_IN_SECONDS,
               'path' => '/', 'secure' => is_ssl(),
               'samesite' => 'Lax' ) );
    }
  }
} );

The 90 days mirrors the Google cookie lifetime above; match it to your sales cycle and conversion window. In real code, also clear the other two cookies when a new ID arrives.

2. Client-side capture

If pages are cached, PHP will not run, so read the URL in JavaScript instead:

const p = new URLSearchParams(location.search);
['gclid','gbraid','wbraid'].forEach(k => {
  const v = p.get(k);
  if (v) document.cookie = `tr_${k}=${encodeURIComponent(v)}; max-age=${90*86400}; path=/; SameSite=Lax; Secure`;
});

Load it early. Browsers also apply tighter limits to cookies written by JavaScript; for Safari specifically see Safari ITP and WordPress cookies. Check your consent setup too: whether storing a click ID needs consent depends on your jurisdiction and configuration, and this article is not legal advice.

3. Hidden form fields

Add hidden inputs named gclid, gbraid and wbraid to your lead form and fill them from the cookie (or the URL) when the page loads. Most form plugins can pre-fill hidden fields from a query parameter or script; the syntax differs by plugin. The point is that the ID is saved in the same entry as the lead.

4. Order meta for WooCommerce

For shops, copy the cookie values into order meta at checkout (see WooCommerce server-side tracking).

Also avoid sending ads to URLs that redirect, and make sure your cache plugin and CDN keep unknown query parameters on landing pages. Click your own test ad to see the real final URL rather than trusting the tracking template.

How to check the IDs actually arrive

1. Dummy-value test. Open a private window and visit https://yoursite.com/landing/?gclid=TEST123. In your browser’s developer tools (Application, Cookies) confirm your cookie holds TEST123. Repeat with gbraid and wbraid. A dummy will not match any real click in Google Ads; this only tests your capture.
2. Follow it through. Submit the form, then open the entry or order and confirm the value is saved. Visit a second page first to prove it survives navigation.
3. Click a real ad. Click your own ad (accepting that it may cost a click) and look at the landing URL in the address bar. Do this from a desktop browser and from an iPhone.
4. Read the upload response. Errors like CLICK_NOT_FOUND, UNPARSEABLE_GCLID and TOO_RECENT_EVENT tell you whether the problem is capture or timing. A per-event delivery log makes this far quicker than reading raw API responses. In Traculo’s events list, each event shows the response from each integration.

The same idea on other platforms

Each major ad platform has its own click ID. Names and API fields differ; the capture problem is identical.

• Meta. The URL parameter is fbclid. Meta’s documentation says to format it as fb.1.{timestamp in ms}.{fbclid} and send that as fbc, and that the value is case sensitive, so do not modify it. Its guidance for the cookie is a 90-day expiry (Meta, fbp and fbc). More in our Meta Conversions API guide for WordPress.
• TikTok. ttclid is appended to the landing-page URL when someone clicks a TikTok ad. TikTok’s click ID guide says the Pixel stores it in a first-party cookie named ttclid, recommends keeping it for 28 days or more, and has you send it with Events API events.
• Snapchat. Snap appends ScCid to the outgoing URL. You can parse it into sc_click_id, or pass the full destination URL in event_source_url and Snap extracts it (Snap, Using the API).
• Pinterest. epik goes in as click_id inside user_data. Pinterest recommends the _epik cookie over the query parameter because the cookie still works when the URL parameter is missing or removed (Pinterest, Conversions API).
• LinkedIn. li_fat_id is appended when enhanced conversion tracking is on. LinkedIn documents parsing it from the URL or reading the cookie, which persists for 30 days from the latest ad click, and the mapping to a member is stored for 365 days. It goes into the Conversions API as LINKEDIN_FIRST_PARTY_ADS_TRACKING_UUID (LinkedIn, Enabling Click IDs).

One capture routine can cover all of them: read every known click-ID parameter on arrival, store each under its own first-party cookie, and copy them next to the lead or order. For the rules on how each platform deduplicates events once the ID is sent, see one reference table for dedup rules. Our posts on LinkedIn and TikTok, Snapchat and Pinterest go deeper on each.

Frequently asked questions

Do I need auto-tagging on to get a GCLID?

Yes. The GCLID is added by auto-tagging. Turn it off (Admin, Account settings, Auto-tagging) and the parameter is no longer appended.

Can I send a gclid and a gbraid together?

Google’s upload guide says that when you can associate both with a conversion, it recommends setting both. What the API does not accept is gbraid and wbraid together (error GBRAID_WBRAID_BOTH_SET).

Why is my lead form’s gclid field empty?

Usual suspects: the visitor reached the form from a second page and the ID was never stored, a cached page ran no PHP, a redirect dropped the query string, auto-tagging is off, or the click was not from a Google ad at all. Run the dummy-value test above to find which.

Related reading

• Meta Conversions API for WordPress: the complete guide (cluster hub)
• Google Ads offline conversions for WordPress leads
• One reference table: dedup rules and limits on every ad platform
• LinkedIn Conversions API for WordPress
• Why Meta, Google and GA4 never match your WooCommerce orders
• Safari ITP and WordPress: what the 7-day cookie cap really affects
• Why is your WordPress analytics data missing?
• Server-Side Tracking for WordPress: a beginner’s guide

Traculo’s WordPress plugin forwards events server-side to Google Ads (as offline conversions), Meta, TikTok, Snapchat, Pinterest and LinkedIn, and logs each integration’s response. Google Ads needs the click ID on the event, and the plugin does not collect gclid, gbraid or wbraid itself. Check the integrations page for the details of each platform.