Signed in with user ID dimension
The signed in with user ID dimension reports whether activity occurred while a User-ID was set — typically because the person was logged in. GA4 derives it from the presence of a developer-supplied User-ID on the session. It enables cross-device stitching of authenticated activity, but only when you have a lawful basis and a non-personal identifier, so it is governed by consent and policy, not enabled by default.
What this means
Signed in with user ID indicates whether your application supplied a User-ID for the session — usually set after a user authenticates. GA4 records the flag so you can isolate logged-in activity.
When present, the User-ID lets GA4 unify a person's sessions across devices and browsers into one user, which anonymous client-ID-only tracking cannot do.
Preconditions and limits
User-ID is opt-in instrumentation: you must generate a stable, non-personal identifier, obtain a lawful basis and any required consent, and never send personal data such as emails. Sessions before sign-in, or where consent is absent, show 'no'. Treat cross-device linkage as a governed capability, and consult your own legal counsel — this page is educational only.
- Set 'yes' only when a User-ID is present
- Enables cross-device user unification
- Requires lawful basis, consent, and non-personal IDs
How it appears in analytics and logs
'Yes' means a User-ID was present on the session; 'no' means it was anonymous. It reflects your own login instrumentation, not GA4 inferring identity.
Diagnostic use case
Use signed in with user ID to separate authenticated, cross-device-linkable activity from anonymous browsing in your reports.
What WebmasterID can help detect
WebmasterID treats authenticated linkage as opt-in and policy-bound, helping you keep signed-in analytics separate from anonymous traffic without storing personal identifiers.
Common mistakes
- Passing emails or names as the User-ID.
- Enabling User-ID without a lawful basis or consent.
- Assuming pre-login sessions are linked to the identity.
Privacy and accuracy notes
User-ID must be a non-personal, internally generated identifier with a lawful basis and consent. This dimension is educational, not legal advice; never pass emails or names as User-ID.
Related pages
- User-ID dimension: identity you assign, not infer
User-ID is the dimension that carries an identifier you assign to authenticated users, enabling analytics to stitch their activity across devices and sessions. Unlike a client ID, it is identity you provide, typically only after sign-in. GA4's User-ID feature requires that the value be a non-PII pseudonymous key and that you have the appropriate consent, because it links behaviour to a known person.
- Consent state dimension
The consent state describes the Consent Mode signals attached to a hit — chiefly whether analytics_storage and ad_storage are granted or denied. GA4 reads these signals to decide whether to use cookies and how to process the hit; when consent is denied, measurement may be cookieless and gaps can be filled by GA4's behavioural modelling. Treating consent state as identity, or ignoring its effect on data completeness, leads to misreadings.
- User-ID tracking and its privacy cost
User-ID analytics assigns a persistent identifier — often a logged-in account ID — so sessions across devices and over time can be joined into one profile. It answers cross-device questions that cookieless measurement cannot, but the cost is real: it creates durable, identifiable personal data with full data-protection obligations. Whether the insight justifies the surface is the trade-off. This is educational, not legal advice.
- Privacy-first analytics
Authenticated linkage as an opt-in, governed feature.
Sources and verification notes
- Google — [GA4] Measure activity across platforms with User-ID
- Google Analytics — User-ID feature policy
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.