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

User Experience Analytics and Hashed User ID: FAQs and Guidance Summary 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))

The analytics data is associated with a Hashed User ID (which is a 256 one-way hash of the sys_user_id). UX Analytics translates the end user's IP address to a city level location, and the IP address is not stored.

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

UX Analytics does not store the user_id, but a hash of the sys_user_value. 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 UX 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.

6. Will the analytical data be shared with anyone outside of OneWeb and if so where, and in what form?

No.

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

For single session data the retention period is 3 months. For aggregated analytics reports the retention period is 2 years.

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

Data is purged at the DB level (entries are deleted).

9. 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, UX Analytics can detect the location of the user per the user's IP address. There are different consent behaviors for end users depending on the location:

EU Users - explicit opt-it US Users - auto track Other locations - tracking notice popup 10. How to track the User ID from Hash 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 from here for example: SHA256 online tool ). You can use this hashed value to filter on the results found in the analytics dashboard.

11. 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.

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

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

Instructions There will be a frequent requirement to decode the Hash User ID for organizations to identify the user list from various dashboards.

The Hash 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.

Prior to San Diego, to identify one Hash 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