Skip to content
accs-net.com

Press Esc to close

User-ID

User-ID is the identifier you assign to a signed-in visitor and pass into GA4, so that their sessions on different devices and browsers count as one person instead of three strangers. Google’s documentation describes the feature as letting you “associate your own identifiers with individual users so you can connect their behavior across different sessions and on various devices and platforms.” It is the only identity mechanism in GA4 that you fully control — and since Google Signals left the reporting identity in 2024, it is also the only one that genuinely stitches devices together in your reports. This entry covers how User-ID differs from the client ID, the rules Google enforces, implementation, and the honest limits of what it can see.

What User-ID Is

Out of the box, GA4 identifies a browser: the client ID lives in a first-party cookie, so one human on a laptop and a phone is two users with two unconnected histories. User-ID inverts the responsibility. Your site already knows who a logged-in visitor is — the account number in your database. Pass a stable, anonymous version of that value with your events, and GA4 treats every event carrying the same User-ID as one person, whatever device it came from.

The value itself is an opaque string of your choosing — an internal account key like u-84213. GA4 does not know or care what it means; it only groups by it. That indifference is the point: identity lives in your system, and GA4 borrows it.

User-ID vs Client ID: Two Layers of Identity

Client ID User-ID
Assigned by GA4 automatically You, at login
Scope One browser on one device One person, everywhere they sign in
Coverage Every visitor Signed-in visitors only
Survives Until cookies are cleared As long as your account system does
Where it lives Cookie Your auth system → the tag

The two are not rivals — every event has a client ID, and events from signed-in users carry both. GA4’s reporting identity uses them in order of strength: User-ID first where present, then device ID (the client ID), with behavioural modeling filling consent gaps. A visitor who browses logged-out for a week and then signs in gets their identity upgraded mid-stream; from that point, cross-device stitching applies wherever the same User-ID appears.

The Rules Google Enforces

  • No personally identifiable information. The value must not be an email address, a name, a phone number or anything else that identifies a person on its face. A database key or a hash qualifies; anna.k@example.com is a terms-of-service violation that can cost you the property.
  • 256 characters maximum — in practice a non-issue, since good IDs are short.
  • Consistency is everything. The same person must get the same string on the website, the iOS app and the Android app, forever. If the web team sends 84213 and the app team sends user-84213, GA4 sees two people, and the entire exercise fails silently.
  • Your privacy policy has to cover it. Tying behaviour to an account is processing users can reasonably expect to be told about — under GDPR, User-ID tracking belongs in your records of processing and, in most readings, behind consent for analytics.

Implementation in Practice

The mechanics are one line wherever your tag is configured. With gtag.js, set the property before events fire on a logged-in page; in Google Tag Manager, populate a user_id field from a data layer variable your backend writes at login. Server-side, the Measurement Protocol accepts the same field, which is how purchase confirmations and subscription renewals sent from your backend attach to the right person.

The implementation detail that separates working setups from broken ones is when the value is available. Set it as early as the page allows — before the first event on every authenticated page, not just the login-success page. Common failure: the ID is set only on the post-login redirect, single-page-app navigation never re-sets it, and 90% of authenticated pageviews go out unidentified.

What Changes in Reports Once It Works

  • User counts drop — usually the first visible effect, and the correct one: three-device people stop triple-counting. Expect the dip when you enable it and annotate the date.
  • Journeys become legible. Research on the phone over lunch and purchase on the desktop at home become one funnel path instead of an abandonment plus a mystery conversion.
  • Audiences follow people, not browsers. A remarketing audience built on behaviour includes the person’s other devices — within the signed-in population.
  • BigQuery gets the key. The user_id field lands in the BigQuery export, which makes joining analytics to your own customer data a plain SQL join instead of a probabilistic guess.

Rolling It Out Without Breaking History

User-ID plugs into GA4’s reporting identity setting (Admin → Reporting identity), which decides how users are deduplicated in reports: Blended (User-ID, then device ID, then modeling), Observed (User-ID, then device ID), or Device-based (client ID only). Two properties of this setting make rollouts forgiving:

  • It is non-destructive. Switching reporting identity re-views existing data rather than rewriting it — you can flip between Blended and Device-based and back, and compare how user counts change, without losing anything. The underlying events always carry whatever IDs they carried.
  • Collection and reporting are separate decisions. Start sending User-ID today while reporting identity stays device-based; the IDs accumulate in the data (and in BigQuery), and you switch the reporting view once coverage looks healthy.

The practical rollout order: implement the ID on all authenticated surfaces → verify in DebugView and BigQuery that coverage matches your logged-in share → switch reporting identity → annotate the date, because user-metric trendlines will step.

Edge Cases That Corrupt the Graph

  • Logout: stop sending the ID; do not “unset” it by sending an empty string or a placeholder like guest. A shared placeholder is the worst possible bug — it merges every logged-out visitor into one giant fake person.
  • Shared devices: a family tablet or a kiosk where several accounts sign in sequentially is handled correctly as long as each login sends its own ID — but never cache the previous user’s ID past logout.
  • One person, several accounts: User-ID follows accounts, not humans. Someone with a work and a personal account is two users by design; that is usually the honest count for business purposes.
  • ID migrations: if your account system ever renumbers users, the old and new IDs become different people in GA4 forever. If a migration is unavoidable, map it in your warehouse via the BigQuery export — GA4 itself cannot merge them.

The Honest Limits

User-ID only sees what authenticates. On a typical content site, that is a small minority of traffic; on a SaaS product, nearly everything that matters. Two consequences follow. First, your blended user counts remain estimates for the anonymous majority — User-ID improves the signed-in slice and leaves the rest to device ID and modeling. Second, pre-login behaviour on a device the person never signs in from stays unconnected forever. User-ID is not surveillance; it is bookkeeping for relationships the visitor already chose to have with you.

Frequently Asked Questions

Is the GA4 User-ID the same as the client ID?

No. The client ID is GA4’s automatic per-browser identifier stored in a cookie; the User-ID is your own account identifier for signed-in users, passed by your site. Events from logged-in users carry both, and reporting identity prefers the User-ID where it exists.

Can I use an email address as the User-ID?

No — email addresses are PII, and sending PII to Google Analytics violates the terms of service. Use an internal account key or a hash. The value only needs to be stable and unique; it never needs to be meaningful.

Does User-ID work for visitors who never log in?

No. Anonymous visitors are identified by device (client ID) and, where consent gaps exist, by modeling. User-ID adds precision exactly where you have an authenticated relationship and changes nothing elsewhere.