Cross-Device User ID in GA4: Implementation Patterns and Privacy Trade-offs (2026)

How does GA4 handle cross-device user tracking?

GA4 has a User ID feature for tracking users across devices and sessions. Implementation: set user_id on every event for logged-in users, using a stable internal identifier (NOT email or PII — usually a hashed account ID). GA4 stitches sessions across devices when the same user_id appears.

The Reporting Identity setting controls how identity resolution works in reports: Blended uses User ID first, then Google signals, then Device-based — required for modelled conversions; Observed uses User ID + Device-based (no Google signals); Device-based uses only the anonymous client_id. Most properties should use Blended (the default in 2025+ properties).

User ID is also the foundation for Enhanced Conversions, cross-platform reporting (web + iOS + Android), and accurate cohort analysis. The privacy consideration: user_id is technically pseudonymous PII under GDPR — store it accordingly.

What user_id enables

When a user logs in on desktop, then later opens the app on their phone, then later visits on their work laptop — without user_id these look like 3 separate users with 3 separate journey histories. With user_id consistently set to the same value across all 3 events, GA4 stitches them into a single user with unified journey reporting.

The capabilities user_id unlocks:

• Cross-device user reports — user count is people, not devices
• Cross-platform journeys — web → iOS app → web sequences visible
• Accurate user-level cohort analysis — same person counted once
• Enhanced Conversions — server-side conversion attribution requires hashed user identifier
• More accurate audience definitions — "users who viewed pricing on any device"

Without user_id, GA4 falls back to client_id (the anonymous _ga cookie). Client_id changes when cookies clear, when the user switches browsers, when they use private browsing. Cross-device tracking is impossible.

How to implement user_id correctly

The implementation rules:

Rule 1 — Only set on logged-in users

user_id should only be set when you have a verified user identity (logged-in account). For anonymous users, leave it unset — GA4 falls back to client_id.

The wrong pattern: setting user_id on every visitor by generating a synthetic ID. Defeats the purpose and creates compliance issues.

Rule 2 — Use a stable internal identifier

The user_id value should be:

• Stable — same value for the same user across sessions and devices
• Internal — your account ID, not external (avoid email, phone, social media IDs)
• Pseudonymous — not directly identifying without your account database
• Hashed — even better, send a one-way hash of your internal ID rather than raw

Common patterns:

• Internal account UUID: usr_a1b2c3d4-...
• Hashed account ID: sha256(account_id) truncated to 32 chars
• Sequential internal ID with prefix: acct_8392384

Avoid:

• Email addresses (PII, breaks if user changes email)
• Phone numbers (PII)
• Social media IDs (privacy concern, can change)
• IP-derived IDs (changes too often)

Rule 3 — Set on every event after login

Once the user is identified, every subsequent event in that session and future sessions should include user_id. In gtag:

In GTM, configure the GA4 Configuration tag's User ID field to read from a dataLayer variable that's populated on login.

Rule 4 — Don't include user_id in event_params

user_id has its own dedicated field in GA4. Don't push it as a custom event parameter. The dedicated field enables the cross-device stitching; an event parameter doesn't.

The wrong pattern:

The right pattern:

The three Reporting Identity options

Admin → Property settings → Reporting identity. Three options:

Blended (recommended for most)

Uses, in order: User ID → Google signals → Device-based.

For each user, GA4 picks the most accurate identifier available. Logged-in users get cross-device User ID matching. Non-logged-in users with Google account session get partial cross-device matching via Google signals. Anonymous users fall back to device-based.

Pros: Most accurate user counts. Required for modelled conversions in Consent Mode V2 Advanced.

Cons: Privacy-conscious organisations may prefer to disable Google signals.

Observed

Uses, in order: User ID → Device-based.

Skip Google signals. Cross-device works only for users who logged in.

Pros: Simpler privacy model. Only your owned identifiers used.

Cons: Disables modelled conversions. Lower-quality cross-device tracking for non-logged-in users.

Device-based

Uses only client_id. No User ID, no Google signals.

Pros: Maximally simple, no cross-device.

Cons: Disables modelled conversions. No User ID even when set. Each device counts as a separate user.

The recommendation: use Blended unless you have specific privacy requirements that mandate one of the others. Blended is the default for new properties and enables the broadest set of GA4 features.

The modelled-conversion impact

Reporting identity directly affects modelled conversions (covered in *Modelled Conversions in GA4*). Specifically:

• Blended — modelled conversions ENABLED (subject to other prerequisites)
• Observed — modelled conversions DISABLED
• Device-based — modelled conversions DISABLED

If you've implemented Consent Mode V2 Advanced expecting modelled conversions to fill the consent-denied gap, but Reporting Identity is set to Observed or Device-based, modelling silently doesn't work. Check this configuration.

Privacy compliance considerations

user_id is technically pseudonymous PII under GDPR. Treatment requirements:

1. Document it in your privacy policy. "We send a hashed internal identifier to Google Analytics for cross-device tracking."

2. Honour DSAR requests. When a user requests data deletion, delete their GA4 events by user_id.

3. Don't use external PII as user_id. Email and phone are explicitly PII; using them as user_id violates GA4 Terms of Service AND adds GDPR risk.

4. Encrypt at rest in your warehouse. When user_id appears in BigQuery exports or your downstream warehouse, treat it as PII for encryption and access-control purposes.

5. Honour consent. If a user denies analytics_storage consent, don't set user_id (or use Consent Mode V2 to gate it).