Guide to unique links for web forms

This support article is a supplement to our core documentation on using custom links to pass information into forms.

When using web forms, it’s common to send out links to the form, especially if anonymous access (no need for SurveyCTO credentials) is turned on. However, there may still be times where you would like to track respondents by sending them a unique link. When you create a unique link, the field "caseid" in your form is given a value based on that unique link. That field value can be used to track respondents, check for duplicates, and several other situations.

To learn how to create and use unique links, skip to how to create unique links below.

Use cases for unique links

Here are a few use cases for the above web form data collection strategies. This list is by no means comprehensive, so use unique links as you see fit.

Tracking respondents

Unique URLs can be used for tracking respondents during longitudinal studies. Instead of sending a follow-up form where a respondent has to find and enter what their unique identifier was (which they may have lost, or can't remember), you can send them a unique link that has the identifier already included. That way, when they submit their form, you can use the "caseid" to compare their answers to the baseline survey answers.

Checking for duplicates

Unique URLs are also a great way to make sure a respondent does not complete a form more than once, and also make sure they are not sharing that link. If they have you just have to check if any submissions share a "caseid" value. Just make sure each link sent out ends in a different unique identifier.

Different relevant fields

Even though we refer to "unique identifiers", they do not have to be unique to each respondent. What you can do is divide respondents into groups, and then make certain fields relevant only if the respondent is a member of a certain group. For example, if only members of group 1 should answer a certain field, you can make their unique identifier "group1", and give that field this relevance expression:

${caseid} = 'group1'

Of course, "group1" is a somewhat generic group name. It is great for randomized groups, but you can also be more specific. For example, each respondent in the state of Haryana can have a unique identifier of "haryana", and fields meant only for them can have this relevance expression:

${caseid} = 'haryana'

You can also give each respondent a unique identifier, and then attach a server dataset or CSV file that shows which categories they are a part of. For example, let's say in the server dataset called "cases", the unique identifier column is called 'id', and the respondent's home state is in the column called 'state'. When that dataset is attached to the form, you can have a calculate field called "state" with this calculation to return the state of the respondent using their unique identifier:

Let's say a respondent has the unique identifier ("caseid") of 1001. In the server dataset called 'cases', if the row with the unique identifier ('id') of "1001" has a 'state' value is "Haryana", then the above field "state" will return "Haryana". Then, you can include a field that is only relevant when that respondent lives in the state of Haryana:

${state} = "Haryana"

That way, you can track individual respondents, and also make sure only certain fields will be relevant to certain respondents. You can even use this method to assign multiple categories to a respondent. In addition to "State", you may also want to ask certain questions based on occupation, family status, and even responses to fields in previous surveys. You could also ask about these in the form, but sometimes, it is easier to pre-load that data. To learn more, check out our documentation on pre-loading data into a form, as well as this webinar.

How to create unique links

In SurveyCTO forms, there is a field called "caseid" (if you created your form from the SurveyCTO server console, this will be automatically included). Usually, this is used for case management to store the ID of the case, but you can also use it to create unique URLs to track respondents.

If you created your form definition spreadsheet from scratch, make sure you include a caseid type field. In your form definition, simply add a field called "caseid" of type caseid.

For example, if you go to the Collect tab of your SurveyCTO console, and click on the Share button for one of your forms, a URL will appear that looks something like this:

https://SERVERNAME.surveycto.com/collect/FORM_ID?caseid=

Do you see how it ends with ?caseid=? You can add a unique code after that, and as per the product documentation, that code will be the value of the field "caseid". For example, let's say a respondent is sent this link:

https://example.surveycto.com/collect/example_form?caseid=123abc

When a respondent opens a form from that link, the value of the field "caseid" will be 123abc, and you will be able to see that when you go to export your data.

Preventing duplicates with form publishing

If you would like, you can use an attached dataset to prevent respondents from completing the form more than once. To set this up, create a server dataset that keeps track of which unique IDs have already been completed, and use dataset publishing to update the server dataset when a form is filled out.

For an example, check out the sample workflow in this folder; for help deploying it to your server to try it out, check out our support article on deploying form definitions and server datasets. Here is a brief overview of how it works:

The server dataset has two columns, 'id_key' and 'complete'. The 'id_key' column has a list of all unique IDs, and the 'complete' column has a value of 1 if a form for that unique ID has already been completed. The 'complete' column will have a blank value if it has not yet been completed.
The form has a calculate field called "get_completion" with this calculation:
```
pulldata('completion_check', 'complete', 'id_key', ${caseid})
```
That way, it retrieves the 'complete' value for that unique ID from the server dataset, so it checks if that unique ID has already been completed.
The form has a note field that is required and has this relevance expression:
```
${get_completion} = 1
```
That way, if "get_completion" has a value of 1, meaning that unique ID has already been completed, then the respondent will not be able to move forward.
The form has calculate field called "complete" with this simple calculation:
```
1
```
The form is set up to publish to the server dataset so:

The unique ID field "caseid" publishes to the unique ID column 'id_key'.
The calculate field "complete" (which always has a value of simply 1) publishes to the column also called 'complete'.
The Form field to identify unique records is "caseid".

Keep in mind that once a form is submitted, it may take up to five minutes for the server dataset to be updated.

Ensuring unique URLs are used

If you would like to take this a step further, you can add additional checks to make sure the case ID was not removed from the URL. For example, you can include a required note field with the relevance expression empty(${caseid}) with the label:

Warning: Please use the link you were given unmodified. Since you have already opened a version of the form, please open that link in an incognito/private browsing window. Thanks, we appreciate your participation!

Because SurveyCTO web forms use cookies to save a web form session ID, if a respondent opens a different unique URL to your form without completing the first form, the old "caseid" value will still be saved and used. This is why the example warning above mentions using an incognito/private browsing window, which does not use cookies.

Another way to ensure unique links are used is by branding your links. To learn more, check out our support article on branding your links.