DEX score NQL examples

Use Nexthink Query Language (NQL) to access DEX score data and other relevant information.

NQL data structure

The dex.scores and dex.application_scores tables contain score data. The system computes each score once a day at 00:00 UTC for a combination of user and device objects, and device dimensions active over the last 7 days. For example, employee A who used device 1 and device 2 over the last 7 days will have two sets of score data for the current day.

DEX score V3 primarily focuses on user-centric experience management rather than a device-centric approach, which differs from previous versions. Even though starting an NQL query with the device table is technically possible, you may witness deviations between the device's metric value and its score. Refer to the FAQ section of the Computation of the DEX score (available to Nexthink Community users) documentation for more information.

dex.scores table

The dex.scores table contains score data for the endpoint and collaboration scores and their subscores. The system structures a set of scores as follows:

Each node of the DEX score has a score value with the syntax [node name]_value. For example, if you want the score for logon speed, you would enter score.endpoint.logon_speed_value.

In addition, each node has a score impact value with the syntax [node name]_score_impact. This value represents the estimated decrease in the Technology component of the DEX score due to issues monitored by this node.

dex.application_scores table

The dex.application_scores table contains score data for the application scores and their subscores. This table is linked to users, devices and application objects. The system structures a set of scores as follows:

• node.type represents the type of node of the application score structure:

  • page_loads

  • transactions

  • web_reliability

  • crashes

  • freezes

  • application

• node.value indicates the score of a node of the application score structure. It must be used with the field application_score.node.type to specify the target node score.

• node.score_impact indicates the estimated decrease in the Technology component of the DEX score due to issues monitored by this node. It must be used with the field application_score.node.type to specify the target score impact.

Refer to the List of hard metrics and their default thresholds documentation (available for Nexthink Community users) for the full list of nodes and their respective NQL names.

score_impact values

Both dex.scores and dex.application_scores include a score_impact value for all nodes, i.e., [node name]_score_impact. This value estimates the number of points removed from the DEX score due to user-level issues for the node. For example, logon_speed_score_impact contains the estimated impact on the DEX score for a user due to slow logons.

To compute the impact on DEX score of a node for a population, use the following formula:

Examples of NQL queries

Get the overall latest DEX score of your company.

users
| include dex.scores during past 24h
| compute DEX_score_per_user = value.avg(), c1 = count()
| where c1 > 0
| summarize Overall_DEX_score =  DEX_score_per_user.avg()

Get the latest virtual session lag score values for employees in Switzerland

users
| include dex.scores during past 24h
| where context.location.country == "Switzerland"
| compute Virtualization_score = endpoint.virtual_session_lag_value.avg(), c1 = count()
| where c1 > 0
| summarize Overall_virtualization_score = Virtualization_score.avg()

Compare DEX score values per operating system platform.

devices
| include dex.scores during past 24h
| compute DEX_score_per_device = value.avg(), c1 = count()
| where c1 > 0
| summarize Overall_DEX_score_per_OS_platform = DEX_score_per_device.avg() by operating_system.platform

Get the application score and the corresponding page load score.

users 
| include dex.application_scores during past 24h 
| where application.name == "miro" and node.type == application 
| compute application_score_per_user = value.avg()
| include dex.application_scores during past 24h 
| where application.name == "miro" and node.type == page_loads 
| compute page_load_score_per_user = value.avg()
| summarize Overall_application_score = application_score_per_user.avg(), Overall_page_load_score = page_load_score_per_user.avg() 

Get the top 50 users suffering from poor digital experience.

users
| with dex.scores during past 24h
| compute DEX_score = score.value.avg()
| list name, DEX_score
| sort DEX_score asc
| limit 50

Get the estimated impact on the technology score of the logon score

users
| include dex.scores during past 24h
| compute logon_speed_score_impact_per_user = endpoint.logon_speed_score_impact.avg(), dex_score_per_user = dex.score.value.avg()
| summarize Impact_of_logon_speed_on_technology_score = (logon_speed_score_impact_per_user.avg()*countif(logon_speed_score_impact_per_user != NULL))/countif(dex_score_per_user != NULL)

Compute the impact of the logon score on the DEX score for an entire population:

users
| include dex.scores during past 24h
| compute logon_speed_score_impact_per_user = endpoint.logon_speed_score_impact.avg(), DEX_score_per_user = value.avg()
| where DEX_score_per_user != NULL
| summarize total_logon_speed_score_impact = logon_speed_score_impact_per_user.avg()*countif(logon_speed_score_impact_per_user != NULL)/count()

Considerations

Timeframe associated with the dex.score table

• A user or device object without any data over the last 7 days will have no score.

• The score computed today at 00:00 UTC is associated with today's date, not yesterday's date.

