Settings for respondent access: cookies and passwords

You can set cookies, limit access and set a password for the survey questionnaire by clicking on the 'EDIT' - 'Settings' - 'Respondents access' tab.

1) 'Cookie' is a code that is stored on the respondent’s computer by server-side (e.g. 1KA), so that the 1KA tool can authenticate a possible re-attempt of the respondent to fill out the survey. You can choose how long the cookie will be stored for. The following cookie options are available:

• 'Until the end of questionnaire', which means that the cookie is deleted as soon as the respondent finishes answering the survey. This is the default option and is highly recommended. There must be very good reasons to decide otherwise. On the one hand, cookies do not really prevent re-answering of the same person – which is usually the main reason for their use – because users can delete them, access the survey from other devices like another browser. On the other hand, the power of cookies pulls all the problems that are linked to European legislation (the user must agree, etc.). The greatest danger of cookies, however, is that a researcher accidentally makes it difficult to access the survey for users for whom this is not intended (eg. other user on the same computer, interfering with identification based on passwords).
• 'Until the end of the browser session', the cookie is deleted when the respondent closes the current browser (e.g. Internet Explorer, Mozilla Firefox, Opera, Chrome…). If, therefore, within the same session respondent returns he can be correct his answers. Warning: If in the same session after the first respondent another respondent enters a survey, the cookie from the first respondent is still saved and there will be trouble!
• 'For 1 hour', the cookie is deleted one hour after the respondent first clicked on the survey URL. Same warning as above (browser session).
• 'For 1 month', the cookie is deleted one month after the respondent first clicked on the survey. Same warning as above (browser session).

Choosing to have cookies stored for a longer period than just to until the end of the survey allows you to select what happens when the respondent returns to the survey:

• Start the survey from the beginning, in this case you would get double answers, since the previous entries of the respondent have already been stored in the database;
• Continue on the page where the respondent has left the survey, at the last submitted page, in which case the previous answers have already been stored in the database and the respondent only proceeds with the remaining questions.

For respondents that already completed the survey, you can provide with an option to re-edit their answers afterwards, thus changing the data and the analysis. Therefore, it is generally (but not always) better to mark the option that that respondents cannot re-edit their responses.

2) The 1KA tool also enables recognition of respondents; however, only for registered users of 1KA. There are two options available:

• 1KA recognize the person as a respondent, i.e. the person (registered in the system), which answers to your survey. Setting is suitable for internal administrative processes when for example members of the collective fulfill certain information (e.g. address, contact) and can always correct them;
• 1KA recognize the person as an enterer or interviewer who enters the answers, i.e. enters the answers of other people and in this context 1KA provides appropriate adjustments to the interface (see the Option Settings-Advanced modules-Administrative data input and Telephone survey). This option is especially useful in the event of mass entries or when you perform a field survey and then enterers enter the answers, so you can see who entered which answers. The same is true for the telephone survey.

The above examples are rare; the default option, of course, is that 1KA does not recognize the registered user of 1KA. Activation of this option could have serious consequences.

3) Limitation of IP number.

To ensure that the same person does not fill out a questionnaire more than once, you have the option to block IP addresses. You can block the IP for 10, 20 or 60 minutes or for 12 or 24 hours. However, this means that if multiple users use one computer, you can prevent another user to access the survey. This option makes sense only in rare cases, for example for voting, where there is a risk that someone fulfilled the survey using a script. Of course, IP restrictions can be outsmarted and shown as that the respondents come from some fake addresses. In general, this is a risky option that does not solve the problem, it generates a risk of preventing a large number of valid users to fulfill s survey. Namely, it is often the case that a whole organization or unit with a lot of computers and potential respondents have the same IP number. More >>

4) Access to survey with individual password.

Access to survey and identification of respondents can best be edited through passwords. To this end, each potential respondent is assigned with a password or code. Usually this code is then used in the email invitation, either automatically (in the URL of the survey) and the respondent is not required to enter it. Alternatively, you can request that the code be entered manually. Similarly, you can send them the code in a different way, for example via letter, and respondents re-type them. Using passwords is generally stronger and prevail over other settings to identify the respondents (cookie, IP number, identification of registered 1KA users), but interference can occur. Therefore, we strongly recommend that you use only one of the above mentioned methods for identifying respondents: cookie, IP number, identification of registered 1KA users or individual password.

You can create any number of passwords through which respondents will be able to access your survey. Password can be unified for all respondents, however you can send different passwords to respondents and thus separate them (e.g. by groups or organizations). A similar effect can be achieved by creating groups of respondents, where respondents are not asked for a password, because it is already implemented in the URL. In both cases, the base is, of course, uniform, but in both cases we cannot distinguish between respondents within a certain group, as we cannot connect identification data with the password.