User Experience Analytics and Hashed User ID: FAQs and Guidance - Support and Troubleshooting

User Experience Analytics and Hashed User ID: FAQs and Guidance Summary User Experience Analytics collects anonymized ServiceNow application usage data, which is stored off-instance for performance and scalability. This article addresses questions related to specific usage data collected, how it is anonymized, and how customers can re-identify users to connect PII to usage data.

1. Can the analytical data be used to, or does it, identify a living individual (end user)? (Note: Geolocation information may be considered personally identifiable information (PII))

To anonymize users while retaining the ability to consistently connect individual users to their session data, ServiceNow uses a one-way SHA256 hash on the sys_id of the sys_user record, or Hashed User ID. This one-way hash allows customers to re-connect their User Experience Analytics data to personally identifiable information available on the sys_user table if they choose.

Out of the box, User Experience Analytics translates the end-user's IP address to a city level location, which is stored; the IP address is not stored.

2. Is the data anonymized by the system to avoid point above?

User Experience Analytics does not store the User ID, but a hash of the sys_id is stored on the sys_user table ("Hashed User ID"). This is done to consistently identify the same user, even if that user is using multiple devices.

3. What are the protections in place to ensure the confidentiality of such data?

The User ID is hashed on the client side and pushed to the User Experience Analytics tracking SDK.

4. What is the full list of purposes that the collected data will be used for?

The data is strictly tracked for providing ServiceNow customers with analytics and reporting capabilities so they can better understand usage and adoption across the different channels of the ServiceNow platform.

5. How is the data stored?

The data is stored in an encrypted manner in a central ServiceNow multi-tenant repository within the customer's region of AMS, EMEA, or APAC. A backup copy is stored in a central repository in AMS, and customers can request that this be turned off.

6. What is the defined retention period for this analytical data?

For customers on Yokohama and future releases, the retention period for single session and aggregated analytics is 2 years.

For customers on Xanadu and prior releases, single session data is retained for 3 months, and aggregated analytics is retained for 2 years.

7. How is the data disposed of or anonymized for continued retention once the PII retention period has passed?

Data is anonymized before it is sent to our repository, and purged at the DB level after the retention period (entries are deleted).

8. Is there a method of identifying the Geolocation of a user to ascertain if particular Data Protection legislation is in force (UK or EU GDPR, CCPA, Brazilian, etc.)?

Yes. As mentioned above, User Experience Analytics collects and store's a user's geolocation by translating their IP address at login during a session.

However, determining a user's location for use in opt-in and consent for Data Protection legislation purposes is separate, and can be configured by the customer. Refer to the User Experience Analytics documentation Define how to detect your user's location .

9. How can I track the User ID from Hashed User ID?

In order to find a certain user's records on the analytics dashboard, you will have to find their sys_id from the sys_user table and then find the hash value of it. This can be done by using, for example, SHA256 online tool to provide the Hashed User ID after you supply IDs from sys_user. Starting in San Diego, a Hashed User ID field was added to the sys_user table out of the box. If you have admin permissions and are not able to see this field on sys_user, reach out to ServiceNow support.

Starting in Yokohama, customers can add custom user properties as filters for the data collected in User Experience Analytics directly, which can remove the need to join data from the sys_user table. See documentation Add user properties as filters to User Experience Analytics .

10. Is the hash salted?

The hash is not salted (intentionally). This means that customers can obtain the ID of a specific user they want to track, apply a SHA256 on that ID (for example here: SHA-256 hash calculator ), and then use the output to filter the data for a specific User ID.

11. Is it possible to decrypt the value to get the User ID?

This is not possible, it is a one way hash.

Release Yokohama

Instructions Customers sometimes need to decode the Hashed User ID to identify users in connection to usage data collected with User Experience Analytics.

The Hashed User ID is a one way hashing and it is not possible to reverse hash for getting the sys_id of the user.

From the San Diego release and onwards, "Hashed User ID" is available Out-of-box (OOB) on the sys_user table. This is a string field. Customers can request that this field be exposed by contacting ServiceNow support.

Prior to San Diego, to identify one Hashed User ID, you need to Hash all sys_id from the sys_user table and run it across the Hash User ID on the dashboard to identify the user. This can be a tedious job.

There is a custom solution for this that applies to releases prior to San Diego and is as followed:

Create a custom field on sys_user table and create a custom business rule on INSERT to create the Hash User ID of the sys_id and store it as a string value on the field.

Note: Customers should check with their internal developers to check how best to implement this solution on their instances. Note: Regarding the SHA-256 algorithm, ServiceNow uses the standard SHA-256 hash (with no salt) on the user sys_id for storing the data.

As the Hash User ID is now on the sys_user table, it is now possible to search for individual users in the sys_user table from the User Experience Analytics Dashboard. See screenshot below as an example. Related Links For the SHA-256 algorithm, internal developers should be able to find the code on the web as it is not a ServiceNow code but an industry standard code.

For more information regarding this topic, please refer to the following:

How to generate SHA256 Hash for a Given String ? Generating SHA 256 Hash for a given String in ServiceNow