What Do gad_source, gbraid, wbraid and srsltid Mean in My URLs?

The short answer

You open your analytics or your form submissions and find landing page URLs ending in strings like ?gad_source=1&gad_campaignid=…&gbraid=… or ?srsltid=…. None of them came from you. Google added them.

In one line each, using Google’s own wording:

• gbraid and wbraid are Google Ads click parameters created for Apple’s iOS privacy rules. Google describes gbraid as a privacy-preserving identifier that measures conversions without linking them to individual people.
• gad_source identifies the source of the ad, such as Google Search or the Display Network. gad_campaignid identifies the Google Ads campaign. Neither is unique to a click.
• srsltid comes from Google Merchant Center, not Google Ads. It tracks purchases from clicks on your free product listings.
• gclid, the older one, is the Google Click Identifier that auto-tagging adds when someone clicks your ad.

Why are they there? All of them help Google measure your results. None of them is a virus, a bot or a sign of a hacked site, and the safe default is to leave them alone. To check one specific URL, paste it into the ad click URL explainer: it labels every parameter with what Google’s help pages say it means, and flags values Google doesn’t document.

gbraid and wbraid: Google's iOS-era click IDs

Both parameters exist because of Apple. Google’s iOS 14 measurement page explains that since Apple’s App Tracking Transparency (ATT) policies took effect on April 26, 2021, Google no longer sends the gclid on traffic affected by those rules. It needed another way to measure ad results on iPhones, so it added two new parameters:

• wbraid arrived in March 2021. The Google Ads API guide says it is present when someone clicks an ad in an iOS app and is sent to your webpage.
• gbraid arrived in May 2021. The same API guide says it is present when someone clicks an ad on the web and is sent to your iOS app. The iOS page adds that it is added to landing page URLs when auto-tagging is on, for iOS 14.5 and later clicks, and that it applies to Search, Shopping, Display and Performance Max campaigns.

Newer Google pages describe gbraid more broadly. The Google Ads glossary entry calls the GBRAID URL parameter a privacy-preserving identifier used to measure ad performance. It measures conversions in a non-unique way, like a campaign ID, without linking them to individual users or events. So don’t be surprised to see gbraid on ordinary website visits too.

gbraid vs gclid. The gclid is Google’s identifier for a click (Google notes it is sometimes created at the impression rather than the click, per About auto-tagging). The gbraid is deliberately not tied to one person. You can see both on the same visit. Google’s API guide says that in some cases you can associate both a gclid and a gbraid with a conversion, and recommends sending both when you have them.

Handle the values exactly as they arrive. Google says GBRAID is case-sensitive and shouldn’t be changed to upper or lower case. The gclid is case-sensitive too (GCLID setup guide). Google doesn’t state a case rule for wbraid, so treat it the same way: never change it.

gad_source and gad_campaignid

Google’s About gad_* URL parameters page groups these as parameters that carry aggregate campaign data without compromising user privacy.

• gad_source identifies the source of the ad URL, for example Google Search or the Display Network. It isn’t customizable, and every ad from the same source gets the same value. It used to be called gad.
• gad_campaignid identifies the Google campaign that drove the visit. All conversions from the same campaign share the same value.

Google adds both to the end of your final URL, before any # part. The values are case-sensitive and should look the same on every page of your site. Search Ads 360’s help adds that these parameters are not controlled by auto-tagging (About gad_ parameters). Google also says any URL coming from a Google ad now has gad_campaignid in its final URL.

What does gad_source=1 mean? Google doesn’t say. Its pages explain that the value identifies the source, but they don’t publish a table of values, and the gad_source=1 in Google’s examples is just an example. You’ll find blog posts that map numbers to networks. Treat those as guesses, not facts.

gad_source vs utm_source. They do different jobs. utm_source is a label you choose and add yourself so Google Analytics can name the traffic. gad_source is a code Google adds on its own. Analytics Help says gad_ parameters and gbraid help in cases where Analytics can’t get campaign information from the standard identifiers (About aggregate identifiers). Keep both. Our UTM naming guide covers the tags you control.

srsltid: the Merchant Center parameter

srsltid is the one that confuses store owners most, because it often appears on visits that weren’t paid clicks.

