User Experience Analytics (Appsee) How to identify users records from sys user using Hashed User ID - Support and Troubleshooting

User Experience Analytics (Appsee) How to identify users records from sys user using Hashed User ID Description 1. Can the analytical data be used to, or does it, identify a living individual (end-user)? – Geolocation information may be considered personally identifiable information (PII)

Ans: 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, the IP address is not stored.

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

Ans: 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 he is using multiple devices.

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

Ans: 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?

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

5. How is the data stored?

Ans: 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

Ans: No.

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

Ans: 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?

Ans: 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)"

Ans: Yes, as mentioned above, UX Analytics can detect the location of the user per his IP address. There are different consent behaviors for end users depending on their 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

Ans: 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: https://emn178.github.io/online-tools/sha256.html ). You can use this hashed value to filter on the results found in the analytics dashboard.

11. Is the hash salted?

Ans: 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: https://xorbin.com/tools/sha256-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.

Ans: Not possible, it is a one way hash (this was the requirement from the ServiceNow privacy team).

Instructions There will be frequent requirement to decode the Hash User ID for Organisations to identify the user list from various dashboard.

The point here is the Hash user ID is a one way hashing and we cannot do a reverse hashing for getting the sys_id of the user.

****From SanDiego release, "Hashed User ID" is available OOB on sys_user table. This is a string field.

Pre SanDiego, to identify one Hash user ID we need to Hash all sys_id from 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 for PRE SanDiego and as follows:-

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 there on the field.

Customers need to check with their internal developers to check how best to implement this solution on their instances. Regarding the SHA-256 algorithm, we have a confirmation from DEV team that we are using standard sha256 hash (with no saltt) on the user sys_id for storing the data.

As the Hash User ID on the table; it will be easy to reverse engineer to search for individual users in sys_user table from the User Experience Analytics Dashboard

For SHA-256 algorithm internal developers should be able to find the code googling it as it is not a ServiceNow code but a standard code.

Also, these topics are discussed in our community and below listed are few of the links. https://community.servicenow.com/community?id=community_question&sys_id=e96a9741db662b00656a5583ca9619fd https://community.servicenow.com/community?id=community_article&sys_id=97c5faffdb36a3045d782183ca961940

Hashed User ID on sys_user OOB SD

Additional Information