Users may interact with your website or application from a number of different devices, such as a desktop web browser, a browser on a mobile phone, or via a native mobile application. By default, Analytics assigns each device a unique Client ID, and considers each unique Client ID as a unique user in your reports. User-ID enables holistic measurement of user interactions that span across devices, such as attributing an interaction with a marketing campaign on one device to a conversion that occurs on another device, or de-duplicating unique users across multiple devices.
The User-ID feature consists of:
userId field, which can be set to a stable, non-personally identifiable ID to represent a unique user.When User-IDs are sent with Analytics hits in the userId field, your reports will reflect a more accurate count of unique users and offer new cross-device reporting options.
This article describes how you can configure and send User-IDs to Analytics, as well as how User-ID data is processed and reported in your User-ID-enabled views.
ConfigurationBefore sending User-IDs to Analytics, you must enable at least one reporting view for User-ID.
Enabling a view for User-ID produces two effects on that view:
Warning: Once you enable the User-ID feature for a view, you cannot disable it. That view will only show hits for which the userId field was set.
When a user is known to your website or application, you should send an ID representing that user with all of your Analytics hits, such as pageviews, events, ecommerce transactions, etc., using the userId field.
It is up to you to provide the IDs. IDs are typically generated by an authentication system that assigns each signed-in user a unique, stable ID. IDs should have the following characteristics:
For more information on how to set userId in a particular environment, see the Collection APIs and SDK dev guide for your specific library.
Analytics hits, like pageviews, events, or transactions, for which the userId field has been set, are processed separately from non-userId hits and will only be visible in User-ID-enabled views.
For example, in User-ID-enabled views, if a User-ID is set in the middle of an Analytics session, then the start of the session changes to the first hit in which the User-ID was set.
Non-User-ID views (profiles) would report the entire session without regard for the userId field.
userId field was set will be reported in User-ID-enabled profiles Reporting
After processing, session data for which userId was set is available for User-ID-enabled views (profiles) in Cross-Device reports. Although the session data is available via the Core Reporting API, the userId field is not available as a dimension in reports and can not be exported from Analytics.
New and Unique user metrics will also be based on User-ID in these views. In non-User-ID-enabled views, these metrics will be calculated using unique clientIds.
: Cross-device reports can have a maximum date range of 90 days.
Client ID vs. User-IDThe following table summarizes the differences between Client ID and User-ID:
Client ID User-ID What does the ID Represent? An pseudonymous device or browser instance. A single user, like a signed-in user account, that may interact with content across one or more devices and / or browser instances. How is the ID Set? Randomly generated and automatically sent with all hits by Analytics libraries. You must set and send your ownuserIds with your Analytics hits. How is ID Used to Calculate Unique Users? In a non-User-ID-enabled view, Client ID is used to calculate unique users. In a User-ID-enabled view, the user ID is used to calculate unique users Limits
The following limits are currently in place for the User-ID feature:
How can we improve it?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3