User-ID: Why & What

User-ID: Why & What

Have you ever wondered how peopleblog_image use your site across different devices? Are people using their computer to register on your site but then interacting with it on their phone or tablet? How many of those “unique” users in Google Analytics are really the same person? By implementing User-ID, you can answer questions like this from within the standard Google Analytics reporting interface.

The User-ID feature overrides the typical way that Google Analytics stitches interactions into sessions and identifies unique users. By using your own identifier, you can associate engagement data from multiple devices and different sessions with unique IDs. This feature can also improve content analysis and help you generate more relevant and compelling content:

  • Rather than assuming that your content is equally useful to all, if your users have told you their preferences, you will be able to associate this information with their behaviour each time they visit
  • You will therefore be able to see what content is attractive to users with specific preferences, and what is not
  • If you send out emails to attract readers to fresh content, such knowledge will allow you to customize your emails, which should fuel higher open and clickthrough rates

Moreover, with additional configuration you will be able to do the following:

  • Unify user sessions across different devices without asking for a log in
  • Segment your registered users based on personas or user types
  • Import user information from other systems or databases into GA
  • Unify historical behaviour pre-registration session data

3 things you need to get started with User-ID

1. You must be running Universal Analytics

  • User-ID tracking will only work with the Universal version of Google Analytics
  • If you are using Classic (ga.js) code you will need to update to the Universal version (analytics.js)

2. You must supply GA with a unique, persistent, and non-personally identifiable User-ID value for each visitor

Check with your IT staff or website vendor whether they can provide you with an ID that meets the following requirements:

  • Unique and persistent: the User-ID value must be unique to each visitor and must be the same for each time that person logs in
    • If you use a CMS and ask users to login/register then the best unique identifier to use would be the primary key from your CMS’s user database
    • If you are using a marketing automation software you might be able to use its API to retrieve a customer ID  upon registration and send that ID to GA as a User-ID
  • Non-personally identifiable: As with any data sent to GA, the User-ID cannot personally identify an individual visitor to anyone looking at the data in Google Analytics (See next item for more details on privacy considerations)

3. You must abide by GA’s User-ID Policy and all applicable privacy laws

Here are a few key things to note in GA’s User-ID policy:

“You will not upload any data that allows Google to personally identify an individual”

  • This means the User-ID cannot contain the user’s name, email address, username, etc. Essentially, the same rules about Privately-Identifiable Information (PII) apply to User-ID as for any other data in GA. Note that even hashed/scrambled PII is still considered PII by Google

“You will give your end users proper notice about the implementations and features of Google Analytics you use”

  • This generally means that you must disclose details of your data usage in your site’s Privacy Policy, but in some countries this may mean getting explicit consent from a visitor in order to track them

“You will only session stitch authenticated and unauthenticated sessions of your end users if your end users have given consent to such stitch, or if such merger is allowed under applicable laws and regulations.”

  • This paragraph is currently not included in the User ID Policy posted within the GA Developers Guide, but is displayed in GA before you activate the User-ID feature. Once a visitor has been assigned an ID, it is possible to track them with this ID in future sessions, even if they do not login again (e.g. by storing the ID in a cookie). This clause means that you can only do this if allowed under the relevant privacy laws and with the consent of your users

Limitations of User-ID

User-ID is not perfect and you should not expect it to solve all your problems or answer all your questions, but it can be a really powerful tool if used correctly. It can also be a really “creepy” tool if used incorrectly and can lead to a lot of problems. Plus standard Google Analytics limitations on data accuracy still apply.

What if I don’t have a login?

By its nature, User-ID requires visitors to authenticate in some way, usually via a login or registration. But if your site does not force users to login with every session (or you don’t have a login at all), you may only be able to capture a small proportion of your visitors with User-ID.

You could argue that this defeats the purpose of using User-ID tracking at all. However, even that small proportion would be valuable for you to understand, especially if those users logged-in to make a purchase, registered for an event, or signed up for a newsletter. These are likely your most loyal and valuable visitors, and User-ID will help you identify, analyze, and understand them even better.

Don’t be creepy

User-ID is not intended as a way to “stalk” users. While you can get really granular you should be cautious about how that information is used. Although User-ID values cannot be personally-identifiable to Google, it is possible for you to tie those IDs back to your customer database or CRM system. Hence, you can identify individuals offline and use User-ID to associate each customer’s profile with their online activity.

For example, GA may tell you that user #314159 added 3 items to their shopping cart, but never completed their purchase. If in your customer database, you know that #314159 is actually John Smith, you could send him an email saying “Hey, we noticed you almost bought these products. Would you like to checkout now? Let us help you.” This may come across as being overly intrusive and could actually deter customers from doing business with your organization.

A more useful approach may be to ask yourself questions like: Why did this user start, but not complete the purchase (or registration, signup, etc.)? Did they see something that stopped them from continuing? Did they encounter a technical issue? Is there a pattern here or is it just an outlier? Once you have a theory, you can do some further analysis and even run tests to see if you can adjust this behaviour.

The data is not perfect

Finally, as with any client-side tracking (which is how most web tracking works), the usual limitations still apply – deleted cookies, disabled JavaScript, and visitors using new, borrowed, or public devices will affect the accuracy of the data. While User-ID helps mitigate some of the usual issues (e.g. cross-device usage), general session and interaction tracking still relies on JavaScript and cookies. As with most web analytics data, you should focus on analyzing patterns, trends, and changes, rather than absolute numbers.

If User-ID tracking sounds applicable to your business and website, check out some additional links under “Further Reading” below. Next month, we will post a follow-up article on the technical details of implementing User-ID.

Further Reading

By |2019-05-17T11:57:12-04:00June 18th, 2015|2 Comments


  1. Nik December 14, 2015 at 11:12 am - Reply


    If we do not have any login feature, can we fetch cookie data using JavaScript and generate user-id and then pass it to the CRM? So next time, when the same user visits the site, we can show personalized message. I believe in order to map specific user-id, we’ll have to fetch user-id from the log files (when CRM is not available) or from CRM? Am I correct or is there any other way to show personalized message for sites with no login feature. Any help would be appreciated, since I’m not a techie person.


    • Max Bondarenko December 21, 2015 at 7:41 am - Reply

      Hi Nik,
      One can certainly use the described method to display a personalized message; however, that is not quite the main reason one would want to implement User ID. Main intention behind implementing User ID is enabling analyst/marketer to link all interaction of a user despite him/her using different devices. So, for example, if a person first arrives to your site from a marketing campaign while browsing on his/her phone and then completes a conversion from a desktop/laptop – you can link that conversion back to the campaign and review what other interactions lead to it.
      You can certainly drop a cookie to track that user if you do not have a login feature and then use the value of that cookie as “User ID” and also pass this value to CRM. However, if that cookie is deleted or person uses a different device you may end up having multiple records for the same user. One way to go around this limitation is to use that “User ID” when bringing this visitor back to your site. The best case scenario here is when this user subscribes to any email communications – then you can attach this “User ID” to all email links for that user. That way when user clicks on an email link you can rewrite “User ID” on that device with the correct one from the link. This method is not perfect but better than having nothing at all. We will be covering it in more details in a next month’ post.

Leave A Comment