Client ID vs user ID on events
Every GA4 event is associated with a client/instance identifier that distinguishes a browser or app instance, set automatically. A user ID is a separate, optional identifier you assign to authenticated users so their events join across devices. The two answer different questions: device/instance continuity versus cross-device identity. This page explains how each attaches to events and why user ID demands extra privacy care.
Two identity spaces
GA4 attaches a client_id (web) or app instance id to every event automatically, identifying the browser or app install (GA4 developer docs). Separately, you may set a user_id — your own pseudonymous key for a signed-in user — which lets GA4 associate that user's events across devices and sessions. Client ID is device/instance scope; user ID is person scope across devices.
When and how to use user ID
Use user ID when you genuinely need cross-device, signed-in measurement and can assign a stable, non-personal key. It must never be an email, name, or other PII — only a pseudonymous identifier — and it carries heavier consent and governance obligations than the automatic client ID. If device-level analysis suffices, the default client ID alone is simpler and lower-risk. Match the identifier to the question, not the maximum tracking possible.
- client_id: automatic, device/instance scope
- user_id: optional, pseudonymous, cross-device person scope
- user_id must be non-PII and consent-governed
How it appears in analytics and logs
The same person counted as multiple users across devices means only client ID is in use; user ID, when set consistently, unifies their events across devices.
Diagnostic use case
Decide whether device-level (client ID) measurement is enough or you need cross-device joining via an assigned user ID, and attach the right identifier to events.
What WebmasterID can help detect
WebmasterID's cookieless model avoids persistent cross-device identity by default; GA4's client-ID-vs-user-ID model is documented here for comparison.
Common mistakes
- Using an email or name as the user ID.
- Enabling user ID when device-level data would do.
- Assuming client ID identifies a named person.
Privacy and accuracy notes
Client ID identifies an instance, not a named person; user ID is a stronger identifier and must be a non-PII pseudonymous key with proper consent. This is educational, not legal advice.
Related pages
- User properties vs event parameters
User properties are attributes that describe a user across all their events — a plan tier, a preferred language, a logged-in state — rather than a single action. They differ from event parameters, which describe one event. Used well, user properties let you segment behaviour by audience. Used badly, they become a place where people stash personal data, which is exactly what they must not hold.
- User-scoped parameters and properties
User-scoped parameters — set as user properties — describe an attribute of the user that persists across their events, such as a membership tier or preferred language, rather than a fact about one event. They contrast with event-scoped parameters (per event) and item-scoped ones (per product). GA4 reports them as user dimensions once registered. The scope you choose decides whether a value follows the user or stays with a single event.
- Cookieless analytics: how it works and its limits
Cookieless analytics records visits and events without setting cookies or persistent cross-site identifiers. It relies on first-party, server-side signals and aggregate counting. The trade-off is honest: it cannot follow an individual across sessions the way cookie-based tracking can — which is exactly the point for privacy-first measurement.
- Privacy-first analytics
Measure without persistent cross-device identity.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.