Google Analytics 4 User ID for cross-device tracking: how to configure it

Updated: December 8th, 2022

Google Analytics 4 has three ways of identifying people who visit your website: User ID, Google Signals, and the device. “Device” basically means 1st party cookies. If a visitor clears cookies or starts using a different device, then that will be treated as a new device. Google Signals uses data from people who use Google Accounts and have enabled ads personalization. However, the most accurate way of identifying visitors is the User ID. But it works well only if people can log in to your website.

In this blog post, I will explain how to configure User ID in Google Analytics 4 with Google Tag Manager and where you can later see that data in GA4 reports.

 

Table of Contents

+ Show table of contents +

• #1. What is the User ID feature in Google Analytics?
  • #1.1. Improvement (compared to Universal Analytics)
• #2. How to send user ID to Google Analytics 4?
  • #2.1. Not everything can be a User ID in Google Analytics
  • #2.2. Historical data, User ID length, and other quick tips
• #3. How to get a user ID?
  • #3.1. Method No. 1: Asking a developer to push the User ID to the Data Layer (or getting a plugin)
  • #3.3. Method No. 2: Fetch User ID from the already existing cookie
  • #3.4. Method No. 3. JavaScript Variable
  • #3.5. Method No. 4. DOM Scraping
• #4. Insert the User ID variable in the GA4 configuration tag
• #5. Let’s test
• #6. Where can you find/use user ID data?
• #7. If you want to use User ID as a dimension in various GA4 reports
• Final Words

 

Video tutorial

If you prefer video content, take a look at this tutorial from my Youtube channel, where I explain how to implement Google Analytics 4 User ID tracking with Google Tag Manager.

 

#1. What is the User ID feature in Google Analytics?

User ID lets you associate a persistent ID of a single user with that user’s engagement data from one or more sessions initiated from one or more devices (and, of course, browsers).

When you send an ID to Google Analytics and related data from multiple sessions/devices, your reports tell a more unified, holistic story about a user’s relationship with your business.

You will be able to see how users are using different devices. The example below is not the best one, but that’s the quickest one I had:

But that’s the reality when most of your traffic comes to anonymously read content (and not log in to accounts).

You will see those users in the user explorer too:

The count of users will be more accurate (if the same user uses multiple devices, you will see one user instead of multiple).

But I can’t emphasize this enough: user ID will work for your business well if a visitor can log in to your website/app. This means that once a visitor/user accesses his/her account, you have its ID in your database.

Later in this blog post, I will show you how to send that ID to Google Analytics 4.

 

#1.1. Improvement (compared to Universal Analytics)

If you wanted to adopt user ID tracking in GA3 (Universal Analytics), you had to create a separate User ID view, and that data was available only there. With Google Analytics 4, thankfully, that is no longer needed.

 

#2. How to send a user ID to Google Analytics 4?

The process is fairly simple. And, if you already know me, I will explain how to do this with Google Tag Manager. In GTM, you must already have a Google Analytics 4 configuration tag. If you have no idea what it is, read this.

In that tag, you should click on Fields to Set > Add Row and enter user_id (see the screenshot below):

Then you will need to enter the value (a variable that contains the actual ID of the visitor who has logged in to your site).

If a user is browsing your website anonymously (read not logged in), that variable will return undefined. Therefore, the user_id will not be sent to GA4. But once the user logs in to his/her account on your website, the ID should become available, and then the next time this GA4 config tag fires, it should also contain the user_id.

Now you might be wondering: where and how can I get that user_id?

There are several possible options depending on how your website is coded. In the several upcoming chapters of this blog post, I will explain them.

But before that, I want to share several important things.

 

#2.1. Not everything can be a User ID in Google Analytics

It’s really important to understand that Google Analytics Terms of Services do not allow tracking PII (Personally Identifiable Information), such as Email Addresses, Social Security Numbers, etc., stored on their servers. The same principle applies to the User ID. Even if you use email addresses to identify users in your system/CRM/etc., you cannot use email as a User ID in GA.