It comes from Google Merchant Center. Its auto-tagging help page says auto-tagging adds a parameter called srsltid to your URLs. Its purpose is to show how well clicks on your free listings and free local listings lead to valuable customer activity, such as purchases. Auto-tagging is on by default for new Merchant Center accounts.

A few practical points:

• It comes from Merchant Center, not your store platform. Google’s page says Merchant Center auto-tagging adds it, so it can appear on any store with products in Merchant Center, whatever software runs the site.
• Google Analytics knows it. The GA4 BigQuery export has a field for it, described as the Google Merchant Center identifier collected with the event (BigQuery export schema).
• How to stop it. In Merchant Center, click Settings, then General, open the Key event setup tab and switch Auto-tagging off. You then lose the purchase tracking it provides for free listings.

Is srsltid bad for SEO? Google’s Merchant Center page doesn’t discuss search rankings, so there is no official answer to quote. What Google Search Central does document is how to handle duplicate URLs. Its consolidation page names a rel="canonical" tag (a line in the page’s code that names the main version of a URL) as a strong signal for which URL should be the main one, and it even uses a URL with a gclid as an example of the version you wouldn’t want shown. Check whether your pages already carry a canonical tag before you think about stripping the parameter.

Should you remove these parameters?

No. Google’s Analytics Help is direct: for the most accurate attribution and measurement, don’t remove or block aggregate identifiers (gbraid and gad_ parameters) from your landing page URL.

The usual ways they get lost are accidental:

• Redirects. A redirect from http to https, or from one path to another, can drop the query string. Google says to keep gad_ parameters through redirects, because its tags expect them on the page where the tags load.
• Strict sites. Google says a small percentage of websites reject URL parameters they don’t recognize and show an error page. Test yours: open a landing page with ?gad_source=1 added and see if it loads normally. If it doesn’t, ask your developer to allow arbitrary parameters.
• Cleanup plugins and scripts. Some “clean URL” plugins or custom scripts remove everything after the ?. If you use one, exclude Google’s parameters.

If a parameter makes a URL look messy in a report, filter the report. Don’t break the measurement.

Using them in offline conversions

If you send sales or qualified leads from a CRM back to Google Ads, these parameters matter beyond the website. Your form or landing page script should save them with each lead, next to the gclid.

• BRAIDs are accepted. Google’s How to upgrade offline imports page says each conversion needs a timestamp plus one of: GCLID, user-provided data (customer details such as an email address or phone number) or BRAIDs. It recommends adding GBRAID or WBRAID to conversion actions in all scenarios.
• Count setting. When you use braids, Google says the conversion action’s count setting must be Every, or the upload may fail.
• Same row is fine now. Since October 3, 2025, a gbraid, a gclid and user-provided data can sit in one row without an error.
• Limits. Google’s API guide says custom conversion variables can’t be combined with wbraid or gbraid. For refunds, adjustments work with gclid and gbraid but not with wbraid. Our guide on removing conversions after refunds covers that.
• gad_ parameters help too. Google’s gad_* page suggests capturing them on all landing pages and importing them with your conversions. It matters most when there is no gclid or user-provided data.

If your CRM already stores the full landing page URL, you don’t need to rebuild anything. The URL parameter extractor reads a column of saved URLs and splits gclid, gbraid, wbraid, gad_source, gad_campaignid and UTM tags into their own columns, ready for an upload file.

What Google doesn't document

Plenty of articles claim more than Google has published. As of this writing, Google’s help and developer pages don’t cover:

• The meaning of each gad_source number. Google says the value identifies the source but publishes no list.
• What is inside a gclid, gbraid or wbraid. No official page describes their structure, so any “decoder” that claims to read a click time or campaign out of the value is guessing.
• A case rule for wbraid. Case sensitivity is documented for gbraid, gclid and gad_ parameters only.
• Whether srsltid appears on other organic traffic. The Merchant Center page names free listings and free local listings, nothing else. If you see it on other visits, Google hasn’t explained that case.
• Whether srsltid affects rankings. No Google page addresses it.

When a page or a tool gives you a firm answer to one of these, ask for the Google source. If there isn’t one, treat it as a theory. The parts Google has documented are enough to act on: keep the parameters, pass them through redirects, save them with your leads, and send them back with your conversions.