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.
How Does Cross-Platform Tracking Work?
To be clear, you can only track authenticated users across platforms. We all know that Google has tricks and fingerprints and algorithms to recognize an individual user as they travel the web, which can be used to enable numerous remarketing features, but this functionality is not available in either traditional Google Analytics or Google Analytics 4.
Google Analytics 4 will use one or both of the following ID’s to identify an individual user:
- User Pseudo ID (set automatically)
- For Android and iOS apps: the pseudo ID is set to the App-Instance ID. This will be unique to each instance of an app downloaded on a device.
- For websites: Firebase uses the classic client ID you are familiar with from prior versions of Google Analytics as the pseudo ID.
- User ID (set by you)
The user ID is a unique identifier that you provide after the user has logged in (usually from your own authentication system). It should be consistent across your apps and websites for the same user.
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.
When you create a new GA4 property, you will need to set your “Reporting Identity” to “By User ID and Device” (use User ID if you have it, otherwise use User Pseudo ID) or “By Device Only” (just use User Pseudo ID).
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 set the user ID for all of your logged in users to determine when the same user is utilizing multiple devices.
Other Unique Identifiers You Should Be Aware Of in Google Analytics 4
- 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). As of iOS 14 (Sept. 2020), Apple requires that users grant permission before apps can access the IDFA (more).
- Device ID – You may have noticed a dimension in the User Explorer reports called “Device ID”. If you hover over this dimension in a report you will see a description that states this corresponds to the “Advertising ID”. However, this description appears to be incorrect as this will actually return the User ID if it exists, and if not it will return the User Pseudo ID.
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 hit (this is the same for Universal Analytics). If you use Google Tag Manager you can simply add the “user_id” field to your configuration tag (more on how to do this below).
Mobile apps are much more forgiving, however. You will only need to set the user ID once per session (more detail from Google).
Let’s Set It Up!
STEP 1) To get started you’ll first want to start setting the User ID in your tags.
- 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 either the gtag or GTM:
- If you’re using gtag, Google’s instructions can be found HERE.
- If you’re using GTM, there is currently no instruction provided by Google. However, you can set the user_id under “Fields to Set” in your configuration tag as shown below:
STEP 2) Once the tagging is complete, you’ll need to open your property settings in Google Analytics and set your default reporting identity to “By User-ID and device” as shown at the beginning of this post.
STEP 3) Finally, head over to “Custom Definitions” and create a new custom dimension called “user_id” with “user” scope as shown below.
This is confusing because technically the User ID is not a property, but once you do this you will be able to use this value as a dimension in the Explorer (there’s no need to set it as a separate user property for this to work).
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.
- 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.
- 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.
- Finally, to verify that user activity is being stitched together across devices, you’ll need to look for overlap in the “Users by Platform” Venn diagram found in the “Technology > Cross-platform” report.
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.
- 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.