However, you can still use a less readable User ID from your system (that consists of random numbers, letters, etc.) e.g. 1234567 or 123aboasdb2234. These are acceptable User IDs that you can use in Google Analytics.

But you might say Hey, aren’t such IDs still PII? I can look that ID up in my CRM and still identify the visitor. 

Well, yes, you can. But GA allows that. Kind of a gray area, but the industry aligns with it. So don’t panic and use them. To sum up:

• [email protected] – CANNOT be used as a User ID in Google Analytics
• 5239asbd923fade923da – CAN be used as a User ID in Google Analytics.

 

#2.2. Historical data, User ID length, and other quick tips

Before we get the user ID, here are several more tips and gotchas.

Historical data. User ID is not applied to historical data that goes beyond the scope of the same session. When a new visitor lands on your website, Google Analytics 4 stores a cookie with a randomly generated ID (this is NOT a user ID). This client ID is then used on every page.

If, after several sessions, that same user decides to register on your website, he/she gets a user ID. However, a user ID is not automatically applied to all those past sessions. You could do some magic with BigQuery if you know how to work with it, but there is no automatic user reverse-stitching.

But on the other hand, if a visitor does event 1, e.g. a page_view (without a user ID), then logs in during the same session, user ID will be automatically applied to page_view  too. So, the events that happen before the user ID is sent to GA4 during the same session will get the user ID too.

User ID length. The maximum length of the user ID that you can send to Google Analytics 4 is 256 Unicode characters.

User ID can’t be merged across GA4 properties. If you want to track a single-user journey in GA4, you will have to use the same GA4 property (even if that means sending data from multiple websites to the same property).

You need to send user_id with every event to GA4 (when user_id is available). You should set the user_id field in the GA4 config tag (but then make sure that all other event tags are using that config tag).

user_id cannot be registered as a dimension. If you want to use the ID as a dimension in your various explorations (analysis), you will have to do additional configuration. I will explain that in chapter #7 of this blog post.

 

#3. How to get a user ID?

There are several options. Some are more reliable, others not so much.

 

#3.1. Method No. 1: Asking a developer to push the User ID to the Data Layer (or get a plugin)

If your website has an authentication feature (login), then you can ask a developer to push the User ID to the Data Layer. You can hand him/her the following code (a developer must replace the ID with an actual ID of the user):

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  'event' : 'login',
  'userId' : '1234567' //this number must be replaced with an actual User ID
})

This is the most robust way compared to other alternatives.

If you’re working on a regular website (that refreshes the entire page when the user is navigating), then it’s preferred to have this code placed above the GTM container (that way, you’ll have it available even with the All Pages GTM trigger).

If you’re working on a Single Page Application, then the location of this code does not really matter. Also, the ‘event’ parameter is not required. But if it is implemented, you can use it as a trigger to track Login events.

Another important thing would be to ask a developer to push the User ID every time new page loads (I mean when the page entirely refreshes and the previous values in the Data Layer are wiped out). Then the code could look like this (placed above the GTM container snippet):

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  'userId' : '1234567' //this number must be replaced with an actual User ID
})

After a developer starts pushing the User ID to the Data Layer, get back to your Google Tag Manager account, go to the container of the website you’re currently working on and enable Preview and Debug mode.

Now, head over to your website, refresh it (while being logged out of that website), and log in. After you successfully authenticate, a login event should appear in the Preview console. Switch to the Data Layer tab of the Preview console and keep looking for the userId parameter. It should contain some value (the actual User ID).

Quick note: If you are working with a popular website builder/ecommerce platform, chances are that readymade Google Tag Manager plugins exist for it. For example, there is a WordPress plugin called GTM4WP. It can also push the user ID to the data layer once the user logs in.

Even though the User ID is in the Data Layer, you cannot simply use it in your tags or triggers without actually turning that piece of information into a GTM Variable. That’s why you need to create a Data Layer Variable for that User ID.