This means that querying the dex.scores data with during past 7d is not correct, as this returns seven days of data points, and each data point is already a rolling window of 7 days. The data should be queried for only 1 day, for example

• dex.scores during past 24h

• dex.scores on 2023-10-30

Example:

users
| include dex.scores during past 24h
| compute software_reliability_score_per_user = endpoint.software_reliability_value.avg()

The daily computation of the scores starts at 00:00 UTC, but may take several hours to complete. Once the computation is finished, Nexthink tags the outcome with 04:00 UTC.

Timeframe associated with raw data tables

To compare raw metric tables, for example, session.logins, web.page_views with corresponding scores, the timeframe must mimic the one used in the DEX score computation:

00:00 UTC today - 7d to 00:00 UTC today

Ensure that your timeframe matches the timezone of your browser.

Example:

• Your browser timezone is CET (i.e., UTC + 1).

• You want to compare the raw metrics with the DEX score of 2024-01-17.

• You are interested in checking the page loads trends of Outlook.

web.page_views from 2024-01-10 01:00:00 to 2024-01-17 01:00:00
| where application.name == "outlook" and user.name == "TBD"
| summarize average_page_load_per_hour = page_load_time.overall.avg() by 1h

Hourly samples

The DEX scores take into account hourly samples of data. This data is either an average of a field or a sum of events over the past hour, depending on the metric type. To understand if a metric has breached the configured score thresholds, use hourly aggregation, not 5-minute or 15-minute time buckets.

Example:

Session.logins from 2024-01-10 01:00:00 to 2024-01-17 01:00:00
| summarize average_logon_time = time_until_desktop_is_visible.avg() by 1h

Computing DEX scores for populations

Computing the DEX scores of a population requires first computing the score of each employee and then averaging them across the entire population.

First, aggregate the DEX score per user or device and then for the population.

In this case, you should not start an NQL query with dex.scores during past 24h, but with the users or the devices table to compute individual scores. Use the summarize statement to compute the DEX score for the population.

Example:

users
| include dex.scores during past 24h
| compute dex_score_per_user = value.avg()
| summarize dex_score = dex_score_per_user.avg()

Looking at the right combination of user, device, and device dimensions

The system computes a score for a combination of user, device, and device dimensions such as geolocation, or location type. The rationale behind this approach is to enable advanced filtering on each employee context to extract insights.

This means employees who have changed their location during the last 7 days will have several scores for different geolocation or location types. Additionally, a device used by multiple employees will also have several scores.

To compare the raw metric with its corresponding score, you must:

1. Understand the different dimensions associated with the score data.

2. Apply the same dimensions when looking at the raw data.

Example:

device_performance.boots from 2024-01-31 01:00:00 to 2024-02-06 01:00:00
| where device.name == "TBD" and context.location.type == "Remote" and context.location.state == "Vaud"
| summarize average_boot_duration_per_hour = duration.avg() by 1h

Device events without an employee associated with the device

Some metrics used in the DEX score computation do not have any user association in the Nexthink data model, for example:

• device_performance.events

• device_performance.boots

• device_performance.hard_resets

• device_performance.system_crashes

• connectivity.events

The DEX score pipeline keeps a list of recent users on a device so that these events can be associated with these users’ DEX scores. If no recent users can be found on the device, these events will not be factored into the device’s DEX scores.

Employees working on multiple devices during the same hourly time bucket

The priority of the DEX score V3 data is to report on the user experience and highlight when it can be improved to deliver a proper Digital Employee Experience management solution. This implies that Nexthink accurately captures the user experience, but the data is approximated when projected on the device.

Suppose an employee is working on multiple devices simultaneously. In this case, Nexthink collects all the data received on the user object for the hourly time bucket, but we only associate one context, for example, device, geo-location, location type to the bucket. This means that the system associates the last context of the hour with the time bucket, extracting the last data message received for the hour.

Nexthink flags score events with a warning to inform users that the multi-device situation resulted in an approximation when associating a device with a score event. The field score_computation_approximation indicates whether an approximation related to the device or its context influenced the computation of the score. The possible values are:

• unknown: No information about any score computation approximation associated with the score event.

• none: No computation approximation was used in the computation of the score.

• multi_device: An approximation regarding the device associated with the score was made. This indicates that the score cannot be associated beyond the user.

• multi_context: An approximation regarding the device context associated with the score was made. This indicates that the score cannot be associated beyond the user and device.

Examples:

Should I be careful with any of my scores, as some hourly approximations were applied when computing it?

dex.scores during past 24h
| where device.name == "devicename"
| list score.time, score.value, device.name, device.entity, user.name, score_computation_approximation

How many devices have their score impacted by the multi-device situation?

dex.scores during past 24h
| summarize Number_device_impacted = device.name.countif(score_computation_approximation == multi_device )