After you publish a campaign, targeted employees start answering the campaign questions. Create Nexthink Query Language (NQL) investigations to see how employees interacted with the campaign and answered questions.
The results of campaigns triggered by remote actions are only available locally during the execution of a remote action screen. Consequently, remote action campaigns have no response data available on the Campaign details page.
Viewing the results of a campaign in Investigations
Select Campaigns from the main menu.
Select a campaign listed in the navigation panel to view more details. The navigation panel shows published and retired campaigns.
Select Campaign overview from the navigation panel to view all published and retired campaigns and their statistics.
Refer to the Getting started with Campaigns documentation for more information.
On the Campaigns details page, click on the action menu at the top right corner of the page and select Investigate to open the Investigations page with a prewritten query to generate results for campaign responses, including:
Response state and state details.
Answers to each question and free-text comments where applicable.
Values of the parameters in case the campaign is parametric.
On the Investigations page, you can refine the NQL query to adjust the columns or filter the results according to your requirements.
Querying campaign information and results with NQL
Using NQL, you can access key information regarding your campaign and their responses querying the following tables:
campaign.campaignscontains the basic information about all campaigns with a published or retired state.
campaign.responsescontains details of every campaign response, given or expected. Use it when you need to gather statistics across campaigns but do not need to inspect campaign-specific data, such as answers to questions or parameter values.
For each campaign (after the campaign is published), a dynamic table
campaign.nql_id_of_the_campaign.responsesis available to inspect the responses of that particular campaign, for example,
campaign.dex_score_campaign.responses. In addition to the fields available in the table
campaign.responses, the dynamic data model table of a campaign includes fields with answers to each question and, if the campaign is parametric, values of each parameter.
Refer to the NQL data model page for the full list of fields.
If a user is targeted several times by the same campaign, then each occurrence corresponds to a different response. If you need to access only the last answer of a user to a campaign, you can leverage the
last NQL operator. Refer to the NQL syntax for details and the query examples.
Inspecting answers and parameters using the dynamic data model
The dynamic data model provides fields per question to gather details about the employees' answers. The question identifier NQL uses corresponds to the question ID defined in the campaign. When using Campaigns (Classic), the question identifiers are based on the question order, for example,
The available fields correspond to the type of question:
For single-answer questions, you can get the answer label the employee selected using
For multiple-answer questions, you can get the list of the answer labels selected by the employee using
For opinion scale questions, you can get the answer label the employee selected using
answers.question_id.labeland its associated value with
answers.question_id.value. The value is the name of the answer selected, followed by the numerical value attributed to the answer between parentheses.
For NPS questions, you can get the details of the selected choice in different ways using
answers.question_id.value(numeric values from 0 to 10),
answers.question_id.category(either promoter, passive, or detractor) and
answers.question_id.label(ranging from detractor with 0 to promoter with 10).
In addition, for all question types, you can access the optional free text comment using
answers.question_id.comment and know the question type using
For parametric campaigns, you can access the value of the parameters specified at the time of triggering the campaign, using
The state of a response informs about the delivery status of the campaign, the employee interactions with it, and the employee answers to the campaign question. The field
state_details in the
responses tables reflect the current state of a response. The historized state information is available using the
Find below the details of the different states for a response.
The employee was online on a device at the time the campaign was triggered, and the campaign is ready to be displayed as soon as the employee’s device is able to do so, taking into consideration the employee protection rules.
The state details field is not applicable in this case, as there are no variations for this state.
The employee was offline at the time the campaign was triggered.
The campaign has not been delivered yet because it arrived during an interval that protects the user from bursts of campaigns (DNDP, NNPP). The employee receives the campaign once the protection period has elapsed.
The user clicked the remind me later option to postpone the campaign The default reminder frequency is twice a day.
The user has been presented with the campaign, in a semi-collapsed way or fully open, depending on the content size of the first question.
The user was presented with a campaign and opened it from a semi-collapsed state, meaning the user saw the first question in full. When the question appears non-collapsed, the state directly updates from notified to the opened one.
The employee declined to answer. The state details field is not applicable in that case, as there are no variations for this state.
The employee only answered part of the questions.
The employee answered all the questions.
Event canceled by scheduler rules for a technical reason, such as the employee or device no longer exists.
User not found
The system is not able to find the employee associated with the SID provided.
The request targeting the employee was sent and not answered or declined within the standard expiry time.
Requests expire by default after one year. The expiration can only be modified when triggering campaigns using the API.
The employee already has a pending response for the same campaign (not answered nor declined yet) and, in case of a parametric campaign, with the same parameter values, when re-targeted manually or via API. The system canceled the request to avoid double notifications.
The campaign is retired and the response was not in a final state (answered, declined or cancelled).
The state details field is not applicable in that case, as there are no variations for this state.
The campaign did not target the employee or the employee did not receive the notification, either because of problems communicating with the employee’s device or because the device is turned off. The state details field is not applicable in this case, as there are no variations for that state.