A client ID is a random identifier that Google Analytics generates on a browser’s first visit to your site and keeps in a cookie on your own domain, which lets it tell when the same browser returns. In the data sent to Google it travels as the cid parameter, which is why tracking guides often call it that.
How the client ID works
When GA4 runs on a page for the first time in a browser, it sets a cookie called _ga on your domain. Its value looks something like GA1.1.1234567890.1759572000. The last two blocks, a random number and the time of the first visit, together form the client ID. Every event that browser sends afterwards carries the same ID, which is how GA4 knows that the person reading your pricing page today is the visitor who came from a Google ad last week.
A client ID belongs to a browser on a device, not to a person. The same customer on their phone, their work laptop and their tablet has three client IDs, and clearing cookies or using a private window produces a fresh one. GA4 calls this the device ID and counts users by it, unless you also send a user ID for logged-in visitors and your reporting identity is set to use it.
The cookie lasts up to two years by default and is renewed on each visit, but browsers cut that short. Safari’s Intelligent Tracking Prevention limits cookies set by scripts to seven days in many cases, so an iPhone visitor who returns after a fortnight is often counted as a new user.
Why it matters
Almost every user-level figure in GA4 rests on the client ID: new versus returning users, how many visits come before a purchase, which channel first brought someone in. Knowing its limits stops you over-reading those numbers. A jump in new users can simply mean more Safari traffic or more people rejecting cookies, not more new people.
It also has a legal side for UK businesses. UK GDPR names online identifiers among the things that can make data personal, and a client ID exists precisely to single out one browser, even though it carries no name. That is why the _ga cookie should wait for the visitor’s consent before it is set, why you should never send names or email addresses into GA4 alongside it, and why GA4’s tools for deleting an individual’s data look them up by client ID.
Common mistakes
- Reading users as people. They are browsers, with duplicates across devices and resets after cookie clearing and Safari’s limits.
- Two set-ups on one site. A GA4 tag in the theme and another in Tag Manager, or two properties with different cookie settings, can split one visitor into two.
- Losing the ID across domains. If your booking system or shop runs on another domain without cross-domain tracking, the visitor arrives there with a new client ID and the sale is credited to a referral from your own site.
- Inventing IDs. Sending server events through the Measurement Protocol with a made-up client ID creates phantom users instead of joining the real visitor’s activity.
How to act on it
Find your own client ID: open your site, then your browser’s developer tools, and look for the _ga cookie under Application in Chrome or Storage in Firefox. Knowing it lets you find your own test visits in a user explorer exploration and check what GA4 recorded for them.
Then check three things. Only one GA4 configuration should set the cookie. Cross-domain tracking should cover every domain in the customer journey, including payment and booking pages you control. And your cookie banner should hold the cookie back until the visitor agrees. If customers log in, sending a user ID as well gives a much truer picture of returning customers than the client ID alone.
Reliable visitor identity is part of the groundwork for judging paid campaigns, which is where performance marketing begins: if one buyer looks like three users, every cost-per-user figure is off.