How the client ID works
The first time someone reaches your site with measurement running, the Google tag generates a random value and writes it into a first-party cookie on your own domain. That value is the client ID. On every later request from the same browser, the tag reads it back and sends it with the events, which is how GA4 knows that two visits belong together.
Two things follow from that, and both are worth saying plainly. It identifies a browser on a domain, not a person: the same customer on a phone and a laptop is two client IDs. And it lives entirely in that browser’s storage, so it lasts only as long as the cookie does.
The value is also what stitches server-side and offline data back to a visit. If you send events from your own server through the Measurement Protocol, you have to supply the client ID yourself; without it, GA4 has nothing to attach them to.
Why the client ID matters
Everything GA4 reports about people rests on it. New and returning users, sessions, retention, first user source and most audiences are all built from whether an incoming client ID has been seen before. When recognition weakens, none of those numbers is wrong exactly — they just describe browsers more than they describe customers.
It is also the natural companion to a login-based identifier. Where you can send a User-ID for signed-in visitors, GA4 can join their devices together and stop treating each one as a separate person. Without that, the client ID is the only thread you have.
Common mistakes with the client ID
The first is treating it as a person. Shared computers, several devices per household and browser switching all break the assumption, and no configuration fixes it.
The second is ignoring how short cookie lifetimes have become. Browsers now limit how long values written by scripts survive, private windows discard them at the end of the session, and a visitor who declines tracking never gets one at all. Long consideration cycles are the worst affected, because the gap between research and purchase can outlast the cookie itself.
The third is losing it at a domain boundary. Move a visitor from your website to a separate booking, payment or subdomain-based system without cross-domain measurement configured, and a new client ID is issued on arrival: one journey becomes two visitors and the original source is lost.
The fourth is forgetting that an identifier tied to a device is still personal data under most privacy rules, even though it holds no name. It belongs in your privacy policy and in your consent handling.
How to act on it
Keep the tag first-party and consistent: one measurement setup across the whole estate, cross-domain measurement configured wherever visitors cross between your own domains, and referral exclusions for the gateways they pass through. Test it by walking the full journey yourself and confirming the same identifier survives to the end.
Send a User-ID as well if people log in, and use the client ID deliberately when you import offline conversions or send server-side events. If enquiries in your CRM regularly cannot be traced back to a source, the client ID is usually where that trail broke, and it is the first thing to check in a GA4 implementation review.