ukraineUAWC stands with Ukraine and its peopleJoin us

The Definitive Guide to Google Analytics 4 User ID

The strict Google privacy policy does not allow the use of personally identifiable information or IP addresses of users to provide insights into the structure or behavior of your audience. However, as a workaround, unique user IDs can be used to learn valuable information about new and returning visitors to your website. Also, this approach helps to resolve cross-device problems with attribution when most purchases are being tracking as coming from direct.

In this article, we explain the GA4 User ID concept in detail and present examples of its application in case you need to identify users more precisely. Let’s structure this article for your convenience:

Table of Contents

What is User ID in Google Analytics?

User ID tracking is used to connect engagement data from different sessions that are initiated from multiple devices or even browsers to the same users.

Google Analytics 4 can recognize the journey of the same users regardless of how many devices they use when they visit your website. There are certain situations in which this feature is not available. You may use this option only in case you have a proper authentication system, let’s say with logged in users.

User ID - Google Analytics

Let’s imagine the following situation: A person seeking a product uses a smartphone to browse your store and interact with it. After taking a look at various products, the customer chooses one he/she likes and leaves your store.

After some time, this customer decides to conduct some further research and consequently visits your website using a tablet. He really likes the product now, and so he decides to buy it. However, this person prefers to fill out forms on his desktop device. As a result, he takes a laptop and buys the product he found in your store using his smartphone earlier.

Without Google Analytics User ID implementation, it appears as if three different users have visited your website. The first user with a smartphone clicked through a lot of pages and products on your site. The second user appeared to be interested but then abruptly leaves the site. The third user is walking directly to the product and purchases it as if it were his job.

But actually this customer is the same person and a single user.

Reporting Identity option in GA4

Officially released in mid October 2020, Google Analytics 4 launched different systems of user identification in Google Analytics 4 in comparison to the Universal Analytics. Three types of default reporting identities can be chosen in the Reporting Identity section of the GA4 property settings: the first is the Blended model, which contains User ID, Google Signals, Device ID, and Modeling methods (in Beta now), the second is Observed, which contains only first three methods above, and the third is the Device-based model where only the Device ID will be used.

The Blended model means that if you have the User ID tracking implemented, it will be used. If it is not implemented, Google Analytics 4 will rely on Google signals. However, if neither User ID nor Google signals are available, Google Analytics 4 will rely on Device ID. If this option also is not available, GA4 will rely on modeling. 

In case you choose the Observed model, it works so that when the User ID is unavailable, Google Analytics 4 uses Google signals to obtain the required information. If both the user ID and Google Signals are unavailable, GA4 uses the device ID.

The last model uses only the device ID and ignores other collection methods.

Google Signals is a feature that collects data from users who have turned on Ads Personalization. Because these users are already signed into Google accounts, Google Analytics can utilize their data (in lieu of a website authentication system like the User ID) to users cross device tracking. Google Signals may not be enabled in GA4 unless you consent to User Data Collection Acknowledgement in your Google Analytics settings. In your Privacy Policy, users have to be informed that this method might be used to collect their data across devices.

In your Privacy Policy, users have to be informed that this method might be used to collect their data across devices.

The Reporting Identity option allows you to get a more accurate view of your users throughout the whole GA4 property, while at the same time for the User ID set in the UA property, you need to create a separate User ID view for this feature.

Sending user ID to Google Analytics 4

As usual before sending User ID to Google analytics, you should ask your developer to push the code with User ID value to the Data Layer.

Regular websites that refresh the entire page when the user is navigating should have this code placed above the GTM container (so you still have it available when using the All Pages GTM trigger).

It is also crucial to ask a developer to push the User ID every time a new page loads (that is, when the page entirely refreshes and the previous values in the Data Layer are erased). You can then use this code (placed above the GTM container snippet):

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

Then, technically the User ID value can be passed to Google Analytics preferably by the Google Tag Manager via several methods.

One of the methods we have chosen for the use case below was built on the algorithm where the first developer’s code pushes the User ID to the Data Layer so that we have a Data Layer variable userId.

After that, a Custom JavaScript Variable checks if the Data Layer contains User ID value and then stores it in a cookie.

If there is no User ID in the Data Layer, then the value of the cookie will be used. In the end, we send the cookie’s value with every GA hit configured by GA4 tag to Google Tag Manager.

In the Fields to Set section, you should enter the value (i.e., the User ID variable that equals the actual ID of logged in users on your site).

