GA4 User-ID: Measuring Signed-In Users Across Devices

What User-ID does

Google's User-ID help page describes it this way: the feature "lets you associate your own identifiers with individual users so you can connect their behavior across different sessions and on various devices and platforms." GA4 treats each ID you send as one user, which Google says gives "more accurate user counts."

Without it, GA4 relies on the device ID. On websites that comes from the client ID stored in the browser's cookie, and in apps from the app-instance ID, as Google's reporting identity article explains. Clear cookies, switch browser or move from the website to the app, and GA4 sees a new user. Google calls User-ID "the most accurate identity space, because it uses data you collect to identify your users."

User-ID is a different fix from cross-domain measurement. Cross-domain keeps one visitor's session together when they move between your own domains in the same browser. User-ID joins the same signed-in person across devices, browsers and your app.

When it is worth setting up

User-ID only helps if people sign in. It fits:

• web apps and customer portals where most activity happens after login;
• shops where repeat customers sign in to buy;
• a product with both a website and a mobile app sharing one account system;
• membership and course sites.

A brochure site with no accounts has nothing to send. Two more limits from Google's help page are worth knowing before you start: data collected before you add User-ID "won't be reprocessed and associated with a user ID," and User-ID data from one property "can't be shared or mixed with data in other properties." Keep the website and app streams in the same property if you want one joined view.

Choosing the ID: no personal data

The ID is yours to create. Google's help page says it must be 256 characters or less, unique to each user, and assigned consistently, usually at sign-in. The rule that matters most: "Your user ID must not contain information that a third party could use to determine a user's identity." Google's Firebase documentation is blunter: "you cannot use a user's email address or social security number as a user ID."

Google's own suggestion is "an identifier you assign and only you can track back to an individual user", such as your internal account number, or "better yet, a hashed version" of it. In practice that is the primary key of the user row in your database, never the email, username or phone number. This sits inside Google's wider rule, set out in its guidance on avoiding personal data, that "no data be passed to Google that Google could use or recognize as personally identifiable information (PII)." That article lists "User ID override" among the features needing special care.

Google also says you are responsible for "providing appropriate notice of your use of identifiers in your Privacy Policy," so update your privacy notice when you add it. If you link GA4 to BigQuery, note that Google says user IDs are exported there "regardless of the consent status of your users." Our website privacy basics guide covers the notice side.

Sending it from a website

Google's developer guide to sending user IDs sets three states:

• Never signed in: do not send the user_id parameter at all.
• Signed in: send their ID.
• Signed in, then signed out: send null.

With gtag.js, you add user_id to the config command on each page. When the ID is only known after the page loads, for example the visitor signs in without a full page reload, Google recommends the gtag('set') command, which sets the ID "for all subsequent events on the page." On sign-out, set it to null. Google is specific about what not to send: not "an empty string", a blank string, or the word null or NULL sent as text.

user_id is a reserved configuration setting. Google says not to send it as a custom user property, inside user_properties, or as a parameter on individual events, and not to register it as a custom dimension. In Google Tag Manager it goes in the Google tag's configuration settings. If you need a refresher on how tags fit together, see our Google Tag Manager basics.

The usual place to hook this in is your login and logout code. Your developer reads the internal user ID from the session the server already holds, the same session described in our web app login guide, and prints it into the page or passes it to the tag.

Sending it from an app

In apps using the Firebase SDK for Google Analytics, the call is setUserID (setUserId on Android and the web SDK). Firebase says "all future events will be automatically tagged with this value." It also notes that setting a user ID "is never required for Analytics to work correctly": if you only need events from one install on one device, the automatic user_pseudo_id already does that. Use the same internal ID in the app as on the website so GA4 can join the two. Our mobile app analytics guide covers the rest of app measurement.

Reporting identity

Sending IDs is half the job. GA4 only uses them in reports if the property's reporting identity includes User-ID. In Admin, under Data display, open Reporting identity. Google lists three options:

• Blended: "By User-ID, device ID, then modeling."
• Observed: "By User-ID, then device ID."
• Device based: "Uses only the device ID and ignores all other IDs that are collected."