Note: Data Layer Variable Name (the field that I’ve highlighted in the screenshot above) is case-sensitive. So if there is a userId (with the uppercase I) parameter in the Data Layer, you must also use the uppercase I in the variable’s name (in GTM user interface).

 

#3.3. Method No. 2: Fetch the User ID from the already existing cookie

There’s a chance that a website/shop/etc. you’re working on already stores the User ID in a cookie. In that case, you could just read its value with Google Tag Manager and then (later) send it over to Google Analytics. If you have direct access to the developers of that website/shop/etc., ask them whether they store the User ID in a cookie and what its name is.

Otherwise, you can check this hypothesis by yourself. Go to your browser’s developer tools. I’m using Chrome, so I’ll go to More Tools > Developer Tools.

Then go to Application > Cookies and choose the domain of your website.

Now browse and keep looking for a name that might be related to a User ID. There is no standard name for that thus various options are possible. Once you find something, it would be good to ask the client/colleague to confirm whether that’s the actual User ID.

So if you got lucky with the cookie (insert your fortune cookie pun here), memorize its name and go to Google Tag Manager UI > Variables > New (under the User-defined variables). Choose the variable’s type, 1st Party Cookie and enter the name of the cookie here:

So if this User ID fetching method worked for you, Feel free to skip to Chapter #4 of this guide, where I’ll show you how to use that User ID in the Google Analytics tag (within GTM).

account_id cookie is just an example. It does not mean that the name of a cookie on your website (if such exists) is named like that.

 

#3.4. Method No. 3. JavaScript Variable

I’ve explained this technique in a dedicated blog post so if you want to learn more, go check it out. Here’s a quick summary.

In short, the JavaScript variable lets you access the values of global JavaScript variables available on that page. For example, a browser language, the title of the current page, etc.

I’ve seen many cases where the User ID was also stored in a Global JavaScript Variable. So all you need to do is to find it.

How do you do that?

• Option A: ask a developer who is involved with that website/shop/etc.
• Option B: try to find it yourself.

Option A is easy and should always be your first choice.

Option B requires much more time. To start the search, go to the developer console of your browser (here’s the tutorial on how to do that on Chrome), type window and hit enter (like in the screenshot below).

Click the black triangle near the Window, and you’ll see a list of properties that we can access with a JavaScript Variable in GTM. Brace yourself. That list will be huge.

Now, imagine you’re working with a Shopify online store. Intuitively, I’d scroll down and start looking for a shopify property. To save you some time, I can say that shopify property does not contain the User ID. However, ShopifyAnalytics does (I just had to spend some time looking for it).

Click the black triangle to expand the property and dig deeper. Unfortunately, I don’t see an ID anywhere, but there are some other possibly useful data points. Let’s dig even deeper. If you go to meta > page, you’ll find the customerId. This is exactly what you were looking for.

Now, head over to Google Tag Manager interface > Variables > New > JavaScript Variable and enter the entire path from top to both that you followed to reach that customerId (window is not required). The final value of the variable must be ShopifyAnalytics.meta.page.customerId (case-sensitive). Every level is separated by a dot.

Save the variable, refresh the Preview mode (in the GTM UI), then go to the page and refresh it, too (make sure you’re logged in to that website/shop/etc. as a user/customer). In the Preview console, go to Variables and check whether your JavaScript variable returns an actual User ID. If not, check for spelling mistakes in your JS variable.

So if this User ID fetching method worked for you, Feel free to skip to Chapter #4 of this guide, where I’ll show you how to use that User ID in Google Tag Manager (Google Analytics tag).

 

#3.5. Method No. 4. DOM Scraping

This option is risky due to its fragility (especially in websites where developers constantly implement improvements/changes/AB tests in the front end).

In a nutshell, DOM scraping is a method to get a value from the website’s document object model by, well, scraping it. So if you, as a logged-in user, see your User ID displayed somewhere in the interface, you could fetch its value with the help of DOM Variable or Custom JavaScript Variable in Google Tag Manager. In this blog post, I’ll show how to use the DOM Element Variable.