If a user enters and browses through your website without logging in, the value of the User ID variable will be undefined, hence the User ID will not be sent to GA4. But if a user logs into his/her personal account on your website, the User ID should become available, and then, the next time this Google Analytics tag fires, it will contain the value of User ID.

Be aware that you are not allowed to send personally identifiable information as User ID to Google Analytics (i.e., email addresses, names, or phone numbers that could identify a person). Personal account number, login number, or account ID from your CRM will be the best options to send as User ID.

Testing implementation

After implementing all steps above you can test your implementation in Google Tag Manager with the help of Preview mode.

As we have set our GA4 configuration tag firing by Window Loaded trigger, we should find it in the preview mode. Switching to the Values in the top-right corner of the preview mode shows that our tag also sent the user_id parameter with a certain value.

Then, we should check whether these values have been sent properly to analytics with the help of the Google Analytics 4 DebugView. For this, you need to open your GA4 property, open the Configure section, and choose DebugView.

If you select any subsequent event from the list after the user_id item has been highlighted with orange color, just click on its User Properties section on the right side. The user_id property should be listed there, and its value must be the same as the one you saw in the Google Tag Manager preview mode. Moreover, we could find two additional user properties: Client ID and user id dimension. Please look through the Useful Tips section below where we describe why you need them and how they can be sent.

Use case example

One of our clients with a SAAS business model had a problem when lots of transactions were attributed to the direct source and there was no User ID implemented in his UA property. On the way to purchase through the single user journey, the user had to sign up and acquire his unique ID as a 10 character number. The purchase could not be made without signing in to the personal account of the user.

Detailed analysis of user behavior in User Explorer reports of UA showed that a large amount of transactions were held when a user entered a website directly for the first time then signed in to the personal account and made a purchase. In this case, there was no mention in the report that the user signed up during such a session which is why the only conclusion was that a user entered the website from another device or browser. 

And this is how standard user identification by Device ID works in Universal Analytics. A new Client ID (that is stored in cookies) is assigned to the user if the same user accesses the website from a different device. This will make your Google Analytics statistics inaccurate. Hence, our proposal was to migrate to Google Analytics 4 and to implement the User ID tracking simultaneously to investigate this problem and assess how many single users purchase by User ID.

After successful migration to GA4 and implementation of the User ID feature, we have created a custom report in GA4 that provides us with the opportunity to indicate how many purchases can be made by a single User ID account across different devices. 

When we compared the data from Universal Analytics during the same time period, we found all these transactions with the same Client IDs. Therefore, they were held by the same User ID account. 

Useful tips

Here are a few little tips when you implement all steps above to send a User ID with Google Tag Manager. You can not observe Client ID value in any of the custom reports in GA4 except for User explorer reports where it is implied as the App-instance ID. To pass it as a custom dimension to GA4, you need to create in Google Tag Manager a 1st-Party Cookie variable that pulls Client ID value from _ga cookie.

Then, create a Custom Javascript variable (CJV) that extracts this Client ID value from this cookie variable. After that, CJV is sent to GA as a value of Client ID user property with every hit.

Another tip is that as soon as you configure and send user ID to Google Analytics, its value will not be accessible as a dimension and you’ll see other as its value in your reports. Just send an additional parameter and register it as a user-scoped custom dimension. For this, in the Google Tag Manager, modify your GA4 configuration tag by adding a parameter with any name except “user_id” to the User properties section (see our GA4 config tag above).

Then, you should go to your Custom definitions subsection in the Configure section of GA4 property and choose Create custom dimensions. The scope of the dimension should be User and the User property name must be exactly the same as you added to your GA4 configuration tag in Google Tag Manager. The dimension name can be whatever you want. Save this dimension and after some time, you can observe and use it when creating your GA4 custom reports.

Summary

Implementing User ID in Google Analytics 4 provides a powerful feature that enables you to conduct a more in-depth analysis. You can only apply it if you have some form of user identification on your website. You can associate your own identifiers with individual users by User ID in Google Analytics 4 so that you can gain a more comprehensive picture of your user’s journey across devices.

As we mentioned above, the User ID value cannot be personally-identifiable but it allows you to connect those user IDs to your customer database or CRM system.

For example, Google Analytics can tell that a customer with User ID # 1234567 has added four items to his shopping cart but has not completed the purchase. In your customer database, you know that user # 1234567 is Mr. Bean, so you are able to send him an email and ask “We noticed you almost completed the purchase. Would you like to continue checkout and how can we help you?” 

Subscribe for our
Email Updates
Get useful tips about scaling your business!