Properly Setting the User ID to Track Activity Across Web and App with Google Analytics 4

User overlap by platform in the tech overview report.

If you want to track a user’s activity across your websites and mobile apps with Google Analytics 4, you’ve come to the right place. This post will bring you up to speed on how to install the User ID across your platforms and verify that it is working properly. However, to learn how the User ID is used to generate reports, take a look at my post called Understanding the User ID.

LAST UPDATE (Sept 25, 2021)

Updated to reflect changes to custom dimensions and instructions for verifying that the user id is setting properly.

Contents

How Does Cross-Platform Tracking Work?

To be clear, you can only track authenticated users across platforms with he user ID.  The user ID different from Google Signals (Google's proprietary technology used to recognize an individual user as they travel the Internet), because you set it from your own database when you have confirmed the identity of the user.

The reports in Google Analytics 4 will use one of three methods to identify your users (these are called "identity spaces"):

1) User ID (set manually)
The user ID is a unique identifier that the website or app provides after the user has logged in (usually from your own authentication system).  It is the most accurate and comprehensive way to identify a unique user, and it should be consistent across your apps and websites for the same user.
2) Google Signals
Google signals is data from users who are signed in to Google, and who have enabled ads personalization. Because of those two conditions this is not a comprehensive way to identify all of your users, but it is a useful fallback when the user ID does not exist.
3) User Pseudo ID
The user pseudo ID is the least accurate method because it really only recognizes a device (not a user), but it was the standard way to identify users in all the previous versions of Google Analytics.

For Android and iOS apps: this is set to the App-Instance ID.  This will be unique to each instance of an app downloaded on a device.

For websites: this is set by first-party cookies (previously known as the ‘client ID’). You can use the user pseudo ID in the "User Explorer" report, but it is called "App-instance ID" regardless if it was collected from a website or mobile app.

User ID and Reporting Identity

When you create a new GA4 property, you will need to set your “Reporting Identity” to “By User-ID, Google signals, then device” (prioritize the three identity spaces and use the best) or “By Device Only” (just use User Pseudo ID).

Default reporting identity

A user who accesses your site through multiple devices will have a different pseudo ID for each device, even if they are logged in.  So you will need to use the first option to determine when the same user is utilizing multiple devices.

What Happened to the IDFA?

You may be familiar with the Mobile Advertising ID / IDFA. This value is made available by the device’s operating system, and will be shared by all apps running on the device (more).

However, as of iOS 14 (Sept. 2020), Apple requires that users grant permission before apps can access the IDFA (more). It is not used by default in Google Analytics 4 (or Firebase Analytics).

When Should the User ID be Set?

The answer to this question is different for websites and mobile apps.  On the web you will need to set the user ID with every single event (this is the same as it was for Universal Analytics).

Mobile apps are much more forgiving, however.  You will only need to set the user ID once per session (more detail from Google).

NOTE

Also, I shouldn’t have to tell you this, but privacy is very important to Google. The User ID’s you set must be compliant with the TOS, which means that you must inform your users of how you use identifiers in your Privacy Policy, and the ID you set cannot contain information that a third party could use to determine the identity of an individual user (such as an email address).

Let's Set It Up!

IMPORTANT

When creating a User ID variable, never set a default value like "unknown" or "not-logged-in"! If the User ID does not exist it should not be set at all.

Mobile Apps – Google provides helpful instructions for setting the user ID within a mobile app HERE.  A common mistake is to set the user_id as a user property, so make sure your app developers read Google’s instructions.

ONE MORE TIP

When the user logs out you might consider setting the User ID to null.  Otherwise the unauthenticated activity will continue to pass the User ID.  You might prefer this, but be aware that the User ID will only persist this way on mobile apps, and setting the User ID to null will be consistent with your website implementation.

Websites – On the web you will need to set the user ID with the "configuration" tag. You can do this with the global site tag , or with Google Tag Manager.

Global Site Tag (gtag)

1gtag('config', 'GA_MEASUREMENT_ID', {
2'user_id': 'USER_ID'
3});

Google Tag Manager

Set the user_id under "Fields to Set" in your "Google Analytics: GA4 Configuration" tag.

Fields to set area of the configuration tag

How to Validate if the User ID Working Properly

I recommend taking three actions to validate that you are properly setting the user ID across all of your devices.

  1. Before you deploy the changes, you can activate Debug Mode in a staging environment and confirm that a “user_id” is set as a user property in the DebugView report.  You should do this for each data stream (typically: web, iOS, Android).

    If you are having trouble getting the User ID to set on a website, you can also use the Network tab of Chrome developer tools to make sure a parameter called “uid” is being passed with every hit as shown below.

    Validating the UID parameter in the network

  2. After deployment, you can open the “Users” report and use the “Build comparison” tool to view only signed in users with a user ID.  This will verify that the ID is setting properly.

    Build comparison tool

  3. Finally, you can use the tech overview report to verify that user activity is being stitched together across devices. The headline image for this post is an example of how this should appear when working properly.

What to Do If the User ID Fails Validation?

  • Your developers may have accidentally set the user_id as a user property or event parameter. You can verify that this is happening when DebugView does not show the user ID highlighted in orange like below. To fix this, your developers need to follow the instructions HERE.

    UID set as a user property in debugView

  • Another possibility is that the user_id in one stream is set to a different value than it is in another stream. The best way to verify this is to log in to each with DebugView running and verify that you see the same value highlighted in orange.