DOM Variable enables you to pick a website element and read its text or one of its HTML attributes (e.g., href, title, ID, etc.). You can pick an element by defining its ID (if such exists) or by using CSS Selectors. In order to make use of it, knowledge of HTML and CSS Selectors is required. Also, be familiar with what DOM is in general.

There are millions of websites. Therefore, there might be millions of ways of how that particular element is coded. If you’re lucky, maybe that element will have an ID:

In that case, it should be a no-brainer to use the DOM Variable with the following settings:

If there is no Element ID, you could then try to fetch the element based on its (and its parents’) CSS Classes.

That’s where the knowledge of CSS Selectors would come in handy. Speaking of the screenshot above, the user ID is a span element with the class username. Let’s pretend that we know that there are more elements on a page with the same class. Thus we need to be more precise. This element is a descendant of the li element with ID wp-admin-bar-my-account. We can use this in our CSS Selector:

The CSS Selector I’ve used above means that I’m targetting elements that have a CSS class username and are descendants of an element with an ID wp-admin-bar-my-account.

Just don’t forget that several items on a page might be caught by the same CSS Selector. That’s why you should use the document.querySelectorAll() method to ensure you’re fetching only that element that contains the User ID. Read tip #20 in this guide to learn more.

Public Service Announcement: When you’re using DOM Variable with the CSS Selectors (or a Custom JS variable generated by the GTM Variable Builder), you’re telling Google Tag Manager the exact path to that website element in the entire website document (e.g., from its parents to that very exact element).

Now, if that path changes anywhere along the way (due to the developer’s input or something else), your CSS Selectors or Custom JS variables will break and return undefined. This means your User ID tracking in Google Tag Manager will stop working.

Nonetheless, in most cases, scraping is better than having/doing nothing. But if there is a slight chance of talking with developers, PLEASE, PLEASE, PLEASE do that and cooperate with them.

You + Developer + Data Layer is an unbeatable trio in tag management.

Anyway, if this User ID fetching method worked for you, Feel free to skip to Chapter #4 of this guide, where I’ll show you how to use that User ID in Google Tag Manager (Google Analytics tag).

 

#4. Insert the User ID variable in the GA4 configuration tag

At this point, you should already have a Google Tag Manager variable that returns the User ID. That variable should now be inserted in the value of the user_id parameter that you have set in chapter #2 of this blog post.

Save the GA4 configuration tag, and let’s test the setup.

Also, you must ensure that your configuration tag fires when the user ID is already available. So if you, say, asked a developer to push the User ID to the data layer, it should be pushed before the GTM container is loaded. Therefore, your config tag (that fires on Container Loaded) could access the User ID.

 

#5. Let’s test

After you created a User ID variable and saved the GA4 configuration tag, enable the GTM Preview mode by clicking the Preview button in the top right corner of the GTM interface.

Then you should see that your configuration tag has fired. In this blog post, I presume that you fire it with the Pageview trigger (Container Loaded event). Click Container Loaded in the preview mode and click the Google Analytics 4 configuration tag.

Then switch to the values in the top-right corner of the preview mode. You should see that your tag also sent the user_id parameter with a certain value.

If you see the correct ID, check Google Analytics 4 DebugView. In GA4, go to Admin > DebugView. Find your own device.

Once you do that, you should see that one of the items in the event stream is user_id. Click any event that comes after it. On the right side, you will see Parameters. Click User Properties. You should see the user_id property there, and its value must be exactly what you saw in the preview mode of Google Tag Manager.

If everything works correctly, you can now publish your changes in the GTM container. Click Submit button in the top-right corner of the GTM interface and complete all the steps that you will be asked.

 

#6. Where can you find/use user ID data?

24 hours after you have implemented and published your GA4 user ID tracking setup, you might notice that the number of users will decline. It does not mean this will happen 100%, but there is a chance. The reason for this is that GA4 will start seeing several devices as the same user (if that user is using multiple devices to log in).