Modeling fills gaps for users who decline analytics cookies, using the behaviour of similar users who accept them. Google says the choice "does not affect data collection or processing" and you can switch at any time. The trade-off it names: with Blended or Observed your property needs enough signed-in activity "to adequately obfuscate their identity," so reports are subject to data thresholds, where GA4 withholds rows that could reveal individuals. Widening the date range is one of the fixes Google suggests.

Where you see the results

Google's User-ID best practices page lists where the data shows up:

• All reports: with User-ID in the reporting identity, user counts are de-duplicated by ID.
• Comparisons: the "Signed in with user ID" dimension lets you compare signed-in and signed-out users in standard reports.
• User explorer: the user explorer technique shows a timeline of one user's activity. The developer guide says the raw ID appears there as "Effective user ID". See our GA4 explorations guide.
• Audiences: you can build remarketing audiences from User-ID data and share them with a linked Google Ads account, covered in GA4 audiences.
• BigQuery: raw IDs are not a dimension in standard reports. For user-level analysis or joining with CRM data, Google points to the BigQuery export, which carries both user_pseudo_id and user_id. Our GA4 BigQuery export guide covers the setup.

One detail on sessions: if someone browses, then signs in, Google says events before sign-in in that session are associated with the ID too. After sign-out, events without an ID are no longer associated with it.

User-ID vs user-provided data

GA4 has a second first-party feature that is easy to confuse with User-ID. Google's user-provided data article draws the line:

• User-ID is "your unique, non-personally identifiable identifier that you assign to signed-in users." It joins journeys across devices and sessions inside GA4.
• User-provided data is fields such as email addresses, phone numbers and postal addresses, hashed with SHA256, that Google matches with its own data to support enhanced conversions, Customer Match and demographics. It needs GA4 linked to Google Ads, is switched on in Admin under Data collection, and Google says it is not available for properties in the Health industry category.

So the email goes into user-provided data, hashed and only with consent, and never into User-ID. Google says you can use both together and recommends sending user-provided data "alongside User-ID".

Common mistakes

• One ID for several people. Google's example: two people sharing the ID UserID123 appear as one user with both people's activity mixed together.
• Dummy or blank IDs. Google warns that repeatedly sending a blank or dummy ID "can lead to inaccurate data (including permanent data loss)". Clear the ID with null, not an empty string or a placeholder such as guest.
• The words undefined and null as text. Google notes that these words sent as strings are treated as real IDs, so a template that prints a missing value as text turns every logged-out visitor into one user.
• user_id as a custom dimension. Google says this creates a high-cardinality dimension that pushes data into the (other) row.
• Email or username as the ID. Not allowed, as above.

A checklist

• Users actually sign in on the site or app.
• The ID is your internal account number or a hash of it, never an email, name or phone number, and 256 characters or less.
• The privacy notice mentions the identifier.
• Signed in: ID sent. Signed out: null. Never signed in: nothing.
• gtag('set') is used when sign-in happens without a page reload.
• user_id is not a user property, event parameter or custom dimension.
• Website and app send the same ID into the same property.
• Reporting identity is Blended or Observed.
• A test sign-in shows up in the user explorer under its Effective user ID.

New to GA4? Start with Google Analytics 4 basics.

Frequently asked questions

Can I use the customer's email address as the GA4 user ID?

No. Google says the user ID must not contain information a third party could use to identify the user, and its Firebase docs give the email address as an example you cannot use. Use your internal account ID or a hash of it.

What should I send when a user signs out?

Send null. Google says not to send an empty string, a blank string or the words "null" or "NULL" in quotes. If the user never signed in, do not send user_id at all.

Does User-ID change my old data?

No. Google says data collected before you implement User-ID is not reprocessed and associated with a user ID.

Which reporting identity should I pick?

Blended or Observed, since both use User-ID first. Blended adds modeling for users who decline cookies; Observed uses only User-ID and device ID. Google says you can switch at any time without a permanent effect on data.

Is User-ID the same as user-provided data?

No. User-ID is your own non-personal identifier for signed-in users. User-provided data is hashed fields such as email and phone that Google matches for enhanced conversions, Customer Match and demographics. Google recommends using both together.

Do I need User-ID for a mobile app?

Not always. Firebase says setting a user ID is never required for Analytics to work. It helps when you want to join the same person across devices, apps or your website.

Want help setting up GA4 for a site or app with user accounts? See our services or email [email protected].