Netigate Feedback allows you to send surveys to your users. Those responses will then flow to Netigate for analysis.

The typical flow of the feedback collection is as follow:

1. Company sends email to target end-users asking for user feedback.

2. The end-user clicks the Netigate Survey link in the email.

3. The end-user will be redirected to the Netigate Survey

4. The Netigate Survey reads the Survey Identifier from the URL and fetches the correct configuration.

5. The Netigate Survey is customized using the returned configuration.

6. The Netigate Survey is translated using the available languages.

7. Background variables (tags) are parsed.

8. The end-user writes open-ended feedback and clicks the 'Send' button.

9. The given score, open-ended feedback and background variables are sent to the Netigate Feedback API.

When redirecting the end-users to the Netigate Survey, the URL must contain a valid form identifier. Your identifier will be automatically generated when the link for your survey is created.

Each company can have multiple different form identifiers and configurations, therefore supporting multiple Netigate Surveys. For example, a company might want to ask different questions based on different end-user segments.

Here is an example of the Netigate Surveys URL:

Netigate Surveys can be used for collecting end-user feedback in multiple different languages. For example, the form can be displayed with English or Finnish translations, based on the user's preferred selection.

The language is defined in the URL as follows:

In the above example, the end of the URL has the l=0 param which means the survey will display its default language. The 0 would change to other identifiers for other languages that are active in the survey, and these identifiers would be survey specific. Below is the same survey, but using its Finnish language identifier:

If the language parameter is not defined, and there is only one language, that language will be displayed. If there are multiple languages, and the language param is not defined, the URL will reload to a page where the user can select their chosen language, and then the page will reload the URL with the selected language param defined.

Netigate Survey sets the date of the feedback automatically to the moment when the feedback is given.

Tags are background variables used for filtering the feedback in Netigate's service. Each response can have multiple tags, split into a tagName and a tagValue. For example, tagName Gender with and tagValue female or male. If these are sent attached to feedback, the tags can be used in Netigate to filter answers and calculate scores based on the respondent's gender.

Tag names and values must be a String, and the maximum length is 128 characters.

Tags can be passed to Netigate through the URL of the Netigate Survey.

Consider the following example:

The example above would add two tags to the given feedback:

Please note that:

It is possible to have multiple values for the same tag, in that case, each unique value should be sent separately as in the below example:

The example above would add one tagName with two tagValues to the given feedback:

Each imported feedback should have a unique identifier that can be used to identify the feedback in external systems, or to enrich the feedback with background variables in Netigate.

Using the Netigate Survey, the ExternalID is added as a tag through the URL of the survey, as in the example below. More can be read about tags above:

If you have a feedback in Netigate where ExternalID = 123, and you submit another feedback to Netigate with ExternalID = 123, the one currently in Netigate will be overwritten with the one you are sending.

Within your CRM, you are able to pass Replacement Tags (also known as Dynamic Variables, Dynamic Tags, Replacement Variables) directly into the URL of your survey. This allows you to send the following link to your customers through email:

The example above would add two tags to the given feedback:

The values for these tags are dynamic. Meaning, your CRM will send out a unique link to each customer, with the UserID and Region for that customer automatically updated to be the correct value associated with that customer.

The exact formatting for replacement tags changes per CRM. Applying them to your URL should be the same steps as if you were to apply "Hello {{firstname}}" in the header of the email. If you are struggling with applying them into your URL, please contact your CRM support team.

An example can be found below:

If tag names and/or values are sensitive, the name and/or value can be masked. For example, you might not want to show in the URL that this customer has customerType = Bronze. In that instance, you could use tag masking.

To use tag masking, just replace the sensitive values with whatever else you think is appropriate. So instead of the URL showing customerType = Bronze, you could instead put in the URL CT = B.

Then, once the feedback has been delivered to Netigate, we can manually mask that filter to display in the UI as customerType = Bronze. Its worth noting that masking is purely a visual change - the data you are sending and what we are storing in the database is CT = B, we are just making a visual change so that its easier to read in the UI by masking CT = B to instead be customerType = Bronze.

More about masking can be read from the Filters page.

Example:

In the above example CT=1 and CN=2 are values being passed through the URL, that the customer cannot identify, that will be masked once they reach Netigate.

The API response from the customer's API must contain the 'consumed'-parameter. The consumed-parameter is used for detecting if the user has already given feedback and if a 'thank you'-page should be displayed instead of the Netigate Survey.

So if

The consumed-parameter is used together with 'Notifications to Company's own API' feature to send notification of response to customers own API.

Typical use case for the consumed-parameter:

1. The end-user receives an email asking for feedback.

2. The end-user clicks the link in the email and is forwarded to the Netigate Survey.

3. The Survey fetches the background variables from the Company's own API.

4. The consumed-parameter is false, so the Netigate Survey will be displayed to the end-user.

5. The user fills the form and submits the feedback.

6. The Netigate Survey will send the data to Netigate's API and to the Company's own API ('Notifications to Company's own API').

7. The Company API sets the feedback as consumed.

8. The end-user clicks the link in the email again and will be redirected to the Netigate Survey.

9. The Netigate Survey will fetch the background variables from the Company's API.

10. The consumed-parameter is now true, so a 'thank you' page is displayed instead of the Netigate Survey.

📧 Do you have any questions or comments about using Netigate? Please don't hesitate to email Lumoa Support at [email protected].

​