User exploration. If you go to Explore > User Explorer, you will start noticing two types of App Instance ID values. The first one is the usual GA client ID. It contains a dot in the middle of it, e.g., 2101187682.1610061461. The other IDs will be the ones you send as user_id to GA4. You can click on that ID and see what that particular user did on a website.

However, keep in mind that user_id does not affect historical data. If an anonymous visitor visited your site five times before signing up (and getting the user id), you wouldn’t see that data linked to the user id.

 

Segment overlap. You can also see how users are using your website with different devices and how their devices overlap. Go to Explore > Segment overlap. Add two default segments: Tablet traffic and Mobile traffic.

Create one more segment with the following settings:

• User Segment
• Include users where the device category contains desktop at any time.

Save the segment and add it to the segment comparison.

Then you might see that some segments overlap. This means that some users are using multiple devices to log in to your website/service.

 

Signed in with User ID dimension. By implementing user_id tracking, you will also unlock a new dimension called Signed in with User ID. It does what it says. If a visitor has signed in to your website and you send user_id to GA4, the value of this dimension for that user will be true. Otherwise, false. So if you want to quickly see how many people have signed in, you can make a quick comparison.

In the Reports > Reports Snapshot section (or any other standard report) of GA4, click Add comparison. Then enter the following condition: Signed in with user ID equals true. Save the comparison.

Now you will see how many people (compared to all visitors) have logged in to your website.

You can also use this dimension in other parts of the GA4 interface, like Explorations.

 

Other tips. Also, you can look at Ken Williams’ guide to learn some additional tips about using the User ID.

These were just several ideas where you could use a User ID. But what if you want to add a User ID as a secondary dimension in Free Form exploration? That is not possible out of the box (too bad because I would expect this to be handled automatically). But there is a recommended workaround. Read the next chapter.

 

#7. If you want to use User ID as a dimension in various GA4 reports

Update: it is no longer recommended to do what is described in this article. Otherwise, you will often see (other) value in your reports. I am keeping this chapter so that other readers will be aware.

If you configure Google Analytics 4 user ID tracking, that ID will not be available as a dimension. I wish that this was handled automatically, but at the moment, that’s the reality.

If you try to register a custom dimension and use the user_id parameter name, that will not work (because user_id is a reserved parameter that cannot be used as a custom dimension).

The workaround (that Google used to recommend) is to send an additional parameter that you can later register as a user-scoped custom dimension. The only requirement here is that the parameter CANNOT be named user_id.

You can name it anything else, like user_id_dimension, crm_id, internal_id, etc.

In this blog post (as an example), I will name it user_id_dimension. In Google Tag Manager, open Google Analytics 4 configuration tag (the same that we previously used). Then click User Properties > Add Row and enter the following settings:

What you will notice is that the value is identical to what we used in the case of user_id. That is exactly how it should be done. Basically, we are sending the same value as an additional parameter.

Save the tag and test the setup (just like we did with the user_id). After everything is tested properly, publish your GTM container changes.

Now, you should go to Google Analytics 4 > Admin > Custom Definitions > Create Custom Dimensions. Enter the following settings:

Important things to note:

• The scope should be User
• In the Event parameter field enter the same name that you have just configured in the GA4 config tag. In my case, that is user_id_dimension (NOT user_user).
• The values of other fields don’t matter much. You can enter whatever you want (or just follow my example).

Save the dimension. 24 hours after this is done, you can use the newly created user-scoped custom dimension in GA4 reports. But keep in mind that this is not retroactive. This new dimension will start reporting data only AFTER you create it in the Google Analytics 4 interface.

 

User ID in Google Analytics 4: Final Words

User ID tracking in Google Analytics 4 is definitely an improvement compared to Universal Analytics. You don’t need to create a separate view for that. The data is applied to the entire property as soon as you start sending the user_id parameter with all events where the user is logged in.

However, it is still not perfect. I wish the User ID was available as a dimension out of the box. But I bet that this will never happen, unfortunately.